Meta

In this book I wanted to lay out a plan that an average programmer may follow in order to improve the quality of their work.

We’d need to get clear on what this “work” actually is, and how to define “quality”. As with many such things, the definitions are far from clear-cut, and various concerns are interlinked and multidimensional, so perhaps rather than giving a (necessarily incomplete) up-front definition, I’ll try guiding the reader towards building a mental image of what we are aiming for.

The basic premise of what I’m trying to describe here is that to become better at programming, the programmer needs to get good at a number of “skills, tools, ways of looking at things, etc”, which I refer to as things. Since getting better requires active focus, it’s only feasible to be working on a few things at a time. This book attempts to describe what these things are, recommend an order in which to acquire them, and offer a framework, composed of a number of themes, which makes thinking about things, programming and problem solving in general more productive.

Some of the content will overlap. One could imagine me trying to distill it in such a way that repetition is reduced to the minimum, and only pure essence is presented. I will not do that. In my experience, communication with words is highly problematic in that a rich, multi-dimensional set of thoughts and mental images gets shoehorned into a linear, narrow-bandwidth channel of words, which necessarily leads to a mismatch between what the writer meant to express and what the reader understood. One effective way of addressing this problem is saying the same thing, multiple times, in different contexts, with the aim of slowly building up the mental image in the readers’s mind, instead of misguidedly hoping that this image will just manifest from a single linear reading.

For reasons similar to the ones described above, I will also make digressions into topics not directly related to programming. After all, in writing this, I am trying to share my mental state with you, and that is necessarily a context-dependent exercise, so transferring some adjacent context will increase the chances of success.

Making digressions runs a risk of running into a reader who grumbles “what is this unrelated nonsense, stay on topic!” Such a reader is unlikely to derive much value from this book, and is not part of the intended audience. Getting meaningfully better at programming requires curiosity, time, and an open mind. Much of the gains come from learning to look at the same problem from different, often competing perspectives. Much can be gained by indirect effort, and perhaps even most things worth gaining can only be gained through indirect effort. So readers that are only capable of direct effort and do not have curiosity for adjacent topics are not yet at a stage in their journey to benefit much from this book.

Throughout this book we’ll be using this style for things, themes, and a handful of other terms and concepts. Special visual style is meant to indicate that these are not mere words to be interpreted at will, but names we put on concrete concepts whose meanings we want to be in sync on.

A note on reading examples. They are similar to analogies, in that they are tools meant to demonstrate concretely something that I was until that point discussing in the abstract. And no more than that. So if I am talking about “naming values”[1], and give an example like this

function getNames(things: Seq<Thing>): Seq<string> {
    const result: Array<string> = [];
    things.forEach(thing => {
        result.push(thing.name);
    });
    return result;
}

one could make a comment “you can do the same with a simple map call”, but this would be missing the point of the example. I know that I can use map. That’s not the point, that’s not how examples and analogies work. The point is about “naming values”, in this case specifically something like “if the value is meant to be returned as the result of a short function, it may be more readable to call it result than a more content-specific name like names. The latter describes the contents of the value, while the former describes the purpose, and in a short function with a good name, result will capture both of these things”.

A screwdriver is not a poor tool because it can’t drill holes — it’s great at driving screws, and is not meant to drill holes in the first place[2].

These days [at the time of the original writing] I write a bit of Scala and a lot of TypeScript, and a lot of F#, so most of the examples here will have a TypeScript flavour to them.

Next: The Problem ⇒

[1] I say “values” and not “variables”, because it’s about time we stopped using the word “variable”. All kinds of bugs can be avoided if you stay away from mutable variables.

[2] And just to illustrate the multi-dimensionality and the somewhat contradictory nature of things, I’d like to point out that when forced to make do with what you have, you can drill holes with a screwdriver just fine, and should know how to. There will be times when that’s just the right thing to do. Just depends on context. Contradictions will keep rolling in, but in most cases there will be a clear best choice, so embrace them instead of avoiding them.