Blog

After reading Glyn Normington’s Top ten technical books I started thinking about what books have had the greatest impact on my thinking. While it is hard to separate personal and professional aspects of oneself, this list focuses on the technical books. Without further ado, these are the books that made me the programmer I am today1, in order of reading (as far as I can remember). Refactoring # Key insight for me was that code is not only written once, it can and needs to be continuously changed.

There always seems to be more things to do than there is time available. The backlog is long and growing ever longer. People want their features yesterday. And not only are there features to build, you want to build them right! How can we decide what to prioritize? It’s easy to feel overwhelmed. You might find yourself thinking: “Got to get it right from the start, or it will be a mess later.

It is easy to think that creativity requires great freedom, but the opposite is often true. I first heard the phrase “constraints are good” at a tech conference in 2010. I don’t remember who said it, but it has stuck with me ever since. When I first heard those words, they sounded rather odd. “Constraint” is a negative word to me, so intuitively I want to remove constraints. Why would they be good?

Software development processes in the 1990s have gotten a pretty bad reputation. (Largely for good reason, one could argue.) They were typically plan-driven and process oriented. The underlying idea seems to be that if we can just specify everything in enough detail, we can all but guarantee success. Compared to the then-common waterfall process, at least the processes of the 90s were often iterative. But they still put a lot of focus on up-front planning and following protocol.

I have a love-hate relationship with teaching and explaining things. On the one hand, explaining something puts me at risk of exposing that I don’t really know what I am talking about. “Better to remain silent and be thought a fool than to speak and to remove all doubt”, as the saying goes. On the other hand, teaching is a great way to determine if you truly understand a subject. When you try to explain something, you will quickly discover any parts where your understanding is not as good as you thought.

Artificial Intelligence has taken the world by storm. Especially generative AI with Large Language Models (LLM) with ChatGPT as frontrunner. It is not hard to see why. Like many others, I was blown away when I first started using them and realized what they could do. Like many others, I was then disappointed when I realized their limitations. Because it is when things go bad that you really need to start thinking.

You know that feeling of accomplishment gained from understanding a large or complex piece of technology? I like to think of that as a warning sign. I mean, it is nice to feel smart. But it should also make you stop and think – why was this hard? Is the complexity of the solution justified by the problem? Is there perhaps a simpler solution which will work just as well? Are there other options which would be easier to understand?

Maybe it is a sign of me getting old gaining seniority as a software developer, but I’ve come to reflect a lot more on my professional contribution. Since this is a new year, I’ll allow myself some introspection. Personal reflections #I’ve been writing software since I was eleven years old. While the first few years obviously cannot be compared to professional experience as a grownup, I’ve had a lot of time to practice.

I think consistency is one of the most important design guidelines. When things are consistent, we use our hard-earned knowledge about how things have worked in the past to understand how new things work. Consistency helps us avoid superfluous and distracting choices. You don’t need to think about whether X is different from Y for a good reason, or just because the developer was bored that day. You can focus your energy where it really matters.

In technology choices, sometimes “boring” can be better than “interesting”. This is something I’ve slowly realized over the last few years. I would rather solve interesting problems with boring technology than solve boring problems caused by interesting technology. To be clear, “boring” in this case does not mean “outdated” or “wrong”. It means choosing technology that is appropriate for the task. Technology which is well-known and battle-tested. Technology which you can easily recruit developers for.