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.

Why software engineers are grumpy

Dear new developer,

I thought that this post, “The care and feeding of software engineers (or, why engineers are grumpy)”, from 2012 was still relevant today. It’s a long one, so I won’t excerpt all the interesting parts, but this really resonated with me:

Both engineers and product managers tend to think, incorrectly, that product specifications or requirements are equivalent to the furniture manual from Ikea. In reality, these documents rarely contain enough information to build an actual thing. They’re usually just the starting point. And that presents a unique problem to the engineer.

The author explores the metaphor of the house, and how you really should fully define such a structure before you start building it. And yet, sometimes software is “just started” and defined and re-defined as needed changes are discovered

The author doesn’t let software engineers off the hook either:

Software engineers are put into a difficult position every day, but we are not victims even though those of us who are more melodramatic tend to act that way. Part of our grumpiness actually comes from within, with something that for some reason is deeply ingrained in the majority of software engineers. We have a tragic flaw and that flaw is that we overestimate our knowledge and abilities..

In addition to all the complaints engineers have, it also has a few suggestions about ways to help (including appreciate the engineer’s effort and cross functional training). Well worth a read as someone who either works with software engineers or as someone who is one.

Sincerely,

Dan

How to manage one to ones

Dear new developer,

Hopefully you’ll work in a place where you’ll have regular one to ones with your manager. I find these helpful for building a relationship and engaging with your manager and your reports (if any). I even did them with my co-founder when I founded a startup.

These meetings tend to be 30 minutes and on a regular cadence (weekly, biweekly or monthly, typically). If you are face to face, you can have them in the office, but going for a walk or to lunch is a great way to mix it up as well. If you are doing them over video chat due to being in different locations, it’s best to have a great internet connection, a quiet space and video turned on. There are nuances you pick up via someone’s face that you’ll miss if you only have their voice.

The purpose of these meetings is to keep communication lines open for both parties. It also helps both parties get to know each other as people. People generally react poorly to surprises and stress, but building the relationship and communication practices before any of these situations arrive (and they will) will help the team to navigate them.

It’s worth stating that as a new developer, you probably don’t have a lot of influence over many things. In fact, you might not even have a one to one. If you don’t, the first step is to ask for a regular meeting with your supervisor. You can start with a monthly 30 minute meeting, which shouldn’t be impossible to schedule. I’d frame this request in terms that are helpful for the company and your supervisor:

  • I want to understand where we are heading
  • I want to know how I can best help you and the company
  • The insights I gain will help me be more effective in helping the team

If you do have a one to one, you can use it to share knowledge and gain understanding. Here are some tips for making the most out of your one to ones as a new developer.

First, schedule (or ask for) regular meetings at a time that works for both of you. Be cognizant of each other’s schedule (does someone like to get up early or work late? Are you in the same time zone?). Scheduling these back to back can be helpful for a manager. And scheduling them outside of “in the zone” blocks of time can make sure that there’s time for other work to be done.

The fact that the meetings are regular is important. They don’t have to last the entire scheduled time, but the manager should never cancel them, and if they must be rescheduled, do that promptly. (This meeting is very important for you as a new developer, and the manager should treat it that way.) If your manager is stretched too thin or is for whatever reason not treating this like an important meeting, suggest decreasing the frequency.

Regular meetings establish the relationship. If the only time you are meeting with your manager is when there are issues, you need guidance on work to be done, or at your performance review, that relationship won’t have the time to grow.

As the employee, come to a one to one with your agenda. I use a google doc in reverse chronological order, with the current meeting at the top. If you can, share this with your manager. Over the week or weeks between your meetings, add items to this doc. This can include items such as:

  • How should I have handled situation XXX?
  • I’d like to learn more about NoSQL databases; what are the opportunities at this company?
  • I’m struggling with XXX, do you have any suggestions?
  • What are the challenges you see facing our team during project YYY?
  • I heard a rumor that we’re opening a London office; is there anything you can tell me about that?

In general, topics should be about professional challenges, discussions or opportunities. Some chitchat about what you each did over the weekend is good social lubricant, if you both feel that way. (I’ve struggled in the past with connecting to reports, but found that discussing their out of work interests can lead to good conversations and a stronger relationship.)

I like to record action items for myself and the other party right in this google doc (sometimes the action item may be as simple as “bring this up again in three months”). This means that when the next one to one comes around, I can see what we discussed last time and if there was any progress. This doc is also great for preparing for your performance review, sharing with a new supervisor, or even just to see what you’ve done or been concerned about over time.

Another thing that I’ve had to learn over the years is that one to ones are a great place for me as an employee to ask for what I want. It’s awkward for me, because I’m a people pleaser at work, but if I don’t ask for what I want or need from my supervisor, how will they know? Now that doesn’t mean you can ask for the moon, but if you see opportunities in adjacent areas to your current work, ask for them.

If you see technologies that you think would make everyone’s lives easier, ask if you can investigate them. If you see a conference or other educational opportunity, ask if there’s money for you to attend. I remember at my very first job, I was interested in learning about databases and database administration. I asked my supervisor about doing a three month internship in that group, and they let me do so. I learned a lot about the data driven mindset during that time.

What is said in a one to one should be kept private, unless sharing it is discussed and both parties agree. Keep the agenda doc between the two of you. I think this article, “The 1-on-1 Disclosure Framework”,  covers the levels of privacy very well.

Finally, it’s worth acknowledging that there’s a power differential in every one to one, based on the fact that the manager influences and/or controls the employee’s role, salary, and job. This meeting isn’t about being buddies or friends, but rather about building the person to person relationship that will allow both parties to thrive and help the company with its goals.

Sincerely,

Dan

Be Adaptable and Authentic

This is a guest post from Morgan Whaley, lightly edited. Enjoy.

Dear new developer,

Honestly my #1 piece of career or technical advice to new developers is:

Be adaptable and authentic.

I don’t think there is any one magic bullet to helping someone “break into” a job, or business, or new city. Humans are all different and the beauty of diversity in industry and environments is when everyone truly brings themselves and overrides the homogenization that we accuse modern cities and tech of becoming.

If something isn’t working, there’s “no harm, no foul” in changing approaches, or taking a break, or simply admitting something isn’t working.

I see a lot of people who treat that first job like it’s a task they gotta beat into submission and they tie so much self-worth to it. Which is completely understandable… but the more you resist a situation and don’t remain open to possibilities, the more you are going to run into brick walls.

Morgan

PS Also, LEAVE YOUR HOUSE AND GO TALK TO PEOPLE FACE TO FACE OH MY GOD PLEASE IT’LL BE OK.

Morgan Whaley is a Senior Prototype Architect at Charter Communications.

Never stop learning

Dear new developer,

I was at a lunch a few weeks ago and asked some senior engineers and managers what advice they’d give to a new developer. One said: “never stop learning”. I thought this was a perceptive answer and wanted to expand on it. I learn something new every day. I’m going to talk about how to learn and then why people stop learning.

First, how to learn. I think the short answer is “Google”. The internet is an amazing place.

The longer answer is:

  • Think about why you want to learn. Is it for fun? To find a better job? To be better at the job you are at now? A side project that you are interested in? Scratching your own itch with a solution? Because you want to make the world a better place? Having a firm “why” will encourage you when things are difficult.
  • Determine what you want to learn. From the why comes the what. Is it a business  domain? A particular technology? A framework? A certain mindset?
  • Consider how you want to learn it. After what and why comes the how. Do you learn best through videos? Reading? Code tutorials? Blogging? A realistic side project? Reading others’ code? Try each of these if you haven’t and see what gets you excited and what seems to cause knowledge to stick.
  • Execute. That one little word is hard to do. But you need to find the time and the willpower to take the why, what and how and actually do it. As some say, it’s easy to write and hard to do. Start. And when you fail to make as much progress as you’d like, think about the why.

Why do people stop learning? I think there can be any number of reasons:

  • Bored: they simply aren’t interested in learning.
  • Frustrated/blocked: they can’t learn what they want to because of other constraints.
  • Tired: too much else going on and they need their energy for other things.
  • Comfortable: they know what they need to know and are “punching the clock”.
  • Shifting priorities: other things in their life have taken precedence.

All of these make sense. And it’s important to realize that you have a job to live your life, you don’t live your life to succeed at your job.

But, if you are not interested in learning new things, pretty soon technology will pass you by. You can still make a great living, but opportunities will get fewer and fewer, and you may need to shift companies or locations, or give up salary. There are definitely people still writing COBOL, but every year fewer companies need it. There may be people still writing java applets, but I can’t think of any companies that need that particular technology.

Another thing to note is that sometimes a shift in perspective, whether a new job or a new way of looking at your current job, can remove some of the obstacles that prevent you from learning.

So, figure out how you want to learn, and never stop doing it.

Sincerely,

Dan

Confessions of a conference speaker

Dear new developer,

When I was newer to development, I thought that conference speakers were experts in their area, harbored no doubts, and that they knew exactly what they were doing. Speaking about technology seemed scary (until it wasn’t).

I enjoyed this post, “Confessions of a Conference Speaker”, pulling back the veil on the experience of a prolific tech conference speaker–20 talks in 2019. (She also has a post about being a conference attendee.)

I particularly enjoyed this section, titled “The Audience is Rooting for You”:

People come to conferences and attend your talk with the hope of getting value for their time. But that’s what is important to remember. They WANT to have chosen a good talk. They WANT you to succeed!

Being a speaker can be nervewracking for any number of reasons. There is so much prep that goes into it. Not every talk will go perfectly. But it helps to remember that the audience is rooting for you. This is especially true with those live coding mistakes. They’ll enjoy helping out 🙂

And the tips about a tech check and adding your author info on every slide were spot on based on my limited experience.

I can’t recommend public speaking enough for a a way to level up your skills. It can be terrifying, but you’ll learn:

  • how to dig into a topic
  • how to present something in a coherent fashion
  • the confidence of knowing that you (likely) know more than anyone else in the room on this topic
  • the value of connecting to your peers

If you are considering doing a talk, I’d suggest starting at a meetup or a lightning talk at a conference. Read the whole post to get Laurie’s inside view.

Sincerely,

Dan

You have to fit the job

Dear new developer,

A few years ago I was job hunting (during a hot job market and with almost two decades of experience) and had a lot of people turn me down or say I wasn’t a good fit. Sometimes it was for coding ability, sometimes it was for familiarity with various systems, sometimes it was because I wanted too much money. I have turned down or left jobs for a variety of reasons, including money, demands on my time, or even just a bad feeling.

What I want to drive home, dear new developer, is that a job needs to fit both sides. The employer and the employee should both feel like they are getting a good deal.

The honest truth is that this means that there are some jobs that you could perform well at that the employer doesn’t know, believe or trust that you can. That can be a blow when you are looking for work. I’ve been there, hungry for anything that will help pay the bills. But you have to have faith. And keep looking. There are lots of developer jobs out there, at big companies and small companies, product companies and consulting companies, software companies and companies that don’t know they are software companies yet. And often, especially as a new developer, you can get hired for your potential.

I’ve also been in jobs where I contorted myself, either a little or a lot, because I thought that was what was needed. I’m all for taking one for the team for a while and doing an unpleasant task or job. But if I have to do it for months and years then that is the wrong job for me.

You have to fit the job, and the job has to fit you.

Sincerely,

Dan