First Post.
I’ve just spent a morning and an afternoon working out a very difficult programming problem involving circular buffers. This problem plagued me for the past few weeks as it’s an important and integral part of a major piece of software I’m working on. Thing is: It’s now 15:20 and I’ve only just turned on my computer.
I worked this problem out with a good old-fashioned pen and paper, and I’m glad I did. There are some programming problems that simply need this kind of attention, and a stint away from the keyboard with pen in hand and some paper is the only remedy.
The particular problem which I finally solved today involved circular buffers. Not too difficult on their own, most programmers can handle them without losing too much sleep (or hair), however the particular problem I was working on involved one ‘real’ circular buffer and N ‘virtual’ circular buffers which were contained within the real one. To save on memory, the application just uses one buffer, but it simulates many circular buffers of varying sizes, all of which are subsets of the master buffer. To make things even more complicated, these virtual buffers were situated at varying offsets trailing the master buffer. And to make things even more complicated, when a new piece of data was written to the master buffer, this piece of data would rarely be immediately written into any of the virtual buffers, but usually would be scheduled to be written into the virtual buffer some time in the future. Further complicating things, I had to make sure it wasn’t too far in the future that the piece of data would have been overwritten due to the main buffer having done a full lap. To achieve this, each virtual buffer needed an array of booleans to keep track of which slots in the buffer were used and which ones were free.
Before solving this problem, I was very intimidated by it, (as I’m sure you are too having read the above). It was one of those problems that’s simply too big to run in your head. Also I didn’t have a pre-rolled algorithm or recipe that I could just work off. I was inventing the wheel. I had a basic understanding of what the problem was, but it wasn’t clear in my head. It still isn’t totally clear, but it’s much clearer than before. I had a feeble go at programming it, but I just didn’t know where to begin. That’s why today I left the computer off and instead took my pen and started drawing diagrams.
I intend to use the pen and paper method as much as I can in future because I believe it has the following advantages:
1. Digital distractions are lessened when you move away from the computer screen and all you have in front of you is a blank sheet of paper. There’s no tweeting, googling.
2. It avoids trial-and-error programming. When you haven’t got a compiler at your disposal you can’t just try random configurations of code until you find something that works. This is a sloppy and dangerous way of coding that I’m guilty of doing in the past.
3. It forces you to think. When you’re away from the computer screen, you’re also away from all the calculators, hex editors, and handy tools that often do your thinking for you. You have no choice but to use your brain.
4. You think at the conceptual and visual levels. When you begin doodling and drawing diagrams to try and solve a problem this is very different from writing code to try and solve it. In fact you should never be using programming to solve a problem. If you’re doing this you’re doing trial-and-error programming. If your program doesn’t work after a few ‘goes’, and you’ve checked all your code then there’s probably some fundamental flaw in the way you’re thinking about the problem. The best thing to do in these situations is move away from the computer and start drawing diagrams, which are a much more natural way of understanding concepts. When you draw the diagram from scratch the variables you need will naturally emerge and you may even find a much faster or better way of solving the problem because you just *see* it in the diagram.
5. You’re improving your cognitive skills. Like anything, the more problems you solve with pen and paper, the better you’ll get at it and the easier it will get. You’ll become a natural problem-solver, and the programming will become the easy bit, as it should be. You’ll learn to separate the concepts from the code and once you’ve done this you’ll be an elite programmer.
computersciencealgorithms 