Programmer for Hire

A while back I interviewed a longtime client on how he viewed working with me: I was looking to get a real, introspective look on what works about my style of service, what’s lacking, why hire me at all, and so on.

I got a number of pearls out of the experience, but one in particular I’d never heard or even considered before: “What’s really nice is that you put up no resistance.”  Eh?  “Say more about that”, I replied.

Paraphrasing, he said that when there’s a problem or a snag I just go with the flow of whatever is deemed important and I’m game to just work any which way towards a solution.  Whenever faced with “hey, this isn’t working”, I’ll quickly improvise a fix and it’s NOT A BIG DEAL.  No resistance.

What a cool distinction.

For sure, it’s common in my field for formality and ceremony to get in the way of a quick, pragmatic solution to a problem (this is, after all, an industry that derives a lot of self-importance out of months long dev cycles, rigid road maps to follow, rigorous testing, and the occasional 370 million dollar error).  So if a programmer assumes the demeanor that doing X or changing Y will be a big deal and is likely to take loads of time or apt to cause tons of complications, their expertise and warning generally needs to be heeded, at least by non-programmers.  (This is not unlike the futility of arguing with your mechanic over the state of your car’s transmission, when you are not a mechanic.)

Being a low resistance programmer requires a combination of both mastery over the domain (necessary to responsibly perform a given task, correctly and without ill side-effects) and the discipline to not indulge in a story of exaggerated burden (which can be gamed for inflated pay and longer time lines).  So when it comes to the relative merits of programmers, low resistance is of course favorable, but only given comparably good end results.  Two programmers might share the “can do, no problem” attitude up front, but if one of them took 3 times longer than anticipated or made a quick mess of things, that’s a matter of being naive, not willing and able.

Every situation is different, of course (some things should be a quick fix, and others genuinely are a big deal), but over time I think it’s possible for a non-programmer to gauge what kind of programmer they are working with.  Say you have a programmer that you rely for keeping critical parts of your business operations running smoothly.  If it’s a pleasure to bring issues to their attention because you typically leave the interaction with a sense of peace and that all is well in the world, you probably have a programmer who makes your issues theirs, and then makes small and tidy work of it.  If you have someone you hate to bring problems too because it makes you feel like life is generally a complicated mess, then you probably have a programmer who’s more invested in telling you how hard their work is than actually tending to what you need them for.

There are some services for which I think the model of charging based on an hourly rate is appropriate.  Software development is not one of them.

Consider: some services fit the hourly model to a T.  These are jobs where the hours spent are directly proportional to the value realized by the hirer.  It makes sense that getting the hour long massage costs roughly double what the 30 minute session does.  Or manning a reception desk.  When somebody needs to be there, every hour that a body is there that creates value and fulfills a need of the hirer.

But software development runs counter to this notion.  We programmers are pretty much always hired to solve a real problem stemming from a real need, not to provide hours of coverage hunched over a keyboard, and certainly not to provide extended enjoyment for the client by virtue of working longer hours (the massage therapist might hear the phrase “hey, that’s nice, why don’t you do that a little longer?”, I don’t think a programmer ever has).

No, in software development it’s virtually always the opposite: the longer a project drones on, the more painful it is.  Just ask any stressed-out looking project manager who keeps getting excuses and pushed back deadlines from her development team.

But doesn’t more hours mean more quality?

Maybe, but that correlation is sketchy at best.  To realize a given set of features, a pro can often do it both better & faster: the number of hours spent becomes an argument against quality, not for.  (I’m much more apt to trust that a WordPress install got done right by someone else if it took them 15 minutes rather than 3 hours.)

Programmers can (and should) be hired on the overall demonstrable quality of their work, and a review of their portfolio plus a mutual understanding of the level of thoroughness/quality that is called for (throw-away prototype or enterprise level masterpiece?) keeps the fixed price model honest.  (Because yes, without that mutual understanding a developer could hack the fixed-price model by racing through a project and cutting corners, to say nothing of whether or not he’ll be hired again).

Alignment of Priorities

If we can assume that a contractor is guaranteeing satisfaction (and we probably should, right?), then a faster execution of a fixed-price project is in the best interests of both parties.  The client gets what they need sooner, and the effective hourly rate of the contractor is higher.  When an accurate sense of the quality to be expected and a correlate price tag are established, the fixed price model creates this nice alignment of priorities between contractor and client.

By contrast, hourly creates a misalignment of priorities of client and contractor: the contractor gets rewarded for dragging their feet and making problems out to be more complex.  Not a huge amount of course, because in the logical extreme they’d get dumped sooner or later.  But it’s just too easy to milk the clock and divert energy from actually solving the problem, to instead convincing ones self and others that it’s more difficult than not.

Effective software development is all about fewer smart hours as opposed to longer hard hours.  Pricing for it should probably then reflect that, and by the  same token programmers should probably strive to avoid the curse of the hourly wage.