Congratulations: You’ve finished your training, landed your first software job, and started your journey as a professional. Your growth, though, is just getting started. Some engineers carry around a specific dream, like solving a problem they loathe or helping a community they love. Absent that, or assuming good work at a software company is part of your vision, I’ll offer you a placeholder goal: to solve the biggest problems your abilities allow, constantly challenging yourself and nurturing your technical and people skills. While other chapters discuss many of those skills in detail, this chapter will focus on the trajectory per se, including self-study and mentorship, while also discussing how companies evaluate performance.
Read Every Day: The Practice of Study
You should be reading (or watching or listening to) technical content every single weekday. People say all the time that they’d rather hire someone smart than someone who “just knows a bunch of stuff”; I happen to disagree. The best engineers I’ve worked with know tons of cold hard facts, much of it from self-study. You’ll discover your own study rhythm, but your default position should be to study every single week, ideally every weekday; it should be built into your routine like physical exercise or time with friends. My personal method is to dedicate every morning commute to technical reading, but I’ve also known people who read every day after breakfast or take a larger block every weekend at a coffee shop.
Facts we can use tactically in our day-to-day jobs, like optimizations, libraries, or tools we didn’t know about
Fundamental concepts we can use to design systems and drive projects, like design patterns, algorithms, project management methodologies, and reliability techniques
A sense of the landscape of the field’s technologies, so we’re prepared to choose among them
Technical white papers: Those from academia or companies like Google and Facebook can offer theoretical insight, though they’re generally the least directly practical reading.
Conferences: Are a good way to get a broad, practical sense of what’s going on in the industry; except when you have a specific need to network in a domain, their main purpose is to carve out more time than you otherwise have for study (after all, the talks are usually online too). They are often expensive, and quality varies; definitely see if your company can send you to one a year!
Newsletters and blog posts: Are a good way to find a steady flow of bite-sized practical updates. I tend to read these with at least one of my reading days per week.
Books: I like to read technical books cover to cover on subjects like databases, build systems, and programming languages. They often don’t offer the best density, but I find reading a whole book cover to cover the best way to get the sense of the whole landscape for a technology—so I can start using it without a constant worry that I’m missing the obvious.
Reading code: Reveals the real patterns and technologies used in successful (or unsuccessful) projects; the best engineers I know read a lot of code, which helps them build a bigger toolbox and stronger opinions about design and style. Well-known open-source projects can be a good place to start, but their quality varies! Ask a senior colleague for a suggestion in your team’s language.
Online courses: The quality of courses available for free online is breathtaking; if you’re breaking into a brand new technical area and need an overview, this is your best bet.
Podcasts: The last five years have seen an explosion in quality technical podcasts, often offering deep discussions of real systems at successful companies. This should be your go-to if you drive to work.
Discretionary coding: It lets you really use the systems you’ve read about. It demands creativity I almost entirely lack, but it’s the only way to fully learn a language or demystify a framework outside of the office; you can solve a problem for yourself or make a contribution to an open-source project.
I struggle to balance all these content types. If you only read papers, you’re too theoretical; if you only read open source code, you’ll struggle to bootstrap the big picture; if you only listen to podcasts, you don’t challenge yourself enough to understand theory the way a paper challenges you. I don’t have a schedule to offer. Personally, my scheduling is ad hoc except when I have a specific technical goal. I read every morning; I catch up on newsletters at least once a week (usually Friday), I read a book when I feel like I haven’t “in a while,” and when I finish a book, I read a few papers and listen to a few podcasts; when something interesting comes up at work or from a friend, I read something specific at interrupt priority. I wouldn’t sweat the schedule too much as long as you’re learning and erring toward content relevant to your work.
Mentorship
Finding a Mentor
A great mentor is a wonderful asset, in every respect similar to a pet unicorn. Your expectation should be that mentors of any kind are hard to find, and good mentors ten times as hard, which means that you should never look to mentorship to be the engine of your growth—you should expect to teach yourself. I see countless young people lament that their careers can’t move forward because they can’t find a mentor; I think their careers aren’t moving forward because they labor under the delusion that anything other than constant self-directed study and effort produce advancement. Even if you do happen to find a mentor, you remain the owner of your growth (refer to “If You Only Take Away One Thing” in Chapter 1).
However, if you encounter someone you admire that you think might have something to teach you, you should feel free to seek out their advice—in my opinion, asking a more senior person for mentorship is perfectly reasonable.
Explain your goals: Maybe you want to level up your project management, maybe you want to master some new technologies, or maybe you just want to get promoted (not the most compelling goal, but it’s something).
- Suggest that you meet every 2 weeks for 30 minutes: Once a week is too much of an imposition; once a month is too little to build a rapport. An hour is actually optimal, but asking for an hour of a busy person’s time is a strong move; start with 30 minutes, and you can ask to double that once you’ve gotten to know each other. Propose that
You will come prepared every time to discuss areas you particularly want to grow, and your mentor will share their thoughts and assign reading in those areas.
You will come every time with at least two specific questions to ask.
You’ll bring proposals/documents/emails for your mentor to review with you.
Making the Most of Your Mentor
Think about ways you want to improve; come to every 1:1 ready to discuss them.
Prepare for meetings by thinking about recent challenges; always come with at least two recent struggles to discuss, like a meeting that went poorly, a proposal that you’re struggling with, or an idea you’re struggling to evangelize. Come to the meeting with notes; discuss what happened, what you want to achieve, and what you’d like them to advise you about.
Maintain a shared 1:1 agenda, and always update that document in advance; it shows your commitment to making the most of the relationship and helps organize the conversation.
Think hard about your own aspirations to prepare for goal setting.
Follow through religiously on any reading suggested by your mentor, and come with questions.
Review the mentoring techniques from Chapter 8; when you feel that you’re not getting the most out of your 1:1s, suggest that you try some of those techniques together. If you run out of steam, get on that Internet and search for exercises others find useful.
If you feel you’re not getting enough from your mentor, think first of stepping up your mentee game; you’re an empowered professional trying to learn from a busy colleague, and it’s up to you to make the most of it.
Imposter Syndrome Is Underrated
A lot of talk on blogs and LinkedIn goes into overcoming imposter syndrome. I say embrace self-skepticism and doubt yourself every day. In a fast-moving industry where lots of your knowledge expires every year, even the most junior people around you constantly cook up skills you don’t have; you stay competitive by applying yourself with the determination (and even fear) of the novice. The upside of this treadmill is that every engineer is on it: just because you’re an imposter doesn’t mean that other people are more deserving than you, because they’re imposters too. You should advocate for yourself, take risks, pat yourself on the back when things go well, and, as you start to build a track record of solving problems, trust your skills and adaptability. Just make no mistake: you’re only as good as the last problem you solve.
Having Your Own Project Ideas
Sometimes we’re handed amazing projects; it’s convenient and it’s fun. At some point in your career, though, you won’t need that; in your final form, you’ll look around you, see need or opportunity, propose projects, and lead them to fruition. In fact, this is a good indicator of whether you’re ready for the big leagues; if you find yourself saying, “my manager isn’t giving me the project I need to get my Staff Engineer promotion,” then you’ll know you aren’t ready, because an expert finds their own work.
How, though?
There are two options. The first is to be brilliant—to conceive of projects by sheer creativity and insight. I’ve never done this in my life, but if you can, you’ll go far.
The second option, the people’s creativity, is knowledge. Diligent students don’t need brilliance to generate good projects; they learn and learn and learn, then diff their knowledge of the state of the art against the state of their neighborhood. If you don’t have good ideas yet: keep learning. Read papers and watch talks: somewhere out there, someone is writing about technology they’ve built that works better than yours. If you find the right paper, you’ll find your opportunities. Ask your manager, your customers, and your teammates what they think is broken and what opportunities aren’t being exploited; maybe they’ll put you onto something great.
Thus, read every day, and don’t worry if your ideas aren’t brilliant; I’ve never had a brilliant thought in my life, but that doesn’t stop me from solving the occasional problem.
Performance Reviews
Personal growth is the foundation of career growth, but at least once a year, your employer is going to try to reach its own conclusions about your performance; that process has financial and career consequences, and it can often loom large in the work year. This section will describe the performance review processes companies use to allocate promotions and raises and will prepare you to put your best foot forward.
Every company has systems to incentivize employees. These systems distribute finite money and promotions1 among employees to create the best performance the system can achieve as the leaders of the company perceive it.2
Leaders may have wildly different ideas about the behavior they want to encourage and the properties they care about in a compensation system. Some leaders believe in comfort and earnest collaboration; others believe that anxiety and competition inspire excellence. Some think mostly equal compensation creates a productive familial atmosphere, while others think a winner-take-all system is more motivating. Despite these differences of temperament, these systems usually work roughly the same way, with modest differences in the details.
The process starts with executives and the board allocating a pool of money and equity for raises and bonuses across each division in the company; that pool is further subdivided down the org tree.
It continues with self-reviews (covered in the next section) and peer feedback, where everyone in the organization receives feedback from three to five peers. This feedback process has two purposes: the first is usually a genuine desire for individuals to learn from each other, and the second is to inform managers of how their people are doing as an input to the performance process. In my experience, there’s variation in the degree of openness in this peer process—at some companies, the equilibrium is for no one to give substantial negative feedback, whereas at others, there’s a genuine cultural commitment to openness. Your mileage may vary; ask an experienced colleague.
After or concurrent to the peer review process, the money-focused process begins in earnest with battle royale-style meetings of managers, often called calibration, to “stack rank” their employees, creating a ranking from best to worst of the employees at every level. Some companies claim not to stank rank, but that’s a lie—whether there’s a spreadsheet with a sorted list or not, there exists a total order on compensation, so there is a stack rank in practice. This ranking is fed up the chain for consistency checks and eventually determines compensation. The curve of compensation with respect to ranking can vary: maybe the top employee gets 1.5x the median employee, or maybe they get 100x. Managers usually want more compensation for their own people at the expense of other teams, so the battle royale can get pretty heated; remember that if your manager didn’t come through for you, it’s more likely that they couldn’t than that they didn’t want to.
A compensation package including some or all of cash bonus, cash raise, and equity.
A written review structured around a rubric of areas like coding, architecture, and leadership. This review usually has a loose relationship to the actual money, being written after the money-oriented process is concluded.
A promotion (or not).
I want to end this section with some advice about your emotional approach to this review: to the extent possible, don’t take it personally, and accept the feedback with all the grace you can summon. You might disagree, you might get fed up with your compensation and go elsewhere, you might be enraged with your manager’s misunderstanding of your efforts, but in the end, it’s just a way for an organization to allocate its finite resources, and your manager is a human with an imperfect grasp of the fractal achievements and failings of their team.
Chapter 6 will cover two closely related problems: accepting feedback and collaborating with your boss, including upward communication, advocating for yourself, and handling grievances.
Self-reviews
Many performance processes require an annual or semiannual self-review, where you summarize your work and its impact, essentially making argument (not in so many words) that you should get a good review and a good bonus.
The overall content is the review is pretty easy—it comes from what you’ve done, and if you’re smart, you’ll have documented that work prodigiously in a Worklog (Chapter 5). I’ll offer a few tips to optimize your self-review.
First, it should not just be a list of tasks; like any piece of writing, you need to construct a narrative that your reader can follow. That means, not “I completed tasks CODE-1001, CODE-1002, CODE-1003…” but “I managed the inbound bug queue for the store page, including working with stakeholders to prioritize bugs and fixing over 20 bugs.”
Led meetings
Did your own project management
Proposed new projects
Took the initiative to improve infrastructure
Owned a component, especially managing inbound requests, supporting stakeholders, reviewing code for other teams, etc.
Mentored more junior colleagues
Provided design feedback
Finally, your self-review is an opportunity to be your own advocate; if you’ve messed up, you should never conceal it, but this isn’t the place to enumerate your mistakes. If you’re obliged to mention where you’ve failed, the answer should, more or less, take the form: I should have led more, I should have taken more initiative, I should have seen the big picture more, that is, aspirations to the next level of execution.
Stop Worrying About Title
Most young people I meet these days are chronically obsessed with getting promoted. I argue: that’s mostly misplaced. Title is a bureaucratic blessing, the product of a committee of committees, and a poor way to measure your career success. First, because you need your own sense of the meaning of achievement, you must, as you mature, evaluate your work for yourself. Second, because we have the good fortune to build things for a living, skill and achievement create opportunity and fulfillment in the long term.
My experience personally, and observation of my peers, is that advancement and fulfillment flow from constantly hunting the toughest, most interesting problems you can find and solving them for the sheer joy of building things (what is engineering if not that?); preoccupation with promotion, in my experience, is an obstacle to it, because it keeps you from bringing your best effort to your core responsibilities.
That’s not to say that you shouldn’t proactively get the best deal for yourself; you should, because money, unlike a bureaucratic badge, comes home with you to buy things you like. But, if you’re spending your time worrying about whether a committee wants to put a feather in your cap, you’re missing the point of your career.