The "High Priest" Developer

Over the years I have grown as a developer. As I reflect on past projects and past jobs, I often remark at how differently I approach my role today than I did a few years ago.

A few years ago, I was a "High Priest" developer. Today, I am a "lowly servant". The difference is a change in attitude, and a change in everyday disciplines.

The High Priest

A High Priest thinks mostly about code. Indeed, he worships his code. He positions himself between user and code because, after all, he is the one who knows how to communicate with the code. The user doesn't know what makes good software. Therefore the High Priest should make the decisions about the code, and should make the decisions about the features, since they are merely an extension of the code.

A High Priest will usually:

• Focus on writing "beautiful" code.
• Skimp on tests, because they make code less beautiful.
• Skimp on UX, because he is ready to move on to the next pet-project.
• Avoid feedback from users, because they will "ask for too much" or be "unreasonable".
• Resist time-based commitments (deadlines), because "it has to be done right" and "software changes are too unpredictable to estimate accurately".
• Respond to user questions with technical jargon, like "it's slow because we haven't indexed that column in the database".

The Lowly Servant

The lowly servant thinks mostly about users. He recognizes that his job is to serve users, and users don't care about code. The user knows what he wants, and it is the lowly servant's job to translate those wants into software. Therefore the lowly servant must listen closely to his users, and work hard to delight them every time.

The lowly servant will usually:

• Focus on writing boring, predictable code.
• Write good tests, because they know correctness is of the utmost importance to users.
• Spend time creating good UX, because they know that is all the user sees.
• Seek tight feedback cycles with users, listen intently, and ask lots of questions.
• Strive to make good estimates and time-based commitments, because the users need a sense of how long things will take.
• Respond to user questions with something they can understand, like "it's slow because of an oversight, I can fix that for you tomorrow afternoon".

Why Change?

I think my change happened because I have worked in business environments with lots of internal users. Perhaps these lessons don't apply to a kernel maintainer, for example.

The important thing to me is that we remember why we do what we do. We build software so that people can use it, not because we like beautiful code. We control the code because the users can't, but that doesn't mean we should control the features, or resist making time-based commitments.

A common reaction when I share these thoughts is: I don't want to feel like a cog in a machine. I don't want to be a servant—I want to create!

I absolutely understand this perspective, as someone who gets great joy and satisfaction from coding. Ultimately it is not as black and white as the "priest/servant" analogy. It is possible to be creative, and derive joy from coding, even if your goal is to write boring code. It is also possible to be a leader and an influencer, while still bowing to the needs of your users.

If you cannot achieve this, the cost will be failure. Most of the engineering failures I have witnessed (or been a part of) have been due, at least in part, to over-indulgent High Priest developers. I have never seen a great engineering success without at least one lowly servant participating (and usually pulling most of the weight).

Part of becoming a senior developer is learning to be a lowly servant, while still enjoying what you do.