Developer Career Paths

IT is a very wide field, and there are many career paths that can be taken. It can feel overwhelming at times, but it's also motivating and reassuring to know that you have many options laying in front of you. In this post, I will explore a number of options together with you. I'll also share some advice about how to design your own career to maximize joy and personal growth.

If you're just getting started in the field or are thinking about getting in tech, then this article should help you get a clearer idea about what you can aim for in the future. If you're already further ahead in your career, then this article might give you some ideas about where to go next.

Note that this is not an exhaustive list of career paths. I won't cover all the possible roles in detail, but I will give you a general idea of what you can expect.

What's in a job title

In this article, I'll mention a number of job titles. Don't worry too much about those. Truth be told, there is a lot of fog and confusion around job titles in the IT industry. Many titles exist for the exact same roles, and roles with the same titles are not necessarily the same. There are different interpretations, overlaps, and quite some storytelling involved.

But don't fret. At the end of the day, what matters is to understand:

• What your role will be like
• What your responsibilities will be
• What will be expected of you
• Who you'll work with
• Which resources you'll have at your disposal

Don't worry too much about the terminology. Instead, focus on what the job entails.

Keep in mind that it's your job (pun intended) to set boundaries and avoid letting yourself be pushed too far for too long. It's okay to help with things that are not under your responsibility from time to time. If it becomes the norm, then it might be time for you to remind your managers what role you've been assigned so far. And potentially to ask for a new title and an accompanying raise 😂

Career paths in software development

Before we look at options beyond software development, we will discuss different paths you can follow in software development. Let's look at a few different dimensions.

Seniority: Junior vs medior vs senior

One key point I want to make here is that seniority is not directly related to the number of years of experience one has or with the education level. Seniority is only about knowledge, expertise, and skills*. A developer can have ten years of experience and still be a junior. Conversely, a developer can have a handful of years of experience and already be a senior. Seniority has a lot more to do with attitude towards learning and motivation than with time.

When you start your career, your title will be something like "Junior developer". For a while, you'll get "simple" and (normally) very well-defined tasks. Other members of your team will prepare the work for you. You'll get to learn about your development environment, your tools, and the technical stack used by the project. At first, you might not be exposed too much to the business side of things or to the analysis work.

From a technical point of view, you won't have a lot of freedom. But that will probably be reassuring in a sense. You'll hopefully be working with a team composed of more experienced people. Those should be there to assist you and guide you, unless if the team is not managed correctly. If you're lucky, then you'll be able to pair program a lot, which will help you learn a ton in very little time. Step by step, you'll learn more about the project you work on. You'll discover more and more about the business model, the users, the work that they do, their workflows, etc. As you work on different features, you'll learn more about the business rules, the features of the application(s), the priorities and the roadmap of the product.

The very beginning is tough because there is so much to learn, so little time, and pressure to prove your worth.

As a junior, you'll have limited debugging skills and will be stuck regularly. Sometimes, you'll have no idea about how to solve a problem. Moreover, many areas will be "scary". You'll make mistakes, you'll introduce bugs, and you'll break the rules. But it's all okay, that's how we learn. Your main focus will be on improving your knowledge and skills as quickly as you can. A big part of that is to quickly recognize when you need help, and to go get it however you can. Your first reflex should be to find answers on your own using search engines. To that end, the very first skill to master is being able to search the Web efficiently.

Next to that, you will need to learn as much as you can about the programming languages you're using, the frameworks and libraries used within the project, and coding best practices (e.g., how to name things correctly, how to avoid needless duplication, how to properly comment and test your code, how to avoid memory leaks, etc). You should also try to learn as much as you can from code review sessions. You should be like a sponge: always ready to absorb more knowledge.

The transition from junior to medior is gradual. You'll hone your skills and will require less and less help. Once you're well-versed in the technology stack you're using, you'll get to learn more about higher level concerns. You'll start diving into design patterns, code efficiency, project structure, dependency management, code quality in general and cross-cutting concerns like logging, auditing, and more. At this stage, you'll have deeper knowledge about your programming languages and tools. This mastery will be a real pleasure for you and a source of pride. You might already start helping out more junior team members to learn more about the craft. You'll also do more analysis work and participate in more important discussions with the business and/or analysts.

More importantly, your responsibilities should expand. Little by little, you'll get assigned more important/complex tasks. As a medior, you will also get less and less guidance. You'll get to design and implement larger features. You'll have more freedom in your work, but will still work in a garden with walls established by others.

At this stage, some developers feel satisfied and don't feel the need to grow any further. Those basically stop being curious and learn little more. It's not bad per se, but that has to be a mindful choice.

If you keep learning and experimenting, then you'll finally reach the next level of seniority. As a senior developer, you'll be expected to go from a problem statement to a working solution. You'll have little to no guidance, and a ton of freedom. This can be extremely rewarding, but it's also a very demanding job. You'll have to make impactful choices for the project and will have to tackle tough problems with your team. You'll feel more pressure as all eyes turn towards you when something goes wrong. At this stage, your code design skills and deep knowledge about the technologies should allow you to make sound and future-proof choices. You'll be able to counsel both the business and your team about the right choices and how to avoid pitfalls.

As a senior developer, you'll really understand the big picture, and how everything fits together. You'll master abstraction, testing, software design, clean code, data structures, etc. All put together, it means that you'll have higher standards and a clear understanding of the whole development process. You'll often be the one with the most knowledge about the existing code. You'll be the shepherd of the structure, rules, code quality, and technical debt. It'll be your responsibility to ensure that the code doesn't deteriorate and rot too quickly.

You'll have to divide your time between deep technical tasks (e.g., troubleshooting tough problems, fighting technical debt, high-level design, analysis work), communication with different stakeholders, and helping the rest of the team achieve more. At that point, communication skills have more and more importance.

It's frequent for senior developers to code less and less. Some people misunderstand and think they're getting lazy. But that's not the case. A senior developer that doesn't write any code but helps the whole team throughout the day is actually a very important asset.

As a senior developer, you'll often have to work across the whole stack, from database to front-end, and everything in between. Your understanding will go far beyond the code itself. You'll need to take care of things such as release management, continuous integration, continuous deployment, source control management, and more. Basically, you'll take care of tasks all across the lifecycle of the project.

In summary, you'll have to be able to do a bit of everything. But there's no one size fits all. Some seniors and experts have actually a very narrow skillset. For instance, there are world-class experts for specific technologies (e.g., Web performance, Databases, Security, Java Virtual Machines, etc). This fits into the career development choices that we'll discuss later in the article.

As you transition from junior to senior, your focus will shift from "making it work" to "delivering production-grade solutions".

Quickly going from junior to senior and beyond

As I've mentioned, the evolution from junior to senior is gradual, but it's not necessarily linear. It's up to you to make the right choices and either go with the flow or set your own pace.

For instance, working in a startup environment or building your own products/side projects is a great way to learn and grow much faster. The smaller the environment, the more responsibilities you'll have, and the more opportunities you'll get to learn more.

The best way to learn and grow faster is to expose yourself as much as you can to code. Write code, but also read as much as you can. A very useful tip is to always take opportunities to dive into the code of the open-source libraries that you use. If you regularly do so, you'll quickly learn a lot.

Another way to quickly improve your skills is to write. It may seem counter-intuitive, but if you write a blog post each time you learn something new, you'll understand it better, and you'll help others grow. It's a win-win. By writing, you'll force yourself to explain concepts using your own words, thereby forcing you to clarify your thoughts. To do that, you'll need to make sure you really grasp the subject, thereby improving your understanding. Remember this: teaching is learning.

Another great way to learn and grow faster is to start freelancing. It's a challenge because it'll force you to learn many things beyond software development and technology. For instance: business development, communication, negotiation, customer relationship management, marketing, outreach, sales, project management, etc. But the advantages of being a freelancer outweigh the difficulty of getting started.

First and foremost, you'll have the ultimate freedom. Freedom to pick your clients, freedom to accept a project or not, freedom to set your own rates, etc.

Importantly, as long as you manage to convince customers of your value, you can increase your salary as you see fit. It's a whole different ballgame. In contrast, when you're an employee, you have to be patient to get a raise, assuming the organization you work for recognizes your work and promotes you. I've seen super talented people wait 4-6 years to get their first promotion... Of course, freelancing is not an easy path either, but that's a topic for another article.

If software development is your passion, then you'll certainly grow much faster than most other developers. Simply by virtue of continually exposing yourself to code and technology... But it doesn't have to be a passion. You can purposefully put yourself in the learner's mindset and grow faster. Side projects really do wonders to help us learn new things and move forward with our careers.

Front-end vs Back-end vs Full-Stack

There are different "types" of developers: front-end, back-end, mobile, and full-stack. Front-end developers are the ones who focus on everything that end-users can see and feel, while back-end developers focus on data management, APIs, and security. Most of the work done by back-end developers is pretty much invisible to end-users. That is as long as everything works as expected.

Front-end developers focus on User Experience (UX), User Interface (UI) design, usability, etc. On their end, back-end developers need to think and implement very different things like data models, data sources, authorization, logging, etc.

The focus of back-end and front-end developers is very different, and each requires a different skill set. It's important to realize that not all developers can work on all aspects. Some will specialize in back-end development while others will prefer front-end engineering. That being said, some developers (generally people with more expertise) can work across the whole stack.

Mobile developers are often full-stack developers in disguise because their code regroups both front-end and back-end aspects.

Full-stack development is challenging because it requires knowledge and expertise about very different concepts, libraries, and frameworks. Becoming a full-stack developer is a worthy challenge, as those are rare on the job market.

My advice is generally to pick what resonates most with you and explore that area for a while. After that, you can switch your attention to the other area and become a full-stack developer. There are no shortcuts. If you go full-stack, you'll realize that it's nearly impossible to stay up to date with the latest evolutions happening here and there. It's a fact of life, don't worry about it. Just try to refresh your knowledge from time to time to stay relevant.

Technical leadership

Senior software developers who want to grow but don't want to get into purely managerial functions may evolve towards technical leadership positions. Technical leadership, like many other roles in IT is associated with a number of job titles such as "Lead Developer", "Engineering Lead", or "Principal Engineer". Independently of the title, which is more cosmetic than anything else, technical leaders play different roles depending on the organizations and projects they work for.

At the core, technical leaders need to have deep a deep level expertise across the stack and clearly understand architectural choices. They are able to help coordinate different technical teams (e.g., back-end developers, front-end and mobile developers), and to troubleshoot tough issues that don't necessarily pertain to code alone.

They're aware of everything that surrounds the application: its environment, its infrastructure, its external dependencies, its non-functional aspects, etc. Thanks to that understanding, they're able to discuss with IT infrastructure teams, database administrators, project managers, etc. They focus on orchestrating the key technical aspects of the project, either on their own or in collaboration with IT and solution architects.

Technical leaders don't necessarily like management, but it's often part of their job to some extent, even if they're not line managers per se. Importantly, they have to be true leaders. They need to be able to communicate their ideas clearly and rally their team around a shared vision. They shouldn't impose that vision, but rather create it together with the team. Ultimately, they need to ensure that the whole team is on the same page and moving in the same direction.

They're also key innovation drivers. Because they keep an eye on how the field evolves, they quickly pick up the trends and are able to understand which technologies are just over-hyped and which will become de-facto industry standards. Organizations that listen closely to their technical leaders can make better long-term technology investments and avoid becoming laggards.

Finally, if new developers join the team, it's also their role to introduce them to the project, to the codebase, to the tools, to the ways of the team, etc. This can also be taken care of by other senior developers. As usual, it depends.

In some organizations, technical leaders also participate in sales meetings. When they do, they're the ones answering all the technical inquiries.

Evolution towards architecture

With time, some senior developers and technical leaders decide to move towards architecture. There are different "levels" of architecture that may be considered.

The most obvious one is software architecture. Software architects might continue to code, but it's not the main part of their job (although there are no hard and fast rules!). Instead, they take care of the technical architecture of their project. They structure it, design the main modules, determine how those will communicate with each other, and help make very impactful technical decisions. For instance, they influence the choices around programming languages, frameworks and major libraries to use. They also influence the way code is organized and choices around build tooling, testing, continuous integration, infrastructure, etc.

Software architects may focus on a specific part of the solution (e.g., back-end, front-end or mobile), but it's not necessarily the case.

One level "above" are solution architects who have a much broader role. They take care of the end-to-end architecture of a solution. They look at all the aspects: technology, front-end, back-end, mobile, infrastructure, security, team organization, etc.

Solution architects need to help create a shared vision across a wide range of stakeholders: business, software development, infrastructure (e.g., servers, SaaS services, networking, backups, monitoring, etc), security, customer support, and more! To be able to do that, solution architects need to have expertise well beyond software development.

They also have to pay close attention to the costs and risks involved. For that reason, they need to work in close collaboration with project managers. They're the bridge between various disciplines.

Finally, enterprise architects are the shepherds of IT architecture at the level of the organization. They ensure that each solution fits nicely in the IT landscape of the organization and respect important policies. They focus on standardization, security, cost control and always look at the next steps. They need to ensure that IT is well-aligned with the evolution of the business and that existing infrastructure. They make plans for phasing out legacy technologies and solutions. And they study and push forward new evolutions.

Director of engineering

Also called VP of Engineering, they focus on building and growing engineering teams. They also help shape the organization's engineering culture and operations. The role of director of engineering is to help create a super-efficient organization (on the technical side). In that position, one has to do anything possible to empower teams to do their best work, removing anything slowing them down.

Chief Technical Officer (CTO)

At the very top level of the technical IT roles lies the Chief Technical Officer (CTO), which is part of the so-called "C-suite" of top-level executives. The CTO usually reports directly to the Chief Information Officer (CIO) or to the CEO.

The CTO helps define the direction technical vision of the organization in order help the business achieve its goals while keeping costs under control. The role of a CTO is to oversee the technical side of an organization. CTOs are the ones that usually have the keys to influence the most impactful technical decisions of their organization. For that reason, the CTO role must be held by someone with a very broad and deep expertise, ranging from software development to IT infrastructure, security, quality assurance, business support, business strategy, and management.

The CTO is a key decision-maker, but isn't alone in the boat. On the contrary. The CTO needs to listen to technical leaders, architects and project/product managers, and others who'll help him make sound decisions. Again, teamwork is key.

Note that the CTO role varies greatly between small startups and larger organizations. In the latter, CTOs are regularly in contact with various vendors and service providers. As such, that person is usually at the center of many "influence games".

Other paths

The above roles correspond to the seemingly linear path that one may follow. But there are actually countless career options, and that's the fun part. Let's explore a few.

Business analysis

After a while, if you enjoy analyzing problems and describing solutions, but feel like code isn't necessarily your thing, then one path you could follow is to become a business analyst.

Business Analysts focus their time and on understanding and describing business needs. They conduct research, interview key business stakeholders and users, document their findings and try to improve the business. Most importantly, business analysts study and describe Jobs-To-Be-Done (JTBB), including the workflows and processes that need to be followed to achieve specific business goals. As they dig into Jobs-To-Be-Done, analysts need to clearly identify the business needs and the business rules. That is, the pre-conditions and post-conditions for every step of the processes. In addition, they also focus on data models and data flows (i.e., which information is manipulated and/or generated by certain processes and workflows).

By describing those, analysts explore the "as-is" situation, which is key to understanding what could be improved. When a certain process is clearly described and understood, it becomes possible to identify the parts that need improvements. Possible improvements include redesigning the processes to reduce the time and effort spent on the same tasks, or adding new processes to improve the overall efficiency of the business.

The other part of the analysts' job is to collaborate with the development teams in order to describe the ideal "to be" situation from a business point of view, and follow the implementation closely to ensure that the business goals are indeed achieved. One pitfall to avoid here is for analysts to do all this work on their own, without any help from the development team. Working in silos is almost always a bad idea. True agility comes from close collaboration between all parties involved and short feedback loops.

Another important trap to avoid is cutting communications between the development team and the business. Analysts need to support the development by analyzing and clarifying problems, but they should not add indirection between the development team and the business.

Business analysts sometimes also double as trainers for the business. Once an IT solution has been created to solve specific business problems, analysts may take care of the training sessions for end-users.

Note that business analysts can be catalysts of innovation and propose new IT solutions to the business. It can be a very rewarding job.

Finally, by getting much closer to the business, analysts can also evolve towards the business later in their careers. This can be a path for people who want to fly towards different horizons.

Product management

Another option is to evolve towards product management roles. Product management is all about focusing on the product side of things, and ensuring that it maximizes user satisfaction. The goal of product managers is to define the product vision and help shape the best possible product.

Product managers deeply influence product decisions (e.g., features to implement, product roadmap, UI & UX direction, etc) and collaborate with various groups: end-users, business stakeholders, developers, UI and UX specialists, etc. It thus requires excellent communication skills, but is ideal for creative people. Product managers need to have a good feel for design.

With a clear understanding of the technical aspects, software developers are well-positioned for this role as they are able to sense what is feasible or not, what will be more or less costly, etc.

People management

Yet another alternative career path is to become a people manager, and help others grow and strive. I won't dive into the details of these roles here, but those can be deeply fulfilling.

Project management

One more obvious path is to become a project manager. Project managers are responsible for the entire project lifecycle, from planning to delivery. They ensure that they have the necessary budgets and resources, and keep close track of the project's progress. They also keep an eye on project risks and do everything in their power to help mitigate those.

Again, there is a lot more to be said, but I won't dive into the specifics here.

IT Infrastructure & Operations

There is a big gap between software development and IT infrastructure. People on either side tend to underestimate the complexity of the other part. Software developers are often completely unaware of how complex IT infrastructure is. And the opposite is also true. But in practice, both are just different sides of the same coin.

It is very enlightening to pursue a career in IT infrastructure, even for a little while. It opens up a whole new world of possibilities. IT infrastructure is composed of various roles: system administrators, network administrators, platform administrators (e.g., Windows, Linux), database administrators, package administrators, storage & backup administrators, firewall specialists, cloud engineers, middleware specialists, automation engineers, and so on.

By diving into IT infrastructure after having spent time in software development, you'll be able to bridge the gap between the two sides, which is very valuable

Design your own career

Let me give you an important piece of advice: design your own career.

Don't let others decide for you. If you let things happen naturally, good things might occur, but you might also be very disappointed. Clearly identify where you want to go with your career, and make conscious decisions that steer you in the right direction.

Be wary of local maxima bias. You may stay in a single organization for many years. While it may be very rewarding/fulfilling (e.g., from a social point of view), you may actually be losing out on the opportunity to grow and improve. There's a local maxima issue, where you'll fight for promotions that don't have a huge impact on your career growth and net worth. Another risk is thinking that you've seen it all while you're actually stuck in one way of working. Sometimes switching between organizations is a much easier way to evolve.

In any case, if you feel stuck, don't stagnate. Go join another project, team or even company. If you feel too comfortable, then it's probably a sign that you're not pushing yourself enough. If you don't get out of your comfort zone, you won't grow much.

Never forget to keep a healthy balance between career development, health, and happiness. Money is not the end game. What matters is your journey. Maximize growth, but never at the detriment of joy. Sometimes, a raise or new job opportunity might be appealing, but if it pushes you into a role that you don't enjoy, it's probably not worth it.

Don't underestimate the power of storytelling

To finish up, don't underestimate the power of storytelling.

As I've mentioned at the beginning of the article, there are various job titles for the same roles, and jobs with the same title are often different in practice. You might be labeled as "Software Engineer" while you're in fact a team leader, project manager and DevOps engineer. Don't let yourself be defined by the titles used by your organization.

Your resume is yours. When you update it, don't hesitate to use a title that better corresponds to your actual job. Also, put forward what is most relevant depending on your current goals. Never lie, but tell your own story your own way. Your career is yours, and it's up to you to paint it in a bright light. Of course, you must always be ready to back your claims, ideally with referrals.

Years ago, my job title was officially "System engineer". In practice though, I was a software architect, team leader, project manager and DevOps specialist. Quite a difference! Thankfully, this has allowed me to explore various other areas.

Conclusion

In this article, I've explored a few different paths you may want to explore during your career in software development and IT. I hope you found it interesting and useful.

There are many more possible paths such as developer relations (DevRel), developer advocacy, IT Security, software quality assurance (QA), etc. Rest assured that software development is the perfect place to start your career. There are endless opportunities for you to grow. Whatever you choose, my hope is that you'll enjoy your journey. Be bold, and don't be afraid to try new things!

That's it for today! ✨

About Sébastien Dubois

Hello everyone! I'm Sébastien Dubois the author. I'm an author, entrepreneur, founder and CTO. I write books and articles about programming (TypeScript, Web, React, Angular, NestJS, etc), knowledge management, and productivity.

If you've enjoyed this article and want to read more like this, then subscribe to my newsletter: https://newsletter.dsebastien and check out my Dev Concepts collection: https://dev-concepts.dev 🔥.

You can find me on Twitter: https://twitter.com/dSebastien and on my Website: https://dsebastien.net/.

About Sébastien