Rock stars and Intelligent fools

There’s a great quote that I found on Scott Hanselman’s blog (that he found on Quora) that keeps coming back to me:

  • Junior engineers solve simple problems with complicated solutions
  • Mid-level engineers solve simple problems with simple solutions
  • Senior engineers solve complicated problems with simple solutions
  • “Rock star” engineers make complicated problems go away

Giving members of a team titles like “junior” or “senior” has always bugged me, because it tends to do far more harm than good. I’d much rather have a team who work together for a common goal than a bunch of individuals who are more interested in climbing a ladder. It also prejudges the ideas that come from each individual team member – for example, it can be hard for a “junior” to get his suggestions taken seriously, because a “senior” doesn’t deem them worthy. “Senior” engineers can also commonly feel that they can rest on their laurels and stop learning, and especially feel that they have nothing to learn from a “junior” – which in my experience is preposterous; I personally find that “juniors” often have a level of curiosity and enthusiasm that means they can bring the most interesting new material to the team. The other thing I see very often is when people try to aggressively climb this ladder, they sometimes get a “promotion” to the next rank up and feel a need to prove themselves. The canonical example of this that I see over and over is the first time “senior” who has just read 1 book on software patterns and now feels a need to implement every single pattern in every single piece of code he writes, to show that he can. By the definitions in this quote, the “senior” is behaving like a “junior” – he is introducing complication beyond what is truly necessary.

With a little experience, it should become apparent to software engineers that every piece of code that is written is both an asset and a liability to the company. The functionality and features are hopefully leveraged as an asset, providing business value. The code itself requires support and maintenance, and incurs ongoing costs, which grow vastly in size the more complicated the solution is. The more esoteric or exotic any solution is, the more likely it is to have problems, and the harder it will likely be to find and resolve them. In the worst cases, this can spiral to the point where the cost of supporting an existing piece of software is not viable, and companies can and do fold as a result of overcomplicated software.

There’s another quote, this time from Ernst Schumacher, that also applies here:

“Any intelligent fool can make things bigger and more complex… It takes a touch of genius – and a lot of courage to move in the opposite direction”

The challenge here – for all of us, at any stage of our journey – is to resist at all costs being the “intelligent fool”. We should measure the merit of a solution not by how big or clever it is, but by how small, elegant and simple it is. Doing this isn’t the easy option, it takes a deeper understanding of both the problem and the tools available to solve it, and it almost certainly won’t be the “quick” option, at least in the short term. In the long run however, a simple and elegant solution incurs less of a maintenance liability, and as professionals, we should strive at every opportunity to leave this as our legacy.