This is a guest post from Cara Borenstein. Enjoy.
Dear new developer,
A couple of years ago, I started my first job in Silicon Valley. I was a junior software engineer at a fast-moving company and I was so excited to have the opportunity to learn. I worked hard. I looked up terms I wasn’t familiar with. I was constantly asking “how?” – “how do I do this?”, “how does this work?” I was shipping code and learning fast.
Only after a number of months, did I realize I was doing something wrong and letting my team down.
It came to my team’s attention that we had chosen the wrong type of core technology for one of our main projects. The team leaders wanted to understand why we had chosen this technology.
I had no idea why we had chosen this technology because I had never asked. Had I asked, we would’ve realized pretty quickly that this technology wasn’t a good choice for our system. But I was confident that my senior teammate always knew the right choices to make.
I didn’t think I knew enough to ask. I had what’s commonly referred to as “imposter syndrome”.
My failure to ask why wasn’t just a missed learning opportunity for me. It resulted in my team making an expensive mistake of choosing a wrong technology.
Now I can see that I did know enough to ask why and it was my responsibility to do so. The same goes for you, new developer.
Software engineering is a lot about tradeoffs – choosing one software design over another. Design trade-offs are often not completely clear cut and they warrant a discussion. You don’t need to have decades of experience to be able to understand the choices you and your team make. You just need to do your part to make sure your team has these discussions.
When you ask your teammates why you push them to explain their thought processes. This helps your team to more thoroughly evaluate different options and to eventually arrive at better decisions.
Moreover, these whys create some of the best documentation for future engineers that join the team. If the thought process behind a choice wasn’t obvious to you, it will likely be confusing to many future team members too.
How to ask “why”
Here are some tips that have worked well for me.
First, make sure that you are asking “why” with a mindset of learning and understanding, not blaming. This will shape how you phrase your question. For example, you can start your question with “I’d like to understand why we…” or “I’m unclear as to why we…”.
Then identify one person who is likely best to discuss “why” with. More often than not, you’ll want to start by asking one senior engineer on your team or your technical lead. After speaking with them, if there’s further discussion or changes needed, you can bring this to the rest of your team together.
To initiate your question, bring it up informally without an expectation of immediately discussing it. This can be in an informal conversation, at your team’s daily standup, or in a Slack message. For example, you might ask – “Hey teammate, I’m confused as to why we’re… Do you have time later today or tomorrow to go over it?” With this approach, you can communicate your question while being respectful of your teammate’s time.
How to document “why”
Now that you’ve asked “why,” you may have driven some changes in your team’s plans, but you definitely have learned something interesting. Write it down! This is some of the most useful documentation your team can have.
When writing down why be sure to include
- your question
- a summary of what you discovered
- any constraints that impacted your team’s choice
- any other options your team considered and the pros/cons
- any action items for your team given what you learned
Ask your teammate to review your written “why” to make sure you didn’t miss anything and are on the same page. Once it’s approved, share it with the entire team.
If your team currently uses a wiki or shared drive solution for documentation, you can
- create a “start with why” folder
- write a new document for each “why” within this folder
- add a hypertext link to this document from each software doc that’s impacted
Start asking “why”
So, new developer, asking “why” will help you learn faster and help your team make better choices. And writing down “why” will provide your team with useful documentation for future work. So get started now. Start asking “why.”
Sincerely,
Cara
Cara Borenstein is a founder at Bytebase – a collaboration tool for lightweight knowledge sharing. If you’re interested in a faster way to capture and organize your “why” learnings, you can try out what we’re building at Bytebase.
Letters To A New Developer 