Skip to main content

There are two kind of programmers: Nihilists and Optimists

The nihilist programmer takes as axiomatic that their product is already broken. It is in constant flux, poorly defined, the product of compromise in design, and inevitably compromised in implementation. Even more, that it will remain this way, by its nature, forever. The nihilist programmer starts from these axioms and then decides what to do. What to do? The least amount of change possible. Limit exposure, limit effect. Get to the next checkpoint.

The particular medicine isn’t a bad one, per se. There’s value in those limits. What’s bad, I think, is the ethos. If a thing is undefinable, you will naturally resist efforts to define it. If a thing is forever in flux, you will resist efforts to freeze it. If a thing is composed exclusively of compromise, you will resist efforts to make decisive decisions. And if a thing will never be good, you will resist efforts to make it good.

In this sense the nihilist programmer ensures their travels on a dead-end road are as comfortable, and perhaps long-lived, as possible.

The optimist programmer, in contrast, seeks to change course.

The optimist programmer assumes the thing can be good, and constantly initiates to make it good. That the thing shouldn’t contain compromise, and should reflect clear decisions. That the thing should be defined and then built, and not rock forever on a sea of changing assumptions. That the thing ought rightly be defined, that its true form is definitional.

What’s bad about the optimist programmer isn’t the ethos, but the practice. In reality, nothing is fixed, and everything is in flux. By straining to define and then build, the optimist programmer inevitably builds the wrong thing. Or, perhaps more often, nothing at all, as the thing never escapes the design stage.

Successful projects live somewhere in the middle. But I think all good software is fundamentally optimistic. Not that it won’t contain compromise, or technical debt to be repaid, but that it doesn’t start from the assumption that nothing is definite and all hope is lost. Optimistic software makes decisive claims, executes on them, and owns the compromises it makes. Optimistic software can be critiqued for doing the wrong thing, but not for doing it poorly. I am an optimist programmer and I want to write optimistic software.

Comments

Popular posts from this blog

On working remote

The last company I worked for, did have an office space, but the code was all on Github, infra on AWS, we tracked issues over Asana and more or less each person had at least one project they could call "their own" (I had a bunch of them ;-)). This worked pretty well. And it gave me a feeling that working remote would not be very different from this. So when we started working on our own startup, we started with working from our homes. It looked great at first. I could now spend more time with Mom and could work at leisure. However, it is not as good as it looks like. At times it just feels you are busy without business, that you had been working, yet didn't achieve much. If you are evaluating working from home and are not sure of how to start, or you already do (then please review and add your views in comments) and feel like you were better off in the office, do read on. Remote work is great. But a physical office is better. So if you can, find yourself a co-working s

Capture and compare stdout in python unit tests

A recent fan of TDD, I set out to write tests for whatever comes my way. And there was one feature where the code would print messages to the console. Now - I had tests written for the API but I could not get my head around ways to capture these messages in my unittests. After some searching and some stroke of genius, here's how I accomplished capturing stdout.

Todo lists are overrated

My tasks come from a variety of sources: 1) Tasks from emails  2) Meeting notes with details of people who participated  3) Project related tasks that can have a long format and can be tagged/ delegated  4) Scratchpad for unrefined ideas  5) Detailed documentation for completed technical tasks / ideas  6) FIFO list of high priority small daily tasks No one app has been able to map all the requirements above, and I have tried a lot of them! In my lifetime I’ve tried a dozen todo apps. In the beginning they all seem different, novel and special. Slick UI, shortcuts, tags, subtasks, the list goes on and on. But all our stories were the same: I start using the new app, then after awhile I stop using it. Up until the last week I thought the problem was in myself (you probably think so too). After all, David Allen seems to have figured this shit out. Also there are people leaving long 5 star reviews on every major todo list app, they discuss them on forums, recommend them to friends. But the