Bureaucracy Considered Harmful

Okay, I’ve written this essay a hundred times.

It’s always true. It’s always necessary.

Sometimes, I get stuck. Writers talk about writer’s block. I’m not a writer. I don’t get that, not in the normal course of life.

I’m an engineer. I get engineer’s block.

The solution is always to do something, to do anything. For me, the solution is usually writing.

I need to write something. To put words on a page, to get used to making progress on something again without feeling constantly overwhelmed by the approach of obstacles.

By bureaucracy and its hideous head.

I hate paperwork, and I hate testing (not unit testing manual testing), and those are the two rewards for completing the work that’s assigned to me.

This is my problem.

I’m sure that this is what causes me to get blocked.

What I need to do to overcome it is to do work that goes unpunished.

I want to write code, really I do. But I also really, really don’t. I’ve developed a resistance to the idea. A mind block, maybe even a phobia.

I bet the writers who get the worst writer’s block are the ones who dislike editing.

When work is its own punishment, you develop an aversion to doing it.

I like writing. I like editing. I'm afraid of publishing, sharing, having a world that can in principal respond. Trying to publish and thinking about publishing are the things that have given me writer’s block in the past. (I finally got over this about three weeks ago, I think and hope.)

JIRA tickets give me engineer’s block.

Sometimes, I want to get buried in a project and not come up for air for a month or two. Always, I want that. There is some semblance of peace in that, some escape from drudgery.

Instead I have to edit JIRA tickets constantly, go through the experience of annoying a coworker until he or she finally reviews my code, and then do a bunch of manual testing every couple of days as soon as I finish a little project, and I hate it. I detest it. I feel like I’m suffocating.

Come up for air is a strange analogy. I think I’m a fish and writing code is my water, and every time I finish a project I get dragged back up onto the boat. I just wish I could just write code and never finish projects.

Actually, I don't wish that. I just wish the release process wasn't so horrible, and I could go back to working in a code base that relies on unit tests instead of manual processes for quality control.

Complicatedness

[This is another unpublished old post that I decided to edit, finish, and post instead of delete.]

Every project will rapidly build up complexity until it reaches the point where the most skilled developer working on the project routinely finds his work somewhat challenging.

Human's thrive when they are working on problems that are challenging but solvable. Read virtually any book about design from the last twenty years, and it will tell you that the flow state is real and that it matters. The flow state is the state in which people are most productive and happiest to be working. They achieve it only when they are working on something that challenges them.

What happens naturally when people are maintaining code is that the most adept programmer tends to have the biggest individual impact on the codebase. Others may have equally or more drastic impact on the overall project by introducing problems that everyone has to spend time cleaning up or by setting the tone for some piece of the project that ends up becoming a central piece, but in the average day, the smartest developer is probably the one writing the most lines that are being kept and the one doing most of the prototyping, factoring, and refactoring that create the context in which everyone else is doing their work. S/he won't slow down until s/he finds the complexity challenging, and in in fact her/his subjective evaluation of the quality of the codebase will be that it is improving with each increase in complexity until s/he begins to find managing the code somewhat challenging.

Not all challenges are the same. Witty Haskell-style one liners that showcase clever tricks are a very different kind of challenge than the kind of challenge that gets created by a nebulous distributed cloud of little intricacies and corrections that have to do pieces of code separated by 30 lines of other code interacting with each other. The witty one-liners are a lot less time-consuming to debug and maintain even though they pose a few skull scratching challenges when people look at them and try to figure out what makes them work.

If it is true that the complexity in the codebase is going to climb to some limit either way, it's much better to have complicated lines of code than it is to have complicated patterns of interaction between different lines of code. So you want to keep your codebase full of pithy one liners.