Stories about Software


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.

Don’t worry.

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.

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:

  • Cooking
  • 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.

Newest Most Voted
Inline Feedbacks
View all comments
Santiago Magariños
4 years ago

Thanks for the great post and congrats on the choice for the new direction! “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.” As long time reader, I couldn’t be happier! I would like to dispute the assertion that software is just efficiency or automation. A video game doesn’t fit very well any of those words. Code also creates new possibilities: virtual worlds, virtual communities (which are not necessarily more efficient), trust systems (blockchain). This matters because a lot of business value comes… Read more »

Mark Johnston
4 years ago

Welcome back!!

So profound. Great post, Erik!!

4 years ago

Here is my question: What do you think is the best way to implement this sort of philosophy of “software as a business tactic” for Game Developers who develop software not for business, not to be “useful” in the usual way, but for ludic purposes, where the software is much more an objective in itself then things like productivity software which are done to enable something else.

Joshua Beck
Joshua Beck
4 years ago
Reply to  Erik Dietrich

You might not be aware that it is common for a developer to create a game without selling it to consumers directly. In this case, it is possible to sell video game software as a business tactic. One of the important divisions in much of the video game industry is between developers and publishers. A “developer” is a team of people responsible for creating the game. So not just programmers, but also composers, artists, level designers, etc. Publishers are responsible for everything else required to get a game into customers’ hands, and also perform the important function of funding the… Read more »

4 years ago
Reply to  Erik Dietrich

I meant software developers, working for money (either wage or freelancer), that happen to be game developers.

4 years ago

This post was quite the dance, and I’m still not sure what I’m supposed to take away from it.

4 years ago

Shoddy journalism and sad clickbaits are a buisness tactic, not a profession

Mike Stallings
Mike Stallings
4 years ago

Interestingly, generally speaking, the “professions” are precisely the jobs that software is most likely to first automate away.

Erik Dietrich
4 years ago
Reply to  Mike Stallings

Did you have specific ones in mind? Because for me, what comes first time mind are doctors and lawyers, both of which seem likely to hang around. Are you think of professional trades, like electricians?

Rob Saddler
Rob Saddler
4 years ago

I completely subscribe to this world view of software development Erik. I thought Gojko Adzic made this point very nicely in his Impact Mapping work:


In short, he makes the point for delivering business outcomes, not features, and using impact maps as a way to keep that idea in sharp and constant focus.

Erik Dietrich
4 years ago
Reply to  Rob Saddler

Seems like an interesting concept. I hadn’t seen that before — thanks for the link.

Joseph S Stevens
Joseph S Stevens
4 years ago

This article really hit home for me. I find myself becoming increasingly frustrated I can’t build systems, and instead have to do other things like meetings and “discussing the best approach”. I would say there is a certain argument to be had about keeping the values Bob put in place. I can imagine in a world where developers only care about business value. Copy paste sloppy hacky code could become the norm. And then it is incredibly difficult to clean up hockey code after the fact, rather than not do it sloppy in the first place. But… I can also… Read more »

Erik Dietrich
4 years ago

Glad it if provided interesting fodder to think about. Along the lines of developers focused on business/end-user value, I think experienced developers would be uniquely in place and motivated to prevent that situation. They’re understand the trade-offs in question better than anyone: “we’re going to pay for this later.”

I think, for instance, about the codebase that I keep for managing Hit Subscribe’s editorial calendar and that exact thing goes through my head constantly.

Damien Lebreuilly
Damien Lebreuilly
4 years ago

Hi, This post is interesting, and I agree when you say that automation is a business tactic. However, I don’t really see why this would be incompatible with a profession. In fact, I would even go as far as saying that the fact that automation is mostly used as a business tactic is the main reason for needing a profession around it, because ethics is not really something that businesses are known for making a priority. To reflect on your criteria for a profession, we still lack serious studies, but we have a body of common knowledge, practices and tools… Read more »

4 years ago

This seems to ruffle quite a few feathers. I think the word “professional” is overloaded with positive connotations (vs. amateur for example) so naturally people react annoyed when what they’re doing isn’t called a profession.