Frank Schacherer Homepage
home technology bibliography

What I learned about coding (the hard way)


Understand your problem

Coding is not done for it's own sake. Usually there is a problem you want to solve with the system you are building. It may be a big problem, like the integration of heterogeneous database systems in a big company, or a little problem, like a formated list of records. In any case, before you start to code, you have to understand and be interested in this problem. You have to find out what the right way to solve it is. This is hard, when you are uninterested. If you work in bioinformatics, you have to be interested in the biology, for example.

Do not make the mistake to sit down and start hacking when you are not knowing what you do. The results will be ugly and cost you time.

Examine your problem, think it through, draw sketches on paper, until you know how to solve it. Then the code writes itself much easier.

"All Programming is about abstraction"

Even a medium sized computer program is much too complicated to fully understand. You never can keep the variables, parameters and whatnots in your head. Your brain is too weak, and you have to find a way so that it has only a few things to remember at the same time. That's where abstraction, object-orientation, modularisation and so on come from. Keep it simple, because you are not smart enough to make it complicated. It's getting more complicated all the time all by itself, and keeping it simple is a though fight, and an art. If it is elegant, then usually it is good.

Build large systems from components

This is the self-evident advice. Still I have seen a lot of large systems full of lava code, cut-and-paste programming, double developments etc. Systems where basically every programmer went in and redid his stuff from scratch for himself, because the things that were there were to difficult and undocumented and cumbersome to understand. In the end the whole system starts to collapse, because it is much too complicated to understand. For most of the code it is not even known if it is still needed, but people are afraid to get rid of it.

The most important and most difficult thing is to find the right segmentation. Make it so that each module bundles stuff that you'd expect to find there intuitively, and you'll be about right.

Create the components really as general components. Make them libraries, with a defined interface, that is robust to malformed inputs and usage. You can think of them as little servers that get client requests. Then, when you tested the library, you can trust it and need not waste brain power looking for mistakes there, anymore.

Another crucial thing is to limit the number of dependencies. If every part depends on a lot of other parts, you can change nothing in isolation without affecting a lot of things. Libraries should have little to no dependencies.

"Programming is all about separating the parts that change from the parts that don't"

"Programming is all about data representation"

Many programs could be simplified with a table driven approach: the general code is in the program, and all the specific quirks are in the tables, or in config files. This also nicely helps to split the parts that change from the parts that do not.

Some useful design elements