Home United States USA — software If You Want to Matter in the Software Industry, Stop Being a...

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

276
0
SHARE

This article lists one quality of a programmer-to-consultant path, which is to become an individual who diagnoses and prescribes instead of administers.
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.
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.
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.
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.
Think of it this way. The participants in this criminal conspiracy are in something of a pickle. They can’t exactly call a local cleaning service or send out a task on Fiverr to get what they need. The labor pool is extremely small for people to whom they can delegate execution of the gruesome cleaning tasks. So they wind up (and bear with me here) paying hit men, who presumably command a high hourly rate, to wash a car. This washing is disproportionately expensive because of a labor shortage, but not intrinsically valuable.
Programming isn’t as hard as we make it out to be, when we turn it into a hobby with asinine “coding wars” competitions and such. But nor is it easy. Programming is knowledge work and it requires the amalgamation of complex and formidable mental skills: creating useful abstractions, sequential logic, deductive and inductive reasoning, etc. We’re not punching above our weight in a room with doctors, lawyers and accountants.
So how is it that, unlike all of them, we manage to turn our knowledge work into commodity labor and ourselves into low-influence grunts? Well, as I said, I’m not in rant mode today, and going into that would require a rather lengthy, ranty post. (If you want to see me speak to that in a lot more detail, check out my book, Developer Hegemony .) But let’s just say that a lot of it ties heavily into our assumption that being a “real” programmer means hyper-focusing on writing code and doing little else.
To put it another way, we never bother to think about diagnosis and prescription.
Why are we building the software we’re building? How does it save someone money? Will it contribute to a product that will have product-market fit? And so on. For the most part, only two types of people with programming skills think about these questions.
And, it just so happens, this series is about how to become the latter.
If memory serves, Winston Wolf didn’t do any of the scrubbing. Could he have? Sure. But if someone were value-pricing that whole affair, I think they would have given the Wolf the same (enormous) consultative fee whether he did that himself or delegated it. That should be your model as you start to turn yourself from grunt to consultant.

Continue reading...