How to ask Questions as a Jr. Dev
Asking questions in a coding bootcamp is expected, but once you transition to a real job, it feels different. You’re no longer talking to instructors, whose main job is to teach you, you’re talking to coworkers. Busy coworkers. Suddenly each question feels like it has judgement or risk attached to it. “Is this a dumb question?” “Am I wasting their time with this?” “Am I dumb for even needing to ask this?”
Look, I’m a Jr. dev too, I understand the feeling. No matter how friendly my team is, I still feel self conscious about asking too many questions. But the reason I became a programmer is because I love solving problems. So, I studied the kinds of questions I kept having and boiled them down into 4 main categories:
- Bridge Is Out
- Toll Bridge vs EZ Pass Bridge
- Long and Bumpy Roads
- Oh God, How Did I Get In This River
After I made charmingly disarming names for each type, I came up with helpful strategies to deal with them.
1. Bridge Is Out
These are problems that are literally impossible for you to solve on your own because the solution is company, or even developer, specific. This is a bridge you cannot cross without help. These are things like: the locations of documentation/passwords, how to set up your environment, what a company’s jargon/abbreviations mean, etc.
Solution: Ask once, take notes
You are going to have to ask these types of questions, but on the bright side, so did everyone else. However, you can help yourself out by only asking these questions once. Do this by keeping up to date and thorough notes. Every time you find yourself asking a dev a question about the systems, you should always make a note of the answer.
If the question is about a higher level concept, write about a paragraph that explains it in layman’s terms. If something is a process, write down each step starting from scratch. I write my notes as though I’m talking to a forgetful stranger, because when you look back at them in 6 weeks, that’s going to be your state of mind. Trust me on this one.
2. Toll Bridge vs EZ Pass Bridge
These are questions about company specific code that you could eventually figure out on your own, but a senior dev could do it faster. For example, let’s say you’re tasked with refactoring some files. Yes, if you: followed each callback, looked up the function signatures in the company docs, and messed around with things for two hours, you could figure it out. But if you asked the dev who wrote it to explain it, you’d be all set in like 20 minutes. What should you do?
Solution: Try on your own, but pair if there’s time
Even if it will take you longer, learning to decipher someone else’s code is an unbelievably useful skill. Becoming self sufficient is an essential part of being a developer, and it’s also a handy cure for imposter syndrome. Plus, the more you do it, the better you’ll get. After a certain point, you may even prefer the learning process over someone giving you the answers.
However, these types of questions are also great opportunities to pair up with more senior developers. Now, instead of asking a quick question, you’re going through the codebase with someone who wrote it. If you tried on your own, but hit a roadblock, that wasn’t wasted time either. The research you did will allow you to ask more specific question and get better answers.
3. Long and Bumpy Roads
These are questions about things that are in no way company specific. We are finally onto Google-able problems. Things like starting on a new team, so you need to learn some of the new languages in their stack. You know “the answer,” it’s to learn a whole new language. It’s just going to be a bumpy ride
Solution: Google it
These are my favorite questions because I don’t need to bother anyone on my team for help. Unfamiliar with the syntax? Google it. Weird error? Copy it into Stack Overflow. Don’t know how a library works? Check the docs (or if you’re lucky, find some YouTube videos). Easy peasy.
Kidding aside, if you’re stuck with a crazy problem and the internet’s answer was to shrug you off, then it is time to ask your team. Briefly ask a teammate for help and tell a teammate all the approaches you’ve tried and why they didn’t work. Often times, it only takes another set of eyes to see a solution that was there the whole time. The key here is: try your best to solve it alone first, because odds are, you can.
4. Oh god How Did I Wind Up In This River
These are the kinds of things that have gone so wrong, so quickly, it literally couldn’t be as serious as it appears. A PERFECT example was when I loaded a project, went to a new git branch, and watched my browser explode. There were page long server errors, it looked like a dozen files we’re missing, and just for fun, Nginx said the website didn’t exist.
I tried to stay calm, but before I could even ask, “What happened?”, the dev next to me said, “Ugh, I hate when Docker does that. Run npm restart, sometimes it’s too dumb to keep track of branches.” I typed that into the console and everything was fine.
Solution: Quickly ask your team
If you feel like what you did couldn’t possibly have crashed the entire system, it probably didn’t. These kinds of situations are great for your team’s Slack channel (or whatever group forum you use). Describe the error and ask if it’s happened to anyone else. There’s a 99% chance it has, and your team will give you the quick answer to fix it. And next time that same weird thing happens to someone else, you get to be the helpful one with the quick fix. Just be sure to save the answer in your notes!
Bottom line: don’t be afraid of questions
As the old saying goes:
Ask a question and you will be a fool for a moment. Ask no questions and you will break a production server.
No one likes to bug their team members for help all the time, but the fact of the matter is, there will be times when you have to ask for help. And that’s a good thing. A well thought out question shows you’re engaging with the codebase and growing as a developer. If you want to learn all you can, the fastest way is to ask questions. Whether they’re to yourself, the internet, or your team, I hope the strategies listed here will help you ask the best ones you can.
Happy coding everyone,
Mike
