I came across an old Joel on Software (Joel Spolsky) article from 2005 called Hitting the High Notes that I thought was particularly thought provoking. One of the premises of the article is that a single brilliant developer is more valuable for innovation and invention than an army of mediocre ones. His reasoning is that the brilliant developer is capable of thinking things and creating things that are virtually impossible for mediocre developers. The best line that captures the essence of the article is "Five Antonio Salierie's won't produce Mozart's Requiem. Ever. Not if they work 100 years."
But how often does the average organization require the elegance and brilliance of Mozart to compose the software equivalent of his Requiem? When viewed from the context of what the overwhelming majority of software engineers do every day, the answer is “almost never”.
Like Joel Spolsky, I’m a big fan of greatness. Real life accomplishments can often be better than fiction. However, software is as prolific and ubiquitous as there are people and it is because it doesn’t require Mozarts to create useful software to serve an organization and save tons of time and money and provide insight into business and industry trends.In fact, the effect of hiring purely on programming talent is at best problematic.
Let’s agree that software engineering is intellectually demanding. You can't be a dolt and do this job effectively. Technologies and subject matter change too quickly so having intellectual horsepower is a must. It’s also my opinion that for those same reasons one needs to understand that being a software engineer is not a 9-5 job.
As an organization, having intelligent and committed individuals is still not enough. The New York Yankees proved that by trying to buy World Series championships year after year through the assembly of the most talented players alone and failed miserably (As a Red Sox fan I consider that a success story).
That talent-alone strategy doesn’t work in software engineering either. The whole doesn’t necessarily have to be more than the sum its parts to be effective but in those cases one should expect mediocrity and not a whole lotta fun for those involved.
To accomplish cool things, if not world changing things, and have fun doing it there has to be synergy. Included with talent, intellect, and commitment, everyone should respect one another as people and professionals, understand what each other needs to be effective, compliment each others talents, and together fill all pieces of the engineering pie. If you think getting all these pieces to fit together properly sounds really, really, hard - I'm in full agreement!
Accomplishing the assembly of the aforementioned team is certainly a non-trivial task. As with everything in life, it requires compromise and balance. In this case, the compromise and balance is between the individual and team attributes needed, weighting them accordingly, and then hoping you’re right when hiring your next engineer.
Posts
I think it depends on how long-term your vision is with your team. I totally agree that you can assemble a team that consists of the following:
ReplyDelete1) Someone (anyone, literally a single person) with business contacts and a little charm
2) Someone who has some basic understanding of how a particular business functions -- or at least the capacity to listen to someone explain it to them
3) Someone (likely multiple people) who have the ability to code. Not engineer, but just bang out code that will, for the most part, work
I think that team could extremely effectively get contracts, execute on any given project, and deliver on schedule something that works within an organization, delivers a ton of value, and is high margin work. No argument there.
I think that in particular if (a) you live in a less transactional environment, where you have to live with the same grand code base every single day, and (b) you have a longer-term horizon, the "brilliant" engineer becomes completely invaluable. My take on the contribution of the "brilliant" engineer is that she generally makes every other engineer more productive and have to know less in order to write better code. She knows where the biggest time sinks are in your engineering team, identifies targeted ways that could improve code quality, stability, efficiency, etc. and builds reusable components that can be leveraged out of the box (and by sub par engineers). That contribution translates directly to efficiency boosts that are absolutely necessary to scale cost as the size of your team and business grows.
Those are valid points. A brilliant engineer on a team of bright engineers, assuming that person fits properly into the team's framework, will enhance whatever synergy already exists. However, the big assumption is that the brilliant engineer fits. That person's brilliance with engineering could be offset by other not-so-brilliant attributes to a point where s/he are more of a liability than an asset.
ReplyDelete