I was talking to a former student when he brought up an article written by a well-seasoned programmer regretting his choice of career. This fellow had rejected the management path in order to stay in the coding trenches and as a result, ended up in some absolutely crummy situations. He writes about management antipattern after antipattern that left him sitting with the bill.

Hearing about a dismal career like that is depressing. So much so, that my student who previously was one of my most enthusiastic programmers had turned morose. Who’d blame him? All he had to look forward to was a life filled with misery caused by other folks’ poor decision-making skills. Learning that sub-par managers will dictate your whole life is almost as traumatizing as dealing with said managers. To make matters worse, his team had recently mulled over their future career plans at lunch. None of them anticipated that they’d remain programmers. As soon as they could, they were going to take the leap into management, avoiding what our blogging friend refered to as his “biggest regret”.

I’ve talked to a lot of people who live, eat and breathe programming. It’s hard to stand next to them without hearing about the latest library or tool they’re checking out and how what they’re building is awesome and going to revolutionize everything (or is useless but _ aren’t neural networks cool!?!_). Almost all of them echoed the earlier sentiment - programming as a profession wasn’t for them.

How could this be? A group of people, granted the ability to do what they love for great pay & perks, all wanting to move on? It all comes down to:

People want to make decisions rather than execute them

Turns out science agrees on this: People want power because they want autonomy. Most of the time, folks desire to move up the career ladder not for pay, better title, or keys to the executive washroom (are those still a thing?) but because they wish to be able to exercise greater autonomy over their lives. Psychologist Daniel Pink agrees - he’s found that the three qualities that contribute most to workplace satisfaction and overall productivity are autonomy, mastery & purpose.

I too, was bitten by the “Management = autonomy” bug. My original career goal was to rise up in the ranks of programmers, eventually crowning myself king of my own startup, the ultimate in autonomy (or so I thought). I carefully chose the work I did at each job to align with this goal - and succeeded, eventually earning the rank of a lead position (before the company ultimately collapsed, but that’s another story).

During my last job hunt, I had two fantastic options:

• Leader, with a few constraints
• Not Leader, with full autonomy

This was it! I could capitalize on my previous work and finally …not program. Something was wrong here - what did I ultimately want? When it came down to it, I wanted to write code. I love building things and I didn’t want to give that up. Sure, startups mean doing a little bit of everything but the success case everyone’s working towards means outsourcing all of your own work until you’ve forgotten all of the shortcuts to your favorite IDE. I chose the latter job, the one that would grant me the most autonomy.

Implementers, Solvers, and Finders

Could it be that we’ve utterly mischaracterized how career development as a programmer should work? The guiding trifecta of Junior, Regular, & Senior is incredibly easy to game (A misguided company offered me a senior level job just under a year into my career). A word ceases to be useful when we can’t agree on its purpose - title relativism means a given title can convey entirely separate messages to different companies. Which is more impressive, a “Senior UI Engineer” or a “Javascript Architect”?

If we’re to escape this situation where fantastic fanatic programmers can’t see themselves programming in three years, we need to couple our words to real world meaning. Instead of Jr/Sr nonsense (which already reeks of the years-of-experience antipattern), why don’t we talk about what the job will actually entail? Let’s define your job title by how much autonomy your day-to-day work gives you.

Do you find that most of your time is simply closing tickets, and your team rarely considers your input? Your title is Solution Implementer.

Are you given general problems and left to your own devices on how they’re fixed? When brainstorming, is your input considered by your teammates? You’re working as a Problem Solver.

Are you given near-total autonomy in choosing what you work on? Can you tell your boss “That’s an interesting idea but my time would be better spent elsewhere” (and not get fired on the spot)? You’re a Problem Finder.

Our regretful fellow author of the post above spent most of his time as an Implementer. People (often non-technical) assigned concrete tasks without room for feedback or innovation. Every one of his stories shares the same problem: He wasn’t given autonomy.

I don’t mean to say that everyone who’s at the Solution Implementer level should immediately quit their jobs, or that life as an Implementer de facto means you’re a bad programmer. Beginning programmers who are still learning the base concepts will thrive as Implementers if handed solutions matching the challenge level they’re willing to accept. The mere task of implementing something provides plenty of opportunities to learn (in fact, I’d say it’s the only way to truly understand something). Beginners of all skill levels will get lost if thrown at a problem with too big of a scope for them to handle.

One can’t remain a beginner forever. There needs to be a way for these implementers to level up. We, as a community, don’t have an agreed-upon way to take a budding programmer and hand them continually-increasing challenge. The standard practice in leveling up seems to be to quit and start hunting for a new job at the next level. This is why my standing advice to beginning programmers is to find a new job after six months (hopefully in the same company).

It can be difficult to tell if a company is actually looking for a Problem Solver or the work is just Implementation in disguise. One org smell to look out for is the ratio of programmers to project/product managers. I’ve fallen for this, thinking I’d get to take charge of a frontend when what they really wanted me to do was slog through 17,000 issues in JIRA. Determining the true culture of a company is troublesome, you can start by interviewing your interviewer.

On the other hand, if our programmer does land that Solver job, they will start spreading their wings beyond the basics. At this point their opinion starts to mean something, and the challenges they face take on a new shape as their sphere of responsibility grows. There’s an entirely new set of skills to learn - suddenly effective communication means a whole lot more than “following the JIRA process correctly”. Solvers need to learn how to evangelize their favorite solutions and defend them against other Solvers who have different preferences.

Solver is a enormous growth area and the typical Solver may spend years making mistakes, learning, and causing new catastrophes until their knowledge grows to the point where they’re ready to make the final leap to Finder.

Mid-size Startups (> 50 people) are a great place for Solvers - there’s plenty of problems begging for solutions and often Solvers can branch out into areas that would be verboten to them at a larger, established company. As the startup grows, so does their responsibility - this is a common way for a Solver to grow into a Finder. Another case is for a company to create fertile ground for Finders and recruit them directly.

The final stage of programmer evolution is the Finder. These folks are considered experts in their chosen domain (and are prudent about others). Writing Finder job descriptions is an exercise in futility. As my boss put it: “I can’t tell you the specifics of what you’ll be doing here because your first task will be to figure that out.” A Finder will be able to anticipate problems before they happen, usually because they’ve been in that situation before. Finders are the canonical “Done and get things smart” that Steve Yegge likes to talk about. Empathy is a critical key in a Finder’s toolbox. Finders need to work with a variety of other folks without swinging the “I’m smart & because I said so” hammer (otherwise they’re Brilliant Jerks).

Finders need autonomy, by definition. Any job that puts significant restraints on what a programmer can & can’t do is a poor fit for a Finder. Poorly-managed startups love to hire smart people and then tell them what to do in precise detail. No one wins.

My hope is this post will create shared vocabulary. This triumvirate of concepts can help great folks find the job that’s best for them. A company may be honestly seeking an Implementor, and effectively communicating that to a Solver or Finder will save both parties a lot of time.

More importantly, I want programmers everywhere to realize that it’s possible to have autonomy while still writing code for a living. Some may find fulfillment in leadership (I know I do, the siren song has abated but is not gone) but plenty of hackers out there just want to make great things. There’s hope for us yet!

Postscript: If this article rang true to you and you feel like you’re ready to level up, I’d love to hear from you. What brought you to your current job? What changed? How are you looking for the job that fits you?

Let me know at: isf at rkoutnik.com.