Programming is hard[1] and the current state of software engineering kind of sucks and probably won't get better[3].

But that being said, there is a lot of joy in programming and problem solving.

I have a well-deserved reputation for being something of a gadget freak, and am rarely happier than when spending an entire day programming my computer to perform automatically a task that would otherwise take me a good ten seconds to do by hand. Ten seconds, I tell myself, is ten seconds. Time is valuable, and ten seconds’ worth of it is well worth the investment of a happy day’s activity working out a way of saving it. -- Douglas Adams[5]

From a purely business perspective, this project probably cost the company money. The programming, which was in a part of the system I had never looked at before, took something like a full day of my time including the code changes, testing, and deployment. [...T]he cost-benefit break-even point was at least several months out, possibly many years[.]

But the moral calculus was in everyone's favor. What is money, after all, compared with good and evil? If [...] the only cost was a few hours of my time, that was time and money well-spent making the world a better place. -- Mark Dominus[4]

While often programming is about "efficiency" or "productivity", if I ever forget the joy of reveling in a mundane or silly problem, twisting and flipping it to find a novel or interesting or satisfying solution, the rush of seeing your Rube Goldberg Mouse Trap-esque jalopy fire out the desired result, please pull me out of that hell at all costs.

Programming is Forgetting

The process of computer programming is taking the world, which is infinitely variable, mysterious, and unknowable (if you’ll excuse a little turn towards the woo in this talk) and turning it into procedures and data. And we have a number of different names for this process: scanning, sampling, digitizing, transcribing, schematizing, programming. But the result is the same. The world, which consists of analog phenomena infinite and unknowable, is reduced to the repeatable and the discrete.[14]

Hacker Questions

Instead of saying access to computers should be unlimited and total, we should ask “Who gets to use what I make? Who am I leaving out? How does what I make facilitate or hinder access?”

Instead of saying all information should be free, we could ask “What data am I using? Whose labor produced it and what biases and assumptions are built into it? Why choose this particular phenomenon for digitization or transcription? And what do the data leave out?”

Instead of saying mistrust authority, promote decentralization, we should ask “What systems of authority am I enacting through what I make? What systems of support do I rely on? How does what I make support other people?”

And instead of saying hackers should be judged by their hacking, not bogus criteria such as degrees, age, race, or position, we should ask “What kind of community am I assuming? What community do I invite through what I make? How are my own personal values reflected in what I make?”[14]

Code Is Not Literature

Code is not literature, it is an activity. It is a dialogue. You don't read code, you interact with it, you study it, you poke it and see what happens.[7]

Code Is Expensive

Each 5K to 10K lines of code costs roughly 1 FTE to create. In my experience each 50K-200K lines of code needs roughly 1 FTE of maintenance on a yearly recurring basis.

If you have a 10 FTE team, creating between 50K and 100K LOC per year, you also have created the recurring need to sustain that code over the life time of that software. The first year, the team is super productive. The 2nd year they need part of their time to maintain the code they created in the first year 1 and so on. If you assume that maintenance is a function of code size, your innovation speed will move to zero!

How to break the negative spiral? The first step is to recognize the importance of monitoring the size of your code. You need to embed this in the team culture. Establishing a ‘minimalistic code’ culture will keep your teams in control of their code base. They can spot unexpected code size increases and challenge themselves on finding opportunities to reduce. Setting their own targets will stimulate teams to find and remove dead code where possible.[15]

Code Is Art

Even at its most measured, software development is a creative profession and software is a creative industry.

The software industry has remarkable scope for what platforms to use, which programming language to write in, how you architect a project, and how you solve every tiny problem that the project is made up of. Because there are often many right answers to each question, how a developer solves a problem will always be a creative expression. It is not a single monolithic medium.[9]

The Seven Ur-languages[2]

From madhadron:

[N]ot all languages have the same set of patterns. The patterns for looping in C or Python are very different from the patterns of recursion in Standard ML or Prolog. The way you organize a program in Lisp, where you name new language constructs, is very different from how you organize it in APL, where fragments of symbol sequences are both the definitions of behavior and become the label for that behavior in your mind.

These distinct collections of fundamentals form various ur-languages. Learning a new language that traces to the same ur-language is an easy shift. Learning one that traces to an unfamiliar ur-language requires significant time and effort and new neural pathways.

The Language Doesn't Matter As Much As You Think

Is the syntax worth thinking really hard about? Does it matter how you have chosen to express your model of reality? Do the specific symbols in your toolbox shape your whole experience of work and life? Well, yes. Sure enough. But then are these things the crux of my actual problems? Well, no, not really.[10]

Abstraction Has A Price

Frustration happens when the developer is unable to use their existing skills or feels disproportionally punished for doing it their way instead of your way.[13]


  13. The cost of convenience —
  14. Programming is Forgetting: Toward a New Hacker Ethic, presented by Allison Parrish
  15. Why your team needs a code down target
  16. 1985: Making TEXT ADVENTURE Games | Micro Live | Retro Gaming | BBC Archive
Incoming Links

Last modified: 202401040446