How I work

At this stage, I’m tempted to put “I don’t” and leave it at that.

Maybe I could have thought of a better title for this post. I just wanted to document, for myself mainly, how I think I do work, how I approach a project, how I manage multiple projects and how I decide when enough is enough. Hopefully this will help me to refine what I’ve been doing.

The first thing I guess is when and where I get to code. Outside work, I have only a little time where I can sit down and code. The first is weekends. Weekends are nice blocks of time that I can spend coding. There is a lot of other stuff, however, that needs to be done and unless you live alone, you usually find that when you’re in the middle of a problem, it’s suddenly time to go shopping or something. Secondly, there’s evenings. These are similar to weekends, but obviously with a lot less time blocked together. Finally, there’s while commuting.

Going into more detail, I usually do different type of coding in these different times. Weekends I usually try and find slightly larger issues that I can make a significant dent in with a couple of hours work. I usually document as I’m going along here, because the expectation is that time will be relatively broken up. Evenings I don’t expect to do a lot, I occasionally finish off things that have been bugging me. During my commute I tend to make the most actual progress. This is because it’s more of less an hour of entirely uninterrupted time that I can sit on a train. I usually pick one relatively small feature I know I can complete in that time. I often don’t write much documentation as I just churn through the code to get it working. Occasionally one of my journeys is spent going back over things and documenting what I’ve done.

I should mention at this point that not documenting code is bad. Very bad. I, like a lot of other programmers around, are particularly bad at keeping documentation up to date. I do make an effort though. Even when I code on the train and write barely a handful of comments, I do attempt to name variables and functions well enough that most comments are superfluous. There are 3 ways I use to actually add comments to my code. The first and most regular way, is to reread my code after a week or so of not looking at it and attempt to figure out what it does. If it wasnt immediately obvious, I then add a comment so next time I just need to read the comment and not figure things out. Secondly, when working through an idea I’ve got in my head, I often write a bullet point list in comments, in an empty function, then code in between the bullet points. Finally, I do occasionally code as I go along, but I’ve found that it doesn’t necessarily lead to the best quality comments, even if it is the most “efficient” way to get the project comment count up.

Next topic to skim over I guess would be the projects I actually spend my time on. I unfortunately have what has been called the #1 deadly sin of programming. Frameworkitis. I have a tendancy to spend far too much time setting up a project and generalising, and not enough time developing specific features. I have attempted to address this (with mixed successes) in a number of ways. First of all, when it comes to working on projects, the starting is always pretty similar, so I’ve endulged my frameworkitis a little made a generalised library template. I can now clone this, run a script to rename the library and it’s ready to go. Also, when I’ve got the urge to make some of these generalised features, I don’t just say no, because I know it will eat at me, instead I’ve started defining exactly what features I want, and then making small, self contained libraries, with definite goals, then spend a couple of commutes (fast becoming a unit of time) working on those until they do what I want, then tie the library back into the project I wanted it for. It does mean that I spend time working on these libraries, but I can try and manage what I do, and I get discrete components actually completed, rather than going on forever.

One of the major issues I’ve had with projects in the past is motivation. Especially when it comes to limited time to work on things, if you start hitting your head on a problem you just can’t get past it’s quite difficult to stay motivated. A few months ago I spent a long time trying to integrate a GUI system with Maratis. Everything I tried broke. Every crash and error I fixed uncovered five more. What I’ve done since then is something that seems like it might reduce the amount of time I spend on any given project. I have many projects. The reasoning behind it is this: If I have just one project, I end up spending half my time debugging stupid errors. As time goes on, especially with only being able to code in small blocks of time, that number goes up, and motivation goes down. If I have more projects, I can arrange it so that I still spend roughly the same time on the project, but then when things get a bit frustrating, I have another project I can move onto and make progress with. When I come back to the thing that had been causing me a headache, I’ve usually got a better idea at how to solve the problem and I never go to that low point where I almost feel like ditching the whole thing.

When it comes to the small projects I’m allowing myself to do, one of the things I’ve been playing around with is Test Driven Development. I won’t go into many details here, but it’s helped me define exactly what the libraries I’m working on should do, and make sure that they do what they say, without breaking. I have had a look at unit test suites in the past, but I always found them a little too much to get used to all at once. In general, the testing should be pretty simple, so as part of my frameworkitis, I decided what I wanted to do was write my own test suite. I’m actually very glad I did, I might not do it again, but what it’s meant is that I can now very quickly add tests to any of my projects as I know how my simple test system works, and I can easily extend it. If I wanted a more robust testing system, I might just switch to CUnit or something.

One last thing I want to mention is language. By profession, I am a C++ developer, being in mobile games I occasionally do some Java and ObjC. I’m currently working on an ObjC project. I can also write in C when required. All these languages are obviously very closely linked. I feel that knowing C (or, ASM) is pretty fundemental in writing good code, knowing which algorithms may be slow and why. As I don’t do much C at work, I have started writing my libraries using pure C, to make sure I still can. It does often mean things like writing a list implementation, but it’s surprising how quick that actually is. At the time of writing, I don’t have any projects in other languages, but I often do try things out in lua, sometimes ruby or whatever language seem to make sense at the time. As with a lot of things, variety is the spice of programming.

To see which projects I’m currently juggling, take a look at my projects page.

Am I doing it all wrong? What would you do? Leave a comment and let me know!

Leave a Reply

Your email address will not be published. Required fields are marked *