Growing Your Career

You’re here because you want to learn how to be a better software engineer. You may already know how to code, or you might still be learning your first programming language. But that’s not what this book is about. This book won’t teach you how to write cleaner code or architect better systems. While the ability to write elegant and scalable programs are important skills to have as a programmer, they alone do not make you a successful programmer.

This book will teach you everything else you need to be a well-rounded programmer—a team player who collaborates well with others, who communicates effectively, and who knows how to manage risk while delivering value to customers. These skills, called soft skills, become increasingly important as you climb the career ladder.

In fact, while many programmers reach a certain level of technical ability during their career, not all of them possess the soft skills necessary to have the greatest impact on a team. Simply put, these soft skills are what separate good programmers from great ones in the later stages of their careers. They will help you unlock new opportunities as you take on increased responsibility and accountability.

Unfortunately, many programmers neglect these soft skills during their early career because they’re laser focused on improving their technical skills. As a result, they often have to change their habits as they learn how to collaborate, communicate, balance trade-offs, and lead projects—and changing old habits can be hard.

The good news is that these soft skills can be learned. If you put in the effort to build good habits now, over time they’ll become second nature. Some of these skills may take years to develop, so it’s important to start right now, and persistence is key. If you’re willing to put in the work to build good habits now, it’ll pay dividends for the rest of your career.

As a programmer, it’s important to focus on your career goals because if you don’t know where you’re going, you won’t know when you’ve reached your destination. Even the most ambitious programmers won’t get very far if they don’t have an end goal in mind. Setting a North Star will keep you focused, motivated and on track as you navigate the twists and turns of your career.

​important​ It’s entirely okay if you’re not sure what your career goals are at this time. It can be difficult to know what you want from your career while you’re just getting started—this is common. This exercise is meant to help you think about your future goals, but don’t feel like you have to decide right now where you want to be in 10 years.

There are a few different aspects you should consider when thinking about your career goals—the engineering path you want to take, whether you want to focus on a generalized set of skills or a specialized one, and which leadership path you want to pursue. Together, these factors help you determine where you should focus your time and energy during your career development.

Let’s take a look at each of these in more detail.

Your Engineering Path

You’ve probably already put some thought into the engineering path you want to take. Perhaps you’re learning your first programming language, or you’ve found a framework you like and have built a few projects with it already. That’s great, because that’s the first step to choosing your engineering path.

The engineering path you follow will determine your journey to increasing technical mastery of one or more technologies of your choosing. The technologies you decide to learn early on in your career may seem inconsequential right now, but they will have a drastic impact on your career.

In some cases, the technologies you chose to focus on will dictate which companies and industries you’ll apply to when searching for a job. On the other hand, if you’ve already landed a job, you’ll want to do as much as possible to become an expert in the technologies your company has invested in.

Let’s dig a little deeper into each of those scenarios.

Choosing Technologies to Specialize In

Programmers have a natural tendency to seek out roles that require skills similar to what they already possess. Part of this is because interviewing is hard, so people tend to want to interview in a language or technology they are comfortable and confident with. Because of this, candidates will research and apply to companies that work with technologies similar to ones they are familiar with. So, while it may not be obvious, the technologies you choose to learn early in your career will determine which companies and industries are within reach when it comes to searching for a new role.

​controversy​ Whether companies should filter candidates based on their experience in a specific language, like JavaScript or Rust, is a controversial subject. Good programmers can, of course, learn new languages. But the practical reality is that many businesses have limited time and resources when it comes to hiring and onboarding new employees. They can’t afford to spend more than a few weeks or months getting a new hire up to speed, so they tend to recruit programmers that are experienced in specific technologies the company has invested in.

If a company’s product is built on a codebase consisting of Python code, for example, they’re more likely to consider candidates with strong Python skills over people with no Python experience at all. Taking the example further, if the company utilizes a specific framework or library such as Django or TensorFlow, they will naturally seek out programmers who are familiar with these technologies. The more a new hire is required to learn during onboarding, the longer it will be until they can start to provide real value, so it’s more cost-effective for companies to hire candidates who already possess the team’s desired skills, rather than hiring someone and teaching them those skills.

Most companies tend to be more lenient when it comes to frameworks versus languages, because frameworks are easier to learn if a new hire is already familiar with the underlying programming language. At that point, it becomes a matter of learning the different APIs of the framework, which is arguably easier than learning the semantics of a new programming language in addition to those APIs.

Which brings us back to what we talked about earlier—that it’s easier to land interviews and get offers at companies seeking experience with technologies you’re familiar with. While it’s still possible to find companies willing to hire candidates with no prior experience in the needed programming language, those companies can be difficult to find.

However, as a junior programmer, you are presented with a unique opportunity, because there are companies that are willing to hire candidates in the early stages of their career even if they don’t have any prior experience with specific technologies. These companies tend to be established enterprises with the budget and resources to invest in their employees over a longer timeline. They tend to operate in niche industries or ones with high barriers to entry, so they can afford to spend a year onboarding a new programmer. Some industries, such as aerospace, healthcare, energy, and many others, may take years to get up to speed in, so those companies are willing to invest in their new hires and teach them everything they need to know.

Startups and small businesses, on the other hand, don’t have the luxury of large budgets and longer timelines that established corporations can afford. Startups naturally need to move quickly as they seek to validate and scale their business model, so they tend to focus their hiring on candidates that have the specific skills they need. Smaller companies need new hires to add value as fast as possible, so it may be harder to land an interview at a startup if you don’t have experience with a specific technology.

So, how do you go about choosing which technologies to specialize in? There’s no easy answer to that question because everyone’s situation is unique, but I’ll try to give some advice that will help you decide.

First, think about the languages and frameworks you’re already familiar with. Are you comfortable enough that you feel you could interview for a role in that language? Try solving some practice problems on HackerRank or LeetCode to gauge how ready you are. If you feel like you’re prepared enough to solve interview questions on the spot, then you’re ready to start applying for roles.

Start searching on LinkedIn or other job boards for companies that are looking for programmers with experience in your language. You may even be able to get your foot in the door for interviews with startups and smaller companies that need to hire programmers with your specific skill set.

If you don’t think you’re ready to interview with a specific language yet, that’s okay. That just means you’ll need to keep practicing and learn the language until you feel you’re comfortable enough to interview. You’re not completely out of luck though, because you can still look for larger enterprise companies that are willing to hire smart candidates without any prior experience with a language or technology. These companies tend to hire based on your potential rather than how well you know a specific skill or algorithm.

Now, let’s look at what you should consider once you’ve landed a role and are invested in a specific technology.

Mastering a Technology

Getting hired for your first programming job is one of the biggest hurdles of your career. The next step is to focus on mastering the languages your team uses as best you can.

Unfortunately, you may not have much of a choice when it comes to choosing which programming languages and technologies you will work with. The decision was probably made for you by other programmers who built the company’s systems before you joined. Even if you’re familiar with the programming language they chose, it’s possible they built the system using a framework or library that you’ve never used before.

Like it or not, your ability to succeed is dependent on how well you know the technologies that your team uses. As you’ll learn in the next section, your technical mastery of these tools can actually have an effect on whether or not you get promoted to a role with increased responsibility.

As you gain more experience and work on larger projects, you’ll need to understand the technologies you work with at a deeper level in order to design and scale solutions to meet the business’ needs. You can’t pick the right tool for the job if you don’t have a good understanding of the strengths and weaknesses of each technology you’re working with.

So, what are some ways in which you can master the technologies you work with?

The most obvious resource that you can leverage is right in front of you—your coworkers. They are likely the ones who have written large portions of the codebase you’re working in, which means you can lean on them to learn the best practices and core concepts.

Most programmers need some help early in their career as they make the transition from learning how to program to learning how to solve complex problems through code. It’s a small but important difference that requires a different way of thinking about problems. You’ve learned how to use the foundational concepts of your language to build programs, but now you need to learn how to break down a problem and construct a solution using the building blocks available to you.

This transition can be difficult if you try to do it entirely on your own, so it’s best to try and leverage the experience and knowledge of your coworkers as much as you can early in your career. Read their code, review their pull requests, and ask questions about how they come up with their solutions. There’s a lot that you can learn from reading code and asking the right questions, so we’ll cover those topics in depth in later sections.

With the help of your coworkers, you’ll be on a good path to mastering your first programming language. Early in your career, it’s important to stay focused and get really comfortable with the language you’re using. Don’t worry too much about learning other languages at this stage in your career. Your priority should be to get really good at one language, because you’ll always be able to fall back on that as your foundation. Assuming you chose a language that has a large community and is used by many companies, you’ll have job security because you’ll always be able to find work at companies looking for your skill set.

It usually takes a few years to reach an advanced level with a programming language. Once you approach this point, you have to start thinking about where you want to go in your career. One decision you’ll have to make is whether to take a generalized approach with your skill set or a specialized one.

Let’s take a look at both of these options.

Generalist vs. Specialist

At some point, you’ll need to decide whether you want to branch out and learn additional languages and technologies, or double down and become an expert in one or two specific ones. Programmers can be successful in either path, so it mainly comes down to personal preference and some careful consideration about where you want to take your career.

Let’s look at each path in detail.

Going Broad

A programmer who views themself as a generalist typically wears many hats and will have an intermediate-to-advanced knowledge of many different complementary skill sets. They may work with many different programming languages, databases, and platforms. Their range of skills allows them to collaborate across multiple disciplines to solve customer problems.

​confusion​ It’s worth noting that the term “generalist” does not mean “full stack,” even though the two terms are often conflated. While full-stack developers are considered generalists, you can still be a generalist within a vertical such as mobile development, game development, or systems programming.

Generalists typically cast a wide net, which gives them the ability to jump around to different projects, companies, and even industries throughout their career. They bring with them a broad set of experience because they’ve worked on many different projects and technology stacks. In some cases, they can bring experience from one project or industry over to another in order to solve problems in novel ways.

Because generalists carry such a diverse set of skills with them, they have the advantage of a larger job market and have an easier time finding work. Many companies prefer to look for candidates with a generalist skill set because they deal with constantly evolving requirements from customers. New projects arise from changing requirements, and companies are able to shift generalist developers from project to project without having to hire new programmers with a specific skill set.

More often than not, it’s a good idea to generalize your skill set during your career, but only after you’ve become comfortable in your first programming language. When you generalize, you are exposed to many different technologies and industries, but just because you’ve taken the generalist path does not mean you can’t specialize in one area. In fact, starting off as a generalist gives you the opportunity to try a number of different technologies before deciding which one you’d like to specialize in.

​caution​ One thing generalists should consider is the need to stay up-to-date on multiple skill sets as the ecosystem for each technology evolves in parallel. Generalists may fall behind in one or more technologies if they don’t find time to practice those skills.

Now, let’s look at the specialist option in more detail.

Going Deep

The specialist path is an option for those programmers who want to take a deep dive on a technology, effectively becoming an expert in one specific area. You may choose to specialize in a programming language, a database technology, or a field of computer science such as machine learning or algorithms. It can take years, sometimes decades, to reach an expert level, but once you do, you’re often rewarded with job security and higher salaries, because companies will compete for your skills if they’re in high demand.

Specialists often have leverage when it comes to negotiating job offers and salary increases because their deep knowledge in a field may be considered a competitive advantage in certain industries.

Although specialists may not have trouble finding new work, the size of their overall job market may be much smaller than that of a generalist because there are fewer companies looking for their specific set of skills. This presents an interesting problem and something that should be considered when thinking about your career path: what if you specialize in the wrong thing?

There’s inherently more risk if you decide to specialize in a programming language or field of computer science because you’ll need to devote years of your life becoming an expert in one specific set of skills. If the industry evolves during that time, you may be putting energy into something that isn’t guaranteed to be in demand a few years from now.

That’s a calculated risk you’ll need to take when deciding what to specialize in, but if you understand a specific technology well enough to become an expert in the first place, you may be able to anticipate where the industry is headed and get a head start. When done right, specializing can be very lucrative for programmers.

​confusion​ While most programmers think about specializing in a specific technology, it’s also possible to specialize in a specific industry. You may use different technologies as you jump from company to company within the same industry, such as healthcare or finance. Although you may not be an expert in the technology at a company, you bring a wealth of industry knowledge with you, which can be just as valuable. When it comes to hiring, a company may consider years of experience in an industry as important as years of experience with a technology.

Now that we’ve gone into detail about the technical path of your career, let’s look at another aspect: leadership.

Your Leadership Path

In the early stages of your career, you’re probably going to be focused on developing your technical skills first before thinking about any kind of leadership path. While it’s good to have a sense of where your career is heading from a technical perspective, it’s equally important to start thinking about your career from a leadership perspective.

At some point, usually after you’ve been in a senior engineering role for a while, you’ll reach an inflection point where you’ll need to decide if you want to stick with the technical track as an individual contributor (IC) or make the jump to the management track. There are excellent leadership opportunities in both paths, but it’s important to understand what those responsibilities look like as you think about the direction you want to take your career.

Here’s what the paths look like at a typical tech company.

Source: Holloway Guide to Technical Recruiting and Hiring.

All programmers begin their career on the technical track as individual contributors, because the foundational skills you develop early on are prerequisites for both the technical and management tracks.

The primary responsibility of an individual contributor is to support the organization through the projects and tasks you work on. You won’t carry any management responsibilities or have anyone report directly to you, so you will only be expected to manage yourself and your own work.

Most programmers enjoy working as an individual contributor because it allows them to do what they love—programming. The majority of your time will be spent reading, reviewing, and writing code. You’ll design and implement feature enhancements and identify and fix bugs. As you start out, you will rely on senior engineers to provide direction and context for the changes you make, but as you gain more experience and autonomy, you’ll shift to designing and implementing your own solutions to well-understood medium- and large-sized problems.

Once you reach this inflection point, you’ll need to decide if you want to continue down the technical track or shift to the management track.

Let’s look at both tracks in more detail.

Technical Track

After you’ve reached a senior engineering role, the most common levels on the technical track are the Staff Engineer, Senior Staff Engineer, and Principal Engineer roles. These deal with increasing job complexity and often require expert knowledge in multiple technologies in addition to development best practices.

In contrast to the junior, mid-level, and senior engineers, the higher roles on the technical track are responsible for exploring different solutions to large and poorly understood problems. They often build proofs of concept to demonstrate the feasibility of different solutions before choosing which direction to pursue.

Staff and principal engineers are expected to perform expert programming tasks and find opportunities for large-scale refactorings in order to reduce technical debt. They think strategically about how the technical systems fit into the rest of the company in order to provide leverage and opportunities for the company to scale.

They may not necessarily sit on just one team. Staff and principal engineers often move across teams to wherever difficult and vague problems exist. They may design a solution for one team and then move to a different team to help them find the best direction for a different problem.

Although theirs are primarily technical roles, most senior programmers on the technical track provide leadership through their technical guidance on projects and through mentoring a handful of individuals. Many engineers continue as individual contributors on the technical track because they incorrectly assume that they won’t be managing people. While it’s true that staff engineers don’t have direct reports, there is a fair amount of people management involved. They still need to work with other engineers to build consensus and buy-in for the ideas, concepts, and initiatives they believe the company should pursue.

The technical path provides opportunities for those who aren’t necessarily interested in managing people, while still allowing them to practice their technical skills in order to design and build systems that provide value for the organization.

Managerial Track

The path toward management is gradual. You don’t suddenly become a manager one day when the title gets assigned to you. Rather, it takes years of experience leading projects from a technical point of view, learning to collaborate with others, and listening to the needs of other programmers. Engineering managers have a knack for helping other programmers achieve their potential, and that isn’t something that can be learned overnight.

Rather than continuing down the technical path, some programmers may instead find themselves more comfortable leading the direction of projects or the people involved in them. While it’s possible they still contribute code here and there, they enjoy fostering the collaboration and communication between engineers working on a project to get it across the finish line.

While managers are expected to have an intimate understanding of the technologies involved in the company’s products, they are also required to have an expert knowledge of the products themselves, including how those products are implemented from a technical perspective.

In addition to balancing tactical short-term goals with strategic long-term goals for the company, to be a great leader in the managerial track you need to be able to recruit and retain great engineers. Part of the manager’s job is to build great teams, and in doing so, they need to find ways to foster career growth for the engineers on their team. Above all else, managers support the needs of everyone on their team so that they can all achieve their full potential.

​important​ While the leadership path consists of two discrete tracks (technical and managerial), engineering managers almost always start out as individual contributors. Just like how managers need to understand the technical issues at hand, individual contributors need to understand the management issues in order to be effective.

It’s a Marathon, Not a Sprint

Now that we’ve looked at what things to consider when thinking about your engineering path—whether to generalize or specialize, and options for your leadership path—it may feel like there are a lot of things to think about. There’s a lot that goes into software development, but you don’t need to decide all of these things at once.

It may be overwhelming to think about all of this right now, so it’s important to give yourself a reasonable timeline when it comes to advancing in your career, and to keep things in perspective when setting goals for yourself, because you have a long career ahead of you.

Some skills take years to learn and decades to master, so be patient and take things day by day. Continuous improvement is the best thing you can focus on right now, as that will give you a strong foundation you can build on. Small improvements every day will compound over time, and soon you’ll look back and be surprised at how quickly you’re progressing.

Think about your career as if you’re running a marathon and you’re just starting your race. You wouldn’t want to sprint to the finish line right now because you might burn yourself out. Just be patient, and take it one career milestone at a time.

Go at Your Own Pace

Additionally, try to focus on running your own race. At this point in your career, you’re competing only against yourself, not others, so try your best not to put pressure on yourself if your peers are progressing in their careers at different paces than you are. Even though it may seem like you’re running the same race, each person begins at a different starting line and is running to their own finish line. It won’t do you any good to compare yourself to others because you’re not even running the same race.

​caution​ Keep in mind that as you get promoted and move up the org chart, you will have to compete against others as the number of available roles begins to narrow. You’ll have to shift your mindset from competing against yourself to competing against others, and this is where the soft skills become even more important.

People learn at different rates, and what may come easy to one person might take weeks or months for someone else to grasp. Learning a new skill often requires you to change your way of thinking, sometimes forcing you to change how you approach a problem. While it might click right away for some people, try not to get discouraged if it takes you a little longer to learn a new technology.

You should be proud of every raise, promotion, job offer, or other career milestone regardless of how long it took you to reach it. These things take a lot of hard work—and more importantly, a lot of patience. Just focus on growing each day as a programmer and as a person, because you’re in control of your career and only you get to decide when you’ve crossed the finish line.