What happens to your career after 10 years?
Tags: career, advice, programming, writing
Published: 2020-04-23 00:14:20

I see a lot of great career posts on how to get into programming, and some about how to get into senior engineer roles. I'm coming up on 15 years as a software engineer now and I've been thinking lately about how I got here. I'm not an expert by any measure but I wanted to share some advice I've learned.

## New positions are scary, you should take them anyway

I worked right out of college at Microsoft as the only junior engineer on a team of database engineers. I "knew" I wasn't good enough going in. I was terrified. I was going to get fired on day two.

By the time I had left that job, I felt like I had mastered C++ (not even close, but I learned a lot and it felt really good 😂) and made some good friends.

The next job I took was at a gaming startup that was growing fast. I had no idea what I would be doing and had no experience with startups. The interviewers assumed I had intimate knowledge a million technologies I had never touched.

I guess they didn't care? On my first day, I realized how much I had to learn before I could get started. Over the years I worked there, I learned what I had to learn and ended up working on a lot of new things:

- Deploying code to millions of users
- Testing in production
- Leading a data ingestion system
- A live gaming server
- A Cocoa/Objective-C gaming engine

### Lessons I still carry with me

I keep having this experience where I run up against a job that would have me doing things I have no idea about and I still get scared.

All these experiences taught me two lessons I still carry with me:

1. The people who are "programming gods" are still human. If you ask them nicely for help or advice, they'll happily help you. People in our industry want to pass on their skills
2. All the code that's ever been written was built by a person. I (and you!) can figure out what they figured out, if I have the time and energy

## You should write less code as you progress

Non-tech skills are really important. In my first senior role, I felt like I had to work twice as hard and twice the hours. I actually did that for a while too!

Obviously, 16 hour days burn you out pretty quickly, so I pulled back on that and had to figure something else out.

>Working smarter, not harder, is really easy in software roles

I realized that about 5 years ago, but I think I'll be practicing it forever.

The best ways to work smarter don't involve code, they involve people.

### Learn about new technologies

New technologies can give you big advantages in your career. You might be able to accomplish big projects quickly by picking up that new web framework. Or you might get that new job or higher title because you were an expert in that new language before most other people.

Learning new tech will _always_ give you two more handy skills:

- Spotting vaporware quickly
- Being practical about where (or if!) the new tech fits into your stack

### Write and teach more

Whatever you learn, teach it to someone else. Here are some ideas:

- Write internal documents for your company
- Blog posts
- Pair programming
- Screencasting or live coding
- Workshops
- Talking about something you're working on at lunch

Any of these things will help other people work smarter too. Teaching actually helps you take your knowledge to the next level, too.

### Build communities

This is kind of like teaching, but at a larger scale. Instead of passing your knowledge on, you'll teach other people how to pass _their knowledge_ on.

Think about an open source project. People start contributing because they're trying to get the same general thing done. If they want to solve something specific, they learn the best ways to do it, write up a GitHub issue, and teach other contributors what they learned.

If you're the maintainer of the open source project, you wouldn't be telling anybody to do this, you'd just be making sure that they _can_ do it.

That's what building communities is all about, and it's not just about open source projects. These days we have to do things virtually, so you could set up a virtual brown bag lunch at your work, help out at a local meetup (the organizers always need help), or write an article series and encourage folks to contribute (here's fun example: [testing on the toilet](https://testing.googleblog.com/2007/01/introducing-testing-on-toilet.html)). 

## Don't focus too much on the future!

Plans are guesses in disguise. In real life, if I knew what I would be doing for the last 15 years, I would have been too scared to even try.

These days, I don't spend much time focusing on what I want to do more than about a year out.

## Make sure you still dream!

Plans are different from dreams, though! Imagine you want to become the CTO of a startup. A plan would be to do project1, become VP of engineering at company2, then become an architect at startup3, then move up to CTO at startup4. 

In real life, most of those things won't happen in that order. 

A dream would be different. It would be more like "I want to become the CTO at a startup, but I bet I need to move a few levels up before I can get there. Maybe I'll even need to go to a few different companies"