On Fear, Confusion, and Self-Loathing: Starting New Jobs

For six months after I started my first job, I was well and truly sure every day that today someone would finally figure out that I didn’t know anything and summarily terminate me. That is not in the least an exaggeration; I had trouble sleeping, I had visions of future destitution (so far not realized), and I was afraid to tell anyone. Around eight months in, I got to chatting with a colleague who had about a year of tenure on me; he said that he’d felt the exact same thing for the first six months. Many people have told me the same since, including some luminaries who’ve reviewed this book.

Six years later, I started my second job; I had almost the same experience. And a year later, the same. In no case was I, in fact, summarily terminated for incompetence.

All of the above helped me realize that starting a new engineering job is almost always profoundly unsettling. Even in the rare case where you’re brought in as a specialist to do exactly what you do best, you’re walking into a labyrinth of Byzantine development flows , barbarous shell scripts, and missing wikis that blunt technical knowledge—and the comfort you knew as an expert in your old job (or school) is out the window.

So, tl;dr: don’t worry! Because everyone feels that confusion and unease, no (sensible) veterans expect you to know anything, and you certainly will get better. You should expect six months of struggle to arrive at something resembling ease.

When to Change Jobs

Both of my parents repeatedly worked the same jobs for periods of 15 and 20 years; I’ve already changed roles as many times as they did in their whole careers. In software today, changing jobs every two years isn’t too unusual; four years is a generous stay, and a one-year stint is no problem at all on a resume (two or three one-year stints in a row may be a red flag).

The allure of engineering is precisely its constant learning and discovery, which means engineers usually crave novelty. Also, because our field changes constantly, we often keep moving whether we crave it or not; a complacent engineer is an obsolete engineer.

So, I reevaluate my situation every six months, and you should too. If you only consider a move every two years, you’re apt to waste too much time; if you consider it every week, you’ll always be agonizing and never focusing. So, my cadence is every six months. My mental model is that every 6 months or year (or 18 months; the tours get longer as your projects get bigger), I sign up for a “tour of duty”—I commit to myself and to a manager that I will help them achieve some goal, and I go execute on that without a thought to leaving. When the dust starts to settle, I pop my head back up and ask, is it time to make moves?

There are a million dimensions to a good or bad job, from technology to teammates to commute, so I can’t give you any simple algorithm for deciding when it’s time to make moves. However, I can offer a few heuristics that have felt right to me.

The first and foremost heuristic is: if you feel a powerful urge to go, and that urge lasts 2–3 months, you should go; when it’s time, it’s time. That’s the easy case! Unfortunately, it isn’t the common case; more usually you’ll feel a real conflict, you’ll love the people but hate the work, love the technology but hate the manager, etc., etc., etc.

If it seems like the interesting work on your team is done and it is converging on maintenance and small tweaks, it may be time to go. You can stay through one more planning cycle to find out; if three to six months pass, and no one can tell you about a plan that sounds impactful, it is time to go.

Momentary struggle isn’t a reason to quit; the fun and frustration of every job wax and wane, and tough projects wrap up. However, if you really hate coming to work, it is probably time to go; if you go to bed on Sunday dreading waking up on Monday, and that feeling lasts 3 months, it’s time to improve your life

You should keep track of your compensation relative to your peers on that same six-month cadence; if you’re way behind your market wage, make no mistake, you should go get your money. You can start by negotiating if you like, but there’s no shame in taking a big raise at a new job. Similarly, you can sometimes extract a title bump as part of a move—smaller companies are especially likely to inflate titles as a kind of compensation. I personally value that prize minimally for its own sake (see “Stop Worrying About Title” in Chapter 3), but you may consider it if you believe you’re pathologically held back in your current firm, especially from promotion to a terminal role like Senior Engineer.

Finally, if you feel like you aren’t learning, it may be time to go. Of course, not every project is a chance to learn—a good engineer will take one for the team now and again to ship software that needs shipping. However, if you’ve been on the bored bus for three months, and you don’t see any prospect for improvement, it’s time to go find a new challenge.

How to Change Jobs: Going Out in Style

There’s only one way to leave a job: gracefully, gratefully, leaving only beautiful documentation and neatly tied loose ends in your wake.

That’s… pretty tough to do. I’ve almost always gone through two phases when I leave a role or company. First, “I’m going to go out better than anyone has ever gone out”—determination to be your best self and be remembered as a legend. Second, a devastating drop in motivation, making it impossible to do almost anything; that’s also when I start to feel all the resentments and frustrations of this phase in my life swelling in me, leaving me with a sour urge to give everyone a piece of my mind.

That second phase is a real bear. I once saw someone crank out beautiful bugfixes and documentation until 10 pm on his last day, but you can set your sights a little lower; a departure with good documentation, reasonable productivity up to the end, no loose ends, and no complaining will be just fine for your reputation.

Maintenance Is for Suckers: Choosing Teams and Projects

Maintenance isn’t really for suckers; it’s an honorable responsibility as well as the only way to master the difference between what looks good in a blog post and what works in a production system. But I want your full attention for an important point: make the moves you need to make to find good projects, and don’t languish in a role where there’s nothing interesting left to do.

When choosing projects, you’re optimizing for three things: learning, resume/advancement, and satisfaction. Balancing these objectives requires a regular explore–exploit cycle over time. If you’re always doing something brand new to you, you’re always struggling with the strain of being a novice and never solving the biggest problems available—which means that you’re never putting a big achievement on your resume or enjoying the satisfaction of building something grand. On the other hand, if you stay in the exact same space for ten years, your marginal learning will asymptotically approach zero.

As for whether you should work on back-end systems, mobile, or web, machine learning or ads, search or reliability, etc., etc., etc., I can’t tell you—times change fast, so ask people you respect what they think is growing (they won’t know either—if they did, they would use it to play the stock market, but it’s a start). Conditional on having chosen an area of focus, I can offer some simple guidelines.

Someday, you’ll be deep and bold enough to have your own vision for teams and companies; I look forward to it. Until then, look for an important problem that needs solving, for a team with a mission that resonates, and for a manager who can convey a concrete desired change in the world and a path to realizing it. That change might be of modest scope (e.g., your company’s developers will be able to move faster), but you should understand what needs to change, care about the result, and believe that you’ll have to build something big to achieve it.

Most of the work done in the universe of software engineering goes to maintaining and modestly enhancing existing systems in streams of small features and bugs. In my opinion, making that your whole job is for suckers, and you should almost never choose to work on a team where the technology is so mature, and the vision so anemic, that your life is organized around a bug queue rather than a story. The fun, the excitement, the variety, the wind in your hair, and the jewels on a resume come from tackling big, coherent challenges. That doesn’t just mean building things from scratch—you might fix performance problems, might improve reliability by fixing a backlog of bugs, might implement a new product vision in existing systems, etc., etc., but until you’re ready to retire in place, your job shouldn’t be just to manage an endless stream of isolated tiny tweaks. My advice: seek out the biggest, most impactful problems you can find, deliver impact, maintain what you’ve built long enough to unambiguously prove success, and clean up any messes you’ve created. Finally, evaluate whether there’s a new vision to tackle; if all that’s left is repeatedly repainting the house, move on; leave what you’ve built in superb condition for others to maintain.

I’ve worried about writing what I just wrote; the world needs its systems maintained, cynicism and selfishness are already a big enough epidemic, and a good career doesn’t come from shirking responsibility—you need to do what you’re asked to do, solve problems thoroughly, and reason about what really matters for your team and company, not build things just because you want to pad your resume. However, I can’t lie: I believe that when what matters on your team becomes permanently boring, it’s time to go to a team where what matters is interesting.

The Transition to Management

Sooner or later, you’re going to think about making the jump to management. If there’s a deeper subject, I haven’t found it, and it’s a subject treated in countless books, some of them even good books.¹ This book has no manual for management, but I will offer some thoughts on that transition: what the job looks like, its challenges, and considerations for making or not making the move.

Programmers do real stuff; they write code, they operate systems, and they debug outages. Their days are spent building technology. They enjoy a wonderfully crisp feedback loop; every day, an engineer can type on a keyboard, produce code, see it work, and get a sizzling little dopamine shot to let them know they’re living right. Much of their impact is based on the code they write with their own hands; as they get more senior, it may be by the power of their ideas and persuasion.

Managers do almost everything through the efforts of others. Their daily problems are nurturing humans, organizing projects, and managing themselves. They send status reports, soothe the anxious, write roadmaps, scold the wrongheaded, review spreadsheets and bugs, and on and on; they hide their emotions to create an atmosphere of positivity. They virtually never do something and feel a sizzling little anything; their life is maintenance, hygiene, nudging their teams in the right direction, and waiting anxiously for their engineers to deliver. The relationship between their efforts and their outcomes is much more abstract and slippery, which means that the transition is almost always accompanied by an identity crisis—a struggle to accept life with less direct impact. However, managers have, to a point, authority. Their job is to be accountable for a team, and so they have automatic leverage beyond themselves, the kind of leverage individual contributors may or may not achieve through reason and persuasion. They can decide on roadmap; they’re apt to make consequential calls.

I was squarely in the middle; I love people, I’m a decent project manager and communicator, and I was hungry for more scope. For me, being a manager was a wonderful learning experience, about teams, companies, and myself. It pulled the curtain back on bureaucracy and set the record straight on where the capable grown-ups are (nowhere); it exposed me to a much bigger variety of technology and people than I’d had the pleasure to know before; and I did feel a real thrill at seeing a large organization move, feeling that I had set it in motion.

On the other hand, I would have meetings 6 to 10 hours a day, and almost every moment of every meeting, I was dying to escape; I simply can’t be in a conference room that much. I found the wait for others to execute extremely frustrating, and I was hungry to just do things on my own. And I was aesthetically troubled by the need to conceal my anxieties and frustrations so completely (which, to be clear, I believe to be the right thing to do; see “Harmony” in Chapter 8).

You’ll have to decide which half of that story sounds more like you.

Adaptability Is Everything

I started working at Apple in July 2007, which was just after the release of the iPhone but just before it became arguably the most successful product of the twenty-first century. Apple had already existed for around 30 years, and in the software organization, the Mac had been the big deal prior to the arrival of the phone. As the iPhone rose, I watched some engineers go through a painful transition—experts on the Mac software stack, proud and occasionally territorial, gradually became less relevant as iPhone sales soared. I saw two types of responses: the people who saw that times had changed and remade themselves for an iPhone-first world and a minority who clung to the old turf, saying “no” to requests from the iPhone team and gradually becoming less relevant. History has made it pretty clear that adapting to the iPhone was the right move, and clinging to Mac territory, not so much. I learned a lesson watching all that happen in slow motion—adaptability is everything. As technology and business landscapes change, you’ll face frequent choices between exploiting your expertise and status in a previous wave area and giving those things up status to struggle painfully in a new area.

That explore–exploit trade-off is far from simple. If you’re constantly changing teams or companies, you’re never building up enough momentum making big contributions (or, maybe, big money); if you’re always sitting still, your learning will gradually trend to zero. A willingness to struggle and change also doesn’t guarantee anything—you can bet on the wrong technology or just become a victim of industry ageism. The promise I made myself was that I’d never go down clinging to the old ways when things had already changed or become one of the people with tons of experience that can’t execute because they don’t think they have to keep learning and struggling. The need to keep struggling can be a bitter pill—as you put more projects behind you, you want to be able to slow down and enjoy the fruits of your learning, and perhaps we can now and then. However, we chose engineering for the joy of learning and figuring things out, and in a field that’s essentially about change, where your expertise in one technology can be obsoleted quickly by the advent of another, we survive by changing ourselves.

Burnout, Bouncing Back, and Balance

I was once so burned out that when my boss asked me to send a simple email, I sat down at my laptop and couldn’t bring myself to type a single word; there were several weeks where I’m not sure I did a single hour’s real work, though I showed up at the office, sat at my laptop, and tried to will my brain to do something useful. I thought that my career was literally over, that I would have to leave software and find a brand new career if I wanted to keep a roof over my head. As it happened, my career wasn’t over, and I bounced back to write a few more lines of code. This section will discuss work–life balance, the nature and causes of burnout, and my personal thoughts on how we can recover. It’s based entirely on my own anecdotal experience; for science, you’ll have to look somewhere else. Still, I think my observations have occasionally been helpful to colleagues.