Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Maybe the term "rockstar" is where the trouble lies. Because, I don't know about you guys, but when I think rockstar, I don't necessarily think about virtuoso performers capable of creating masterful artwork. I usually think about burning out by their 30's, trashing hotel rooms, refusing to work because the mic settings are incorrect.

I think what everyone's trying to get at is, "consummate professional devoted to their field." The sort of person who, in an academic setting, might obtain a PhD and publish, or at the very least an engineer who reads technical journals and contributes, either to newsletters or publications, or as a member of a professional society; someone who considers personal improvement necessary to do their job as best they can. I think even if you're looking to hire someone to work on your CRUD PHP webapp, that's the sort of attitude you need, regardless of their actual experience.



I fully agree.

Further I'd argue that even for your CRUD PHP webapp you ideally want the guy who, first thing, explains to you why doing it in PHP is a bad idea and how he'll do it with a more powerful tool in a day - rather than the guy who will just nod and then go off to blindly beat "something" into shape in a week.

Both candidates will deliver the first iteration of your "simplest thing that could possibly..." within a reasonable timeframe. But their respective effectiveness will diverge dramatically starting from the second iteration...


> you ideally want the guy who, first thing, explains to you why doing it in PHP is a bad idea and how he'll do it with a more powerful tool in a day

No, you don't. The last thing you need on a team is a person who's first thing is to start whining about things that cannot be changed. That kind of thing can quickly spoil the atmosphere. Rather, you want the person that accepts that things aren't perfect and use the strengths of the situation and works around the weaknesses. He'll need to do that anyway, even if you use the best "language du jour"...

Not accepting the weaknesses just leads to constantly chasing the perfect state while never completing the project.


No, you don't. The last thing you need on a team is a person who's first thing is to start whining about things that cannot be changed.

Depends on what phase your project is in. You can't start with a mediocre team and later try to hire rockstars. It can sometimes work the other way round, though.

A complete change of platform is obviously not something a real rockstar would suggest when invited to a large, existing codebase. Much rather will he recognize a lost cause when he sees it and just politely decline.

Note how I referred to the first iteration in my parent comment. I was aiming at the bootstrap phase of a startup where the initial choice between hiring a veteran for real stake or "going cheap" happens. Many people don't realize the consequences of "going cheap" at that point.


Yes, I love to hire a guy who's first priority is to tell me why I am wrong. ;)


You must be really good at differentiating that which cannot be changed from that which is ingrained.


If I have a code base of over a few thousands lines (yes, even when that small), changing the language is just a dumb thing to do. It requires a complete rewrite, while changing a language that your team has experience in for one it doesn't. And of course, the usual rewrite problems also apply: killing a fully battle-tested system in favor of one that has not even seen a strong discussion...

And all that because one new hire couldn't get to grips with the fact that the organization didn't use his favorite language.


Problem is a young hacker with no formal experience (but who is nonetheless bright and talented), won't have the leverage to sell the higher-ups on using a more powerful technology.


That's why the higher-ups need to be open to disagreement and be able make decisions based on information. At the same time, the young hacker should have enough communication skills to be able to convince the higher-ups that it is in their interest to use a new technology. The higher-ups should be able to convince him why that may not work, either for tech or business reasons.

Seems there are a lot of "shoulds" in there but that's why management isn't easy.


Just do it - on the side - and then sell it.


No doubt. To continue the analogy, I usually want some guy who's played a hundred gigs, with all kinds of different musical styles, and is going to be focused on doing his part well so he can go home early.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: