You know those lists, like "Must-Read Books on Computer Science". What would I put on the list? I realized ...

I don't recommend flat-out the same to anyone, and I often recommend articles you can find on the web, rather than books.

Recommendations are personal

I find that when I recommend a book or an article to someone, it's often after an hour-long discussion about nothing and everything. I could make notes whenever that happens and then make a list of reads I recommend most often, but really the fact is that every bit of new information needs to pick you up where you are. Depending on the questions I hear you dealing with in your path to enlightenment, I might recommend the Pragmatic Programmer, the Art of Computer Programming, or Dilbert.

This is also why the list is not a pure list but comes with comments and classification.

Small is to the point

When a recommendation blooms out of a discussion like that, there's a difference between recommending the Pragmatic Programmer and Joel's Unicode Advice (the actual title is too long for quoting).

The Pragmatic Programmer is a classic that, while a bit dusty after almost 20 years, probably won't go out of fashion soon. It also is a big list of things that individually apply to specific situations. Yes, it's generally true that you should Use a Single Editor Well, but I think it's hard to start that and Separate Views from Models at the same time. I believe in breaking the learning curve down into small steps. Therefore at some point, when I feel that you already know about 1/3 of pragmatic programming, I'll recommend the book; but I'd rather be able to recommend a single article without ever inducing the hurdle of buying a whole book for just one article, or then feeling guilty if you don't read the book front-to-back.

Joel's advice is different: When I see someone struggling with encodings, I'll point them there. (Actually I'll now point them somewhere else, see below.)

Of course articles on the web have another thing going for them: I can email you the link and you can start reading immediately.

To the point, really?

To what point? When I started compiling this list, I looked at the articles again. I noticed I still like pointing to these articles a lot because the authors are much better prepared to write about this stuff than I am, and the articles are really good. Still I found that some of them didn't really fit my requirement of bringing quick relief to someone who is missing a basic understanding of some area of computer science. I'll just put those next to my new recommendation.

My list

I present here a list of articles that I recommend in certain situations. I'll have to write some of them myself unless I find something that's more fitting – more easily digestible or more practical, respectively.

Numbers in computers

What Every Computer Scientist Should Know About Floating-Point Arithmetic

Practical details may be found in the Wikipedia article about IEEE 754.

Characters and encodings

So this is the classic: Joel's unicode advice (the real title is still too long for this list)

But this one has a lot of beautiful, practical illustrations about what the problem actually is: David's unicode illustration (also comes with a long title)

tl;dr: You don't need to be able to read kanji, just always know your encoding. In order to do that, read the documentation to your language and find the ways of reading and writing files with a specific encoding (never guess or hope, always know), and how to convert from one to the other. Then whenever you do need to convert from one encoding to another, decide what to do with characters that can occur in the first and can't be encoded in the other: drop, replace with a dummy, escape, or complain.

Database Maintenance

When you find yourself managing a database-based application that is likely to change in the future, heed this classic advice by Alex Papadimoulis: Database Changes Done Right

tl;dr: The data belongs to the organization, not to the application.

The only excuse not to understand this is when you really, definitely are working on a one-off thing.

Here's a more more detailed concept.


Off course: Kent Beck's classic book "Test Driven Development".

While you are climbing the learning curve, you might like to take a breather on a landing. Try coding to pre-existing tests at

After you've learned writing code to tests and seen some tests, you can practice writing your own tests: Try it several ways with a kata or another.

Instead of Design Patterns

In order to learn about Design Patterns, read Martin Fowler's classic book "Refactoring" because.

Pair programming

Read the Wikipedia article for a definition. That definition includes the "driver and navigator" mode. I find this misleading – you might think that we pull straws in the morning to find out who's what for the day. We don't.

For one, even when the roles are visible, it's good practice to allow them to flip any moment – whenever the driver gets stuck and the navigator has an idea, let her take over. That's an important benefit of adding experience from two minds together.

Furthermore, in a Code Retreat, you can try out different modes of pair programming. Try ping-pong, or silent pairing! It's a lot of fun!

Now you may think you know how it works, but you haven't really understood until you have thought through all the levels of adapting your infrastructure to the concept.

Then take it up a notch.

Also remember that software development is not just programming – I cherish the memory of many a mob whiteboard session.

Maybe I'm open to this because we used to do it all the time at uni, and because I'm also a pilot: every Cessna is equipped with two sets of yoke and pedals. Pilot training encourages reflection and peer review. We now have two keyboards and mice on every workstation.

Free-floating nuggets

This is instructional about why PHP sucks, what could be properties of good design, and how to (not) lead a discussion like that – or just a classic fun, perhaps slightly disturbing, read: Fractal of Bad Design

jan 2017-09-18