Stop writing software, start solving problems

As software engineers we often suffer from an occupational hazard: we enjoy programming. Somewhere in college or high school we discovered that writing code is fun, and so we chose a profession that allowed us to both get paid and enjoy ourselves. And what could be wrong with that?

The problem is that our job as software engineers is not to write code: our job is to solve problems. And if we get distracted by the fun of programming we often do worse at solving those problems.

The siren call of programming

I’ve been coding since 1995, and I have to admit, I enjoy programming. My working life is therefore a constant struggle against the temptation to do so.

Recently, for example, I encountered a problem in the Softcover book publishing system, which converts Markdown into various e-book formats. I’d been working on my book, and reached the point of needing to render the text into a nicely layed out PDF.

Softcover renders Markdown blockquotes like these:

> This is my story.

into LaTex \quote{} environments like this one:

\begin{quote}
This is my story.
\end{quote}

I wanted the output to be a custom LaTeX environment, so I could customize the PDF output to look a particular way:

\begin{mycustomquote}
This is my story.
\end{mycustomquote}

This is the point where programming began calling out to me: “Write code! Contribute to the open source community! Submit a patch upstream!” I would need to:

1. Learn the Softcover code base just enough to find the relevant transformation.
2. Learn just enough enough more Ruby to modify the code.
3. Figure out how to make the output customizable, write a test or three, and then submit a patch.

This probably would have taken me an afternoon. It would have been fun, and I would have felt good about myself.

But my goal is not to write software: my goal is to solve problems, and the problem in this case is spitting out the correct LaTeX so I can control my book’s formatting. And so instead of spending an afternoon on it, I spent five minutes writing the following Makefile:

build-pdf:
	rm -rf generated_polytex/*.tex
	softcover build:pdf
	sed 's/{quote}/{mycustomquote}/g' -i generated_polytex/*.tex
	softcover build:pdf

This is a horrible hack: I’m relying on the fact that building a PDF generates TeX files if they don’t already exist, but uses existing ones if they are there and newer than the source. So I build the PDF, modify the generated TeX files in place, and then rebuild the PDF with the modified files.

I would never do anything like this if I were building a production system used by customers. But this isn’t a production system, and there are no customers: it’s a script only I will ever run, and I run it manually. It’s not elegant, but then it doesn’t have to be.

I solved my problem, and I solved it efficiently.

Stop writing code, start solving problems

Don’t write code just because it’s fun—instead, solve the problem the right way:

• Sometimes that means writing no code at all, because you can solve the problem with some Post-It notes on the wall.
• Sometimes that means writing boring tests, even though it’s no fun to write tests.
• Sometimes that means reusing someone else’s library, even though it’s much more fun to write your own version.

You can write software for fun, of course: programming makes a fine hobby. But when you’re working, when you’re trying to get a product shipped, when you’re trying to get a bug fixed: be a professional, and focus on solving the problem.

PS: Coding for fun when I should’ve been solving problems is just is one of the many programming mistakes I’ve made over the years. Sign up for my Software Clown newsletter and every week you’ll hear the story of one my engineering or career mistakes and how you can avoid it.