Hiring Great Developers?
Stop whatever it is you’re doing. There’s a new buzz in town.
In our ultra-dynamic industry, yesterday’s Holy Grail is today’s old news. A couple of days ago I wrote about Googlism as the new emerging religion, and what do you know, I’ve just discovered the signs of a new one, already creeping into blogs, articles, and eventually management meetings.
This time we have really found the answer to our collective prayers. The age of looking for the perfect development process might be coming to an end. After years of trial and error, many now see that the quest for the ultimate process is futile. But none of the problems we are facing was actually solved. So, people are thinking, we must look elsewhere.
And thus, after years of Agilism – the people-oriented hi-tech-religion – our industry managed to take the next step and mark its own people as the source of all the world’s problems. And we naively thought the process was bad. Silly us. No, no, no: it’s we, the people, who cause all the trouble.
It started with Joel Spolsky’s article about the quest for Finding Great Developers. Joel didn’t say it explicitly. He just wanted to help you hire the best people for your company. Nothing wrong with that. Then, about a month later, came the by-now-already-classic-article by Steve Yegge, describing Google’s development dynamics. Steve hid it well in his text, but the message was clear (judging from many of the comments to Steve’s article): the secret to great software development is having great software developers.
This kind of message could have been great. The key to success in our business is having a team of true professionals. But Joel’s article, and in a sense also Steve’s article, offered the easy solution: if you want a team of professionals, just go a head and hire the best ones on the market.
Now, imagine your CEO reading these articles and all the fuss around them. “Great!” he says to himself, “all we have to do in order to improve things around here is to hire better developers than the ones we have. We have tried everything else, so THEY must be the source of the problem”. And thus, a new silver bullet was born. And this time it can be really deadly.
People are the key to great software development. Having a professional team is the only (yes, the ONLY) thing that can help a company succeed in the long run. But there is no way in the world that prodigies can fill 100% of the industry’s open positions. And what are you going to do with your existing developers? Fire most of them and spend your time in conferences to get your hands on the next David Heinemeier Hansson? Great plan!
People are the key to great software development. But people are not a commodity. They are… well, people. If you want a team of professionals, you can have one. But the only way to have more positions manned by professionals is to grow more professionals.
There will always be prodigies – people with natural talent who have it all figured out the moment they touch a keyboard. But the rest of us can still be highly qualified professionals. At least most of us can. But just as in any other profession, to become a true professional you need guidance and mentoring.
Dear CEO, if you think the root of your problems lies in not having “the best” developers, ask yourself what have you done to make your developers better. Did you provide them with mentoring? Did you take it upon yourself to nurture them for their sake as well as for your company’s sake? Do you truly believe they can become professionals? Do you tell them that?
My father always said that money doesn’t grow on trees. Well, professionals don’t either. You have to work hard to grow professionals. “That’s not my job,” you might think to yourself. But the fact is you have everything to gain from nurturing your people. Your homegrown professionals will be better for your company. They will be more loyal. They will feel more committed to their workplace and to a shared vision. They will know they are treated not only as professionals, but also as humans. They will help you grow just as you helped them.
Sure, you can hire a couple of prodigies. But without nurturing professionalism as a key strategy, your prodigies will soon find better place to work for. A place with more people like them. A company truly committed to professionalism. A company willing not only to pay for professionalism, but also to work for it.
So, here’s the revised plan:
1. Find your best developers. They might be hiding in their cubicles, or merely too busy to be noticed. But they are there.
2. Reinforce them with some additional committed professionals. You can “shop around”. That’s OK. Just don’t think of them as replacement to your existing developers.
3. Provide mentoring for the rest. Give your best developers anything they need in order to create an extensive mentoring program to help the rest of your developers gain guided experience and develop their skills.
No, the change won’t happen overnight. Mentoring is a process, and professionalism is not built in a one-week workshop. But if you are really committed to professionalism and you chose the right platforms for mentoring, you will start to see the fruits in no time.
So, maybe professionals, unlike money, do grow on trees. But as any gardener knows, growing trees requires hard work, commitment, and patience. You can always get some fruits on your local grocery store, but they will only help you get through the next meal.
***
Followup: The Good, The Great, And The Better
And see also: The Root Of The Matter
October 2nd, 2006 at 5:17 am
I disagree entirely.
This is a mistake most people make. One so common that it’s become common practice now.
Every developer should be cuddled because they’re all so yummy good. Every one of them is perfectly capable of doing the job.
No!
Writing good code is hard. It’s an art and it takes a lot of skill, both in terms of natural ability and knowledge (CS and math (loads of math!)).
Most people do not have this. They should not be writing software.
You need to start by firing these people; along with any idiotic manager (most managers fall under this category.
The revised plan should be, find your good developers (it’s easy, look for the disgruntled ones). Get more of them. Fire the bad ones. Hire not above the average; hire only the best.
Get rid of the idea that everyone can write code. Get rid of the idea that it’s easy. That it should be easy, that languages should be easy to learn.
October 2nd, 2006 at 5:40 am
Hmm, lots of math! For writing run of the mill applications?
October 2nd, 2006 at 6:03 am
Anon: do you really think that nobody can ever become any better at anything? Because that’s the message your post is sending - that there’s no point trying to improve your skill in any area, because you’ve either got it or you haven’t, and the likelihood is that you haven’t… Frankly, if we followed your suggestions, we might as well give up on computers altogether; after all, nobody can program perfectly - everybody introduces bugs.
Fortunately, it is now generally recognised that no amount of natural talent can make up for being taught by an expert and practice in the field. Writing code is not easy, but then neither is any skill worth possessing. That’s why it has to be taught and practised. Just like playing a violin - some people have more natural aptitude than others, but everyone has to get past the strangled-cats stage; the more able simply do so more quickly, but they still have to be taught and mentored until they have mastered the instrument.
(On the other hand, your tone suggests that perhaps the wondrous experience of work lies in your future, rather than your present. No doubt your outlook will change as you mature.)
October 2nd, 2006 at 6:07 am
http://weblog.raganwald.com/2006/10/three-questions-and-three-answers.html
October 2nd, 2006 at 6:30 am
I work with several people with varying skill levels. Some of my colleagues and friends are exceptionally skilled. Others have a great deal of experience but are pretty solidly in the place they want to be and tend to reject change. Still others are new or inexperienced with great untapped potential, unmitigated enthusiasm, and unchecked arrogance. My colleagues that have had the greatest success and innate skill seem to cultivate a culture of meritocracy.
It is silly to question the value of skill and experience when they lead to growth and adaptation, but I don’t believe meritocracy can necessarily succeed unbound outside of a vacuum, particularly where there is financial pressure as in a business. Meritocracy has greater success in academia where there is less obvious economic pressure. Given that, what choices remain but to cultivate the skills of the individuals that you have and periodically assess and remove those that do not demonstrate adaptation and growth?
October 2nd, 2006 at 6:38 am
Anon: What type of software are you working on?
October 2nd, 2006 at 8:30 am
Be careful what you wish for.
Sorry to play devil’s advocate but come here to Japan where the TOP salary for a programmer is around $50k a year.
Why is it this way? Because Japanese companies do nothing but GROW developers. Does that mean there are thousands of amazing developers? Well, no. What it means is that Japanese companies do not hire talent, they hire college students and train them. Because they start with no skills they get paid nothing.
Now, before some western college student gets pissed off I’m not dissing western college students. But, (and you can verify this on the net), Japanese colleges do not teach programming. Most of my co-workers never programmed in college.
The Japanese education system works where you cram like crazy through high school. If you are at the top of your class you get into a famous college and then party for a couple of years. That fact that you got into a famous college means the company you want to work for will hire you.
The result though is they can pay shit because you come with no real experience. Instead of a system like the west where the best *generally* get rewarded for their skills, in Japan they company grows you so they can pay you next to nothing forever. Don’t like it? Fine, leave and they’ll find someone else to train.
Of course from a business perspective that might be great. The average price of programmers goes down. That’s what you want right?
(ps: I still haven’t figure out why market forces don’t fix that here. It seems to be partly cultural. People don’t quit, there is almost no headhunting for anything but execs, People still believe in one job for life, so effectively there’s no market forces in Japan where the talnet follows the money)
October 2nd, 2006 at 9:56 am
I still think that hiring top talent is the most important thing at the end.
In all the companies I worked in, you could grow professionalism all you want – but some people fruited only with stupidity, so to speak.
Let’s be realistic – there are really some bad, bad people out there!
October 2nd, 2006 at 11:13 am
Lidor, you are right. Consider a brief analogy: If you want to be a carpenter, don’t think you can just go out and buy the most expensive power saw and drill and somehow that this will make you a great carpenter. No, you have to learn the principles of great carpentry and apply them. A great carpenter can do wonderful work with a hand saw, a manual drill, and a screwdriver. But he also knows how to use the fancy tools to improve his work. But if you want to become a great carpenter, the first thing you have to do is to sit at the feet of a great carpenter.
Similarly, process is a tool of software development. A great software developer can do good work within any process that works. And the first thing you have to do to become a great software developer is to sit at the feet of a great software developer. Unfortunately, many development shops discourage this. And then, to add injury to insult, they put shackles on their best developers to keep those developers from doing their best work. And then they wonder why things are so bad. And they think that maybe if they just buy the latest, whizziest circular saw or power drill, or maybe if they just hire better carpenters (and then tell them not to drill there), that somehow things will magically get better.
One more note: Most of the time, these shops have the answers to their dilemmas right in front of them. But they choose not to listen. Hiring new people or buying new tools or processes is easy: It’s just money. But listening and changing is hard.
-TimK
October 2nd, 2006 at 11:19 am
[…] It’s the people stupid. Lidor Wyssocky: “And thus, after years of Agilism – the people-oriented hi-tech-religion – our industry managed to take the next step and mark its own people as the source of all the world’s problems.” I have to agree, hiring is not the only way to make a better development team. A company can do a lot to help its people grow better, give people the tools to shine. Hint: it’s not the methodology or the IDE. For the reverse corollary, read Raganwald: “In plain English, they don’t just force their “A” programmers to use a “C” programming language, but they tell them to write software that they think a “C” would be comfortable maintaining.” […]
October 2nd, 2006 at 12:18 pm
I can’t disagree more.
Would a symphony orchestra take on someone that can’t play the violin and say “We can train them”?
Would a restaurant keep a sub-standard chef around and work through things by mentoring him?
Hell no, and neither should your software business. If someone in your organization isn’t competant and can’t cut it, then they need to be shown the door.
Now, is there a place for less-experienced people with lots of potential to come in an grow. Absolutely.
However, there is no excuse for not performing. Cut ‘em loose.
October 2nd, 2006 at 5:20 pm
“Find your best developers. They might be hiding in their cubicles, or merely too busy to be noticed. But they are there.”
Disagree, the best developers would already have been noticed. If you’re trying hard to find the best developers, then chances are that the best developers aren’t really all that good.
In general I find the revised plan too “soft”. In a fast paced environment, poor developers can really bring the team down. And quite honestly I don’t think its that hard distinguishing a junior developer with aptitude and an “old fart” (to speak metaphorically) with no inclination to learn more or the fire in the belly.
My plan would be :
1) to have a rigorous interview process. Its too expensive to get a poor developer on board and getting rid of him even harder.
2) have compensations higher than the market rate even if that means hiring less developers. Good developers have a good demand and you’re not going to get lucky finding a star for sub par compensations. You get what you pay for. This is often not recognized by managers but 1 strong developer can easily be more productive than 3 average or below average developers. Plus you also have to consider that the smart developer will make the right architectural choices compared to a poor technical choice made by a lesser developer which will turn out more expensive to the company in the long run.
October 2nd, 2006 at 6:24 pm
AnotherAnon: Your analogies are convenient.
Let’s be honest: some restaurants DO keep substandard chefs and thrive. Some orchestras are comprised of people who can’t play the violin. What quality is acceptable in what scenario? Playing a film score? Making a cheeseburger (would you like fries with that)?
I expect that there is some level of that true in all industries. What is the acceptable balance between growth and innate skill in the industry?
October 2nd, 2006 at 9:47 pm
Hmm. Why so many anonymous posts here?
This “build or buy” topic certainly brings out strong emotions when the subject isn’t software, but developers themselves.
On all these analogies, I’m wondering if people are really using them completely. In orchestras, the violin section people are indeed good violinists. But they all practice for hours a day (something that’s missing in software, but mentoring could substitute for it) and everyone learns from the first violin. S/he often even stands in for the conductor. And I’m suprised that nobody mentioned professional sports, where both “build” (again, lots of practice and learning) as well as “buy” (scout the colleges, buy the stars from your competitors) are used in equal measure.
Interestingly, by the way, sportspeople’s performance statistics are extremely public. That might be healthy for software development: we would all know who the best developers are, and it would also challenge managers to define successful output clearly. Finally on that, when the team loses in sports, they almost never hold the players responsible, even if they’re superstars — instead, the owner fires the manager.
Back to software. My experience is that suprisingly, in all but the smallest companies, the developers may know who’s best, but the management is already too distant from the detail work to know or care. They are already focused on project management. That may be acceptable, but it does mean that they have to make an effort to rediscover who are the best developers.
Oh yeah — two more things:
1) Good developers may be good at software, but they’re not necessarily good at hiring. Unless you keep a severely flat organization, some of them are going to become managers, and (again, suprisingly) hire some not-so-good developers.
2) Even if you’ve got mostly good developers, don’t they need to learn and improve? Otherwise how will your team keep ahead of the other company’s team?
October 3rd, 2006 at 1:49 am
I agree with Tom about keeping stats. That’s a system that operates on meritocracy. It wouldn’t be too popular.
October 3rd, 2006 at 5:09 am
you know, learning age are from 10 to 20. if you’re not a good programmer by then, you’ll never become one.
could you win the davis cup starting tennis at 20?
how far could you go on a cicling competition starting at 20?
October 3rd, 2006 at 5:20 am
Tom Harris: You are amazing. Your advice is awesome… so many strong analogies. You didn’t just blaze a trail with your opinion, you carefully carved one.
October 3rd, 2006 at 10:28 am
What stats? Lines of code per day? I’ve noticed that the worse the developer, then longer the code. Bug count? One way to get a low bugcount is to avoid work. Number of fixed bugs? Poor developers start fixing a lot of trivial bugs to make the stats look good, while the good ones are spending days digging in to the hard ones.
Stats are worthless. Does the person deliver on hard projects, that’s the only stat that matters.
October 3rd, 2006 at 7:12 pm
[…] Hiring great developers? […]
October 3rd, 2006 at 9:45 pm
[…] Lidor over at The Mindset wrote a reaction article on just this topic. He asserts that companies should avoid drinking this punch, and instead focus on what they can do to raise the talent level of their current developers. People are the key to great software development. But people are not a commodity. They are… well, people. If you want a team of professionals, you can have one. But the only way to have more positions manned by professionals is to grow more professionals. […]
October 3rd, 2006 at 11:58 pm
Opposing forces (hiring vs. raising) require to strike a balance.
Obviously, hiring “only the top 1%” means nothing when everybody “hires top 1%” (they aren’t). Anon end others, how on earth do you think to hire “only the best” if everybody else does it? What happens with average developers? They switch profession? If so, suddenly your “only the best” people are average, aren’t they?
Sorry, but your logic is flawed. Aanybody who says he “hires only the best” should take its head out of it’s … (Unless used as a marketing pitch, as Joel Spolsky brilliantly does).
On the other hand, growing internally and not looking outside may mean missing out, as well. It may be you can hire good people who were “baked” may just be easier than baking them yourself from existing pool (andm maybe even failing at that). Cutting off dead meat is good as well, if you can spot it (yes, it’s hard). So, it’s a question of balance.
See http://www.ericsink.com/articles/Choir.html. This one, IMO, hits it on the head. (Sink says there: “I want to speak of team talent in terms of a choir.”)
October 4th, 2006 at 5:22 am
The top 1% won’t find you. You have to find them.
If I want Linus Torvalds on my team, I’m going to have to hire charismatic, industry-famous experts to woo him. For the honor of lavishing him with gifts I would expect to pay 3-5x the market rate. If your regular technical project managers make $70k, expect to pay 210-350k for the cream of the crop.
I would be surprised if anyone here could talk their boss into even $20k more than the market rate. If Jesus Christ walked in for an interview, about the only thing that would pique your boss’s interest would his savings on health insurance. So my advice is, forget about purchasing the top 1%. Create a cool product and attract them. Create a culture that experts love to be around.
October 4th, 2006 at 9:57 am
As Goran says, I think the answer to the “hire the best” vs. “grow what you’ve got” lies somewhere between the two extremes.
People seem to focus on one metric: “how good is this developer” and then suggest that (if you’re in the “grow” camp) you should work to mentor them or (if you’re in the “hire” camp) get rid of them and hire somebody better.
The metric that people are neglecting is “how interested in becoming a better developer is this person?” A crappy developer who has no interest in becoming a better developer isn’t going to be a good candidate for “growing”. Even a developer with a lot of experience who isn’t interested in improving themself probably isn’t a great hire. On the other hand, an inexperienced college grad with a solid understanding of the basics and a genuine interest in becoming a professional is prime mentoring material.
October 5th, 2006 at 11:08 pm
sojapan, $50k? Mine is something like that, and I always thought it sucks… After all, why shouldn’t it? I am a foreigner, I don’t speak the language, I never went to any famous college, and my employer need to worry about my working visa each year and so on. One of my colleagues (also a foreigner) left for another company which pays him about $100K, at least that’s what he says.
October 9th, 2006 at 6:33 am
*bump*
Anon: (October 2nd, 2006 at 6:38 am) - Aparently coward-ware :-)
November 5th, 2007 at 3:09 pm
Insurance Agents and Insurance Services
I couldn’t understand some parts of this article, but it sounds interesting
July 11th, 2008 at 5:00 pm
彼女を作る具体的実践的方法
彼女の作り方研究会
くちこみ 詐欺 口コミ レビュー クチコミ 評判 情報局
彼女