It's happened again: You're working on a problem and you're stuck. Sometimes the code in front of you makes the solution obvious, but not this time. Your google searches return a sea of purple stack-overflow links. Your dog is beginning to wonder if you'll ever get up from that computer again.
A consistent diving line between junior and senior engineers is how they ask for help & how they get un-stuck when facing difficult problems - do they ask good questions or bad ones?
How you ask questions & get help from colleagues will ultimately help you overcome issues & solve problems more effectively. This will improve your output, and will make you seem a lot more "senior" in the eyes of your colleagues / managers / interview panels / potential spouses.
Side note: I say "seem" because junior/senior is often a blurry dividing line, and may depend very much on specific circumstances (company, team, project can all be factors).
How to Get Help from other Engineers
If you're going on a heroic journey to squash bugs and ship features, here's a few tools that will aid in your quest to get help with coding problems:
- Try things! If you've tried nothing, you've no business asking for help. Once you've exhausted the obvious things to try, organize your thoughts. Write down notes. Include everything you know about the code in question, the problem-space, everything you attempted, (if applicable) how to reproduce the problem, and a handful of questions you wish you knew the answers to. Be able to clearly state the problem back to someone in plain language - imagine you're explaining it to a friend that doesn't code. It may help to practice Rubber Ducky Debugging.
- Ask a colleague for help, but don't be vague. Explain what you know (briefly) and what you've tried so far. Keep your notes handy but don't regurgitate it all, just the summary. Then ask questions.
- Ask open-ended questions. Avoid closed-ended questions. Closed-end questions can be answered with quick responses - often yes/no responses. Example: "Do you know what's wrong with this?" (The most likely response will be "no" which doesn't help you at all!) A better question: "Can you think of anything I've missed?"
- Most importantly: avoid general questions, ie "Can you tell me why this doesn't work?" This will annoy people. Most of your colleagues are (hopefully) busy solving their own problems, and questions like these are a red flag that they're about to be stuck helping you for half a day (and ultimately solving the problem for you). Remember, you're trying to get ideas, not free work. If you're looking for ways to get someone to do your job for you, this is the wrong article, maybe try this gem from reddit.
Here's a short cheat-sheet of good questions to ask:
- What am I missing?
- What should I look into next?
- Can you think of anything I haven't accounted for?
- Does it seem like I'm going down the right path?
- What would you do if you were in my shoes?
- What's the desired outcome of this operation?
- Do I have the right mental model for how the system is supposed to work?
One Last Thing
I'm often asked how long an engineer should try on their own before asking for help. There's no simple answer here, other than the usual "it depends." I can say with some confidence that it will usually take me at least one hour to try the obvious things, collect my thoughts, and form good questions. Any less and I'm probably not trying very hard. For the upper bound, four hours is a decent rule of thumb. That's not to say there won't be big problems that take multiple days to solve, but if you're stuck for more than a few hours, stepping back and bouncing ideas off of a helpful colleague can't hurt.
