One thing I enjoy in my first-ever dev role is the opportunity to learn from the brightest minds and expand my developer skillset. Encountering coding roadblocks and known-unknowns is par for the course, and over the last few weeks, I believe I've honed the skill of properly asking another dev for help. I'll share that now:
Step 1: Triple-check that you are in the right directory, on the right git branch, and that your command syntax is valid and error-free. Following this rule has resolved perhaps 85% of my coding issues 😓 [addition from Jan Schröder: Check that your servers are running and your database is connected].
Step 2: Actually READ your error messages (yes, even those parts that are gibberish). I used to run for the hills whenever my machine spat out a deluge of error messages with nary a complete sentence in sight. However, a comprehensible explanation of why your app is complaining probably lies nested within all those characters. Take the time and read, then tease out any explanatory or descriptive sentences.
Step 3: Google whatever you teased out in Step 2. You'll probably score several StackOverflow hits. As you peruse the message boards, pay attention to version, software, or system architecture differences between the solutions you read and your own. [addition from aksfjh: Also try searching your team/org projects in Github for similar words, functions or errors. Someone else may have implemented code that you can learn from without going to them directly.]
Step 4: Scribble a rough summary of your troubleshooting process and rubber-duck it. I can't tell you how many times a workable solution has popped into my head during this step.
All in all, going through Steps 1-4 shouldn't take longer than 30-40 minutes.
Step 5: This next point may not be applicable in all work environments, but for me, I use the least-intrusive method (typically a Slack massage) to get my teammate's attention. This respects that fact that they may be in deep focus, or not open to any interruptions at the moment.
Step 6: Walk your teammate through your troubleshooting process. Provide context and rationale for each decision you took. Your teammate may just point out the solution, or they may take the "teach-you-to-fish" route and ask leading questions to help you figure a solution out. Either way, you've taken a hands-on approach to finding your answer.
I'm finding that one of my responsibilities at work is proving that I'm a good learner, a fast learner and an intelligent inquirer. I hope this guide helps you portray yourself as the same.
Top comments (11)
Somewhat of an add to step 3, try searching your own team/org projects in git for similar words and functions you are using (and getting errors for). Many times, someone else has implemented or used something similar, allowing you to learn from their example without having to go to them directly.
great point - and something I do a lot; I will add!
Also search the issue tracker, in case of a bug.
A secret tactic: search the issue tracker once more, when cause was found. Others might have stumbled in the same problem.
It happened to me that the fix just unlocked a second bug, and all that (along with a fix for a third bug) was already found and solved in a different release.
Step 7: If you've reached this far, you might want to take a step back, go for a walk, boil a pot of coffee, and take your mind off the problem. A surprising amount of time you just need to clear your mind off the problem to come up with a solution.
One thing I've added, once I've worked through a similar version of your awesome steps above, is considering what questions they may ask me that I hadn't thought of. I don't know how many times I've stood up and thought "wait, they're probably going to ask for x, y, and z" and found my solution somewhere in there. As I grow in my experience, I hope I'll reach those kinds of thoughts much sooner.
Great points! My rule of thumb is, ask after one hour of not making any progress despite various attempts.
A opportunity to ask without interrupting is in a coffee break.
I want to write in depth about debugging in my book - slowly getting there.
At the moment you use slack or any other messenger, follow this old but gold rules about getting help on IRC:
workaround.org/getting-help-on-irc/
Most important, share what you already tried to solve the problem and provide examples to reproduce the error
I read your subject and was planning on replying “It’s never lazy to ask for help!”
While I do think that’s true, this is a fantastic list of things to cover before doing so. Although depending on the team dynamic, I might suggest dropping the error messaging Slack (or whatever) as your starting these steps Incase anyone has seen the message and can give you the answer quickly.
Parting thoughts...
What’s wrong with being lazy. Lazy engineers automate their jobs and move on to bigger better things. 😉
True story: As a “Jr. HTML Programer” in the late 90s, I learned Perl because I was took lazy to make 100s of HTML a day changes by hand. The rest as they say...
Food for thought.
Nice!!!! It's also something I have been questioning myself on, thanks!
For the web devs, in step 1, check that your servers are running and your database is fine.
Oh absolutely! I'm adding this to the post! :D