Developer Pitfall: When to call it quits on a problem

We’ve all done it, you’ve run into a problem while developing which you bash at for a few hours and before you know it, you’ve lost the day, not got anywhere and feel completely frustrated. What’s more, is it’s usually something so screamingly obvious and/or simple that you just know you’ll find the answer on Google.

Rather than pulling your hair out for hours on end, there’s a rather simple rule-of-thumb that you should follow:

If you’re able to bash at it for 30 minutes without feeling you’re getting any closer, you’re probably looking at it from the wrong direction and having someone else’s perspective on the problem will probably answer it within seconds. By walking away from the problem you’re also taking away the pressure and you’ll often find the solution comes to you.

Another advantage of putting a time limit on the issue is it avoids you losing the day and should also mean you’ve explored Google and the lists so when you ask your “friend”, it should stop you getting that annoying lmgtfy response when asking for help (it’s a similar concept to the “wait 1 minute before sending” facility within Outlook).

So the next time you realise something’s taking longer than you think it should, start the timer!