How to Get Unstuck

Jens SchauderOctober 17th, 2011Last Updated: October 21st, 2012

0 38 3 minutes read

Jeff Wofford singles out “getting stuck” as A Programmer’s Greatest Enemy. Stuck as getting stuck with a problem that you just can’t solve. This situation gets frustrating fast. Jeff even tells a story of a coworker getting stuck so bad that he got himself fired.

I agree getting stuck is bad.

Although I’d rephrase it: The real successful developers don’t get stuck. At least not often and when they do they get unstuck fast.

Unfortunately Jeff doesn’t offer any weapons against such an enemy. Michael Feathers offers one solution to the problem on twitter though:

When coaching I spend a good amount of time going around saying “that’s not working, do something else”

So having a good coach obviously helps. But what else is there to not getting stuck?

So here is a list that I think helps a lot.

Be a generalist: If you know only on thing and this doesn’t work you are stuck. If you know lots of ways you have lots of options to explore. It is less likely that all of them are blocked. Often it helps to think in terms of a different technology about a problem in order to get the idea that gets you unstuck.
Analyze precisely: More than once somebody asked me for assistance with a bug where the cause of the problem was nicely described in the call stack. So look exactly at the information you have (and the information you think you have). The first step is to actually read and understand error messages, stack traces and log files.
Ask for help: Work isn’t a competition. It’s team work. So ask a coworker to assist you. Often describing the problem to someone else is enough to solve the problem.
Know where to look for help: I’m quite surprised when people get stuck with a problem and I can solve it by asking google. Of course google is only the first step. For technical questions stackoverflow is a great source. Many libraries, frameworks and systems have their own specialized forums, mailing lists and wikis. Oh and don’t forget their bug trackers.
RTFM: I know it is boring to read documentation. But if you working with a technology every day you should read the main pieces of documentation. Yes I’m thinking of such interesting works like the Java Language Specification or Oracle Database Concepts or HTTP: The Definitive Guide.
Know whom to ask when your team mates can’t help: If you encounter someone who seems to be knowledgeable about a domain, make sure you have her email address available. And don’t be afraid to ask. Most people consider it a real nice compliment when somebody whom they only met once asks them a difficult technical question.
Use the source: A lot of the stuff we use today is open source. So when Hibernate doesn’t behave as you think it should or if Mockito does cool things which might be useful for your DSL, get the source code and get a look at it. If you don’t spend lots of time with it, you probably won’t really understand the source code, but often it will give you hints on what you might do to solve the problem.
Solve a different problem: Sometimes thinking about something else, taking a break and going for a work is all that it takes for a solution or at least a new idea to surface. Just make sure you have something to write with you.