While eagerly listening to “Security Now” episode #923 I was captivated by a portion discussing the art of programming. During the episode Steve Gibson was discussing his experience of maintaining a soon to be released rewrite of his popular software SpinRite. During which he discovered the design he had made failed after implementing several edge cases. It drove him to rethink the design and discover a cleaner and more flexible solution, which motivated yet another rewrite.

There is a broader lesson here that has probably occurred to anyone who codes a lot: There really is an art to coding and the act of solving a complex problem teaches the coder so much about how to approach and solve the problem, that it’s only after they finally have their program running that they understand how it should have been done.

Steve Gibson “Security Now” episode #923, show notes (emphasis mine)

Gibson goes on to summarize a story he heard on another podcast.

…Alex Lindsay told the story of the four months he first took to solve a complex problem… Shortly after he finally had it working, the machine crashed and he lost all of his work. …after recovering emotionally from the loss, Alex re-implemented in just three weeks what had taken him four months to do the first time. And it was only after that, that he then realized how it should be done, so he rewrote it again, in four days. The way Alex expressed it was as three phases: “Do it. Then do it better. Then do it right.”

Steve Gibson “Security Now” episode #923, show notes (emphasis mine)

This idea that coding is an iterative process is exactly how art works. There is engineering involved to guide and facilitate such results but the core of coding is a form of artwork.

I grew up in a household of English Majors and the ability to express one’s self through the written word was always an undertone to our shared family values. Creative writing also involves similar thought processes as coding. We are telling a story. It just so happens that the story we tell is to express ideas to other people reading the code and structured in a way a computer can reliably execute those same ideas.

I think our industry looses this distinction in the efforts to move fast we tend to focus on teaching the semantics of programming and failing to also teach the story telling aspects.

…When that first little innocuous exception [in the code] was needed, the quickest answer was to simply add a couple of [conditionals] for it. And when it turned out to be needed in other places, I had already established a template for how to “solve” that need, so I applied the same [conditional checks] elsewhere. Then, when another type of exception emerged I did the same, since by then I’d established a precedent. But after six months of that, my code had become a true mess. I knew how to solve it… but right up until I bit the bullet, it was more important to me to be almost finished. The good news is that now I’m almost finished again, [after redesigning it again from scratch using the lessons learned prior.] But this time, I really will have a beautiful legacy…

Steve Gibson “Security Now” episode #923, show notes

I think this highlights well the process of creation and that programming is not isolated from that process. Again, just like in creative writing we make drafts, edits, and revisions to our works. I go through this process every day in my programming work. And it is the core philosophy underlying TDD (Test Driven Development). For example, the following table shows my understanding on the correlation between TDD and Creative writing.

This idea feels important to me because our industry doesn’t talk much about the situations our code gets into when we focus on deadlines and MVPs. Instead we banter about technologies, syntax, impertinent paradigms, etc. instead of refining the same parts of the design over and over till we get it right. When we say “almost finished” we need to account for that being the 80% and that we still have another 20% to go.

Unfortunately, we all to often attribute that last 20% to writing tests, documentation, and pull requests most of the time. Alternatively, if we as an industry pay tribute to practises like Pair Programming and TDD we can cover much of those in the 80% leaving the last 20% to actual redesigns and refactoring work. This will also increase our fidelity on estimations as we will have a much clearer idea on the requirements implemented and the general percentage of done we are at.

Doing this I believe we will increase the quality of our output and make for a better world. Users will thank us. Support will thank us. Managers will thank us. Maintainers will thank us. And most of all, future us will thank us.