Celebrating Software as a Tactic, Not a Profession
As you may recall, a few weeks back, I offered the hypothesis that software is a business tactic, rather than a profession. My main purpose in writing that post was to level set a bit with my desired direction for the blog, leaning toward an increase emphasis on reader questions. And, you all immediately obliged, so thanks for that!
So, I’ll start by responding to people’s questions/reactions to that post, both in comments and through other media. The follow-up questions/thoughts that I’ll address fall largely into 2 buckets:
- How do you reconcile “software as a business tactic” with “software as an end,” particularly an aesthetic one, such as with video games?
- Maybe software is a business tactic and isn’t currently a profession, but why shouldn’t it be?
Number (1) is easier and chronologically first, so let’s do that.
Reconciling Business Tactic with Software as an End
First of all, let me offer the easiest form of caveat. In that post and with my belief in the idea that software (automation) is a business tactic, I’m speaking to the mainstream, common situation.
In other words, let’s stipulate, for the moment, that video game creation isn’t a form of automation and it isn’t a tactic. And let’s actually go further and offer other situations involving “software as its own end,” such as
- Code katas, interview practice, etc.
- Pure hobby applications that you never share with anyone (or use, practically)
- Code you create as part of a course or how-to blog post.
- Hackathon stuff that you throw in the dustbin.
You can probably think of more like this.
But, in the grand scheme of things, so what? Sure, a handful of people write code for those reasons and more. But the overwhelming majority write code specifically designed to make others more efficient at other knowledge work.
So, I guess what I’m saying is that I stand by the broad categorization, even if you can find the odd counter-example.
A Philosophical Aside: Game Development as Automation and Efficiency
Now, let me remove my previous stipulation and explore another concept. Do you have to squint that hard to see video game development as a form of automation or enabling efficiency?
50 years ago, playing a game of baseball would have meant rounding up enough other people to field the ball, grabbing bats, balls, and gloves, and finding a field somewhere. Now you can just stroll into your living room and fire up the PS4 or whatever you’ve got.
Technology in general and, software, specifically, have generally raised the standard of living over the years by making the once-impossible mundane. And a big part of that is facilitating yesterday’s extravagant experiences cheaply and efficiently.
In a sense, you building me and selling me a video game is you giving me the same fun, but quicker and more conveniently.
A Mindset Shift When Software is the End
Okay, okay. Thanks for bearing with me.
At this point, I can imagine you arguing, “I guess, but using that extremely loose definition of efficiency, isn’t a plumber really a purveyor of efficiency, since he makes it so that you don’t need to go all the way outside to go to the bathroom?” And, you’d have a point.
So, let’s re-stipulate the idea that some software development edge cases exist where software is the end and not the means. One of the questions I received was (paraphrased), “alright, so how do we adopt the mindset shift you’re proposing if we are developing in one of these edge cases.”
And, in a nod to a video series I’ve been absolutely loving, my response is:
It’s actually super easy. Barely an inconvenience.
Just understand — grok — why people pay for what you do.
Grokking the Business of Software as an End
Workaday devs cranking out line of business code make the mistake of thinking that their pay is (or should be) tied to how “good” they are at software (whatever that means). Their task is to understand that Mary in accounting doesn’t care if they write the cleanest, most-self documenting code imaginable, as long as she can review the payroll report every Friday and help the company avoid hiccups in paying people.
As a game developer, you need to wrap your head around the fact that nobody cares how much of a differential geometry and numerical methods ninja you are when they’re buying Mage Wars. They likewise don’t care how optimized your code in tight loops has become because you’ve injected assembly in there for performance.
Do you know why players of Mage Wars give you money?
It’s because they’re stuck in a dead end job, hating their life and just barely winning a battle with alcoholism, but when they log in to this immersive online world, they’re a level friggin’ 78 fire mage and a force to be reckoned with in this simulated world. It’s because the underlying psychology of the game design keeps rewarding them with unpredictable dopamine hits on the occasional treasure run. You’re offering them escape and something to look forward to.
Why is knowing that important?
Because understanding your buyers leads to understanding decisions that the business makes around you. And that, in turn, leads to understanding how to maximize your own prospects and options.
Shouldn’t Software Be a Profession!?
I’m going to cap the discussion here because I intend for the particulars of “how to maximize your prospects and options” to be a continuing theme of my content going forward. And, more generally, I want to advocate for how we can collectively stop focusing on things that don’t matter.
But let me move on now to the other flavor of question. Folks conceded that software development, at the moment, isn’t a profession, but argued that it should be. I, on the other hand, just axiomatically stated that it shouldn’t.
As a recap, here are the criteria that I established for an occupation to be a profession:
- Requires specialized education
- Has a formal accreditation process
- Has a governing body that enforces ethical standards
Examples I can think of, off the top, of professions include electricians, hair dressers, lawyers, doctors, teachers (I think), and plenty of others. But I think we’d all agree that “software developer” doesn’t currently qualify, whether anyone thinks we should get there or not.
I’ve seen argument in favor of moving in this direction take two basic forms:
- Uncle Bob’s libertarian populist flavor, wherein we all collectively and informally do it before an institution does it to us.
- The more traditional flavor, wherein software developers either unionize or form an association like the Bar (which seems like more or less the same thing)
So with that backstory, I’ll offer my take. (I’m also going to try to deftly avoid the terminally stupid realm of partisan US politics, which mention of labor unions threatens to unleash.)
But before I do, let’s consider that the desirability of “software as a profession” really depends on what kind of world you want to see.
Software as a Profession — Implications
Let’s assume for a moment that someone succeeded at herding enough software development cats into some kind of collective structure. We now have a new reality where professional software development requires the following before anyone lets you at an IDE:
- Specialized education
- Formal accreditation
- Membership in a governing body that enforces ethical standards
What does this look like?
Well, for one thing, the number of software developers would likely plummet. And, because of that, those emerging from the other side would probably command higher pay and substantially more job security.
I’d also speculate that a substantial market for “scabs” would emerge. Government entities and regulated industries would opt for members of the association, but startups and small outfits probably wouldn’t. They’d hire scabs or teach themselves some kind of pidgin automation.
And, I think, on the whole, you’d see a significant slowdown in technological advancement. After all, government entities and regulated industries aren’t currently known for pushing the envelope. A shift toward higher paying, cushy ‘regulated’ jobs would suck some of the air out of sectors that innovate.
Of course, this is all speculation. But I’d say that if you’d favor stability and lower risk, industry-wide, then the profession route would suit your taste. If you favor more collective risk and more payoff, you probably don’t want the professional association.
My Personal Take
Having framed that up a bit, I’ll restate my personal take that I want no part of a profession and that I don’t think software development is suited for being one.
On a personal level, I didn’t even like group projects when I was in school. Consensus building (as opposed to divide and conquer) with 3 other people taxed my patience. I’d rather find a new line of work than try to do it with 19,999,999 other people.
If software development became a profession, I’d either turn scab or make a go of writing professionally (or, I guess, keep running my marketing business).
My Societal Take
Less personally, I think the motivation for regulations around a profession is weaker for people writing software. An unlicensed surgeon is likely to directly kill people, and an unlicensed electrician is likely to burn down a house. But an “unlicensed” software developer? It’s not like someone’s going to drop dead when you commit code with an off-by-one error.
I mean, it could conceivably, with an incredibly long train of coincidence and circumstance, result in a tragic situation. But so too can “bad management.” Manager works developer too hard, tired developer commits the off-by-one error, lots of crazy stuff happens, someone dies.
What’s the solution? Make management a profession?
There’s also the (extremely non-trivial) logistical problem of creating this state of affairs. It’s hard to picture highly compensated knowledge workers unionizing — we can’t even stop agreeing to degrading interview processes.
So the only way I can see “software as profession” emerging is through over the top legislation which, frankly, would just push everyone out of the US or EU or wherever, and into countries that didn’t do that. Enterprise upper IT management everywhere would sigh, shrug, and say, “welp, fire everyone and let’s open up an office in the Philippines.”
I Think There are Better Ways
In the end, I think there is a lot more harm than good, and a heaping boatload of unintended consequences standing between current reality and software as a profession. And I think there better solutions to problems that people commonly cite when in favor of collectivizing, such as commodification of software labor, substandard quality, etc.
And I’ll tie these two themes together by saying that I think a lot of the better solutions involve changing how we, as software developers, regard software. I think that problems in the industry, such as flavors of hiring bias, commodification, and more result from what I think of as the “meritocracy delusion,” where in we kid ourselves that we can agree not just on what “good software” even means, but that we can assign ourselves levels and stack rank ourselves accordingly.
If, as a programmer, I stop trying to compete with every other programmer in the world to be “better” so that I can get hired, I can start to specialize and become an expert in delivering some kind of automation-based solution to my buyers. This, in turn, lets me view “bugs” as real human problems rather than entries in some JIRA instance somewhere, which lets me differentiate the “people will die” from “people won’t like the icon color.” And with years of building this experience and rapport, I’m certainly not commodified.
“Software as a tactic” isn’t something I say derisively, but rather enthusiastically. Sure, it’s a tactic for efficiency, but it’s for the good of the buyers/users you’re serving. It’s a tactic for making their lives better.