Being new is scary, but especially in tech. I remember onboarding onto my first project, where I was tasked to assist in delivering a design system. I was already really nervous because I was surrounded by seasoned engineers, and I, on the other hand, was completely new and self-taught.
Naturally, I spent most of the first few meetings furiously writing notes and compiling a list of terms and concepts that I would research afterward. There was so much I needed to learn and work through. What is Storybook.js? Why am I getting so many errors while setting up my local environment? I’ve never worked with a codebase this big — where should I even start?! Thinking those questions was much easier than actually asking them.
The difficulty in asking
Before delving into how to ask questions, I think it’s important to recognize why it can be so hard. For me, it was simple: I did not want to sound stupid. The fear of asking a question that would garner a response like, “You really don’t know that?” would stop me in my tracks. The fact is, we are far better when we leverage collective knowledge instead of relying solely on our own experiences.
Taking my own advice, I reached out to another engineer on the project. But when I started to ask my question, what came out was a completely unhinged train of thought. It went from disjointed statements to nervous rambling. In my head, I knew the problem I was having and some of the reasons why my approach wasn’t working. Verbalizing my questions was tough, so I created a method to help me prepare, present, and process a question (and its solution) without stress.
The method
Preparation is key to asking great questions. It also helps me confront my anxiety surrounding my fear of not knowing the solution. Writing things down is key to this approach, so grab a journal and give this method a try. Not only can it help you avoid having to ask the same questions again, but you gain knowledge to inform better thought processes in the future!
Define the problem. It’s possible that while attempting to complete a task, you fell down a rabbit hole that led you astray. Start at square one by defining the problem. Ask yourself what you are trying to do and write down your answer.
List the solutions you’ve already tried. It’s important to know what solutions you have already tried and why you thought those approaches could have worked. List out the issues that arose, then ask yourself what you’ve done to try to fix them. Write down your answer for each issue.
Use your notes to present. When you have your problem and the solutions you’ve attempted, present to the person you went to for guidance. Use your notes to retrace your steps in a clean and concise manner.
Ask clarifying questions. Once you have received the answer, stop to write it down. Make sure you understand not only what the solution is but why it works. Try explaining the solution and the why back to your collaborator to make sure you’ve mastered it. You can also use this time to offer any input that could make the solution “cleaner.”
Say thanks! Now you are on the other side, wiser and with one fewer problem to solve. Be sure to thank your collaborator for their time and understanding.
Owning your okayness
When done well, asking questions feels more like collaboration and less like a one-way information exchange. For instance, when I’m asked a question, explaining my thought process helps me better understand my solution.
Even with this guide in hand, it still may be tough to initiate the conversation with a coworker, and it’s easy to think you’re pestering them. When people on my team have offered to help me along the way, I often remind myself that they offered a helping hand willingly. Be sure to take them up on their offer. It gets easier with time and practice.
Don’t get me wrong, being a master at googling is super helpful, and being self-sufficient is the goal. By all means, take time to explore solutions on your own. But if you find yourself confused and in need of direction, remember: It’s okay not to know everything, and it is okay to ask questions. Hopefully this method will make that exchange of ideas a little easier to broach.
Malcolm Peterson (he/him) is an Associate Engineer at Postlight. Say hello at malcolm.peterson@postlight.com.
