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:

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:

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.