It reminds me of the writing process a lot. You sit down at a blank screen after having conducted your research and you have to just dig in and find some way of making progress. Many a developer struggles with a blank IDE screen much in the same way many a writer struggles to find influence. When I was learning how to write properly, I was told that “a professional writer can not be like the poet who spends a morning taking out a comma, and the afternoon putting it back in”. We need to work hard. Same with code. A block then is a real problem.

Slashdot this weekend asked How to Get Out of Developer’s Block?, or rather a user asked:

I have spent the past six months working on a software project, and while I can come up with ideas, I just can’t seem to sit down in front of the computer to code. I sit there and I just can’t concentrate. I don’t know whether this is akin to writer’s block, but it feels like it. Have any other Slashdotters run into this and if so how did you get out of it? It is bothering me since the project has ground to a halt and I really want to get started again. I am the sole developer on the project, if that makes a difference.

The comments that follow in the thread that range from the sensible to the bizarre. I have a bunch of tricks I use when I’m struggling, so thought I’d put them together

1. Get enough sleep – you have no idea how sleep deprivation can mess you up when you’re trying to concentrate. When I’m working on code, I take a minimum of 10 hours sleep a night. Anything less, and I’m not going to be able to think in purely abstract terms for 8 hours straight during the day.
2. Exercise – and whilst those of you who know me might laugh, it’s important. I actually do get regular exercise when I’m coding full-time. Just a long walk at the start or end of the day can be enough. Something that gets the hear rate up helps though (perhaps explaining why I always code better the day after… errr… private stuff that gets my heart rate up!).
3. Don’t drink alcohol – this was something I got when I was trying to sort out my pilot’s license. When you’re going flying, I don’t drink for 24 hours before getting into the plane. I found my workload was easier, my writing got more fluid and my code went up a gear. On big client projects I don’t drink at all on school nights. If I’m drinking in the evenings whilst on a project, it’s because the project isn’t challenging me and I’m bored.
4. Clear your environment out – I’m currently sat at a desk with perhaps 150 items of paperwork on it. In this environment, I can not focus on code. My mental processes are cluttered because my physical processes are. Tidying up might seem like a stupid way to get out of a block, but I genuinely find that a clear working environment leads to much clearer mental processes. I don’t know how or why, it fascinates me, but just get your physical environment fixed up and suddenly your mental environment starts to fire a little better than before.
5. Write a trivial test – this is the code version of “free-writing” that I sometimes use to unblock on writing an article. Basically write a small test (or spec if you’re BDD) for something almost trivial and then get it to pass. Repeat. Now you’re back in the game.
6. Work on the design – it’s amazing how bad we collectively are at really thinking through a problem. Go and work on some wireframes or develop some sketches of the underlying schemas and try and simplify them. Reduce things down, and suddenly you’ll see areas you can work on right away outside of the problem you’re blocked on. If you’re not able to delve into design or architecture because of the nature of the project, quite frankly you need another bunch of guys to work with.
7. Try and find it done already – I once spent a lot of time trying to work out how to solve a particular problem. The answer was non-trivial to implement in my mind. I kept putting it off. I was scared of how bad I could end up making my solution. In a fit of procrastination I spent an hour digging around the problem area and eventually found an open-source tool that did exactly what I needed, out of the box. Well, that solves that problem…
8. Are you scared of success? It might sound like a stupid question because success is good, right? But when we succeed at something, we conquer some barrier we have worked to overcome for a period, things change. Suddenly people might look at you differently. Perhaps you end up having to work on a less interesting project. You might want your current project to be a success for other reasons. Ask yourself whether you really want this project to succeed. And then realise there’s no getting out of it: failing, or staying where you are is just as bad an outcome and harms you, your self-confidence and your reputation.
9. Find a SCRUM meeting somewhere – one of the very best things about daily stand-up meetings in SCRUM projects is that the meeting only has three topics of conversation: outcomes from stuff you agreed to do in the last meeting; what you plan to do today to further the project, if anything; and obstacles in your way. Not everybody has a team (and sole development is the hardest form there is, trust me), so find a SCRUM somewhere else. Use Twitter, your blog, a group of friends down the pub, anything. Just talk about what’s stopping you and see if anybody can help you in any way, or offer suggestions. Obviously asking a friend about a tricky problem relating to class inheritance isn’t going to yield results if they don’t know what you’re on about, but ask around more liberally than you have done to date.
10. Work on something else – we all have other projects on the go. If the above isn’t working, just go and get on with something else. Your subconscious is dealing with the problem and will come up with a solution. Just make sure you hit your deliverables schedule if you have one!

Now comments are back up, I look forward to hearing of any other tips people might have.