Stories about Software


My New Project and Dignity in Hiring

I saw this tweet tonight and thought of dignity in hiring.

I admittedly didn’t read through the site in a ton of detail, but notwithstanding that, I found myself feeling a little giddy. Apologies in advance for the spoiler, but one of the main things for which I’ll be advocating in my in-progress book, Developer Hegemony, is that software developers stop commoditizing their labor at pennies on the dollar. Instead, I think they/we should form organizational structures akin to law firms, and sell software expertise as a professional service. With this model, a rising tide will lift all boats. Even the odd staff developer at some non-software company will be paid more like staff counsel than like someone with 4 layers of middle management between them and people that make decisions.

But, I digress. I mention seeing this site because it was a hopeful reminder that better ways of marrying developers with automation needs are on the way.  And, for my part, I’ve been thinking about how to get there, and not just for the purpose of my book.

A bit under 2 years ago, I realized that I’d completely burned out on salaried, exempt (i.e. full time) employment.  At the core of this was the feeling that exclusive employment cedes entirely too much control over one’s circumstances to another entity.  On a long enough timeline, you’ll find yourself in a situation you don’t like, doing things that you think are stupid, and hoping for reprieve before you have to make the life-disrupting decision to go job hunting on the sly.


So, I followed the advice that brings you continuous integration: if it hurts, do it more and more, until it’s painless.  I decided that, whether it be with employers, clients, or anything else, I’d never be completely able to prevent a situation from going sideways.  But what I can control is how easy it is for me to hit the eject button when it does.  And having a bunch of different clients and a whole ton of connections makes any single depression of the eject button relatively painless for me.  I was done putting all of my eggs in one basket.

That’s gone quite well.  These days I have more offers for work than I can take on, and a lot of different connections, contacts, and clients.  Life is good.  Maintaining my own pipeline is not without its drawbacks.  When you’re taking a break from your 9 to 5 gig on weekends, you might well find me invoicing or following up on prospective contracts.  But, I wouldn’t trade the relative freedom when it comes to controlling my working destiny.  I work more hours than most, but none of those hours are spent doing things that I think are stupid, at the behest of some megalomaniacal expert beginner.  And that has made all the difference.

What I’m Doing with Hiring These Days

So where does the part about hiring developers come in?  Well, about a year ago, I went to work for a company called Pillar Technology.  It was a subcontracting arrangement, and so I started spending most of my weeks at Ford headquarters in Dearborn, Michigan, doing a combination of what might be described as developer coaching and IT management consulting.  My original plan was for the engagement to be a few months, but I wound up spending nearly a year before I finally had to reign in the travel a bit for the sake of my domestic life.  And, what’s more, I’m now continuing the relationship with Pillar beyond anything I did while at Ford, helping out for varying amounts of hours per week.

And one of the things that I’m doing for Pillar still is helping find, interview, hire, and train developers in the software craftsmanship and clean code approach to development.  So, as you can see, my thoughts around matching developers with work are anything but academic.  I’m thinking of all of the things that I’ve found dehumanizing and absurd about the process over the years, and doing my level best to avoid repeating the sins of the past.  And to get this right requires, I think, the kind of creativity on display at Elevator and new ways of thinking about this game in general.  Don’t get me wrong — interviewing and hiring developers isn’t a new activity for me, but having done something isn’t the same as finding the best ways you can to do it, and if I am going to do this, I want to do it well.

It bears asking why I might do this, since any reader of the blog can tell that my attitude toward the corporate condition leans heavily cynical.  I suppose the easiest way to answer is to say that Pillar is the company I had been looking for before I became disillusioned and gave up on the idea of a corporate software development job.  As I burned out on ludicrous algorithm trivia interviews, pecking order determined by years with the company, statements like, “there’s nothing wrong with 5000 line classes as long as you comment them,” and basically everything the Daily WTF has to offer, a port in the storm would have been nice.


I don’t have any regrets, all things considered.  The lack of ports drove me to Pluralsight authorship, this blog, passive income, a healthy and growing client list, largely remote work, and all sorts of other things that make me think of a milder form of Nietzsche’s aphorism about things that don’t kill you making you stronger.  But for those not looking to blaze or follow that high-burn trail, it’s nice to be able to say, “there are actually places where people care about the craft of software development and where writing unit tests is not considered some kind of high-fallutin, book learnin’ waste of time.”  And I think that helping people who want to be at a place like that get to a place like that is a worthwhile use of time.

What I’m Doing

With all of that back story out of the way, let me get down to specifics of what I’m doing and why I’m talking about this.  The way I see it, a natural step to figuring out how to match software developers to a software consultancy is to bypass the experience tuple conversations and head straight for sizing up code.  For example, a company that values the test driven approach and has need of people to help on a Java project would do well to go find developers that write unit tests in Java.  And it seems that one place to find them might be, say, Github.  So rather than calling a recruiter to work on my behalf or spraying a message to thousands through LinkedIn or whatever, it’d be nice to get a list of people that would be likely to be matches up front, and then to have a human conversation with them.

And, by conversation, I mean just that.  “Hey, found your code and was impressed with that trick you use to mock out the data access calls.  I’m working with a company that values the kind of approach you take, so let’s chat if you’re ever looking for full time work or some contracting and moonlighting.  Either way, maybe we could compare notes over pizza at the next user group.”  Wouldn’t it be refreshingly humanizing if conversations about software work started this way?

Toward that end, I’ve started a project on github.  Forgive me for the corny name, but I was making progress and needed to call it something, so I just picked something quick.  But this whole post isn’t to announce that I’ve got a new github repo.  I decided that, as long as I’d be working on a green field project that was neither proprietary nor top priority, I might as well do my gonzo coding experiment.  So I’m going to screencast all of my development work on it.  It’ll be like the Chess TDD series, but more raw and not for the primary purpose of instruction.  It’ll be a unique opportunity to watch a developer build something from scratch with actual, production designs.  It’s not Hello World or a code kata.

The first episode is below.  Please note that, unlike the Chess TDD series, I’m not going to make a blog post out of every episode of this.  I may tweet these as they go out, but it’s possible that I’ll forget.  If you want to follow this, go to my youtube channel and subscribe.  I will add them to a playlist.  I’ve got about 12 or something recorded at the moment, and I’ll be adding more to the queue as I work on this project.

So hopefully this interests at least a few folks.  I’m not curing cancer here or revolutionizing anything, per se, but my hope is that I can be a small part of pushing our industry toward better, more dignified ways of matching development skills with need.