A New Way to Measure Software Careers

How do you measure the progress of software careers?  I don’t mean rhetorically — give it some thought.  As a software developer working your way through the workforce, subconsciously optimizing for AMP, how do you evaluate yourself?

I can think of some things that probably flash into your head:

• Salary (AMP notwithstanding).
• The modifier attached to the title, “software developer” (preferably “senior” or ideally “principal”).
• Languages learned or mastered.
• Maximum cachet of employer (perhaps culminating with an Enterprise Silicon Valley gig).
• Progress toward management.

Maybe you have others.  Weigh in below in the comments if so — I’m honestly interested to hear.

Anyway, today, I’m going to propose a different one.  At first blush, this measure seems kind of binary.  But I think there’s actually a subtle continuum, and this post will explore it.

So, how do I propose we measure progress in software developers’ careers?

Simple.  Your career is as mature as the degree to which you control the decision about whether or not to write software.

What Does It Mean to Decide Whether or Not to Build Software?

Before I get into the progress spectrum I mentioned, I should probably justify my assertion and elaborate a bit.

First of all, when I talk about the decision about whether or not to write software, I don’t mean it in some kind of granular, micro-sense.  I don’t mean that you have the autonomy to decide whether to roll your own logger or to use Log4j.  I don’t even mean that you’re an architect and you can push back on the business about technical feasibility in the short term.

No.  I mean that you make the business decision about whether or not to write software.

For instance, say you’re a free agent that specializes in helping mom and pop retailers establish an online sales channel.  When Mom’s Gourmet Macademia Nuts calls you and contracts you to help, you decide whether to build a custom web app, use Shopify, or send them to Etsy.  (Or whatever — this isn’t exactly my forte.)  Mom asks you for help, and you decide whether or not writing software should be part of that help.

Or take me and my content business, Hit Subscribe.  In order to earn my CTO designation on LinkedIn, I’m handling the business’s technical decisions, including whether to delegate tasks, automate them with off the shelf products, or build custom automation myself.

That’s what I mean about the build decision.

What I’m Describing Sounds Like Management, But That’s Actually Silly

One last point of order before I dive into the continuum of software career progress.  If you think that I’m declaring water to be wet — that of course you mark software career progress by getting close to this decision because that means you’re getting closer to management — let’s take a look at the logical implications of your assumption.

You’re thinking that the decision of whether or not to build software is best made by management.  In other words, the decision about whether or not to build software should not be left to software developers.  There are two categories of people: those who build software, and those who know whether or not building software is a good idea.

Do you seriously believe that?

Does a surgeon need a “surgeon manager” to tell her weather or not to perform surgery?  Does a plumber need a “plumber manager” to decide whether or not to replace your toilet?  No.  In both cases, this is absurd.

But, does a construction worker need a real estate developer and a general contractor to tell him whether or not to build a wall somewhere?  Yes.

What’s the difference?  The difference is that surgeons understand surgery and plumbers understand plumbing.  But construction workers do not understand commercial real estate.

So ask yourself this.  Do software developers understand automation?  Do they understand the domain in which they’re writing software?

Actually, it kind of varies.  Some do, some don’t.  And, because of that, doesn’t it make sense to evaluate your level of progress in the software world on the basis of whether or not you understand why you’re doing what you’re doing and the degree to whether or not you can weigh in intelligently?

Of course it does.  So here’s the continuum.

Level 0:  Your Boss’s Boss’s Boss is Part of a Steering Committee… or Something

At level 0, you’re a cog in some gigantic enterprise.  You clearly do not make the decision about whether or not to build the piece of software that you’re working on.  But not only that.  You don’t even know who does make that decision.

You understand in the broadest, most abstract of terms.  “The steering committee” or “the program” or “the business” or something.  They make the decision.

I don’t care if you’re a wet-behind the ears, entry-level programmer or some kind of CoderNinjas.com black-belt bracket-warrior of Github mastery or whatever.  If the build or not decision is made this far from you, you two are exactly the same as far as your company is concerned.  Any company with enough scale to abstract the decision this far from you has enough revenue to make “$50K salary vs. $120k salary” a few orders of magnitude less than a rounding error.

Mark your progress as a zero.  The only way you get a whiff of non-zero is to stop programming and spend 20 years managing.  Go somewhere else.

Level 1: You’re in Contact with the Decision Maker

Next up, at level 1, you at least knows who makes the “do we build this software” call.  It might be your boss’s boss or maybe even her boss, but it’s someone that you pass in the halls and know by sight.

The odds that you’ll be able to exert any modicum of influence are pretty low, but at least you have line of sight.  There’s an outside chance that you’ll at least be heard if you discover that the product you’re helping to build is actually a terrible idea.  But don’t count on it.

Mark your progress as a one.  If you become an indispensable programmer or a line manager after enough years, you might start to have regular influence on the build decision.  But you’ll get pretty gray waiting this out.

Level 2: Your Boss Makes The Decision

Now, we’re getting somewhere.  It’s not an unapproachable VP or director that makes the call, but rather your boss.  You have a relationship with your boss, and one over which you have a great deal of your control.

Of course, there’s a pretty good chance that your boss, the manager of app dev, isn’t consulting you on decisions about whether or not to build a piece of software.  But your boss is making this decision, which means that your group/team, collectively, has a lot of input into the business.

This is promising!  You have a lot of options for impressing your boss.  If he values technical acumen, you can work on that.  If he likes good presentations or excellent time management skills, you can work on those too.  In short, you can figure out how to land the boss’s ear and thus to have a bit of say in the decision.

Mark your progress as a two.  You don’t have direct influence, but you can acquire a meaningful say within months, rather than years.

Level 3: You Influence the Decision

At this point, the progress is obvious.  You have the ear of whoever it is that makes the build decision.  It could be that a VP just really personally likes you, or it could be that you’re a small shop where a democratically-minded dev manager listens to smart folks.  Either way, you feel pretty confident that you could bring about a veto of a terrible build decision.

Others in the organization can, of course, easily overrule you.  You don’t truly own the decision.  But you have a seat at the table every time there’s a decision to be made.

Mark your progress as a three.  You’re a meaningful part not just of software creation, but of the business of creating software.

Level 4:  You Make the Decision

You own the decision.  Since this post is about software developer careers, you’re obviously still involved in building the software.  But you also own the decision as to whether or not to build the software.

This might be the result of you being the technical founder of a small, sustainable app-based business.  Or, maybe you’re a technical consultant.  If you’re still in the corporate world, perhaps you’re in the sweet spot of working for a company that’s relatively flat, but lets dev manager types code.

Whatever the case may be, mark yourself as a rare four.  You’ve hit the apex of software careers.  You build software and also have deterministic say over whether or not what you’re doing makes sense.  This is the height of being a professional and an authority in your field.

Optimize of this Measurement of Software Careers and Reap the Benefits

You’ve probably noticed something by now.  If you optimize your career for making progress according to these levels, you’ll almost certainly find yourself working at progressively smaller companies.  I don’t deny it.  As any reader of Developer Hegemony knows, I believe that the future of software development as a profession will see an exodus from massive, pyramid-shaped organizations and massive displacement into smaller, nimble “efficiencer” firms.

But I don’t offer this as some sort of evangelism of my future predictions.  Rather, I offer it as career advice for software developers serious about the business of software.  Do you want to look back on your career and summarize it with, “seems dumb to me, but they just pay me to code up the spec?”  Or do you want to look back on a career where you were an expert in the business of software, automation, and a domain, and where you make expert decisions and give expert advice in that capacity?

If it’s the latter, then you have a new career path.  Forget the blog posts about which client side framework will be most marketable in 2019 or which silly interview prep site of the month will give you the inside track to Enterprise Silicon Valley.  Focus on career moves that bring you closer to deciding for yourself whether or not to write code.