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.

What if I have to make a technical decision and I don’t know the right answer?

Dear new developer,

Sometimes you are confronted with decisions for which you simply don’t know the correct answer. This has happened to me many times over the years. A recent example is that the client wanted to build an online quiz. They wanted to be able to edit quiz questions and answers. They wanted it to feel like an application (rather than a website). I had never built something like this before, but I was the person best situated to make the architectural decision which would underpin this application.

You may not have time or money to do all the research you feel you need. You may be doing something that has simply never been done before. You may be in an arena where you are being pressed for a decision (like a meeting).

If you are in a situation where you have to make a choice about a fundamental architectural decision (like a platform/library/framework), you probably are in a small team moving fast, or at a company where you are one of a very few number of technical folks. In this case you may feel over your head and incapable of making the correct decision.

And yet, the decision still needs to be made, and you are the one who has to do it. (The unfortunate fact is that the too late perfect decision is worse than the pretty good timely decision.)

Techniques that won’t work out well for large important decisions:

  • avoiding making the decision
  • googling for an answer and take the first option provided
  • deferring to someone else
  • doing a thorough full examination of all the possible solutions, draw up an excel spreadsheet and a powerpoint to make sure you haven’t missed anything
  • avoiding discussion among team members

Here’s how to proceed.

First make sure that you do need to make the decision, and that you have the proper business context. The number of choices that you should consider and amount of research you should do depend on the impact of the decision. Things to think about:

  • how much of the business does this touch? If it is contained or constrained, you can spend less time thinking about this. If you are implementing a small micro service, or if you are choosing a service that is only used by a portion of the organization (like github for your code), then a choice that needs to be unwound will be easier to do. If you are picking the development language that will be used for the core product, rewrites are almost guaranteed to be far in the future.
  • how irreversible is the decision? Most decisions aren’t irreversible given enough time and money, but some are easier than others. Swapping out one memecached provider for another is pretty trivial, but changing from mysql to postgresql is more complex. Changing from GCP to AWS can, depending on the amount of data you have, be person-years.
  • does your company have internal solutions that you might be able to leverage? The bigger the company, the more likely the problem has been solved before, and finding that solution will be quicker and better than rebuilding it.
  • can you defer the decision until later? Is there a manual process or a service you can buy that will avoid a technology investment, even for a few months?

If you can’t defer the decision, then make the best one you can with the information you have. Research based on the impact on the business. I want to acknowledge the uncomfortable tension between knowledge and action that are at the root of any decision made with incomplete knowledge (aka, all of them!). There’s a spectrum based on risk and commitment, and unfortunately, I’m not aware of any great heuristics for determining risk or commitment other than experience and reading.

My approach towards such a decision is:

  • learn what you can. This includes finding out as much as you can about the problem, including current solutions
  • bounce ideas off of others in the company, but make them specific (both in form and in who you ask). This will help avoid analysis paralysis
  • ask for recommendations. Start at your current company. Even if you can’t find someone who has direct experience with the problem, there may be people who have related experience. You can also google to see what other folks have said about the various solutions (make sure to limit the results to “the past year” or you’ll end up reading about old versions). It can also include searching for experts on twitter and linkedin to ask questions (or to look at their blogs/sites to see if they’ve answered it already). And finally, don’t forget to look for communities (slack, old fashioned forums, open source project email lists) and see what they say. It’s far better to read what you can rather than pop into these communities and ask–those kinds of requests can happen often enough to annoy folks. But if you don’t see any answers, do ask.
  • realize that no decision is perfect. In 20 years of development, I can tell you that I’ve never made a perfect decision, they all involved tradeoffs and lack of perfect knowledge.
  • communicate the risks with the business. This includes the risks of you feeling like you are over your head, as well as any other risks that your research has found.
  • come up with a recommendation and implement it.

Again, hopefully you won’t be confronted with a far reaching architectural decision for a number of years, but it happens. Hopefully this framework gives you a bit of guidance toward making that decision.

Oh, and if you wanted to know my quiz conundrum ended, some of the choices I made were implemented, and others got swapped out as the team changed. The app was a success.

Sincerely,

Dan

There is no perfect system, it’s all about the tradeoffs

Dear new developer,

I want to build perfect systems. There’s something so beautiful about a perfect bit of code that solves a problem elegantly and succinctly. Especially if it comes with a set of unit tests and great documentation.

But, every time I start to work on any real world problems, tradeoffs come into play. Let’s take the example of a simple website that is going to display some information about a business and will occasionally be updated. Some tech tradeoffs to consider when thinking about what to build:

  • how prominent is the business?
  • what is the brand of the business?
  • how often will updates occur?
  • how large does the website need to be?
  • what is the business trying to achieve (a simple online presence? leads/future customers? lowering customer service request frequency? some other business goals?)
  • who is going to be doing the updates? how savvy are they?
  • what is the budget?
  • what is the timeline?
  • who is available to do the work?

Every one of these has an effect on the kind of system that you build. A website for a local jeweler that just wants to have a web presence, show store hours and highlight occasional sales is going to be built one way. A website for a newspaper that needs to be updated regularly and stand up to occasional large spikes of traffic should be built in another fashion. They both might be pretty simple sites, however. You need to find out what the goals are and that will inform the tradeoffs that you have to make.

The point is not that one site or technology is better than the other, it is to acknowledge and make sure everyone is on the same page regarding the choices. (These choices can evolve over time. I have worked on several sites recently that were implemented in perfectly good technologies for their time, but now are aged.)

This letter was inspired by this twitter post (thanks Samuel).

Sincerely,

Dan