On Choosing a Career Path

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 and motivated as you navigate the twists and turns of your career, so it’s important to reflect on the path you want to take so you can stay on track.

There are a few different aspects that you should consider when thinking about your career goals -- the engineering path you want to take, whether you want to focus on a generalized or a specialized set of skills, and the leadership path. When combined, 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.

This is an excerpt from "Junior to Senior", my upcoming book about building the soft-skills needed for a promotion to a senior software engineering role. If you’d like to be notified when the book is available, you can join the waitlist.

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 deciding which engineering path you should pursue.

The engineering path you follow will determine your journey to increasing technical mastery of one or more technologies of your choosing. The technology (or set of 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 programming job, you’ll want to do as much as possible to become an expert in the technologies that your company has invested in.

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

Choosing a technology

Programmers have a natural tendency to seek out roles that require similar skills that they possess. Part of this is due to the fact that interviewing is hard, so people tend to want to interview in a language or technology that they are comfortable and confident with. Because of this, they will research and apply to companies that work with similar technologies that a candidate is 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.

This is partly due to the fact that businesses have limited time and resources when it comes to hiring and onboarding new employees. Most companies can’t afford to spend more than a few months getting a new hire up to speed, so they tend to recruit programmers that are experienced in specific technologies that 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 candidates 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. It’s more cost effective for companies to hire candidates who already poses desired skills a company is looking for, rather then hire someone and team 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 the APIs of the framework.

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 cost effective for companies to hire candidates that are already familiar with specific technologies.

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 that you’re familiar with. While it’s still possible to find companies willing to hire candidates with no prior experience in a 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, because they have the budget and resources to invest in their employees over a longer timeline. These companies tend to operate in niche industries or industries 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, so they 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 for companies on Linkedin or other job boards that are looking for programmers with experience in your language. You may even be able to get your foot in the door for an interview 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 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 system 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. 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 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 on 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 of your coworkers and their knowledge as much as you can early on in your career. Read their code, review their pull requests, and ask questions about how they come up with their solutions. There’s actually a lot that you can learn from reading code and asking the right questions.

With the help of your coworkers, you’ll be on a good path to mastering your first programming language. It’s important to stay focused early on in your career 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 skillset.

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 specialize in a specific skill set.

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 technologies. 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.

☝️ 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 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 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 developers from project to project without having to hire new programmers with a specific skill set.

More often than not, it’s typically 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.

🔸 One thing generalists should consider is the need to stay up-to-date for multiple skill sets as the ecosystem for each technology evolves in parallel. Without continuous learning, generalists may fall behind in one of more technologies if they don’t find time to practice those skills.

Now let’s look at the specialist 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.

🔰 Examples of specialists include a computer vision expert working for an autonomous driving car company, someone who specializes in quantitative trading systems working at a hedge fund, a big data expert working for an IoT company, or even an expert in the Ruby programming language working for a company that has built their codebases on Ruby.

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 due to the fact that 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.

☝️ 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 just as valuable 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.

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 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.

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 that 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 medium and large sized problems that are well understood.

Once you reach the inflection point–sometime after you’ve been in a senior role for a while– you’ll need to decide if you want to continue down the technical track or shift over 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 roles 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 pay down 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 the difficult and vague problems exist. They may design a solution for one team and them move to a different team to help them find the best direction for a different problem.

Although it is primarily a technical role, most senior programmers on the technical track provide leadership through their technical guidance on projects and through mentoring a handful of individuals. Many engineers incorrectly assume that they want to stick on the technical track because they don’t want to manage 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 their ideas, concepts, and initiatives they belive the company should pursue.

The technical path provides opportunities for those who aren’t necessarily interested in managing people directly, 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 find themselves more comfortable leading the direction of the projects, or the people involved in a project instead. 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 they are expected to have an intimate understanding of the technologies involved in the company’s products, managers are required to have an expert knowledge of the products themselves as well, 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 their 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, the managers support the needs of everyone on their team so that they can all achieve their full potential.

🔹 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, the individual contributors need to understand the management issues in order to be effective as well.

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 these things right now, so it’s important to give yourself a reasonable timeline when it comes to advancing in your career. It’s important 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 that you can build off of in the future. 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.

If you enjoyed this excerpt from "Junior to Senior", join the waitlist to be notified when the book is available.