One Blessed Developer

The tedium of everyday coding sometimes catches up to me. So many little decisions, most decidedly inconsequential; the rest, arguably inconsequential. And yet, we’d like to do things Right™. And for the particularly daring, even attempt to do those things alongside other human beings.

If you’ve been caught up in an avalanche of choices when approaching a new software development project, you know first-hand there’s an absurd volume of debate to be had. Should it be in one repository, or many? Should the directory be named X or Y? Should there be a newline at the end of every file.

Many of these choices just don’t matter. They have zero merit from an organizational, business, engineering, or educational perspective. They are a waste of your damn time.

When you develop projects on your own, there is no such debate. You are the team. You set everything up to your preference. It’s fast. It’s easy. It’s practically cathartic.

But when starting a project with someone else, all that minutiae can be cumbersome - if you encourage open discussion, that is.

So should you?

I’m beginning to think that many projects, especially new ones, would be much better off with “one blessed developer” who has final, dictatorial authority on all trivial matters. Stop letting other people waste precious cycles on unproductive discourse. Let this chosen one feel the pressure to decide so that others may focus on actually getting shit done.

There are always going to be times when the blessed developer needs more data to make an informed decision. Being blessed means having the experience and insight to ask for help when you need it. I believe those cases are far more rare than we care to admit.

At first glance, the model doesn’t seem suited to long-term maintenance. The blessed developer might get bored of the project, or even quit. There clearly must be safeguards to make sure the halo could be passed at any time. But those measures would need to exist even without a blessed developer, and perhaps this convention would even function to hasten that preparation, since it is now inevitable.

My motivation for a blessed developer is rooted in a fear of failure. If I am to be responsible for a project, I absolutely want complete control of the code and process. But if I’m a mere contributor, if I’m new to the project, what I seek is more of a transaction. I want to write a piece and entrust it to someone else, someone that actually knows what they’re doing.

I’m aware this is all extraordinarily self-centered. After all, I want it done my way, or I want none of the responsibility. But I do think this setup is where I would feel particularly safe, in the psychological sense of the word. I’d be surprised if there aren’t other engineers who feel the same way.

Or, maybe I just need to go out and fail spectacularly a few times.