Seniors and Juniors

It almost sounds pejorative, doesn’t it? But the distinction between senior and junior software developers is built into our jobs and job titles. Whether we call it entry-level or something else, we distinguish between people who are just starting their careers and those who have been around for a while. We’re all still learning (one hopes), but entry-level people are still learning the basics, and seniors have greater responsibility, along with the potential for making bigger mistakes. Entry-level developers can do some basic programming, but their knowledge isn’t necessarily deep or broad. As they move into the workforce, they need to deepen their knowledge and become part of a team writing a software system for a paying customer. That new role requires developing a new set of skills.

Skills for both junior and senior software developers vary tremendously, but there are some common themes. For a junior developer, we expect:

Familiarity with one or two programming languages and their most important libraries
Familiarity with a small number of basic algorithms
Familiarity with a server-side operating system
Familiarity with common tooling, like Git
Limited experience working with teams, in the context of small group projects

Of course, individuals also vary tremendously, from self-taught programmers who have made substantial contributions to open source projects to boot camp trainees who may not understand the difference between JavaScript and React. Nevertheless, if we’re honest about the skills we expect of a junior developer, this list shows roughly what we’d expect, not five years’ experience writing SQL.

For senior developers we expect:

Familiarity with the languages in use at their companies and deep knowledge of at least one
The ability to get started with a new programing language in days
Experience working with teams, large projects, and legacy software
Experience understanding enterprise requirements
The ability to mentor newer employees
Thorough knowledge of the tooling environment
Serious debugging skills
The ability to take responsibility for major decisions

Languages really aren’t the core of computer science. But they’re a necessity. They’re a way of telling a computer what to do. Within limits, programming languages are all similar. Yes, I hear screams, especially from advocates of functional programming—and I’ll grant that there are two or three major classes of programming languages, and that every language expresses certain important ideas about writing software. For a senior developer, though, we care less about a long list of languages than familiarity with the ideas. We see the same thing with human languages: Once you’ve learned one foreign language, learning a second is easier, and a third or fourth is even easier. You come to understand how languages work. The language itself isn’t anywhere near as important as learning how to learn quickly. Senior programmers also know the deep secret of programming languages: They’re as much about communicating with humans as they are about communicating with machines. The computer doesn’t know C++ and doesn’t care if the software was written in Java, Haskell, or BASIC; no matter how the software is written, it’s going to execute binary machine code. Humans need to understand what their programs are telling a computer to do because whatever you write now will need to be maintained by someone later.

What about algorithms? Is it important to learn about different sorting algorithms, for example? Sorting is important, but not for the reasons a junior developer might think; almost nobody will need to implement a sorting algorithm, except as an exercise. Sorting is important because it’s easy to describe and has many different solutions, and each solution has different properties. The solutions represent different approaches to problem solving. Programmers may not need to know how to sort, but every programmer needs to understand how to solve problems with “divide and conquer,” how to use recursion, how to estimate performance, how to operate on a data structure without creating a new copy—there are all sorts of techniques and ideas embedded in sorting that a programmer really has to know. Thinking that sort is unnecessary just because a sort() function is in every language’s libraries is, well, a sign of a junior programmer who will never become anything more.

Languages and algorithms are both table stakes; they’re not the distinguishing marks of a senior developer. We expect a senior developer to have both broader and deeper knowledge—but what makes a senior developer is everything else on the list: teamwork, the ability to work on large projects, understanding enterprise requirements, mentoring, and much more that we haven’t listed. We can sum it up by saying “experience,” but that’s not really helpful. What does experience teach? Experience starts with the recognition that programming isn’t fundamentally about programming languages. Programming languages are necessary, but seniors know that the essence of programming is problem-solving: understanding problems and figuring out how to solve them in structured, repeatable ways. As Stanford computer science professor Mehran Sahami said in a conversation with Andrew Ng,¹ “We taught you Python, but really we were trying to get you to understand how to take problems and think about them systematically.”

Seniors also recognize that understanding problems isn’t just coming up with an algorithm. It’s understanding who wants the problem solved, why they want it solved, who’s paying for the problem to be solved, what parts of the problem have already been solved, what different kinds of solutions are possible, whether those solutions can be scaled or extended—and much more. Software projects always have a past and a future, and almost always have a political component. A senior developer understands that the current project has to engage with the solutions of the past and prepare for the problems and solutions of the future. We expect a junior developer to do useful work on a small part of a large project; we expect a senior to understand those bigger issues: wrestling with the project’s history and making sure that it’s maintainable in the future.

Senior developers also exercise leadership, although it need not be formal. In addition to formally leading a group, leadership includes mentoring, working well with teams, being the voice of reason when things get heated, making the hard decisions, and being broadly knowledgeable about the organization’s environment: What are the tools? What resources are available? What are the organizational politics? A leader is someone that team members go to with questions.

Senior developers have hard-earned technical skills that go beyond the ability to pick up new programming languages quickly. Perhaps it’s a myth, but seasoned developers appear to have the ability to look at some buggy code and say, “That looks fishy.” Because they’ve seen a lot, they know what looks right and what doesn’t. They know where bugs are likely to be hiding. They’ve solved a lot of problems and know what solutions are likely to work—and know how to test different approaches.

A junior developer becomes a senior developer through time, experience, and guidance. It takes growing beyond classroom assignments and small group projects to working on software that has been under development for years and will still be under development when you’re gone. Professional software development almost always involves legacy code; the great bulk of software development isn’t building something new but maintaining something that already exists. You have to think about how any code you write fits in with what’s there already and also with what might be there in the future; you have to think about larger designs and architectures. And this leads to another important distinction: While junior developers are often fascinated by the latest trend and the newest framework, seniors know the value of “boring technology.”

It’s important to think about juniors and seniors now, as AI-driven coding assistants make it even easier to generate code. Coding assistants are valuable and save a lot of labor. They give software developers superpowers; they can write a lot of repetitive boilerplate code, code that’s necessary but neither fun nor fulfilling. And when used properly, coding assistants can help developers to learn. But they can also create needless work. As Nat Torkington writes:²

When juniors submit code they didn’t write, they have to apply the critical eye of a senior to it themselves—does it follow our conventions, does it handle errors correctly, is this the best way to solve that problem, etc. If the junior doesn’t, then they’re making work for the senior—when the junior submits uncritically-accepted AI code to the senior, the junior makes the senior do the critical work that the junior should have done. Effectively, juniors using AI can MAKE work for seniors.

So, one consequence of AI-driven coding is that juniors have to do the work of a senior, perhaps before they are fully equipped to do so. They need to have an eye on the bigger picture, because they’re not just evaluating the quality of their own work, which is a necessary skill; they’re evaluating the work of an other (which could have a big O), and that’s a senior’s skill. The most important part of programming isn’t generating code. It’s understanding the problem in its full context. That’s what senior developers do. And that leaves us to some conclusions.

First, we hear it said all too often that companies won’t need junior developers any more. Maybe that’s true—but they will still need seniors, and without juniors, where will the seniors come from? They don’t grow on trees or walk into your door ready to go. Everyone wants “experienced” developers; there has to be a way of acquiring experience.

Second, what do we need to teach junior developers so they can become senior? Learning isn’t just about programming languages, libraries, and algorithms. We need to teach the ability to look at problems in a broader context, to think about how software evolves over time, to communicate with others, and to do this as an integral part of a workflow that includes AI assistants. As Addy Osmani writes,³ juniors must “focus on building that critical evaluation mindset and understanding how to effectively use AI tools.” In our experience, junior developers are excited about learning to use AI effectively—but keep in mind that this is an addition to a skill set, and that addition increases the gap between juniors and seniors. And seniors are also working on adding these same new skills; AI is as new to them as it is to the recent graduate—possibly newer.

Finally, coding assistants are good at coding, but the developers of coding assistants have paid relatively little attention to the rest of the job. It’s not clear that they can’t—we have some tools already. AI is good at taking notes at meetings, generating transcripts, and summarizing. In the future, AI will certainly be able to do more: help negotiate requirements, navigate political issues—but not yet. And yes, AI is gradually gaining the ability to navigate large codebases, but we still need humans who know how things work and where the secrets are buried.

We will always need senior developers—so we will always need junior developers, along with pathways that allow juniors to become seniors. As we incorporate AI into our workflows, we need to be thoughtful about preserving and maintaining those paths. How do we build mentoring into job requirements? How do we encourage new hires to look at bigger pictures, when so much of our culture (and our professional environments) is built around shorter and shorter time scales? How do we teach people to become problem solvers rather than code generators? And how do we teach humans to collaborate—both with each and with AI? Those are the problems we need to be solving.