-
Notifications
You must be signed in to change notification settings - Fork 241
What to do when you get stuck when you don't have a ninja
As a new developer, you're going to get stuck on stuff a lot. You'll come across mysterious failures and not have the slightest clue how to begin troubleshooting them.
But even though this will happen, you can't just halt work. It's not okay to just sit there and wait for your next ninja pairing session. So how do you get unstuck when there's no ninja help available?
In most cases, the very first thing you should do when you get stuck is to google the error message you get. Your first instinct may be to start digging through your code and scratching your head to see if you can figure out what the heck is going on. Usually, it's faster to just google the error message because a thousand people will have encountered this same problem before you. The answer may well be clearly documented and readily available to you, just a quick search away.
Google first, and then if you don't find an answer within the first 30 seconds or so of searching, then move onto the next troubleshooting tactic.
Sub-tip: When reading a Stack Overflow question, don't sit there and study the contents of the question. First, scroll down the page to make sure there are actually some answers! Sometimes there aren't. If there are answers, take a quick glance at them. Sometimes it's immediately clear that you're barking up the wrong tree, in which case reading the question would be pointless. Read the question, for sure, but not before you quickly scan the answers.
If Googling doesn't prove to be fruitful right away, ask yourself, "How well do I understand the library/plugin/framework I'm experiencing a problem with?" For me, the answer is often "not very well". Your troubleshooting capabilities will be boosted by gathering some intel on the tool you're using.
Did reading the docs give you some new clues or leads or "ah-has"? If so, it might make sense to start over at step 1, googling, with a new, more intelligent search term.
Any doc you're reading is likely to take the form of a GitHub README. As long as you're there, click on the Issues section and search for the error you're getting. It's possible that this issue has already been encountered by someone else. Maybe there's a discussion and resolution in the GitHub issues.
By putting up a Stack Overflow question, you get the eyeballs of the world's best experts in all software technologies on your issue. Why would you not take advantage of this resource?
When you're posting a Stack Overflow question, don't start with the title. Don't start with any words at all. First paste the relevant code and/or error message so you have some material to work with. Then, once your code is in there, give the reader enough context to understand what you're trying to do and how the results you're observing differ from the results you're expecting.
The use of proper spelling and grammar in your SO question is important. If your language is sloppy you might come off as careless or lazy. If potential answerers assume you haven't done your due diligence on your end because they perceive you as lazy, what do you think that does to their motivation level to help you?
Once you've included code samples/error messages/whatever and a sufficient description of your problem, come up with a title that accurately describes what you've just asked.
For an example of a question I consider well-written, see (http://stackoverflow.com/questions/5836623/getting-lock-wait-timeout-exceeded-try-restarting-transaction-even-though-im)[this SO question I posted].
Your SO question is most likely to get the most answers within the first 15 or so minutes of its life, when it's "fresh". After that it gets stale and sees less activity. So after you post your question, leave that tab open and refresh it every couple minutes. Respond to any commenters. Clarify anything people ask you clarify.
Lastly, if the activity on your SO question leads you down a new path, don't try to ask a bunch of sub-questions in your original question. You'll have way better luck if you just start with a fresh new question that talks specifically about your new, probably more specific, issue.
In the unlikely event that after posting to SO you're still stuck, ask another fellow for help. Maybe someone has dealt with a similar issue before. Maybe you just need a fresh set of eyes to see a mistake you've been blind to because you're too familiar with your own code. Often the very act of articulating your problem causes you to realize the solution yourself.
If you're really really stuck, go ahead and dive into the source code of the library you're using. It may be totally Greek to you, but at least take a peek. See any clues in there? Are there any relevant keywords you can search for in the codebase? If you're having a problem with X, where does X happen in the codebase?
It's easier to understand a technology in isolation than when it's combined with others. If you keep having troubles with a particular tool or library (e.g. Gulp), spin up a blank new project that uses that technology. Can you get a "Hello, world" version working? Can you build on that a little and make it do what you want? Knowledge is the antidote to confusion. You can't keep becoming more and more familiar with a technology and still be indefinitely befuddled by it. At some point you'll grasp the technology well enough to pick back up in the context of the original project.
Your brain has both conscious and subconscious levels of operation. Sometimes, for whatever reason, your subconscious mind can untangle mysterious your conscious mind can't. But if you're constantly running your conscious mind, your subconscious mind might not have the bandwidth to do its thing. So if you're hopelessly stuck and you're completely out of ideas, just go take a 15-minute walk. Forget about computers for a minute. You might find that the solution to your problem magically pops into your head while you're thinking about something else.