A Tale of 2 Developers
This is a tale of 2 web developers. ‘Jim’ and ‘Johnny’. They are both mid level developers looking for a job. Both are technically able and have bachelors degrees in computer science from similar schools. You have interviewed them, and while either should be a decent fit for the position you have, they are decidedly different.
Johnny has a great pedigree. He’s been hacking around the internet since grammar school, and he has a a stellar GPA. He has dabbled with many programming languages, ASP, Perl, to PHP, Python, and Ruby on Rails. He has worked at some great companies as part of a team on some great projects. He knows every acronym, and every design methodology there is.
Jim on the other hand has worked in less programming languages. He is extremely efficient in one language, and has dabbled in one or two others. He has stayed at 2 companies for the course of his career. He worked on a small team where he had to wear many hats. His grades were above average, but not a 4.0. Most projects he did work on are still running on a high traffic site, with many concurrent users, and are quite stable.
So who do you hire? On the surface johnny is a superstar. He is going to give you perfectly architected code written in the perfect language every time. He would be the ultimate generalist which I am a fan of. He can talk to talk to clients, telling wild tales of working on cutting edge XML feeds with the brightest minds at the time. So Johnny is the right choice, no?
I would not hire Johnny. Johnny is a tech snob. When you really think about his resume what has he done? He doesn’t really have a large scale stable project under his belt. I would fear Johnny’s ability to talk to clients without talking down to them, and possibly the same for his team. In my experience the tech snobs of the world would rather work on picking a language and designing the code than actually getting a project to completion. They are enamored with the idea of the ‘correct way’ to design a project rather than the practical way. Practical is not always pretty but it works. It gets projects done and leaves room for future improvement. That is the hard part, getting code to completion. The real effective developer buckles down and writes good clean code.
Does Jim know how to write good stable code? Can he work with new technologies, and learn quickly? Of course. His education and experience to date show exactly that. Too often tech snobs serve as nothing but a distraction to tech teams, and are better off doing R&D or on a large team. But for a small agile team that is looking to be effective, picking a Jim turns out to be the pragmatic and correct decision 99% of the time.
I don’t need my developers to know everything. They need to grow, and be able to tackle new obstacles. If all they did was bounce from idea to idea, their knowledge would be too superficial to be of much use.
Maybe you disagree, I’d love to know your thoughts.
Related posts:
- Knowing your users will help make effective decisions If you are reading my blog, there is a very...
- product versus project manager For years, SmartMoney had project manager(s). This was more of...
Related posts brought to you by Yet Another Related Posts Plugin.
Never let your developers talk to clients.
I think it depends on what you’re trying to do. The other end of the spectrum you have programmers that will use only one tool (java programmers, I’m looking at you) for every job. When all you have is a hammer everything looks like a nail. Twitter made this mistake by building a messaging system with Ruby on Rails. Now they use Scala which is a better fit for what they are trying to accomplish.
Kevin, I I know what you mean regarding developers talking to clients. It depends on the skillset of the developer and their comfort level. I find it is mutual also. Many developers do not want to talk and meet with clients. They find it a distraction discussing mundane features and issues while their brain is running through code ideas. Others are just naturally introverted and avoid it at all costs.
But, some teams are so small, this is not an option.
Mike, good point. I think there is a fine line between a generalist who can apply the right tool for the job, and someone who is just a tinkerer. Ideally your tech leads and management are aware of the possible tools for the job, allowing developers to hone their specific skills without being too distracted chasing technologies.
In terms of who to hire – Jim or Johnny, I’d say it depends on what type of company they’d be working for. A financial company? Probably Johnny. An internet startup? Probably Jim. Myself, I’d like to hire both of them! It would be a good balance. But if I had to choose? I guess I’d lean toward Jim based on your premise that “Johnny doesn’t really have a large scale stable project under his belt.”
[...] This is a great Article I found on Joel On Software. In this article Joel writes about the concept of the Duct Tape Programmer. This is the programmer who gets things done and doesn’t feel the need to show off their software architect skills by over-engineering software. The Duct Tape Programmer is similar to the fictional developer I called “Jim” in my post A Tale of 2 Developers. [...]