Drawing pictures

While working on code, you often find yourself confronted with problems that are quite tricky to get your head around. Such problems might range from things like relationships between classes, to detailed path finding algorithms. In my (short) experience I have found a sure fire way to help in defining such problems, and it's simple; draw a picture.

'Wait!' I hear you cry, 'I'm a programmer not an artist, why the hell do I need to draw anything!?'

Now don't get me wrong, I am not saying you should create a work of art, far from it, what you want is a crude abstraction of the problem facing you, and that is more often than not, best achieved with the aid or a picture or diagram.

By creating an abstraction of the problem, you immediately give your brain a chance to breathe, and absorb the information in a new way. It helps you visualise the problem, and allows you to hold it in your hands, add notes to it and see it in the real world. It takes a load off the old grey matter too so you don't have to be storing all the information you need in your head at once.

Universal Modelling Language (UML, of which I am sure I will talk later) is a fantastic tool for this when describing class relationships, program flow and so forth (it's also great because as it's a standard, if you implement it correctly, other people who know UML will understand exactly what you mean) But I'm not just talking about this, I am talking about any problem at all. It could be something mathematical,  some kind of behaviour, some process; if you attempt to draw a picture of what is happening, or create some pseudocode for the underlying process, it will help no end in your understanding.

The saying goes that a picture is worth a thousand words, in programming, I'd say a diagram is worth 10,000 lines of code.

Now get those pens out and start scribbling.