#talks #career #advice

source

Introduction

I’ve been a software engineer for over 20 years, building systems for hundreds of millions of people. It’s been a wild ride and I’ve enjoyed every day of it (well, most days of it 😆).

Each section describes one principle. The sections are sorted approximately in order of importance. Below is a list of the principles, with relative links to bring you directly to each one.

Persistence is key

Success doesn’t always happen on the first try. Sometimes you pick the wrong solution, or you don’t execute well enough, or something happens that is out of your control. All of these things might happen (and have happened to me). This is ok, it is a part of life.

Try to figure out why the failure occurred, learn from it, adjust your approach, and then…try again. If anything, you’ll have more knowledge about the problem space and your chance of success will be higher.

Fall into the pit of success

I think of this principle as the following:

What do I mean by “position yourself”? This could mean changing either the tasks that you are working on, the role you are in, the team you are a member of, or your employer. Very often I encountered highlights in my career just after re-positioning myself. Like switching a role or switching a team. Don’t be afraid to re-position if you feel that it will increase your chances of success. You are probably correct.

This doesn’t mean that success is guaranteed. It also doesn’t mean that there won’t be hard work. But I feel that positioning yourself correctly is a key part of success.

Choose experiences that energize you

A common career question I hear is “where do you want to be in 5 years?” I really have no idea “where I want to be”. However, I find it easier to identify what types of activities and experiences keep me most engaged at work. Tasks where I often find myself “in the zone”.

Given this, I reframe the original question as the following:

This helps me decide what next steps I might want to take in my career.

When I’m energized by my workload, I’m happier and more successful. This is a sign that I’m in a role that’s right for me. The opposite is also true - if I’m not feeling engaged or energized, this is a signal that I might need to make a change in role or position.

Build a brick wall

Early in my career, I was focused on being the best software engineer I could possibly be. An expert in the field. Every career step I took was in support of that path.

Nowadays, I’m looking for varied experiences. Things outside of that original path. Presentations, coordination across teams, planning events, temporary v-teams, social media, etc. I see these experiences as individual bricks to place on my career wall.

Why the change in philosophy? At first I was just looking to try new things that are fun and interesting. But along the way I’ve noticed that I’m learning new tools that I can put in my career toolbox.

Have a mix of “Preparation” and “Highlight” years

When I look back at the years of my career, each of those years can be classified as either a “preparation” year or a “highlight” year:

It’s natural to have a mix of both. Not every year will be a highlight. But make sure you occasionally experience the highlights.

Looking back at my career highlights, what are the common themes for all of them?

Test your assumptions

This principle manifests itself in several ways, but the general idea is:

The earliest example of this I can remember from my career is unit testing. Prior to unit testing, I was always nervous about refactoring code, and I made assumptions about the correctness of the code based on code review and manually testing. Once I started writing unit tests, refactoring became way easier, and I found a ton of problems with my initial assumptions. To this day, unit testing is one of the subjects that fundamentally changed how I approach software engineering.

A more recent example of this is data engineering. Let’s say I’m evaluating a new data source for visualization, and I find a column in a data table named “US State”. My initial assumption would be “Oh, this will have data for all 50 U.S. States”. It’s important to test that assumption. Many times I find that my assumption is wrong – either some data is missing, or some data is duplicated, or I misunderstood the purpose of the column, or something else. Often when I am starting a new data project, the first thing I’ll do is create visualizations that test my assumptions about the data. Besides initially verifying my assumptions, these visualizations help when issues arise with a data source. I can send a screenshot of the chart and say, “this data doesn’t look right, can we investigate?”

This principle applies to non-technical situations, too. One example of this is when you are working on a team across multiple cultures. Don’t assume that you fully understand the nuances of folks that live and work in cultures that you are unfamiliar with. Communication styles and behaviors may be slightly different. Ask questions and replace assumption with curiosity to ensure that communication is effective.

One a similar note – don’t be afraid to ask questions. If you are in a meeting or on an email thread, and you are making an assumption but you’re not quite sure about it – ask a question. There’s a good chance that other folks are wondering the same thing you are. Also if you are a more senior person in the group, it’s good to ask questions to set the right example for the entire team.

Start with the unanswered questions

When you are working on a new project, sometimes it’s difficult to figure out where to begin.

I like to start projects by focusing on the unanswered questions first. These are things like “will a SQL database support the size of data we expect to receive?” or “does this user interface library contain features to support our user scenarios?”

Why do it this way? I like this approach because it tells you as soon as possible if an idea won’t work, which in turn minimizes the amount of time wasted. The alternative is spending large amounts of time on an idea that ultimately will not be successful. You might learn some things along the way, but you won’t deliver a working project.

Document the important things

This is something I’ve started doing more recently in my career. At first it feels like too much time and energy to stop what I am doing and write a document, but later I find that it provides so much value. It’s something you need to try once to really understand fully.

Some situations where I’ve found this to be useful:

I urge everyone to create a few documents on topics they care about. You might be surprised at how useful these documents become.

Know your tools

Software engineering requires a lot of tools - IDEs, programming languages, version control, graphical tools, etc. All of these tools assist you in solving your scenarios and problems.

Here’s the trick though - if you don’t know how your tools work, you’ll spend too much time fighting with the tools themselves, instead of solving your customer problems. That’s why I like to spend a small % of my time dedicated to learning.

When do I decide to spend time learning? In some cases, the team or organization has mandated use of a tool (build system, programming language, etc.), and I have no choice but to learn it. In other cases, I’ll be using a toolset on my own, and I’ll notice that it has a downside that may be fixed by migrating to something else. In either case I’ll pause what I’m working on and shift my focus to learning.

If you find yourself thinking “if I learn tool XYZ it will be good for my project or career”, you’re probably right. Spend that time on learning and you won’t regret it.

Move to adjacent roles

You may love your current role, but at some point you will reach a moment where it’s time for a change. Maybe a move to a different team, or a different role, or a different company or career.

When making these moves, I like to pick an adjacent role. What does this mean? I try to pick something where my current experience will be useful and help me in the new role, but the new role has new tasks and activities that I can learn and grow with. The adjacency provides familiarity that helps me learn and grow into the new role.

Try things that scare you

I am a risk-averse person. I like to stay in my comfort zone. It is safe there.

This is Ok at times, but if I stay there always, I’ll never learn or experience new things. Occasionally I like to try things that scare me.

Trust your instincts

A few times during my career I’ve found myself in a position where there was a status quo, and I felt strongly that it should be changed (and I had the skill and power to change it). During these times, I chose to trust my instincts and attempt to make a change and follow the path I thought was correct. So far, these have been good decisions.

I will often ask permission in these cases. But not always. Sometimes you need to put your head down, crank out a solution, then come up for air and show it to folks (and apologize later if needed). It’s like that saying – it’s easier to ask for forgiveness than to ask for permission. 😊

Use this sparingly and wisely. Weigh the risks/rewards, and if it makes sense to try it, go for it. There is higher risk here, but the reward is wonderful.

Life is not a competition

In our always-connected online lives, we often see peers celebrating successes. New jobs, promotions, etc. It’s wonderful seeing these successes and joining in the celebration.

But sometimes it’s difficult to not be jealous of those successes. Why haven’t I achieved that yet? Why only them? When will I have similar success?

Avoid this line of thinking. Don’t compare against your peers - compare against your past self. Are you learning and growing? Are you farther along now then you were last year and last decade? That’s all that matters.

Know when to log out

Working hard is great, but it’s equally important to know when to log out. Work/life balance is critical for maintaining a successful, happy, and healthy life. Don’t be afraid to take breaks. Enjoy life. The work will be here when you return.