4 ms·
> 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 d
by lucumo 17y ago
> 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.
- BrandonWatson 17y agoYes, I love to hire a guy who's first priority is to tell me why I am wrong. ;)
- DannoHung 17y agoYou must be really good at differentiating that which cannot be changed from that which is ingrained.
- lucumo 17y agoIf 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.
- moe 17y agoNo, 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.