The next career step for Senior Software Engineers (that isn't management)

You’ve been working as a programmer for a few years, you’ve been promoted once or twice, and now you’re wondering what’s next.The path until this point was straightforward: you learned how to work on your own, and then you get promoted to Senior Software Engineer or some equivalent job title.

But now there’s no clear path ahead.

Do you become a manager and stop coding?

Do you just learn new technologies, or is that not enough?

What should you be aiming for?

In this post I’d like to present an alternative career progression, an alternative that will give you more autonomy, and more bargaining power. And unlike becoming a manager, it will still allow you to write code.

From coding to solving problems

In the end, your job as a programmer is solving problems, not writing code. Solving problems requires:

1. Finding and identifying the problem.
2. Coming up with a solution.
3. Implementing the solution.

Each of these can be thought of a skill-tree: a set of related skills that can be developed separately and in parallel.In practice, however, you’ll often start in reverse order with the third skill tree, and add the others on one by one as you become more experienced.

Randall Koutnik describes these as job titles of a sort, a career progression: Implementers, Solvers, and Finders.

As an Implementer, you’re an inexperienced programmer, and your tasks are defined by someone else: you just implement small, well-specified chunks of code.

Let’s imagine you work for a company building a website for animal owners.You go to work and get handed a task: “Add a drop-down menu over here listing all iguana diseases, which you can get from the IGUANA_DISEASE table. Selecting a menu item should redirect you the appropriate page.”

You don’t know why a user is going to be listing iguana diseases, and you don’t have to spend too much time figuring out how to implement it.You just do what you’re told.

As you become more experienced, you become a Solver: are able to come up with solutions to less well-defined problems.

You get handed a problem: “We need to add a section to the website where pet owners can figure out if their pet is sick.”You figure out what data you have and which APIs you can use, you come up with a UI together with the designer, and then you create an implementation plan.Then you start coding.

Eventually you become a Finder: you begin identifying problems on your own and figuring out their underlying causes.

You go talk to your manager about the iguanas: almost no one owns iguanas, why are they being given equal space on the screen as cats and dogs?Not to mention that writing iguana-specific code seems like a waste of time, shouldn’t you be writing generic code that will work for all animals?

After some discussion you figure out that the website architecture, business logic, and design are going to have to be redone so that you don’t have to write new code every time a new animal is added.If you come up with the right architecture, adding a new animal will take just an hour’s work, so the company can serve many niche animal markets at low cost.Designing and implementing the solution will likely be enough work that you’re going to have to work with the whole team to do it.

The benefits of being a Finder

Many programmers end up as Solvers and don’t quite know what to do next.If management isn’t your thing, becoming a Finder is a great next step, for two reasons: autonomy and productivity.

Koutnik’s main point is that each of these three stages gives you more autonomy. As an Implementer you have very little autonomy, as a Solver you have more, and as a Finder you have lots: you’re given a pile of vague goals and constraints and it’s up to you to figure out what to do.And this can be a lot of fun.

But there’s another benefit: as you move from Implementer to Solver to Finder you become more productive, because you’re doing less unnecessary work.

• If you’re just implementing a solution someone else specified, then you might be stuck with an inefficient solution.
• If you’re just coming up with a solution and taking the problem statement at face value, then you might end up solving the wrong problem, when there’s another more fundamental problem that’s causing all the trouble.

The better you are at diagnosing and identifying underlying problems, coming up with solutions, and working with others, the less unnecessary work you’ll do, and the more productive you’ll be.

Leveraging your productivity

If you’re a Finder you’re vastly more productive, which makes you a far more valuable employee.You’re the person who finds the expensive problems, who identifies the roadblocks no one knew where there, who discovers what your customers really wanted.

And that means you have far more negotiating leverage:

• You can more easily negotiate a raise.
• You can find better jobs, even with a technology you don’t know.
• You can even negotiate a 3-day weekend.

So if you want to keep coding, and you still want to progress in your career, start looking for problems.If you pay attention, you’ll find them everywhere.

We all make mistakes, and I’ve got 20 years’ worth: from code that crashed production every night at 4AM, to accepting a preposterously bad job offer.

Every painful failure taught me a lesson—but only after it was too late.

You can do better! Join 2900 other programmers, and every week you’ll learn how to avoid another of my mistakes.