Category Archives: Lessons learnt from…
Want to write some code? Get away from your computer!
I’ve recently realised something. The best place to write code isn’t in front of your computer, with your compiler, IDE and tools. The best place to write code is far, far away from any of these tools – somewhere where you can think properly. For a language with which you are fairly familiar, the mechanics of translating the program in your mind to a program that the compiler can compile (or the interpreter can interpret) is fairly easy – it’s coming up with that program in your mind which is hard.
The other day I was on a train journey. I had my laptop, but no internet. Unfortunately I was using a commercial programming language (IDL, as it happens) for which I need to use my university’s site license. As I didn’t have access to the internet, I couldn’t get hold of the site license, so couldn’t run the compiler and IDE. Say what you like about commercial programming languages which require expensive licenses, but it stopped me from actually writing code in my editor with the compiler. And…guess what…it actually made me think!
I guess this post is somewhat along the lines of Does Visual Studio rot the mind? and the following quote:
One of the best lessons I learnt from my first boss was: “when your code doesn’t behave as expected, don’t use the debugger, think.”
That is what being away from your compiler forces you to do. It’s very easy to slip into the mindset of:
- Write a bit of (fairly bad) code
- Compile and run
- Test with a poorly chosen test case
- Find it doesn’t work
- Make small change to the code on the off-chance that it might solve the problem
- Repeat…
Of course this leads to code in the end that is ill-understood by the programmer, probably fairly buggy and not well tested.
Being away from the computer forces you to run through all of the thoughts in your head – which tends to take longer than getting a computer to compile and run your code (for small code bases at least…). So you don’t tend to make tiny changes and re-run things, you tend to actually think about what the code is doing. Until I did this on the train the other day, I hadn’t actually run a piece of code on paper (that is, written down columns for each of the variables and worked out what each value will be at each stage in the program) since my Computing A-Level exam!
In the case of the code I was writing the other day, I managed to produce some high quality, fast, bug-free code by writing it in long-hand on a piece of paper, thinking about it, gradually typing up bits of it, thinking some more, and then after a long time trying it in the compiler. The code (which was some region-growing image segmentation code which involved lots of recursion) was eventually copied from my piece of paper to my IDE, compiled (with only one syntax error – impressive I think) and ran correctly first time (and completed all of the tests that I had also devised on paper).
Job well done, I think, and a useful piece of advice, I hope.
Lessons learnt from: My dissertation
This is the first in a series of posts on the lessons I’ve learnt from various episodes in my life. First up: my dissertation.
In case you’re not familiar with dissertations: they are the large written projects which are often given to students in the final year of their degree. The details of mine are available on my academic website. Here I want to try and distil my experience into some generically applicable lessons that can be applied to other dissertations, PhD theses, other projects…and maybe even life generally!
1. Start early
Apparently the most common piece of feedback from students after they’ve finished their dissertations is “I wish I’d started it earlier”. I took this advice and started very early, doing a lot of work on my dissertation during the Easter holiday of my second year, but I still had a bit of a rush at the end. I also put an extra week into my schedule to allow for ‘unforeseen problems’ and was really very glad I had done this, as I suddenly found a major problem with my work a week before the deadline!
2. Keep things organised
I’m a big fan of PhD Comics and one of their comics perfectly describes the bad habits I tend to fall into: A story in filenames. As I’m working in remote sensing I have a large number of image files, both original images from satellites, and a large number of images I’ve created through processing the original files. It gets terribly difficult to find sensible names for the files, particularly when you’re a rushing a bit, and so I often slip into calling them test.bsq or test_again_more.bsq or even the particularly bad test22222_robin.bsq. Through doing this I’ve spent far more time than I need trying to find particular files, and have often ended up with file duplicates taking up extra hard drive space.
3. Spend a lot of time just thinking
I find it very easy to slip into a very mechanical way of doing my academic work: click this button, save this file, produce this graph, write this paragraph – so much so, that I sometimes forget to actually properly think about my work. I got into this phase a number of times during my dissertation, and in fact the major problem I found at the end was caused by this (I’d blindly continued down my planned path for the discussion section without realising that I wasn’t actually discussing the questions I was meant to be answering). I was reminded of this today when I started writing a very simple, mechanical discussion section for a project – along the lines of “This value is big, this means X. This other value is small, this means Y. Overall this worked ok-ish” (although obviously in more academic language!). At this point I noticed, forced myself to stop, and then took my notes away from my computer and went to have a think. I actually went and sat on the sofa near the School of Geography reception and sat and thought deeply about the problem. Fifteen minutes later I came away with a lot more insight into my project, what I’d found, and what further work could be done.