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 past 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.
Learning to code products doesn't take as long as you think - more precisely, 300 hours to learn, build, and launch. Learn about the history and misconceptions of development preventing you from even starting and then hop on that tech bus.