The Programmer Pyramid

Newsflash: some programmers are better than others.

OK, I admit that’s hardly a revelation. But most companies use a grading structure that can obscure the relative strengths of each engineer on the team. There may be a 20-year veteran with the title Principal Engineer who regularly breaks tests and hacks his way through his day while a young intern may be writing some of the best code the team has ever seen.

I’ve built my own mental model of programmer strength and organized it as a pyramid:

Typist

At the lowest level of programming competence is the Typist. They hit the keyboard a lot but don’t produce anything that even remotely resembles professionally-written software. They are utterly lacking in their technical knowledge and have little desire to change that fact.

A software team cannot survive long with typists in their midst because they do more harm than good. They are at best anchors and at worst damaging to the momentum and morale of the other members.

Coder

This is the level that most programmers are at when they graduate from college. They have a good knowledge of data structures, algorithms and are proficient in at least one language. Due to their limited professional experience they typically don’t yet understand why they should make code maintainable or do refactoring (mostly because they haven’t yet had to fix someone else’s bugs).

Coders require investment from the stronger members of the team in terms of review and oversight, and if there are many of them on the team, that can weigh the others down.

Builder

A Builder is a Coder who has adapted to work in a professional environment. They create readable, well-organized code and always ensure that their tests pass.

Builders work best executing the designs of those above them in the pyramid. They write good tests, are self-motivated and have the word “solid” associated with them a lot. Most teams need at least some Builders to be productive, and most teams indeed already do have some of them on staff.

The majority of programmers reach this level during their careers, but not all of them will move upwards to Engineer.

Engineer

Ironically, almost all professional programmers have the word “engineer” in their job title, but many of them simply never live up to the name.

Engineers design scalable and reusable components, infuse others with their knowledge and are very disciplined. They keep abreast of industry trends and technologies but will only use the right tool for the job at hand rather than get distracted by the latest fun tool they played with.

Their code is impeccably written and very well-thought out, and they know exactly how it fits with the rest of the system. They are very good mentors and routinely assist others on the team. Every team should have at least one.

It’s not guaranteed that a Builder will eventually become an Engineer, because some of the traits required (creative design and problem solving, among others) are likely innate and can’t easily be learned.

Master

Masters are rare. These seasoned veterans produce software that is more than just engineered – it is crafted. Their software has aesthetic beauty. They are the Frank Lloyd Wrights of software and are worth every penny if you are lucky to find one on the market.

Whatever they create – be it a user interface, an API or a tool – is incredibly easy to use. It just never gets in the way because it just works, and works well.

Having a Master on your team quickly causes people at the lower levels of the pyramid to move upwards thanks to their positive influence. I was lucky enough to have one on the team that I joined after leaving college, and I’m forever grateful for the experience. The Master created a team culture that encouraged everyone to better themselves and to work like true professionals.

An unexpected attribute of a master is their humility. While there will always be plenty of alpha Engineers around, the Master is confident and secure in their knowledge and doesn’t need to brag or assert dominance. Their work speaks for itself.

Using The Pyramid

The pyramid is most useful at hiring time. Many employers think first in terms of the position they need to fill and then only consider the relative strengths of the candidates after they’ve interviewed them. I think that’s backwards. They end up completely discarding resumes without the “correct” number of years of experience. A better approach would be to think about the desired strength of candidate first and only worry about their grade when an offer is being prepared.

The pyramid helps prevent the kind of pointless discussions that begin with someone in management saying, “We must hire only top talent!”. That’s a fine goal, but you have to realize that you’re not going to find a team comprised only of Masters. You may need a few Coders to write an internal testing tool based on the design of some of the stronger members, and it would be silly to pay top-dollar for that work.

You may also look at your team and realize it’s staffed almost universally by Coders, and what it’s really missing is a strong Engineer to lead, mentor and inspire them to build better software and lead their growth up the pyramid levels.

When you are interviewing a programmer for a position, I’d suggest drawing the pyramid on the board, explaining what each level means and asking the candidate where they think they currently fit. You’d be surprised how much you can learn from their reply: some candidates shoot right for the top and proudly boast that they’re Masters while others take the time to really consider their own abilities and give an honest answer. I have even encountered candidates who, after hearing me explain the level of strength I’m looking for, candidly mention that they may not be right for the position.

And it’s so much better to find that out before they get hired.