Recruiting and Retaining Giants [pdf](alexstjohn.com)
alexstjohn.com
Recruiting and Retaining Giants [pdf]
http://www.alexstjohn.com/WP/download/Recruiting%20Giants.pdf
9 comments
> Was this seriously a talk that was given somewhere?
Looks like it: http://www.alexstjohn.com/WP/2014/07/16/recruiting-giants-pr...
> Do people actually accept this as actionable advice?
Hopefully not, it's actually a bit shocking anyone in 2016 would write/present things like "RULE 1: You don’t recruit and retain male engineers you recruit and retain Wives and Girlfriends" or "Real engineers don’t burn out until their wives or GF’s do."
Looks like it: http://www.alexstjohn.com/WP/2014/07/16/recruiting-giants-pr...
> Do people actually accept this as actionable advice?
Hopefully not, it's actually a bit shocking anyone in 2016 would write/present things like "RULE 1: You don’t recruit and retain male engineers you recruit and retain Wives and Girlfriends" or "Real engineers don’t burn out until their wives or GF’s do."
"Then slot in a new kid."
I hope the kids today have better offers and don't fall for this kind of rot.
I hope the kids today have better offers and don't fall for this kind of rot.
It indeed reads like chauvinistic bullshit, but I think there is a lot of truth in there, especially for small/fast paced companies (like startups or game developers):
* compassionate engineers are most happy when then can do engineering, money is secondary to them
* unexpected bonuses are usually the only way a dev's partner can see that what (s)he is doing has some actual value (though banning someone who worked 80h/week for 2 months from office for a week so (s)he can spend time with the partner is, imho, just as good)
* the 5:1 ratio of "old goats" (or "wise hackers") and youngsters is good, imho. the experienced dev will put in 40h/week and go home unless really necessary, the youngsters have enough energy for 80h/week and are naive enough to think they know everything and will learn a lot by failing (and accomplish a lot by having the naivety/balls to just try things and hack on them until they are "good enough")
* hiring devs with asperger: Sounds evil, but I have some friends with very strong asperger who are remarkable devs and, if given the opportunity, deliver awesome code/solutions and be really happy about it.
* the "useless"/wage slaves: I think this statement is true in fast paced environments - and only there. In big shops those are the folks who keep everything running. But neither startups nor game shops need much maintenance, they need brilliant innovation and the willingness to do the 80h/week.
* the "educated idiot" - yes, I know a smart, well-educated guy who failed google's interview a decade ago because he knew the academically sound answer but not the hacker-style "well, of course, you parallelize like this, then aggregate like - you just need a few thousand of boxes to actually do this". Of course he was right, but if google had listened to guys like him they would never be where they are now.
Overall, the tone of the talk is despicable, but the advise is sound - at least it reflects my own experience pretty well.
* compassionate engineers are most happy when then can do engineering, money is secondary to them
* unexpected bonuses are usually the only way a dev's partner can see that what (s)he is doing has some actual value (though banning someone who worked 80h/week for 2 months from office for a week so (s)he can spend time with the partner is, imho, just as good)
* the 5:1 ratio of "old goats" (or "wise hackers") and youngsters is good, imho. the experienced dev will put in 40h/week and go home unless really necessary, the youngsters have enough energy for 80h/week and are naive enough to think they know everything and will learn a lot by failing (and accomplish a lot by having the naivety/balls to just try things and hack on them until they are "good enough")
* hiring devs with asperger: Sounds evil, but I have some friends with very strong asperger who are remarkable devs and, if given the opportunity, deliver awesome code/solutions and be really happy about it.
* the "useless"/wage slaves: I think this statement is true in fast paced environments - and only there. In big shops those are the folks who keep everything running. But neither startups nor game shops need much maintenance, they need brilliant innovation and the willingness to do the 80h/week.
* the "educated idiot" - yes, I know a smart, well-educated guy who failed google's interview a decade ago because he knew the academically sound answer but not the hacker-style "well, of course, you parallelize like this, then aggregate like - you just need a few thousand of boxes to actually do this". Of course he was right, but if google had listened to guys like him they would never be where they are now.
Overall, the tone of the talk is despicable, but the advise is sound - at least it reflects my own experience pretty well.
> * compassionate engineers are most happy when then can do engineering, money is secondary to them
This has been stretched too far. Remember, if they are even remotely good, they will know their value. Engineering is what engineers do, that's the basic requirement. Without healthy compensation, good luck retaining. They can always be more compassionate towards hobby projects or open source.
This has been stretched too far. Remember, if they are even remotely good, they will know their value. Engineering is what engineers do, that's the basic requirement. Without healthy compensation, good luck retaining. They can always be more compassionate towards hobby projects or open source.
Agreed, but I kept my response short. In my experience, a good environment is more important than monetary compensation: Keep them away from bullshit-meetings, give them slack wrt working hours (they'll work more than you pay for anyway) - or abstractly: make their working environment as nice as possible, surpassing what they could have when working for hobby projects.
As stated in my initial post: I do have serious problems with the tone of the original talk and I think it desperately needs an update by someone who is not trapped in the seventies. But still, the overall advice is sound, imho.
As stated in my initial post: I do have serious problems with the tone of the original talk and I think it desperately needs an update by someone who is not trapped in the seventies. But still, the overall advice is sound, imho.
Also, maybe there aren't many female engineers because they have to encounter misogynist garbage like this on a daily basis. Maybe that's why they keep leaving the industry and not because you can't identify them.
This is the dumbest shit I've ever seen on Hacker News. And I still remember the guy who made an app to measure his heart rate while dunking his head in ice water.
You're making our industry a terrible place to live and giving decent people a bad name. Please stop.
You're making our industry a terrible place to live and giving decent people a bad name. Please stop.
I hope this isn't directed at me -I posted the article cos I couldn't believe someone would actually think this is advice. It's so horrible I wasn't even sure it wasn't just really poorly done sarcasm.
There is a lot of stereotyping in this article.
Lots of assumptions about how developers date, marry, number of kids and what their wife income is. Wives work too, this is not 1800.
The open source world is not a world of autism. I've attended many presentations by successful open source project members and in most cases they're excellent and effective communicators. Many open source organizations are heavily social and cohesive in nature.
In my case the traits I see in mediocre people are:
- heavily materialistic
- focused solely on some getting promoted and compensated (e.g: being liked by managers, shipping incomplete features, taking credit for everything, repeating buzzwords) instead actually pursuing quality
- stopped learning after college. can do programming puzzles perfectly but keep reinventing the wheel and coming up with bizarre solutions
Lots of assumptions about how developers date, marry, number of kids and what their wife income is. Wives work too, this is not 1800.
The open source world is not a world of autism. I've attended many presentations by successful open source project members and in most cases they're excellent and effective communicators. Many open source organizations are heavily social and cohesive in nature.
In my case the traits I see in mediocre people are:
- heavily materialistic
- focused solely on some getting promoted and compensated (e.g: being liked by managers, shipping incomplete features, taking credit for everything, repeating buzzwords) instead actually pursuing quality
- stopped learning after college. can do programming puzzles perfectly but keep reinventing the wheel and coming up with bizarre solutions
I wish this were a joke.
I closed this at the girlfriend slide. Flag this crap ASAP.
You lost me at rule #1 - "You don’t recruit and retain male engineers you recruit and retain Wives and Girlfriends".
Hot, I give this fantasy 10/10
I would love to know the context of this. Was this seriously a talk that was given somewhere? Do people actually accept this as actionable advice?
It's a little unnerving to me.