This draws from 3 articles: 1 2 3

Writing this as a university student with 4 internships worth of experience, I can only read about others’ experiences and lessons. It’d be interesting to come back and re-evaluate once I have more full time work experience.

Article 3 is by a veteran software engineer who consistently rejected the challenge of just leadership in order to continue coding.

Over the years I’ve seen how little ability you have as a programmer, no matter how good you are, at making a difference or changing things that are broken. I simply didn’t realize how little room you have to advance as just a programmer (or even architect or the like); the power to change exists at a level not available to you as a mere delivery device.

This problem boils down to the following fact:

People want to make decisions rather than execute them

People want power because that often implies autonomy.

Psychologist Daniel Pink found that three qualities that contribute most to workplace satisfaction and productivity are autonomy, mastery, and purpose.

There seems to be a paradox – employees want to become managers for autonomy, but that means they have to give up their individual craft (mastery) to an extent. Passionate engineers would find this non-ideal.

Implementers, solvers, and finders

Career progression for programmers historically is Junior, Mid, Senior. Then we can go into management, architecture, etc.

Instead of misleading labels, we can try to describe work being done.

Implementers are beginning programmers, and tasks are defined by someone else.

Solvers come up with solutions to general, less well-defined problems.

Finders have near-total autonomy in choosing what to work on, and identify problems and figure out underlying causes.

The Implementer

Implementers thrive if handed solutions matching the challenge level they’re willing to accept. Badly scoped problems will get an Implementer lost.

To level up, article 2’s author suggests finding a new position 6 months in, preferably at the same company.

The Solver

It can be difficult to tell if a company is looking for a Solver or an Implementer in disguise. One thing to check is the ratio of programmers to project/product managers.

Solvers need to learn how to evangelize their preferred solutions and defend them against other Solvers with different preferences.

Solver is an enormous growth area, and can typically last many years making mistakes and learning.

Mid-size startups (>50 people) are great for Solvers:

  • plenty of problems requiring solutions
  • as the startup grows, so does a Solver’s responsibility – one way to grow into a Finder

The Finder

Experts in their chosen domain. They anticipate problems before they happen, since they’ve seen them before.

“Done and get things smart”.

Empathy is critical. Finders need to collaborate with others without pulling the “I’m smart and because I said so” card, lest they become a brilliant jerk.

Finders require autonomy. Poorly managed startups hire people and then tell them precisely what to do.

Benefits of being a Finder

Many programmers end up as Solvers and don’t know where to go next. Becoming a Finder is an alternative to the management route.

Each stage gives more autonomy:

  • Implementers have little autonomy
  • Solvers have more
  • Finders have lots. They are given a pile of vague goals and constraints, and get to decide what to do

Each stage means doing less unnecessary work:

  • Implementers may be stuck with an inefficient solution proposed by a Solver
  • Solvers may be providing solutions to the wrong problem
  • Finders are vastly productive and valuable