Hitting Roadblocks All Too Often at Work? How to Effectively Ask for Help as a Junior Software Developer.

Have you ever been handed a task by your tech lead that seemed straightforward enough but you repeatedly have to ask for help?

Maybe this isn't the first time you have to ask for help today (or even this hour) and you are a little embarrassed to ask again?    

Or maybe you simply have no idea where to start?

Here's a simple method for requesting assistance from other developers that always makes me a better programmer. I call it the PADD method (Potential solutions, Assumptions and Domain knowledge, Discrepancy):

1. Try a few potential solutions to attack the problem. If you have no idea where to start, write down plausible 'high-level solutions' (or 'angles of attack') without implementation details.
2. Write down the assumption and domain knowledge you used to come up with the potential solutions. This can be based on your understanding of the problem ('I used method X because the problem has the constraint Y') and your understanding of the solution ('tool X is really good at this kind of problems').  
3. Point out the discrepancy between the expected behavior and the actual outcome. Or in the case where you don't know how to start, the fact that you don't know how to map your high-level solution to the problem at hand.

The PADD method has served me well over the years, and I find it to have many benefits over simply asking 'how do I use this?':

• It shows you have at least made an effort to solve the problem, and not simply interrupting another developer's flow with the associated context switch cost without skin in the game.
• It catches domain knowledge gaps at the top-most level, if you have missed an entire area of potential solutions, the answer becomes simply 'have you thought about using tool Z for this problem'?
• It catches incorrect assumptions quickly, no back and forth assumption explorations are needed because they are listed in step 2.
• It catches misunderstood problems quickly, it's easy to point out the problem is not of class Y and instead should be treated differently.
• Lastly, if the questioner's understanding of the question, their use of domain knowledge, and its application are all correct, then you are 90% of the way there we have a cooperative problem-solving session. I usually switch to pair-programming at this stage, because it's an effective method of skill/knowledge transfer.

In my personal experience, I find this pattern to naturally emerge as developers become more senior. Another interesting note is the shift from 'getting to a solution quickly' to 'correcting assumptions and gaining domain knowledge' as I gained more experience. So while it is definitely more work to ask for help by first listing out my assumptions and potential solution, fixing an underlying incorrect assumption or learning about a new piece of domain knowledge is well worth the price.

If you find this article helpful, you may also be interested in checking out the next post in this series, is it bad to ask for help too often?. It'll go over some more tactical level signs for when and how you should reach out to another developer, as well as some example questions that showcase the PADD method in action.

Happy Coding!