DaedTech

Stories about Software

By

Disrupting Agile and the Process Industry

Tonight I give you post number 5 of Developer Hegemony week.  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 now three quarters of the way there, but I still need your help.  It only takes a second.  About 25 more share signups, and I’ll do the raffle!

Whenever I hear the word disruption in the context of industry, my mind does something weird.  It immediately transforms it into someone saying, “hashtag disruption” and then doing jazz hands.  So you can only imagine my mental model (and, honestly, mild hypocrisy) for a title about disrupting agile.  But please bear with me.

I once wrote a post about the nuts and bolts of buzzword fatigue.  And, clearly disruption and agile both quality as buzzwords.  Disruption as a concept originated in Silicon valley’s lexicon.  From there, it wormed its way out into general, uncool industry like a rogue wave of fanny packs.  By now, people talking expansively about disruption have probably never disrupted anything more than an Applebee’s by coming in for dinner 3 minutes before closing.  Jazz hands.

Read More

By

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.

Read More

By

A Closer Look at the Efficiencer Firm

For Day 3 of Developer Hegemony Week, I’m going to up the stakes on the Thunderclap.IT campaign.  If you sign up, you could win a free paperback copy of the book.  I’m going to raffle off three books at random for everyone that signs up, but only if we meet the goal of 100 participants.  We’re more than a third of the way there, but still have a long way to go.

For Monday morning’s post, I introduced the efficiencer in detail.  But I took an admittedly philosophical tack in that post, offering more rhetoric than specifics.  Today, I’d like go get specific instead.  I want to talk about more pragmatically about the efficiencer firm.

In order to do that, I’m going to start by talking about inefficiency.  After all, as efficiencers, we ought to have a keen eye for such things.

My Stint Making Hearing Aid Fitting Software

Years ago, I went to work for a company that manufactured hearing aids.  This included several brands under the umbrella of the parent corporation, and all of them had international distribution networks.  So, at the end of the day, the company does everything needed for the manufacture and global distribution of hearing aids.

Operationally, this includes something you might not consider at first blush.  Hearing aids need something called fitting software.  The people responsible for prescribing hearing aids to the population, audiologists, use this software to program the devices.  This includes configuring different gains at different frequencies and setting up so-called “programs” that wearers can use in different environments.  For instance, you might have a “restaurant” program with a much different array of settings than a “home watching TV” program.

Since you didn’t come here to learn the particulars of the hearing aid business, I won’t keep going with further detail.  But I could.  A lot.  As I would learn during my tenure there, developer in this space face a steep learning curve.  The complex nature of sound and gains mixes with the bureaucratic world of medical devices and regulations for a rich tapestry of arcane complexity.  Months passed before I got my bearings there.

Read More

By

Why is Staff Aug a Dirty Term?

This is day 2 of Developer Hegemony Week, and the book goes live in just over a week.  I’m about a third of the way there on my Thunderclap Campaign, but I need your help!  Even if you’ve already signed up, you can sign up from both Facebook and Twitter.  Thanks to everyone for your support!

“Don’t worry.  We’re not a staff aug firm or anything like that.”

Years before this would matter to me, I remember some recruiter saying this to me on the phone.  I didn’t know what “staff aug” meant, so I remember looking it up afterward.  I won’t force you to do that, though.

“Staff aug” abbreviates the longer form term staff augmentation.  Wiki attempts to utterly crush readers’ souls by calling it an “allocation of dedicated technical resources, usually offshore, hired as overseas development extensions of in-house application development teams on fixed or flexible terms and conditions”.  Jargon aside, it refers to hiring a relatively disposable contractor in lieu of a more permanent employee.

Over the course of the decade following that recruiter call that I never pursued, I learned a great deal more about this subject.  In the world of custom app dev (er, excuse me, “consulting”), you have two types of firms.  First, you have staff aug firms, and then you have firms that scream from the rooftops that they would never stoop to the gutter of staff aug.  Apparently, there’s nothing in between.

Don’t believe me?  Check out this post from an app dev shop.  In 2015, they derisively called the staff augmentation firm a “body shop” and declared it dead.  “The recruiting and staff augmentation model is losing popularity in the industry – they are going the way of the dinosaur. Dunzo.”  Two years later, it turns out that reports of its death may have been greatly exaggerated.

Still, why all of the hostility and scorn?  Why does the industry split this way?

Staff Aug from the Client’s Perspective

Have you ever worked alongside some guy who seemed unremarkable until you learned that he didn’t really work for your company?  He could have fooled you, though.  He came in every day, attended all of the meetings, and exhibited consummately middle-of-the-pack amounts of skill.  But in spite of looking, walking, and quacking just like a fellow employee, he turned out to be contractor.

To make matters even more mystifying (and aggravating), you subsequently learned that the company pays a lot more for him than for you.  At some point, you probably (half) joked to a coworker that you should quit and return as a contractor to make twice the money.  Inside, you may have seethed at the injustice of it all.  Why should he make so much more when you do better work?

You may not like the answer.

Read More

By

Your Job Title of Tomorrow: Efficiencer

Since I boasted about this on Twitter, I have to follow through.  I’m going to do “Developer Hegemony Week” on my blog, leading up to the book launch on May 2nd.  (I suppose this makes Developer Hegemony Week a misnomer of sorts, since we’re talking about 9 days of posts.)  I can think of no better way to kick this off than to talk about “the efficiencer.”  For those of you not familiar, Developer Hegemony is the book I’ve written and am launching on Amazon soon.  In it, I coin the term efficiencer.

First, though, some housekeeping.  I need a bit of help from you, if you don’t mind helping.  I’ve started a Thunderclap.IT campaign to help with the book launch.  Thunderclap operates according to a simple, kickstarter-like premise.  If I can get 100 people to sign up to tweet or share the book, then all of those shares go out on launch day.  If I fall short, all becomes for naught as none of the shares go out.

Okay.  Back to explaining why I’ve coined a word and why you should care.  For the rest of this post, I took an excerpt from the book and modified it a bit.  I’m now offering it here as a canonical definition for the blog.  And in it, I explain why we need to go from shrugging when presented with wire-frames and specs to saying, “I understand the business problem you’re trying to solve — let’s talk revenue goals, and you can leave the specs to me.”

I’m Glad You Called — I’d Love Some Unsolicited Financial Advice!

My cell phone rang about mid-morning, and it presented me with the ultimate conundrum for an introverted entrepreneur/consultant: an unrecognized phone number from my area code. On the one hand, it could have been a prospective client or generally someone whose call it would make sense to take. On the other hand, I didn’t recognize the number, which usually signals some kind of solicitor or scam. I decided to answer because I thought I’d seen the number before. Either someone really wanted to talk to me or I’d have to tell them to put me on their do not call list to get them to leave me alone.

I instantly regretted my decision to answer. A criminally cheerful voice said, “Is this Erik Dietrich?!” You’d think he’d just gotten his personal hero on the phone.

I sighed, recognizing the forced, chipper tone of someone who lives by the motto “Always be closing.” “Yes,” I said guardedly.

He told me that one of my friends had referred him to me, saying that I was someone that would potentially be interested in his services. He was a financial planner, you see, who specialized in helping young couples achieve their dreams — couples like my wife and me, as my luck would have it. “When is a good time for us to get coffee?” he asked after blithely glossing over this dubious introduction. (My friend never had, in fact, briefed me that this guy would call.)

Do you see what he did there? It’s a classic sales technique wherein you don’t give the mark prospect the option of saying no. This bit of slicked-back-hair salesmanship is a close cousin of the “loaded question” logical fallacy. “Have you stopped cheating on your taxes?” “Yes, I mean, no, I mean—hey!!” No matter how you answer the question, you implicitly concede a point made by the asker. In the case of our used-car salesman cum financial planner, answering his question politely leaves me no choice but to agree to meet him.

I sighed again. Briefly, I thought about setting a meeting at some Starbucks in the area and then never thinking about him again. But that seemed disproportionately cruel, so I broke script and told him that I wasn’t interested. After taking one more stab at me with a “When is a good time to follow up to see if you’ve changed your mind?” he’d exhausted his slimy script and hung up on me with no fanfare. Class act from start to finish. I should call him back, say I’ve reconsidered, and set up that phony meeting after all.

Read More