Coding when you’re tired and unmotivated
I've been struggling to motivate myself recently. I spent a lot of my spare time in my twenties programming free stuff after work with no trouble at all, but now in my thirties the energy and enthusiasm seems a little harder to come by. Plus Claire and I are expecting a baby any day now and the last few months have played havoc with sleeping patterns (nothing like what's to come I'm sure!).
Still, it's definitely possible to crank code on your own projects when you're knackered, you just have to be a bit more structured about how you generate motivation and enthusiasm from a body that just wants to watch telly. Note that we haven't had the baby yet (any day now!) so all of this may be completely moot once we hit the real deal, but I figured it might be useful to somebody and I haven't blogged for a while so...
The key to programming motivation for me seems to be all about engineering a low barrier to getting started. I really enjoy spare-time software development, but if I don't get up to speed quickly then it's easy to drift off to doing other things like reading reddit or going through my rss feeds. Here's some things I do to keep my eyes on the prize:
Keep a project diary of ideas and thoughts.
I usually have a text file called 'IDEAS' in the base directory of my projects. In it I keep a diary of thoughts and ideas dated in reverse chronological order (like a blog). Sometimes I noodle in it - write questions I want answered, jot while I think through problems. It is not intended to be read by anybody except me so things are often un-finished, written in shorthand and I rarely write explanations.
The diary serves a number of important purposes in addition to being a low motivation way to get going:
- It's a handy reminder of 'where I'm at' with the project if I leave it for a few days, important for getting up to speed quickly.
- Reading it later serves to motivate myself and galvanises me into action.
- I can 'park' ideas that might be useful later
- It keeps me thinking about the bigger picture. I often change direction with a project as a result of thinking something through in my diary textfile.
Do 'test driven' development.
Test driven development is a great technique generally, but I find it especially useful when I'm too tired to be motivated to program. That also applies when the problem is too big for an obviously good solution to fit in my head and I'm exhausted just thinking about it.
When say 'test driven', I mean really driven. The implementation code written really is just enough to pass the tests. In the early stages that means hard-coded results..:
- Write an automated test. Watch it fail. Hard-code the implementation so that the test passes (e.g. hardcode the result of the implementation function). Watch it pass.
- Write a second test. Watch it fail. Hardcode the implementation so that both tests pass. (maybe by using an 'if input-1 then return this, otherwise return that')
- Maybe do a bit of tweaking/refactoring so that it's not quite so hard-coded
- Write another test ... etc..
The point is that by the time you end up evolving the meat of the functionality, you've already crystalised a lot of what the implementation needs to do and can tackle it in very small baby steps. Small chunks are good for me when I'm tired because I don't need to hold too much in my head at once. The tests passing provides continual positive feedback which is a good motivator and often that gets me out of a programming rut.
Write poorly performing code and optimize later
It's very easy for me to fall into the trap of optimising code early, especially because I'm keeping a project diary and spending considerably more time thinking about the project than actually implementing it. Unfortunately although it's fun to come up with strategies to optimise for performance, coding that way tends to make the implementation code stagnant very quickly and that makes the whole experience very demotivating. To combat this I try to get into the habit of defering performance optimsations by noting them down in the diary instead, and then just concentrate on optimizing for simplicity and code size.
N.B. It's worth bearing in mind that profiling and optimizing your code later is really good fun - I have no problem being enthusiastic about making existing code go faster, especially if I have a good set of profiling data to get my teeth into. Also I find that it's much more time efficient to build something simply and then profile and optimize later. That's really important if you're doing this on scraps of spare time. I can't emphasise this enough: much more time efficient.
Any more?
So that's it. I'd be really interested to hear of any other spare-time-programming motivation tips that people use. With the baby coming I'm going to need all the help I can get!