Software Development is a Business Tactic, Not a Profession
Any regular followers of DaedTech may have noticed that I’ve dropped off the map of late with new content. Now, before I go any further, please understand that I’m not petering out with content, holistically.
I think you’ll pry my (metaphorical) pen from my cold dead hands. I can’t not write.
But the break here is semi-intentional. I say “semi”, because it started with me not having time to post one week, and then realizing that I wasn’t overly excited about any of the content I was queuing up. This led to an unannounced decision to take some time off and gather my thoughts about what I want to address on this blog.
I’ll get to a justification of my premise that software development isn’t a profession. But that operating thesis is fundamentally inextricable from my background and my current wrestling with topics.
A Brief History of DaedTech
I won’t make this section a long, self-indulgent tour of my life. Rather, here’s a quick-hitter history of how the subject matter here has evolved on this blog over the last decade.
- Early-DaedTech: I was a line level programmer (mostly .NET). So I wrote about .NET programming topics, office politics, and general programmer life.
- Mid-DaedTech: I was in leadership and starting to side hustle. Here, I trained .NET/Java devs, so those topics remained, but topics about business/leadership/hustle started to displace them.
- Recent-DaedTech: I was an IT Management Consultant. At this point, granular tech topics dropped off the map, and everything started to be about free agency, career, and hustling.
Which brings me to today.
- Today: I run a tech-serving a content marketing business. So, yeah…
The Topical Conundrum
Whether I’ve written with some broader purpose in mind, or just written about whatever strikes my fancy, I’ve always drawn topic inspiration from my day-to-day work. And this made for relevant content in the tech world, since my journey was IC software developer –> IT leader –> (software) strategy consultant.
But as what I’m doing is increasingly about running a growing business and marketing, a gulf is emerging. Certainly, readership of this blog has evolved over the years, with those most interested in my early .NET unit testing how-tos dropping off, and more folks interested in freelancing stopping by. But I now face an interesting conundrum.
- I could start to write about the trials and travails of being an executive at a growing, tech-facing marketing business. But this would probably create a complete audience overhaul, and, l like writing about the software world.
- Or, I could keep writing about the things I wrote about as a software developer/leader/trainer. But the day to day of that recedes further in my rearview mirror all the time.
Oh, don’t get me wrong. I still write code and have opinions about software. I still occasionally consult on codebase assessments. I’m not worried that I’ll become technically illiterate or something.
What I’m worried about is writing about the industry more as an antiseptic observer than as a participant. I’m worried that an increasing number of posts I might write would invite declarations of “easy for you to say!”
I Have Strong Opinions, But Want to Trade in More than Rants
And, speaking of “easy for you to say,” I do have strong, controversial opinions about the software industry and work in general. I mean, I wrote a book about it, and unapologetically hold the opinion that job interviews are fundamentally a stupid thing we should simply stop doing.
But perhaps you can see the trouble shaping up here.
I risk establishing this blog as a venue for potshots at the industry with little skin in the game. Some of these screeds may inspire views, shares, or controversy, but without offering a lot in the way of actual, meaningful help.
For instance, with my opinion about job interviews, the question logically follows: “what would you suggest instead?”
And the answer is complicated.
So complicated, in fact, that it would probably require an entire blog/book’s worth of treatment, and I’m not really interested in making the site’s tagline, “DaedTech: Alternative Ideas to the Job Interview.”
I mean, frankly, I’m building a business (without doing any job interviews, by the way). I’m busy, and the subject just doesn’t matter enough to me to devote the amount of time it requires.
So, as you can see, I’ve sort of tied myself into knots in terms of what I want to talk about these days in the world of software.
- I want to write about things related to my current work, even as that work evolves rapidly and constantly.
- This blog shouldn’t just be rants (even if they’re fun) — it should be helpful.
- Advice/helpful topics can be dry if they’re not related to my work and require tons of effort.
- What is my current relationship to the software industry, what do I want it to be, and what do I think should happen?
So this, in a nutshell, is why I’ve taken a 3-4 week posting break. I wanted to let all of this kind of percolate in my brain.
Working Toward a Thesis and Thematic Topic Set
And, percolate it did.
I took some of my more controversial opinions and tried to unfocus my eyes for a bigger picture. And, not just a bigger picture of “Erik’s Grand Unified Theory of Everything that’s Wrong with Software,” but rather how I might nudge things ever so slightly in a better direction, while helping people and trying to mostly remain upbeat. (I can’t really promise not to drop the occasional cynical screed.)
So, looking at some themes, a picture emerged.
- I flippantly call job interviews in general (and especially the tech version) “stupid,” but a more neutral statement of my opinion is that I view them as waste.
- Frequently, I talk to people in the Developer Hegemony slack and other similar venues about the trouble with gamification engines like Stack Overflow (or conference speaking for the love of the game).
- I object to soggy industry terms, like “servant leader” and to some of the “aw shucks, I don’t care about business” vibe of “geeking out.”
- The entire corporate pyramid seems to generate a uniquely raw deal for software developers — I spent an entire book talking about this.
- I defined a neologism, “journeyman idealist,” as shorthand for software developers preoccupied with endlessly stack ranking themselves as if the concept of a programming merit ladder weren’t absurd on its face.
And, I could probably go on, but I’m not looking to cut a greatest hits album here. Rather, consider that this is already a lot of objecting and negativity thrown at the professional condition of the corporate software developer. So much so that I personally flipped the table years ago and left to go into business for myself.
But it really all comes down to a simple, easily-expressed thesis: I think we, as an industry, have fundamentally missed the point about how to conduct ourselves in the business world.
And then, the positive spin on that: I’d like to start writing posts about how we can do better.
Professionalism (or not) in Software
Now we’re getting somewhere, vis a vis the title of this post.
I’m talking about how we’re not collectively conducting ourselves in a rational and informed manner. So you might make the leap to think I’m saying, “we should establish what it means to act like professional software developers.”
And you’d be exactly right. I did make that leap. I wanted to start offering thematic content around becoming a “professional” software developer.
But, to do that, I realized I’d need to fundamentally disagree with Bob Martin, who cornered the market on software professionalism with his influential book, the Clean Coder. This is a book that covers ground related to honoring (or else not making) commitments, having a professional code of ethics, sticking to principles about software practices, and more. When I read it, probably ~10 years ago, it heavily influenced my thinking about software and professionalism.
So, it was going to be weird to come back and state my case that, in my opinion, Bob’s definition needed a reboot.
But then, I started to read up on what, exactly, constitutes a profession, so that I’d have ammunition for my argument. And, in doing that, I realized that I was wrong and that Bob was right.
Bob’s (obviously well researched) book is spot on about what a profession is: an vocation/occupation requiring specialized education, formal accreditation and ethical standards enforced by a governing body. And, in his book and subsequent talks, he argues that we should create a sort of grass-roots fraternity of professionalism before some software-related calamity spurs various governments into creating one for us.
And then it hit me.
I was wrong to argue that we should have some other definition of profession and professionalism than Bob’s. In fact, I was wrong to think that software development is or should be a profession, period. It’s not a profession at all — it’s a business tactic.
Jobs and Gigs as Business Tactics
Let’s leave software development aside for just a minute. Imagine someone with a consulting practice that titled herself a “customer service operations consultant” on LinkedIn.
Her specialty? Coming into businesses with significant customer service operations and making them more efficient.
- At one company, that might mean setting up simple ticketing software, because they were still operating in the dark ages of some kind of green screen system.
- At another company, it might mean growing them from a 2 to 3 tier support shop.
It’s never the same thing twice. She just draws on a contextual playbook of tactics for making businesses more efficient.
Or, as another example of a business tactic line of work, think of management/leadership — affectionately (and accurately) known as organizational overhead. Picture your last manager, put down the Dilbert joke, and back away from it. What was this person’s job at the company? The real point of his existence?
Managers serve to allow organizations to scale, both in terms of decision making and communication. Installing a manager is installing a human tactic to grow a system beyond a handful of people.
Is “customer service operations consultant” a profession? Is “manager?”
Evaluating Profession-Worthy Jobs
Here’s a hint: nope and nope.
Humans may occupy these roles, and they may do good and valuable work. But everything those humans do in those roles constitutes business tactics (or, perhaps, strategy at times).
So, let’s really drive the point home.
- Do you have to obtain specialized education or attend a vocational program to become an operations consultant or manager? Should you? (Again, nope and nope.)
- Does a formal accreditation process exist for operations consultants and managers? Should it? (Let’s run that back for another nope and nope.)
- Is there a governing body to enforce ethical standards among operations consultants and managers? Should it? (Can I get a nope, nope?)
Software Development as a Business Tactic
Now, how is software different?
We can answer the “is it” questions about software trivially with three nopes: no formal education required, no accreditation recognized, and no governing board of ethics. And I’m going to go ahead and toss another three nopes out for the “should those things exist” questions.
Do you think they should exist? Should someone need formal accreditation and ethical governance to write a macro that turns Excel cells red when there are negative numbers in them?
But let’s leave the realm of broader swirling ethics and education and look at software development at its very core.
What is software development?
Well, software development is automation.
And, what is automation?
Automation is the application of technology to make a process more efficient.
And, what is efficiency?
Efficiency is doing more stuff in the same time or doing the same stuff in less time. Efficiency is a means, rather than an end. In other words, efficiency is a business tactic.
But Software Developers Build Stuff!
I like to build and make things, personally. I’ve dabbled in various hobbies in my life, some of which include:
- Home improvement
- Home automation
- Writing (which one resulted in a book)
As you can see, software aside, I very much enjoy the process of creating a thing. So, like most of you reading, I naturally like to think of the software that I build as a thing.
Look at it there on Github! It’s clearly a thing! And double points if it’s something like firmware that powers an actual, physical device.
I get it. I mean, I viscerally get it, because I like building things.
But zoom out a little. And think in business terms.
- If you build a shiny new website for a retail store, are you building the website? Or are you helping the store market more efficiently?
- Let’s say you build a ride sharing app and call it, let’s say, Lyber. Are you building an app and a startup and a culture, or are you helping people get around more efficiently?
- Or, maybe you build a killer static analyzer using machine learning and proven code metrics. Aren’t you just, in the end, helping other people write code more efficiently?
In a commercial context, software is a means to an end and not an end. It’s a tactic that businesses use to operate more efficiently.
Thanks for Crushing My Soul, What’s Your Point?
I’ve gone on for a while here, as I’m wont to do. But I really wanted to lay out the foundation of my reasoning because the conclusion is uncomfortable but important.
Still, you might find yourself wondering why it’s a big deal to think of software creation as an “end” and a “profession,” even if it’s really a business tactic. And you might really be wondering what this has to do with my blogging fodder.
To answer why it matters, think of the hackneyed witticism that someone probably explains smugly to you at least 2 or 3 times per year.
Ya know, when you’re on Facebook, you’re not PAYING them anything. So you may think you’re the customer, but you’re really the PRODUCT!
Now let that piping hot take cool on the windowsill for just a minute, and think about the truth in that statement and the underlying context. You have a constituency inside of an ecosystem that subtly, but fundamentally, misunderstands its own role to such a degree that it can’t really grok the problem with that misunderstanding.
The Downstream Consequences of Misunderstanding
Put more simply, Uncle Steve, your Facebook feed’s favorite political ranter, certainly doesn’t understand his role as Facebook’s product. Do you then really expect him to be able to understand an algorithm designed to administer a dopamine hit once every three sponsored network news ads, that also then sells information about the one he clicks on to third parties? His basic misunderstanding has advanced consequences.
My contention here is that the workaday software developer, misunderstanding the essential point of software, is Uncle Steve.
Uncle Steve the software developer misses the basic point, causing more advanced ones to woosh silently, unseen, over his head. Uncle Steve the software developer, will eternally wonder why the “pointy hair” in the corner office makes more money, doesn’t sit in an open-office plan, plays by a different set of rules, and signs off on whether or not Steve can install a $179 IDE plugin in spite of Steve being obviously more intelligent and capable in general.
At least, he’ll wonder that fleetingly, before the cognitive dissonance kicks in and he tells himself it’s because he’d never want to take his “fingers off the keyboard” or something.
Software as a Business Tactic: Aligning our Goals with the Value We Create
And, that’s just one simple example of the consequences for missing the point. There are others.
Now, I don’t begrudge Steve, the pointy-hair, or really anyone in this equation. But I’d at least like to talk about the equation, and help people make a choice, whatever that choice may be. I mean, hey, I use social media in spite of knowing that I’m the product.
What I’d like to do now is start a conversation about how we can focus on software creation as a means, rather than an end, ideally while not sacrificing the joy of flow states and creating the software itself. But I’d like to help anyone reading and interested position yourselves to develop software in pursuit of your own business interests and autonomy. I’d like to help you exchange vanity goals like experience points on code competition websites for meaningful goals that improve your professional life and grant you more autonomy.
So that developer empowerment theme is what I’m going to return to. I want to talk about how we, as software developers, earn a share of the value we create, rather than bullpens with ping pong tables in the break room and stickers for our laptop to show others what techs we teach ourselves for free in our spare time.
I want to help folks take one of the most useful and marketable (and fun) skills in the world, and get more out of applying it.
So, What’s Next with the Content
Wow, I’ve written a lot of words here. It’s like I bottled them all up for a month and they’re spraying out like a geyser. So, with that vaguely gross metaphor, why don’t I wrap.
The whole premise of this post was my content hiatus and planning what’s next. I’ve generally explained the sort of content that I want to create (helpful, thoughtful, focused on software developer empowerment and the actual business of software development). But I haven’t really gotten specific about what might change.
Well, first of all, I’m working on a pretty weighty next post. I’ve been researching and composing my thoughts to make it less of the sort of screed I just talked about wanting to minimize, and more to be a detailed examination of how, exactly, software developers miss the point of software development and software careers. Sneak peak about the contents of that: it’s tentatively titled, “The Gamification of Software Careers: It’s Time We Grew Up.” (I started with “Gamification Considered Harmful” and then hated myself a little, so I scrapped that.)
But, beyond that, I have some ideas for additional posts. But, here’s the thing. What I’d really love at this point is reader questions. If you look at my Youtube channel, I’ve started answering a lot of reader questions in videos, and I have more of those in the queue, too.
I’ve realized that answering reader questions is truly the path to all of my content desires. Writing endless screeds feels like empty calories. Dreaming up “helpful” how-tos under the assumption that people will value them is dry and bores me. But answering real, actual questions about how to get ahead in software helps me keep things more upbeat, keep the content relevant, and keep myself motivated.
So, please, fire away. Email me at erik at daedtech or ask questions in the comments of the blog. Join the Developer Hegemony Slack and ask me there, or in the Hit Subscribe Slack or on my Youtube channel or, really, anywhere.
As I said thousands of words ago, I can’t not write. So I’ll keep doing it at some pace about something. But I’ll do more of it if you all help me with direction by asking questions.