Most importantly, not every project (nor startup, nor business) needs "the very best" engineers. Not every startup is changing the world, and even among the ones that are I'm sure you can pick out a few that aren't solving massively complex technical challenges that will be discussed in lecture halls for decades. The majority of good startups are just making money (sometimes not even that) until they get acquired.
Secondly, you're assuming that the best developers are going to be more introverted than the developer culture/profession as a whole, which I don't think is accurate.
> Most importantly, not every project (nor startup, nor business) needs "the very best" engineers.
This is highly underrated wisdom.
If you focus on always hiring "Rockstar developers," you'll find yourself in a miserable situation of competition and egotistical conflict. Hire your team, not your developers. Get your team working like clockwork with good systems and good relationships, and your company will be rockstar with whatever people you throw at it. Look at github, stripe, twitter, facebook—you think they only hire the absolute best developers? No, they have a top 2% just like you will—your goal should be to increase the competence of your entire company, not just ignorantly hire the best and fire the worst and hope for the best.
Spot on.
You're right about the other assumptions too (though the parent may not have been that serious about them). IMHO stereotyping introverts or extroverts as being better or worse at certain tasks is a huge --ism to avoid, especially in our field. I see 'extrovertists' and 'introvertists' battle it out all the time with their propaganda and ignorant beliefs about people, and no one wins.
It's far better and more productive to be a humanist and find a good balance. Both extroverts and introverts can be valuable to your team; both extroverts and introverts can be great programmers and workers. You should strive to hire a mix, or stop using it as a metric and naturally get a mix, since these traits like many others generally fall on a normal distribution.
Don't trust your assumptions about yourself, and don't apply them to others. They're probably wrong.
Totally agree - imagine you could hire Linux Torvalds. He is a great programmer but his best work was sending emails to others for 12 years.
This leads to an interesting thought - if you hired Linus and he started spending all his time emailing sarcastic notes to the other developers, how quickly would he get fired for "not focusing on developing code"?
Perhaps the key for CEOs is not to grow culture but to hire people who will grow it for you. You dont get to choose the culture, or even direct it. The funny Finnish bloke will.
You just pay him.
... and also he created the kernel, and a way to manage its development better.
I don't see the problem. People who make cool stuff and solve problems in their spare time are the ones you want working for you. Even if they waste time sometimes going off on tangents, it's probably honing their skills and improving something relevant to your company or their own work abilities. No problem, you want that. Trust them to do the right thing.
Exactly. This is where having good engineering leadership can come in. A "mediocre"* developer can often be coaxed into producing great product with a little support from things like paired programing and code reviews. You'll probably increase his/her value and abilities in the process.
So you need your lead to be awesome. But the rest can just be good people who know how to code.
* this would be someone who may not fully grasp all the concepts and sometimes writes bad code, but is open to learn and listen. There are developers who write bad code and are arrogant/confrontational about their abilities. Those should be identified and fired as quickly as possible. They will sink your ship.
The problem here is that the awesome lead will not stay long in a company where all other people are mediocre. Awesome people want to work with other awesome people. There should be a critical mass of them to keep them from leaving.
This is relatively true, but at a small company (< 5 programmers) some people do like the role of "lead" and will stay with it as long as the people they work with aren't total idiots.
> Secondly, you're assuming that the best developers are going to be more introverted than the developer culture/profession as a whole, which I don't think is accurate.
I don't think that's the assumption at all. My personal experience is, unless you happen to be located where one of the "best" developers is, they simply won't move. So you have your choice of them working remotely, being lucky, or not hiring them.
> Whenever I've seen this done, the very best employees leave.
I took this to mean (a) be relative to the office specifically, not the industry generally, and (b) that those very best will get sick of the required face time, quit, and get a better job (the insinuation being that that better job will likely be majority or entirely telecommuting. I may have misunderstood the intent as I commented pretty much immediately after reading it.
I believe the point was that people detest that working environment, and those with a choice will pull the ripcord, whereas people who can't get another job will stay. I've seen that happen.
I just generalized it to my experience, which is less about introvert/extravert and more about "bad conditions force good people out/prevent good people from being hired"
> ... favors your more extroverted engineers. My experience has been the engineers I really want to keep, the ones who solve the really hard problems, are much less likely to be in that group.
I, too, read "group" as "extroverted engineers," and I don't really see alternative readings.
I don't think extroverted helps in a disruptive team war room. Most "collaboration" is someone interrupting to ask a question they could have asked in email and waited for an answer.
This sort of thing is the thing I'd love to see more evidence about.
Getting interrupted kills my flow. I'm less productive as I get back into flow (although I have techniques now that let me get into flow much quicker - but that's a separate post).
However - is that drop in productivity outweighed by the increase in productivity of the interuptee not having to wait / switch tasks / fumble on and make a mistake / build the wrong thing / etc.
Times when I've been put in a war room were absolutely infuriating for me, but the tighter loops in bringing people in on what you're doing got the "why not just do X" questions answered much faster. As much as I disliked the interruption, I'm more thankful for all the code that didn't get written because we talked it over first.
If I were to estimate, this probably doubled efficacy of our junior devs while halving the (direct) productivity of senior folks. In my cases, it was immediately apparent that we came out ahead: the former outnumbered the latter by several times.
This pretty much matches my experiences. I went from a sceptic to a believer in co-located team rooms after seeing this a few times.
Did you also see the incidence of "bad" interruptions drop as the team got more experienced? That's what I've seen pretty much every time I've worked in this sort of environment.
> If I were to estimate, this probably doubled efficacy of our junior devs while halving the (direct) productivity of senior folks. In my cases, it was immediately apparent that we came out ahead: the former outnumbered the latter by several times.
I really like this. I consider myself an intermediate developer, and can't even count the times a 5-10 minute conversation would have saved me an entire day - or week! - of wasted effort. I think this is easily overlooked because its not totally obvious that interrupting a highly productive, highly skilled developer could result in higher team productivity.
Generally I think about flow in terms of setting up intermittent reward cycles where I need to put in a little bit of effort, but not too much, to get the reward.
So I think about ways I get get back into those cycles quickly. To do that I try and cut up my work into the right size chunks, have a plan, and leave work with an "easy win" so I can get back into the loop again quickly.
Some examples. Hopefully I'm not descending too far into life-hacker wankery here ;-)
* I TDD code, and always try and leave myself with a failing test. If I'm interrupted and don't have a failing test I will deliberately break something or hit undo enough times to get a fail so I have an easy win when I get back.
* I don't track time on task. I do block out time for tasks - and track non-relevant interruptions during that time and see if there are ways to stop 'em happening.
* I run a personal kanban board for stuff so I can keep that continual ping of reward happening during the day.
* I breakdown tasks as they come in so they I can get little reward pings on a regular basis.
* When I have real problems getting into flow I give myself automatic rewards (do 20m on X then you can do 5m of fun on Y). Similar to http://en.wikipedia.org/wiki/Pomodoro_Technique. Once I get started the normal task-achievements often mean I don't actually end up doing Y - it's just a personal hack to get me started.
Basically - fake the reward cycle until the real one takes hold.
The reward technique never works with me. Because, to me, there is not 5m doing something fun. I cannot have something really fun in 5m. So I rather finish all the things in limit time and enjoy the rest of the day, it's the biggest motivation.
My only work solution to get back to the flow quickly is leaving something undone. Depend on which task, it will have different ways.
Btw, I really love the idea of leaving failing test :D
Secondly, you're assuming that the best developers are going to be more introverted than the developer culture/profession as a whole, which I don't think is accurate.