Often I find myself suffering from a chronic bout of “project fatigue” – I made this term up off the top of my head so don’t go to your doctor asking about it 😉 . However, it’s not the symptoms of this illness that concern me, it’s the consequences of getting it. So what is this “project fatigue”?

You may be one of the lucky ones never to have experienced this, but I know my close friends who also work in the programmer trade have suffered. It can onset at any time. It’s characterised by a morning or afternoon of doing anything but typing code into the computer, which can then be followed by days (or weeks) of doing absolutely nothing related to the work you’re supposed to be doing. And it all happens because you got tried/bored/frustrated/stuck with the project you are working on.

When you first start a project (or a new job for that matter) it normally has a euphoric feel to it. You charge in head first, and it’s brilliant, you are learning all these new things. You come in every day and after the obligatory email and quick favourites check you are straight on to coding away like a demon (or daemon). You’re thinking that “if I’m this productive and can get so much done, I don’t understand why it takes so long to finish things”. What you have forgotten about is THE FATIGUE.

So after maybe a month of working away night and day, it hits. Myself, I normally find it starts when I find out that the way I was doing something doesn’t seem to work. This inevitability means that some of the code you have written is now useless, and other stuff you have done really should be changed to accommodate the new design. To generalise, I would say that it causes you to do ANYTHING just to get the project done. This maybe because you either don’t have the time to let the fatigue pass, or that you are just so desperate to get off the project that anything will do.

What this means is that where before you were creating a design of your code to die for, you now just make sure that it “works”. This is where it becomes so very easy to do some bad software engineering.

For example, you think “I should really change that class/method to such and such” but you also are thinking “well I could just hack round it by doing something not so nice, as that is bound to be quicker”. When you start thinking like this you should ALWAYS make sure that you do the former rather than the latter, as much as it pains you to do so. Why? When you come back to looking at the software for a later version you will be glad you done it, and also it never takes as long as you think to do it the correct way.

So how can we avoid the fatigue? I really don’t know, maybe YOU have some suggestions? What I tend to find helps is leaving the code for a day or so and not think about it. Why not write a script! Obviously this “leaving it for a day or so” may not sit with your employer so well, but if he only knew that it would mean less bugs in the long run then it may be a different story. I dunno, as this line of thought doesn’t always work.

What I think is a far better option is to have good mentor. As I would imagine that about 98% of the fatigue is caused by a lack of motivation to finish or that you are stuck on a certain problem. Talking to someone about the work and resolving points that you are stuck on can be empowering. You can often be even more productive than just before the fatigue set in after a simple chat with someone – I often experienced this after a meeting with my supervisor when doing my PhD. It’s important to have the right person doing the mentoring though – as there are people that can make the situation worse by just plain confusing you or demoralising you with their “superior” knowledge.

So in the style of a counselling group, my name is Gregg and I’m suffering from project fatigue. What are your suggestions?