You know more than you think

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.

Don’t Shit on Someone Else’s Work

Dear new developer,

There will come a time when you are looking at a system and trying to understand the choices behind it. You may be looking at a particular class, a subsystem, or a more fundamental choice, like the language or the system architecture.

And you’ll wonder what the hell the initial implementer was thinking. You’ll wonder why this system is still in production. You’ll wonder why someone didn’t fix this.

You will be tempted to trash talk this piece of work to your colleagues.

Don’t do this.

Why?

It’s not helpful. Now, it’s perfectly acceptable to point out issues and ask questions about why choices were made. It’s a good idea to suggest improvements, whether those be code changes, removal or replacement of portions of the system or something else. But complaining about the existing system doesn’t do any of that. It’s just complaining.

It displays a lack of empathy. Chances are you don’t know the constraints and pressures that the original implementer and past maintainers faced. Making judgements based on code without knowing the constraints is like hiring someone based on the color of their shirt–you just don’t have all the information needed.

Trust me, in the future you’ll face constraints, like lack of knowledge, time or labor or money, that will cause you to make choices that are suboptimal. At least once in my career I’ve come across a boneheaded piece of code. Cursing under my breath, I wondered “who wrote this crap?”. As I pulled up the commit log, my face fell as I realized that I had. Doh!

(What should you do if the code or system doesn’t work at all? In that case, the questions about constraints and understanding how a failed system was built are even more important. But again, complaining doesn’t help anyone at all.)

In short, when you are working in a codebase and trash talk it, you are the critic, not the man in the arena.

Sincerely,

Dan

Beware Of Your Arrogance

Dear new developer,

I wrote this post years ago, but it still applies today.

Ah, the arrogance of software developers. (I’m a software developer myself, so I figure I have carte blanche to take aim at the foibles of my profession.) Why, just the other day, I reviewed a legal document, and pointed out several places where I thought it could be improved (wording, some incorrect references, and whatnot). Now, why do I think that I have any business looking over a legal document (a real lawyer will check it over too)? Well, why shouldn’t I? I think that most developers have a couple of the characteristics/behaviors listed below, and that these can lead to such arrogance.

Just because you are good at something valuable (development) doesn’t mean that you are good at everything. I was blinded in my youth because I was good at asking questions, paid attention to details, and was good at creating logical constructs in my head. That is helpful in so many contexts.

But it is also true that almost every profession has as long, if not a longer, sense of history and as big, if not a bigger, well of knowledge than software development. So beware that your ability to probe, ask questions and solve problems doesn’t inadvertently (or worse, intentionally) dismiss the learning of other professions.

On the flip side, domain expertise (through lived experience or study) and software development is a powerful combination. You can model software such that end users can speak in the domain. You’ll be closer to understanding their problems.

Another issue with arrogance is that when you’re sure you know the answers (or have the right way to find them), you don’t listen to other people as well.

I was very happy to charge forward with whatever solution I thought made sense, and that led to suboptimal solutions. Both in the coding sense and in the sense that you have to bring people along. The best coded solution in the world won’t work if people won’t use it. So listen to your users and make sure you fully understand their worldview as best as you can before you charge ahead implementing solutions.

Sincerely,

Dan