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 :)
- If you’ve been struggling with a bug in a 20 lines functions; split it up.
- If your problem involves the client and server side; develop and test these separately.
- If you must develop a task that involves different levels of abstraction / libraries / APIs, split it up.
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…):
- the thumbnail generator (takes an image and create thumbnails for it - uses the file and image library)
- the S3 manager (takes an image and copy it to an S3 bucket - uses Amazon S3 to copy the files there)
- the actual script (uses the ORM + the 2 above modules)
- records which entities have thumbnails
- prioritise which ones need thumbnails to be generated (no thumbnail or updated image)
- generate thumbnails and save them to S3
- log results
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:
- the user input/output
- you’re testing by typing some text in a form; use a proxy like Charles to check the actual HTTP POSTed data
- this will help you to find HTML/JS error (enctype attribute missing is a classic)
- check the framework “request” object
- check the framework “form” object
- check what value you give to your service
- check what’s updated in the database
- if using any external API, check their logs
- you got the idea, check everything
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.