François Constant logo

I can't do it, I'm stuck

March 2016

You’ve been delivering high quality code for days, weeks, months… and it suddenly hits you; you’ve been stuck on that one feature or bug for two hours with no success at all. Not only you didn’t make any progress but you don’t even know if you’ll ever be able to get it done/fixed. The only thing you’re sure about is that this is getting to your nerves. What should you do?

1.Take it easy

It happens to everyone and only a developer with serious ego issues wouldn’t admin it. You’re a human being, not a machine. Go for a walk and get a treat (coffee, tea, sweet food…). The worst you can do is to stick with your problem for 2 more hours with no result. Taking a break will help you in the long run; a five minute walk is often enough to get a new perspective on your code (+ it’s good for you).

2.Do something else

If you’ve got other tasks to work on; it’s probably a good idea to do one of these right now. This is a rare situation where task switching is preferable.

3.Explain and challenge it

Explain what you’re trying to do; what you’ve done and what you’re planning to do next. You don’t even need to bother anyone; simply imagine that you’re explaining the problem to someone skeptical ! Basically, you could run through the calls as the computer would and simply print every variables in various places and explain what the values should be and why. It’s important to do this in the full stack and with all values (basically not assuming than anything is correct).

4.Break it down

Breaking down tasks and problems arguably is the most important skill a developer must have. It’s really obvious but we somehow forget about it once in a while :)

The latest one is the less obvious. For example, a script that generate thumbnails and save them to Amazon S3 seems to be a unit but it should actually be split into three distinct modules (functions / classes / packages…):

5.Don’t overthink and get started

Sometimes you get stuck into “analysis paralysis”. In that case, the best thing to do is to break the problem down, pick the easiest part to build and build it. Then build the second easiest part, etc. Once you reach the tough part you’ll probably realise that it wasn’t that difficult after all.

In the above example, writing down the S3 manager is probably the easiest part.

6.Test it

Unit and functional testing are here to make your life easier. If you find yourself saying: “that should work”; unit test the hell out of it. If you break it, congratulation, you’ve found the issue; if you don’t, you now know that the problem is somewhere else (at least it’s not part of the X use cases you just wrote).

Writing automated tests also helps you with step 4.

7.Look at all the I/O

Everything is a set of input/output systems (I’ll let you sleep on that one) ! In programming, you input some data in a function and get an output. When you debug, you want to look at all of them. For example, if there is a bug with a form, you want to check:

8.Start over

You’ve spent 2 hours doing something, it doesn’t work; just delete it all and restart (by writing tests firsts). Yes, this is tough but totally worth it.

9.Ask someone to help out

I find fixing other developers bugs 10 times easier than fixing my own… I’ve always been surprised by developers who never asks for help and/or advices. No one will ever think you’re not good enough because of it. If you’re not lucky enough to work with competent developers, remember that they are everywhere and ready to help out as long as you put the minimum effort to express your problem properly. Try Stackoverflow, forums, mailing lists, chats, etc.