DaedTech

Stories about Software

By

Tech Stack, Framework, Library or API: How Not to Specialize

Today, I’m going to keep plugging away with another mid-week post in the developer to consultant series.  To recap, I’ve talked recently about how you need to start by figuring out your positioning and then about how that positioning should orient around problem solving instead of laboring.  Today, I’m going to build on that momentum.  I’m going to talk about the positioning mistake you’re almost certainly going to make and how to avoid it.

The Positioning Mistake

You’re going to try to position yourself around a tech or tech stack.  “I help people with blockchain” or “I’m a Ruby on Rails performance expert.”  Now, this isn’t as bad as the generalist career approach, to be sure.  But it’s really not where you want to go, either.

I’ll get to why in a moment.

But first, let me just say that it’s completely understandable why you gravitate toward this.  Our industry pushes you that way with an aircraft carrier’s worth of momentum.  You should be a generalist and compete with 18,000,000 other programmers to be “the best” and get hired at SiliconPrestigeTech.  Not for you?  Well, fine.  Then get better than everyone else at some tiny piece of technical real estate.  Everything in your experience pushes you this way.

Indulge me for a moment.  I’m going to force one of my parables on you to demonstrate the absurdity of this situation.  And then I hope this will serve as your compass to navigate your way out of the generalist quagmire.

I once wrote a post about what it would be like if contractors behaved like programmers.  This is going to be a bit like that, but doctors are knowledge workers, so it illustrates the point a bit better.  And I’m going to emphasize a different set of specifics.

Walter White, His Doctor Recruiter, and His Doctor Manager

My wife and I have been watching Breaking Bad again over the last month.  It’s not a spoiler if I tell you that the main protagonist, Walter White, receives a cancer diagnosis (it’s the premise of the show).  Lung cancer, and an aggressive form at that.  So let’s imagine Walter in a world where doctors acted like programmers.

The first thing that Walter would need to do is to hire two people for his “diagnose and treat my cancer” project.  These would include a doctor recruiter and a doctor manager.  The doctor manager would sit with Walt, listen to his symptoms, and lay out a roadmap of what comes next.  Now, this doctor manager “isn’t medical” so he would need to enlist doctors to perform the actual diagnosis.  But he’s “medical adjacent” enough to at least know which doctors to call.

Of course, he’s too busy and important to make those calls, so he enlists the doctor recruiter to do that, explaining that he needs someone with at least 7 years of CT scan, 5 years of X-Ray, 6 years Sputum Cytology, 4 years of Biopsy, with strong Bedside Manner skills a plus.

Read More

By

If You Want to Matter in the Software Industry, Stop Being a Laborer

Alright, first things first.  I’m going to do a bit of housekeeping.  My apologies for the sluggish performance of the site lately, and the occasional 500 errors you may have noticed.  My hosting company’s physical machine has been having some issues and they’re trying to figure out whether they can fix it in-situ or whether I need to take an outage while they migrate me to another machine.  Also, my apologies for missing reader question Monday.

Fate has conspired to sentence me to a couple of poor nights of sleep in a row.  So I don’t really have the energy for a rant.  Instead, I’m going to go the more zen route and continue with the “developer to consultant” series.  Today, I’m going to focus on the mindset shift you need in order to go this route.  You need to stop being a laborer.

The Phases of Problem Solving

In a post where I first mentioned this idea of guidance on how to transform yourself into a consultant, I referred to the phases of problem solving.  Roughly speaking, these are the following.

  • Diagnosis of a problem.
  • Prescription of a therapy.
  • Application of the therapy.
  • Re-application/maintenance of the therapy.

When you’re sick, you go to the doctor.  The doctor furnishes a diagnosis and writes you a prescription, and then exits the equation.  An unskilled laborer (i.e. you) then applies the therapy of taking the pills.

A similar concept applies in other sorts of knowledge work.  A lawyer, for instance, figures out which precedents to cite and then hands it over to a law clerk to write up or to an admin to make copies.  Or take a tax accountant.  The accountant herself figures out whether you should file as an S-Corp or pass through the taxes and then turns the paper work over to a less skilled assistant.  You get the idea.

But to tell you how this relates to us and to software, I don’t want to compare us to these people.  I want to compare us to an arch-criminal.

Winston Wolf, Master Consultant

In the movie Pulp Fiction, a couple of gangsters named Jules and Vincent are driving with another guy, Marvin in the backseat.  Gesturing with his gun during conversation, Vincent accidentally blows Marvin’s head off, creating quite a horror show in the car, right in the middle of a public roadway in broad daylight.

Vincent and Jules, hardened criminals though they may be, panic and duck into a nearby associate’s house, and call their boss who sends his “cleaner” — one Winston Wolf.  Wolf is a consultant.  You can watch the (graphic) scene here if you want, but suffice it to say Wolf helps.  He quickly and efficiently sizes up the situation, diagnoses all problems, and lays out a solution.  He then dispatches Vincent and Jules to execute the details of the solution (“apply the therapy”.)

Despite some grousing from Vincent, who doesn’t like being told what to do, Jules and Vincent oblige, and they set about the grotesque tasks of cleaning viscera out of the car, placing liners over the seats, etc.

In this episode, Wolf’s diagnoses and prescription are valuable.  The cleaning/scrubbing/etc tasks of execution are important, but only valuable because of the circumstances.  Without Winston, Vincent and Jules go to jail.  Without Vincent and Jules, someone else could always do the labor.

Read More

By

Positioning Strategy for the Aspiring Consultant

A couple of weeks ago, I wrote a post in which I announced a new flavor of posts for DaedTech.  I was going to do this as a book or video product, but I tired of analysis paralysis.  So I’ve decided to just start teaching anyone reading the tricks to becoming a consultant. (Follow along with a new category).  This is the second post in that series, and it concerns your positioning strategy.

Figuring out your positioning strategy should be the very next thing on your list after figuring out that all software developers should become consultants.

If you just said, “wait, my what?” don’t worry — I’ll get to that.  But first, a bit of tough love.  I have a tactical rant lined up before I can get back to being helpful and upbeat.  It’s for your own good.

The Harsh Truth about Your Current Positioning Strategy

If I ever turn this “from developer to consultant” series into a book or something, I’m not sure if this post from last week will make it or not.  It’s not specifically related, but I’m going to build on it here today.

The Craftsman Positioning Problem

In that post, I talked mainly about our industry’s bemusing fetishizing of medieval craft guilds, and about how letting yourself get sucked into that trap hurts your career.  Toward the bottom of the post, if you’ll recall, I began to talk about positioning.

When you position yourself as a “craftsman,” you’re boasting about superior quality, but competing with cheaper prices.  People who do this fail to understand why people pay them.  But, in all honesty, self-described craftsmen aren’t even the worst at this.  The entire journeyman idealist set gets it badly wrong.

The Broader Developer Positioning Problem

Don't sacrifice your positioning strategy to code-jousting sites, as illustrated by this joust-ready knight.

We as software developers, enabled by opportunists around us, cheerfully ignore the real reason that people pay for us.  It’s fun for us.  We go to sites that let us “joust” or “duel” or “ninja each other” for badges and tokens and stuff, demonstrating that we can write a sorting algorithm 0.01% faster than the runner up.  And then we think that’s our value proposition to employers.

“Why should I hire you?” a non-technical hiring manager might ask.  And you might respond, with something that, in his brain, translates to, “I keyboarded in the stuff with the things and it was 4 nanoseconds faster than the what’s-it by the other guy.”  And then you think that helped you land a job.

If you make $100,000 per year, you might look at a “more senior” developer making $130,000 per year and assume that she’s 30% more awesome than you.  If you suddenly discover that she only knows 4 GOF design patterns off the top of her head to your 14, you might then start railing about the injustice of it all.  The industry meritocracy has failed!  (But not systematically and in a way that invalidates algorithm jousts — just totally in this one isolated case!)

Here’s the thing, though.  To your employer, assuming the employer is larger than “tiny” your two salaries are an inconsequential rounding error.  $100K is $50/hour and $130K is $65/hour and both of those rates line up with low end US contractor talent or good offshore talent, if they’re looking for geographic arbitrage.

They’re not hiring you because you’re “better” at code jousting.  They’re hiring you because you’re the fungible person with the desired citizenship/work status that the interview process spat out the other side.

Read More

By

Software Craftsmanship as a Metaphor is a Career Glass Ceiling

Is software development a craft?  I think this might be a decently long post, so let’s come back to that, to journeyman idealists, and to some of the finer points of what counts as “software craftsmanship” a little later.  Before that, please indulge me in story time.  Or, backstory time, as it were.

About 7 years ago, I digitally “signed” something called the Manifesto for Software Craftsmanship.  Go do a search, if you like.  I’m signatory number 6,662.  I remember submitting that form with something like quiet but fierce indignation in my soul.

Software Craftsmanship as Caring and Professional Pride

The year was, according to the website, 2010, and I was surrounded by expert beginners.  These folks made architecture decisions on the basis mainly of seniority.  The longer you’d hung around the company, the more conceptual votes you ‘earned,’ for some dubious definition of the word earn.

The result?  A codebase littered with global state, spaghetti, beachheads of copy-paste code, and tortured, meandering God classes.  It was like a bomb went off in that codebase.  And if you wanted to try to fix it with newfangled concepts like writing unit tests or paying attention to method complexity, you’d hear predictable expert beginner fare.  “I’ve been doing this for a lot of years, and I’ve been shipping software just fine without any of that stuff.”

In that role, I slowly earned my way into positions of influence and then decision-making before I left.  At the time of my eventual departure, the build executed a growing unit test suite, interfaces existed in the codebase, and I was proud of what I had done.  But it was hard fought and exhausting every step of the way.

And I probably wouldn’t have lasted as long as I did without the galvanization of the software craftsmanship manifesto.  It spoke to me, and it said, “not only is it okay to care and to have standards — it’s your professional obligation.”

My Evolving View of Software Craftsmanship

As recently as last April, I wrote a post about software craftsmanship making for good business.  As a salaried software developer (and company of one, ala Developer Hegemony), you ingratiate yourself more to the business by adopting practices like TDD than you do by competing in algorithm trivia contests that no one who matters can referee.  You start to trade in tight feedback loops, predictable deliveries, and things that make your “clients” really happy.  And you become more marketable as an app dev pro.

And years before that, I defended the software craftsmanship movement against a detractor.  In that post, I argued that the real thrust behind the movement was to establish that software development isn’t an insolvable quagmire of relativism.  Some practices work better than others, and to pretend that isn’t true amounts to quackery, and we shouldn’t tolerate quackery.

In general, if you go back far enough on this blog, you’ll find a bunch of references to software craftsmanship.  And in these references, you’ll find some themes.  I’ve always respected the caring behind the movement, and I’ve always valued the practices: TDD, continuous integration, constant refactoring, etc.  And, whenever I talk about software craftsmanship in praising terms, I’m always talking about those practices and the caring that drives them (including in the post about software craftsmanship being good business).

But, truth be told, I’ve never had much use for the term “craftsmanship,” per se.  Historically, I didn’t give it much thought one way or the other — it was just branding, like “agile” or “lean.”  But over the years people have started to fetishize the craft guild metaphor into titles and practices and even into a philosophical way of looking at software.

And if you fall into this trap, you do so at your career’s peril.

Read More

By

Why Every Software Developer Should Become a Consultant

Since writing Developer Hegemony, leaving the traveling consultant life, and spending a lot of time building a content agency, I’ve flailed around a little with what I want to do with DaedTech.  What do I do with this thing, anyway?

I could treat DaedTech as one of Hit Subscribe’s clients.  But DaedTech isn’t really that kind of business.   I could continue to write a series of posts about whatever happens to be on my mind.  Maybe a mix of technical, career, and the like.  But, these days I write more than enough blog posts for our clients to scratch that itch and then some.  So, what to do?

Well, I’ve had plans to build an info product or info products to continue the ideas I laid out in Developer Hegemony.  And more and more people are also asking me about mentoring/coaching/advice in various forms.  But I think all of this is slapping me with analysis paralysis.  How should I structure things with DaedTech to support the eventual vision of whatever it is I decide later to do?

Ugh.  Maybe it’s time to stop with this nonsense and just start creating the information.  I figure I can do it as blog posts, maybe in a series.  If that goes well, world will spread, people will find it valuable and the revenue thing will happen somehow.  Lead with value, and all that.

The Career Empowerment Prologue

So let’s do that.  And to start, I’ll give you what would have probably preceded chapter one in the book idea that I’ve toyed with about how to empower yourself in your career.

Think of this as the prologue.  And the prologue of how to become a consultant involves explaining why I think you should.  And I don’t mean that some of you, maybe should, if you feel like it.  No, I mean that everyone who counts him or herself a programmer, software engineer, software developer, or whatever other strange titles we give ourselves, should be a consultant.

Now to qualify that statement, I need to explain what I mean by “consultant.”  As I’ve discussed before on this blog, the term gets truly mangled in our industry.  A lot of people think that it means a software developer that writes code for a company other than their employer.  Some think it means you come in, hand wave and spout buzzwords, and leave before anyone can figure out if you’re helpful or not.  And still others think it’s sort of a black belt of soft skills kind of deal.

But it’s none of these things.  Instead, being a consultant means something much simpler.  It means that you provide expert advice in exchange for money.  And every one of you code-slingers out there should do exactly that.

Read More