10 must follow rules for asking coding questions

Part of being a good developer is knowing how to ask good questions to other developers when you are stuck. As a junior developer you are going to have more questions than at any other time in your career and you could probably do with someone on your shoulder all day long to help you out.

This of course is unrealistic and constantly pinging other developers on Slack, Zoom or in person is a quick way to “not make friends”. So, how can you ask the number of questions you need to without feeling like you are a burden on the team or worse, getting a black mark against your name?

There are a few rules I like to stick to before speaking to someone, these might sound like they will slow you down, and in the short term they will. In the long term you will learn more, ask better questions and move faster.

5 rules to check before asking a question

• Double check for simple typos: Go look at the git diff viewer that your text editor or IDE has so you can easily see what changes you have made since the last commit and see if you’ve missed a semicolon, miss-spelt a variable or something else simple.
• Go and read the project/repo Readme: If you missed a bit of config or setup then the answer could lie in there.
• Google any and all error messages: Find the last call in the stack trace that is from your code, copy that error and paste it into Google, most errors have been seen before and posted online. It might not exactly solve your issue but could get you close.
• Reread the task/ticker you have been given: This will remind you of your starting point and might make you rethink the approach that has lead you to this point, the main question here being “Am I even on the right path?”
• Check your input data: As the old saying goes “Garbage in, garbage out”. If you are working with bad data then your code won’t be able to operate correctly and could well explain why you are having problems.

Speak to a rubber duck

If you have been through all of the above and still have no solution then it’s time to speak to a rubber duck before speaking to a person as a practise run. Tell the duck what you are trying to do and where you are stuck, often the answer will materialise in your mind as if the duck is an oracle. And if the answer still alludes you?

Still stuck?

If you are still stuck after doing all of the above and speaking to a duck then it’s time to find a team member to speak to. Unsurprisingly there are 5 rules to this as well, although just aim to follow at least one - doing all 5 every time is likely to bore people 😀

• Tell them what you tried: You should have already practiced this with the duck, basically just rattle through the 5 rules above in order. This shows you didn’t just give up at the first hurdle and lets them skip over some simple things to save time.
• Suggest something you might have missed: This is great for showing that while you are stuck you might have some idea of the direction you should go in, it could be as simple as “Is there some gap in my knowledge that is an obvious place to check next?” to as specific as “I notice this call to the ServiceAPI, is it possible the problem lies there?”
• Ask if they’ve seen something like this before: This is a quick and simple one and can jog their memory that yes, they saw this 6 months ago and that’s a good place to start.
• Ask if there are any docs that cover this area I can look at: This shows a willingness to carry on looking at this independently and that you aren’t just relying on them to do the work for you.
• Ask for a next step rather than a full solution: Sometimes people want to help you the whole way through but really you just need a next step. This again shows a willingness to take the burden of the work and not absorb too much of their time. It also helps your learning as too much help can sometimes make you brain switch off and information just washes over you.

Using the above rules and steps you will be able to ask as many questions as you like because your team will know you have covered off the basics and aren’t just looking for them to do the work for you