One of the best parts of working for a software consultancy is the vast amount of individual knowledge that exists over a range of topics. The ability to ask questions and get help with many different languages or problems is incredibly valuable, especially when starting a new job or project.
However, I’ve realized over the last few months that it’s possible to ask too many questions. And when I get too comfortable asking questions, I rob myself of the opportunity to practice grit and learn through failure or confusion.
In order to combat that temptation, I’ve developed a framework of three questions to ask myself when I feel stumped. They help me decide if I should ask for help or keep trying on my own.
1. Have I given my best effort to solve the problem?
When I’m stuck, it’s always hard to know what to try next. One consistent practice that I have adopted is to brainstorm a few different approaches, then make a proof of concept for each of those approaches. Even if none of them turns out to be helpful, the process of thinking through some possible solutions and their implications only furthers my understanding of the problem.
Another key practice is budgeting the amount of time I will spend on a problem before asking for help. I set a fixed amount of time (usually 20-30 minutes), and if I cannot make any substantial progress in that amount of time without running into a blocker, I take what I’ve learned and ask for help.
These two actions ensure that I have given a fair effort to solving the problem, and they allow me to feel confident that when I ask for help, I truly need it.
2. Is there any documentation that might point me in the right direction?
The whole purpose of project documentation and consistent design patterns is to help answer questions, so they are the first place I go when I am stuck. This practice has helped me become better at traversing codebases to find relevant information and has helped me understand the importance of having consistent code.
There have been many instances where I was able to look at a specific piece of code and adapt it to my use, further reinforcing that pattern in the codebase and in my understanding. In addition to this, the inability to find certain answers in documentation may lead to necessary conversations about changes or updates that need to be made to keep the documentation useful and up to date.
3. Can I clearly explain the problem, my current understanding/approach, and what I need help with?
One of the skills that I have admired the most in my coworkers is the ability to ask good, concise questions. When trying to have discussions about technical topics or problems, I have seen how important it is to be prepared, to understand what you know and what you’re asking, and to have some ideas ready to share.
Before asking someone a technical question, I try to make sure I know enough about the problem to give background information, what I’ve learned so far, what is blocking my progress, and what I’ve already tried. If I cannot give that information, the conversation will not be as effective as it could be.
In addition to that, working through how to ask the question(s) can sometimes make the solution clear. There have been many times I’ve actually answered my own question while trying to frame it properly.
Having this more structured process has helped me a great deal, especially as I’ve ramped into Atomic remotely. It gives me confidence that I’m asking good questions, learning how to solve problems independently, and being as effective as possible in my work and communication with others.