DaedTech

Stories about Software

By

Two Flavors of Technical Opportunists: Missionaries and Mercenaries

“Missionaries and mercenaries” has a pretty intriguing ring to it, huh?  I wish I could claim credit for it, but I heard about it on this podcast with Ribbonfarm creator Venkat Rao.  Apparently, entrepreneurs use this pithy phrase to make a distinction among themselves.  I’ll explain in more detail shortly.

First, however, I’d like to do a bit of explanatory housekeeping.  In the coming months, I’m going to make some changes to my life.  Specifically, I plan to wind down the management consulting in favor of creating content (products) and offering productized-services.  This may sound a little crazy to you.  It would have sounded crazy (or naive) to me up until a few years ago.  Why trade a high profile consulting career for… an unknown?  So I want to explain myself before I lose sight of the fact that I might need to explain that to people.

On “Trading Hours for Dollars”

I’ll tell a quick story to clarify.  A few years back, I’d decided to leave a CIO position in favor of consulting as a free agent (which may also sound crazy, but it worked out).  As I looked to build my book of business, I was chatting with fellow Pluralsight author John Sonmez about the jump he had made away from full time employment.  He said something during that conversation that I’ll never forget, when I asked him about how he finds consulting work.

“To be honest, I’m trying to get away from trading hours for dollars.”

When you listen to the podcasts I listen to, read the books I read, and talk to the people I talk to, you’ll hear this a lot.  At the time, however, I had never heard anyone say that.  I probably replied with something noncommittal like, “oh, that’s awesome, man.”  Meanwhile, I recall thinking to myself, “I don’t even… wat?”

These days, I completely get it.  Back then, I didn’t.  And so I want to start bridging the gap before the curse of knowledge consumes me and I just assume that everyone shares my perspective on hourly work and the corporate condition.

Developer Hegemony launches on May 2nd, and people have been asking me what comes next.  Well, among other things, I plan to pursue a line of business wherein I help support people executing their plan to achieve developer hegemony.  But before I can do that, I have some mental groundwork to lay.  And that brings me back to missionaries and mercenaries.

Opportunist Escapees

If you’ve only recently come to read my blog, understand that I mean something deeper than the dictionary definition when I talk about “opportunists.”  I explain in depth in this post, but this graphic should suffice.

Most simply, opportunists are those who maneuver their way to the top of the pyramid-shaped corporations.  The C-suite consists exclusively of these folks, but you’ll also find them at all levels of the organization.  I think of those working their way up as “ascendant opportunists.”

But wherever you find them in the corporate hierarchy at the moment, you’ll find that all of them have ceded good faith with the organization.  In other words, opportunists ascend rapidly by coming to understand the essential bankruptcy of the corporate advancement narrative.  They arrive at their positions and status through the lonely recognition that the normal corporate rules are for the idealists and pragmatists around them.  They chuckle internally, behind a careful poker face, at the notion that companies can have such things as “missions” and “values.”

If you really want to dive deep into the psyche of the opportunist, my book talks about this archetype and the other players in detail.  For our purposes here, I want to talk about what happens to these players when they exit the game.  (And make no mistake, they’re the only ones who ever do this side of retirement.)  What fates await opportunists that exit pyramid-shaped corporate life?

Read More

By

So, You’ve Inherited a Legacy Codebase

Editorial Note: I originally wrote this post for the SubMain blog.  You can check out the original here, at their site.  While you’re there, have a look around at some of the other posts and sign up for the feed.

During my younger days, I worked for a company that made a habit of strategic acquisition.  They didn’t participate in Time Warner style mergers, but periodically they would purchase a smaller competitor or a related product.  And on more than one occasion, I inherited the lead role for the assimilating software from one of these organizations.  Lucky me, right?

If I think in terms of how to describe this to someone, a plumbing analogy comes to mind.  Over the years, I have learned enough about plumbing to handle most tasks myself.  And this has exposed me to the irony of discovering a small leak in a fitting plugged by grit or debris.  I find this ironic because two wrongs make a right.  A dirty, leaky fitting reaches sub-optimal equilibrium and you spring a leak when you clean it.

Legacy codebases have this issue as well.  You inherit some acquired codebase, fix a tiny bug, and suddenly the defect flood gates open.  And then you realize the perilousness of your situation.

While you might not have come by it in the same way that I did, I imagine you can relate.  At some point or another, just about every developer has been thrust into supporting some creaky codebase.  How should you handle this?

Read More

By

Expert Beginners Rendered Obsolete

I got an awesome tweet at the Expert Beginner twitter account the other day.  Omer had one of those “wow, I can’t believe I never thought of this myself” ideas.

Yes, please.  Up until this point, I have run this account as a solo effort.  But I certainly have no exclusive claim to some of the world’s worst wisdom delivered with some of the world’s most confidence.

So I am now accepting submissions via twitter DM.  Please send them my way, and I will curate, catalog and queue.  As my work becomes increasingly remote and reclusive, I need all the fodder I can get for the account.

Speaking of Expert Beginners

In case you followed this blog only recently, I’m talking about a phenomenon that started with this post.  You know that one job you had once?  It lasted a year and a half, but seemed like 12.  It dragged because of the senior principal architect on the project.  Courtesy of random name generator, we’ll call him Dale.

Dale eschewed popular frameworks because he once wrote this combination ORM-MVC platform back in 2004 and, in his mind, it’s still chugging along nicely.  This framework set the world record for depth of inheritance hierarchy at 124, per your last count.  Every time you wanted to add a column to some table in a CRUD app, Dale would have to come over and perform open heart surgery at your desk while you tried to read XKCD on your phone without his notice.  But should you ever go off on your own and download something like an actual ORM, Dale would go completely nuclear.

In Dale, we have a classic Expert Beginner.  You put up with him for as long as you could before moving on to greener pastures, but you’re pretty sure he’s still there, jamming his tortured framework into some already-doomed CRUD app.

Dale will tell you what’s wrong with so-called professional ORMs.

Anyway, as I decided to throw the satirical account open to public suggestions, I began to contemplate this older concept of mine against the backdrop of some newer ones.  (Can you believe this dude is 5 years old, already?)

Expert Beginners and Developer Hegemony

Specifically, I started to think about how the relatively simple profile of the Expert Beginner has aged.  In the years between his birth on my blog and the recent completion of my book, Developer Hegemony, I’ve spent a lot of time and mileage consulting.  In particular, I have done a good bit of training and management consulting following a stint as a technical executive.  This has furnished me with the office politics equivalent of language immersion.

I began to wonder about the fate of the expert beginner in the world of developer hegemony that I foresee.  I mention him some in the book, kind of in passing.  But what will actually come of him?

Read More

By

The Whiteboard Interview: Adulthood Deferred

I haven’t traveled this week (at least, not for work).  As a result of that, I’ve sat at home, where I tend to have somewhat higher social media consumption.  I therefore couldn’t help but see this post about “confessing coding sins.”

Twitter has, apparently, overflowed with established software developers ‘confessing’ that they would fail Gigantech Inc’s whiteboard/trivia interviews.  I’d like to go on record to point out that I ranted about the foolishness of this practice long before DHH made doing so cool with this tweet.

Here we have legendary techie David Heinemeier Hansson confessing that the Silicon Valley Gigantechs of the world would fail him out of their phone screens.  His tweet offers a compelling symmetry.  After all, when a cranky Thomas Edison invented the ineffective fad known as the “job interview” (that we haven’t bothered to revisit in the last 100 years), his interview would have failed Albert Einstein.

So, when it comes to the humble job interview, we at least know that it’s consistent.  It fails at its only job just as miserably today as it did in the beginning.  All of the MegaTechs out there in The Valley (and emulators around the world) would have passed on hiring meteoric value-creator DHH, thus calling into question the ubiquitous and vacuous claim of every company out there that “we only hire the best and brightest.”

But let’s come back to DHH a little later.  First, to celebrate the coming spring, I want to talk about baseball.

Wins Above Replacement (WAR)

Even if you don’t enjoy the sport of baseball, you should at least appreciate it for its data.  Unlike many sports out there, baseball happens transactionally.  The pitcher throws a pitch, and then a bunch of easily recorded stuff happens before play stops and this all starts over.  Oh, and we’ve kept logs of this going back 150 years or so.  This property has given rise to an entire discipline of statistics called sabermetrics.  So even if you don’t like home runs and hot dogs, you can at least appreciate the Big Data.

Baseball has a fascinating stat known by industry nerds as “Wins above Replacement (WAR).”  I’ll quote them directly on the meaning.

WAR offers an estimate to answer the question, “If this player got injured and their team had to replace them with a freely available minor leaguer or a AAAA player from their bench, how much value would the team be losing?”

Let me parse out the baseball jargon and simplify.  It asks, “how much value (in wins) does this player provide compared to an unremarkable replacement?”  Modern baseball clubs wager hundreds of millions of dollars answering this question.  A player with WAR above 5 commands that kind of money whereas one with a negative WAR gets a pat on the butt and an imminently unremarkable minor league contract.

WAR ain’t perfect.  But it pretty reasonably approximates player financial value.

What does any of this have to do with the job interview or whiteboard coding algorithms?  Well, the job interview represents the business world’s ludicrous attempt to calculate VAR (value above replacement) of prospective hires.

Read More

By

Taking the Guild Metaphor Too Far

Today, I’d like to talk about the pervasiveness of the craft guild metaphor in today’s software development landscape.  Specifically, I want to talk about how I think we’ve jumped the shark with this and how it now harms more than helps.  I recognize that I’m probably going to inspire some ire and get myself in trouble here, but please hear me out a bit.

First of all, some words of caveat.  I don’t say this from a place of any hostility or really even criticism.  In other words, I don’t take the position, “you’re all making a mistake with this and being silly.”  Rather, the more I wrote in Developer Hegemony, the more the guild metaphor came to feel wrong to me.  But only during the course of the last few days did I figure out how to articulate why.  So now, I post from the perspective of, “I think we recently took a slight wrong turn and that we should stop to reconnoiter a bit.”

Before I get to building my case, I want to spend some time applauding the guild metaphor for what I believe it has provided us.  I believe it important that I do so because it clarifies my position.  You can’t make a “wrong turn” without having started on the right track.

Also note that I don’t believe anyone has stated what I’m about to say as the reasoning for the metaphor.  What you will read next comes from inferences I have made.

Prequel to the Guild Metaphor: Drilling Holes in Sheet Metal

Corporate software development, by and large, got its start helping organizations capitalize on efficiency opportunities.  Some VP of something, looking at a typed spreadsheet, would say “if we could speed this process up by 25%, we could hit our third quarter numbers!  Poindexter, come in here and do that thing you do with the computer and make it so!”

Poindexter would then leave and come back a few days later.  “I flipped the bits and bypassed the mainframe and transmogrified the capacitor and –“

“In English, Poindexter!”

“Oh, right, sorry Mr. Rearden.  I was able to do a 30% speedup.”

“Good work, Poindexter!”

In this world, you had business people who would create strategy and delegate cost savings to geeks in bite sized morsels.  The geeks would diligently execute their tasks.

Because of this historical and ubiquitous communication deficit, the business people misunderstood the nature of geek work.  Their mental model of software development paralleled it to building construction and manufacturing.  The geeks occupied the role of line level laborers in their particular domain.  And so decades of horribly mismanaged software projects ensued.

“Come on, Poindexter, I need your codes for the next speedup by Friday or we won’t make our numbers!”

“But, Mr. Rearden, you don’t understand – it’s not that simple!  We can’t just – “

“Look, Poindexter, it’s not rocket science.  Just code faster and copy and paste the thing you did last time.  Think of yourself as a guy who drills holes in sheet metal, Poindexter.  Get a stronger drill bit, and lay the last sheet over the new one, using it as a template.  Do I have to think of everything?!”

“But, Mr. Rearden, it doesn’t work that – “

“Shut up Poindexter, or I’ll find a cheaper, offshore Poindexter!”

Read More