Stories about Software


Hiring is Broken… And It Isn’t Worth Fixing

Usually I fly home from client sites late in the day, but the whims of fate had me driving home instead, early (for me, anyway) this morning.  The end result was a pocket of uncommon free time this evening, before resuming long days and seemingly non-stop travel on the morrow.  Naturally, I wasted this free time poking around the internet.

My travels led me, via Twitter, to this blog post entitled, “F*** You, I Quit — Hiring Is Broken.”  Apparently, this led to some heated, sometimes-angsty debate on Hacker News, where the original piece earned a good number of points.  And, why wouldn’t it?  “Hiring is broken” would serve as a rallying cry for those who don’t play the interview game well, while seeming a shot across the bow of those who do and are now on the other side of it.

Read the article, please.  You need to for context, because when I reference it further, it’ll just be a reductionist tl;dr.  I’ll come back to that.  First, I’d like to address one of the few points that almost everyone seems to agree on, before they get down to armchair dissection of Sahat’s character and market worth.

The hiring process is imperfect deeply flawed (if not broken), but no one knows how to fix it.

Except, that’s not actually true, because I know how to fix the interview/hiring process.  It’s actually pretty easy.  Just stop doing it.  If the value proposition you’re offering to prospective laborers is so weak that you have to solicit and subsequently torture strangers, you should prioritize fixing your organizational mess above making the mess larger (or, in the case of attrition, before doing the same thing again).


I’m honestly not kidding, but let me come back to the mindless growth point later.

Read More


Gathering the Confidence to Leave Your Job

It’s Thursday night, and I’m holed up in a hotel in Lansing, Michigan.  I figure there’s never been a better time to answer a reader question.  This one is about how to summon the confidence to leave your job.

The question is actually a rather lengthy one, and here is a redacted/obfuscated version of it (removing anything that could be identifying).

I have had my developer position for several years. I’ve been promoted, but I’m still not a senior developer. I have become extremely “silo-ed” in my skills, because those are the types of projects I’ve been assigned.  I read your statement that salaried employment is a bad economical decision for developers. The developer should be making $50 or maybe a bit more at $60. I get paid {a good bit less} an hour for 40 hours a week of expected work.  I feel the need to grow my abilities.

I watched your video on Pluralsight on how to propose practices. My manager bought into some,  but most of my coworkers are ignoring the new stuff.  My place of employment fires developers once they are called as a references for checking if they ever worked there.

I need a goal, something I can achieve to give me confidence to start pursuing other options. Something that gets me into a situation where people seek me for relevant development.

There are actually several questions and issues here to unpack, so I’ll tackle them in order of complexity.

Pay is Relative

First of all, when I talk about developers making 50 per hour/100K or 60 per hour/120K, I’m mainly catering to myself and ease of math.  100K is a nice, round figure, and 120K makes monthly finace (10K) easy to calculate.  These figures were slightly high in the Chicago-land area as of 2+ years ago, which was when I was last seriously hiring and evaluating pay there.

But, beyond that, pay varies a lot by geographic location, industry, filing status (nonprofit, for profit), etc.  If you salaried a developer working in San Francisco at 150K per year, he would probably need to move into a homeless shelter.  (I kid, but only slightly).  Pay that same wage to someone in central Kentucky and “should we install a second hot tub on the master bedroom deck” becomes a topic of debate around the marble dinner table.

All that being said, your wage was fairly low for a developer anywhere of your experience.  But don’t base your assessment of how low on my blog and what I know (I don’t pay much attention these days).  Base instead off of researching in your region.

We’ll Fire You for Looking…

Okay, this is where I offer the IANAL (I am not a lawyer) caveat.  This is based on my experience doing management consulting and working as a manager, much of which happened in at will states (this can vary by state and certainly by country).

If you’re a company, terminating employees is like playing Minesweeper, except instead of bombs, there are lawsuits.  You’re clicking along gleefully when suddenly, one day, BLAMMO!  Wrongful termination!  So you learn your lesson and you start looking at all of those numbers really carefully and insulating yourself against potential problems.

Minesweeper Read More


It’s Okay Not To Lead

I originally wrote this post for the Infragistics blog.  You can check out the original here.  While you’re there. take a look at posts by all of the various authors.

When I first entered the workforce, I was in awe of the programmers around me.  I’d spent 4 years of college learning how to implement Alpha-Beta pruning and various flavors of sort(), while these guys had been building things that real people used in the real world for years, or even decades.  I imagine it was, on a much smaller and more cerebral scale, the way a college football player feels upon turning pro.


This didn’t last.  After a while, I viewed them less with reverence and more as simple peers from whom I could learn, given their comparable wealth of experience.  As the years passed, the scales began to balance as I acquired more and more experience.  I was no longer the greenest developer around, and there was a healthy mix of people more and less experienced than I was.

The Path to Leadership

As this transformation took place, I started to develop opinions and preferences of my own, based on experience and on becoming a student of the craft.  I began to read books by people like Uncle Bob Martin and Michael Feathers.  And, sometimes, these opinions I was developing didn’t line up with those of some of the people around me.  I started to notice that the practices advocated by industry thought leaders were dismissed or ignored by some of the people around me.

At the same time, I began to notice that the people making technical decisions from positions with names like, “Architect,” “Principal Software Engineer,” and “Team Lead,” weren’t necessarily the best, technically.  Often, these leadership roles seemed to be as much a function of number of years with the company and familiarity with the domain as they were a function of technical acumen.  And where the developers more experienced than me seemed diverse in their skill, philosophy and approach, the decision-makers seemed disproportionately to value a “crank out reams of code” approach.  And, of course, when you have differences of opinion with the decision-makers, it doesn’t tend to go your way.

Read More


The Trouble with Career Sites

Last week featured some unexpected alterations (read: extensions) to my travel plans, and this week featured me playing a bit of catch up.  So, Monday featured no post at all, and Wednesday was a cross post.  If I do one thing this week, it’ll be to remain true to my attempts to regularly answer reader questions.  Here’s the question in question.

You mentioned in your “Avoiding the Dreaded Experience Tuples” post that there are better ways than monster.com to look for jobs…

Do you group the other common jobs sites with monster (i.e. dice, muse, hired, indeed, stackoverflow careers)?

Or is monster just bad?

First of all, an advanced caveat.  I am not familiar with muse or indeed, so I I’ll skip them and speak to what I know.  The short answer to the question is “I mostly group these sites together, and I think that using any of them to look for jobs is the Greyhound Bus of finding jobs.”  But, not all Greyhound Bus rides are equal — on some a drunk hobo throws up in your lap, and on some the drunk hobo just falls asleep on your shoulder.  And, with one of the sites here, I’d say you’re not really even riding a bus.  Let me do a bit of forced ranking.


Read More


Chasing Developer Productivity Metrics

I was listening to an episode of the “Western Devs” podcast on a plane the other night (I really like this podcast, by the way — give it a listen).  The subject of this particular show was the idea of developer productivity and the measurement thereof.  At the risk of playing spoiler, the discussion digressed in interesting fashion without necessarily taking a serious run at conclusions about these measurements.

But asking for a definitive measurement of developer productivity is a tall order.  I would actually even consider the attempt to be quixotic, though not for the reason alluded to early in the show (the idea that it might be categorically impossible to measure).  I think there are any number of ways, some even credible, to measure productivity for developers.  I think the trouble arises from the notion that they could be applied outside of a narrow context and also that it’s especially important how productive a developer is.

Let me return to that claim a little later, though.  First, I want to talk about The Organization.

What We Want from the Organization

It’s important, at this point, to dispense with the euphemisms. “Productivity,” in a business context, is a measure of efficiency, which is a comparative ability to deliver the same amount of stuff in less time (or for less money, though, in wage-land, time and money are like energy and matter in special relativity).  So productivity is really “worth” for labor.

Building the Pyramids

For developers, then, it becomes more personal.  Monetary worth is a bean counter distinction, and they don’t really know worth, we tell ourselves.  They don’t understand what Alice brings to the table when she goes around performing targeted refactorings that make everyone more productive, and they don’t recognize how important Bob is to the team’s morale, even if he doesn’t, himself, deliver a lot of code.

So we create situational, alternate definitions of productivity that reflect our ethos and emotional attachment to what we do.  We re-couch productivity as a way of describing the meritocracy that we feel ought to exist within the company.  And it is this very tendency that leads us to discuss endlessly “what does developer productivity even mean and how do we measure it?”  Our definitions are aspirational rather than practical.  We want an orderly world and we want the organizations for which we work to radiate fairness toward us.

But the organization has other ideas.  The organization provides individualized feedback on our productivity/efficiency (i.e. our performance) in the form of performance reviews.  And boy do we ever misunderstand these.

Read More