Software Craftsmanship is Good Business

Tonight, I logged into my site and saw a picture of someone’s colon, compliments of everyone’s favorite NSFW advertising engine, Disqus.  (Read more about this here).  Enough is enough, so I switched commenting engines.  Please bear with me and let me know if you have issues with comments.

On a less aggravating note, please enjoy post number 4 of Developer Hegemony week!  Pre-launch activities are progressing nicely, and I’m looking forward to the launch.  If you’d like a free paperback copy of the book, remember to sign up for the Thunderclap.IT campaign so that we can get to the sharing threshold — we’re halfway there, but I still need your help.  It only takes a second.

I feel as though I’d like to balance the scales a bit.  Lately, I’ve made a lot of realpolitik posts about how organizations cast software developers as grunts.  This is true, but also depressing.  So let’s talk about the uplifting alignment between well reasoned code and success in career and business.

Raw Programmer Skill and Diminishing Marginal Returns

First of all, I should point out that I talk a good bit about the diminishing marginal returns of programming skill, both in posts and in Developer Hegemony.  And I stand by that.  To understand why, I invite you to do a thought exercise with me.

I’m pretty sure that most of you programmers reading, if you were so inclined, could go out and find a new job within a few weeks.  And, what’s more, you could probably negotiate a 5% pay increase to switch.  Did you suddenly become 5% better at programming?  Or would you acknowledge that programmer pay doesn’t necessarily correlate simply with programmer skill?

The industry isn’t meritocratic.  Of course, the industry is also not anti-meritocratic.  Rather, if programmer skill and programmer pay had a mutual Facebook relationship status, they would choose it’s complicated.

I would further reinforce the point about diminishing returns.  Go from zero to decent programmer and you might go from 30K per year for non-degreed work to $90K per year for programming.  Go from decent to highly skilled, and you can climb to $120K, which feels less life-changing.  Beyond $120K, your increased skills help you not a lick at puncturing the software developer’s glass ceiling.  Diminishing returns on skill investment.

Good vs Valuable

But don’t despair.  Winning programming “contests” and algorithm trivia jousts won’t pay off, but that doesn’t mean that you can’t make your software career pay off.  You just need to understand what businesses value.

So far, all we’ve done is figure out what they don’t value.  Namely, they don’t value journeyman idealist pissing contests.  The company will say, “it’s great that you can write a compiler on the back of a napkin and have it work flawlessly the first time it’s transcribed and run, but I only want that within the Software Engineer IV salary band.”  The company doesn’t value this prodigious industry cred the way your peers do.

And why should they?  If the company sells cable modems, how does that compiler help them?  “I can see that you’re quite good, but we don’t find this valuable.”

The trick then becomes establishing yourself as valuable.  And, while valuable and good have a deeply intertwined relationship, you cannot simply interchange them.  I submit that the software craftsmanship ideal offers you a ready-made playbook for turning good into valuable.

A Note on Your Approach Valuation

Since I’ve declared it Developer Hegemony week on my blog, I have to include a developer will to power career angle.  I’ll talk in the remainder of the post about the value you offer to others.  But let me talk for a moment about how to reason about that value.

Right at the core of the book’s message lies the notion that you should stop thinking of yourself as an employee and start thinking of yourself as a one person business.  As a business, you sell app dev professionally, albeit to only one client (your “employer”).  And, as a business, you need to worry about your marketing, branding, operations and finances.

Today, I’m going to talk about how software craftsmanship makes for good business.  And the business to which I refer is your business of one as you navigate your career.

The Software Craftsmanship Marketing Angle

Before I get into the nitty-gritty of why software craftsmanship helps you offer legitimate value, let me talk first about marketing and perceived value.  Your career benefits just from being perceived as a software craftsmanship person.  It makes me feel a bit slimy to type this, but that doesn’t make it inaccurate.

The principles and practices of craftsmanship have won.  The industry acknowledges the wisdom of tight feedback loops, clean and readable code, continuous integration, test driven development (TDD), etc.  People either do these things or they talk resentfully about how overrated they are.  But both of those things contribute to the common perception of their superiority.

Think of arguing against TDD today as the equivalent of arguing against source control 10 years ago (rightly or wrongly).  Putting yourself on the wrong side of history won’t help your overall marketability, and it will get worse as time goes on.

So, in the most superficial sense, you should board the craftsmanship train because it helps your brand by association.

The Software Craftsmanship Satisfaction Result

Let’s stop working angles for a moment and consider something straightforward.  Software craftsmanship principles lead to better code because they lead to more valuable code as far as the business (your client) sees it.

People could take to the comments and argue ’til they’re blue in the face about whether TDD represents the one true way to code.  But what they can’t argue is that TDD forces small, factored, testable units of code into the production result.  And they can’t argue that these small, testable units wind up simpler to change.  And they can’t argue that simpler to change means less expensive for the business at change time.

Let me generalize, since this subject could entail a post unto itself.  Software craftsmanship principles force you to write code in a way that pleases the business.  They get frequent deliveries, with code specifically written to promote ease of maintenance and a flat cost of change.  Businesses love this.  So, if you get a reputation for delivering code with these properties, you get a reputation as a valuable service provider.

Pennies in Heaven

When you deliver code on time, your client (employer) loves you.  When you continue to deliver code on time, that love and esteem grows.  But when they come to you asking if you can make a quick change to the invoicing module and you say, “whoo — not the way we built it,” they get irate.  That esteem shrinks.

Software craftsmanship practices steer you away from the kinds of messes that force you to say no.  Instead, those practices push you toward yes.  You say yes over and over again, deliver over and over again, and your brand grows.  You gain a reputation.

So much of our industry involves unsustainable spasms of effort (sometimes affectionately called “death marches”).  We frequently respond to complex projects in high-uncertainty environments by flailing and panicking.  As a result, presiding over calm, measured successes earns you a long range reputation.  (Though, in the short term, you may notice more kudos going to someone that pulled 15 all-nighters than someone that calmly and quietly got things done ahead of schedule)

Software craftsmanship principles thus earn you a reputation over time as a solid and dependable service provider.

The Basis for Efficiencer Status

I’ve enjoyed talking about how writing good software pleases your customers (employers).  In a world of realpolitik corporate intrigue, simple, PG style narratives feel good when you can tell them and have them be true.  Life should always be so simple as, “work hard, help people, and earn rewards.”  Alas.

When you develop a skill set that allows you to write code that businesses appreciate, you have a natural tendency to develop an ability to explain that style of software development to the business.  You learn about metaphors like “technical debt” and about non-techie grokkable terms like “inappropriate coupling” and “lack of a test suite safety net.”  And, when you least expect it, you start to sound an awful lot like a consultant talking about the business of software development.

In Developer Hegemony and on my blog, I urge you to become more business savvy.  Pick a niche in which to offer automation services, and operate as a business in that niche.  Become an efficiencer.  And, while niching in the business of app dev isn’t a great end state, it’s better than talking about how many years of C# you’ve done.

When people do programming contests, they’re participating in amateur hour.  Literally.  Activities you do that have no business/commercial value are hobbies and thus the province of amateurs.  If you want to get serious about the business of software, look to software craftsmanship.

Want more content like this?

Sign up for my mailing list, and get about 10 posts' worth of content, excerpted from my latest book as a PDF. (Don't worry about signing up again -- the list is smart enough to keep each email only once.)

Get the content!