We’re not “resources” | Hacker News Reader

We’re not “resources”

blog.markturansky.com

7 pointsreazalun9 comments

The main thrust of the argument is that "resources" implies some kind of average, that developers are interchangeable cogs in the wheel. But Peopleware taught us that there can be an order of magnitude difference between the best and average developers, so your scheduling and estimates are based not on some abstract "resource" but on the talent of the person involved. Talent matters. You have to build a winning team with talent, not by scheduling "resources" who you think are interchangeable. Those people are inherently NOT interchangeable due to varying levels of talent.

One important point that you missed is that it is also a de-humanizing view of what we do. It's not limited to programmers, it's typical of corporate america to treat employees like they're nothing but cogs in a machine, rather than people.

Who wants to be thought of out of context? I want airlines to think of me as a passenger, and doctors to think of me as a patient -- I don't think I'll get better results if they think of me as a unique and special human being.

Why add mental overhead?

I want my vendors to think of me in their customer-specific mindset, too. But I do not want my boss thinking about me as just another "resource" without unique skills and contributions.

I had a boss years ago who called us all "code monkeys" who were engaged in the process of "tickey-tackey" all day.

There is nothing quite so demoralizing as hearing your most creative work -- that you studied for 8 years in depth at a difficult university to be capable of performing -- described as "tickey tackey that monkeys could do."

Which is similar to the feeling programmers get when called "resources," IMO.

It's completely disingenuous to conflate 1) referring to someone by the purpose for which you're interacting with them (e.g. "the barrista who is making me coffee," versus "Suzie, who is working at Starbucks now but is going to really make it big with her one-act four-hour one-woman play") and 2) using generic and insulting terms (e.g. "the telephone repairman," versus "the little shit").

"Resources" may be a terrible, insulting term. But the argument against it also applies to referring to them as "programmers" (which you did in your last sentence) rather than naming them one by one, talking about their favorite IDE and language, and their reasons for working on that particular program.

I notice you also refer to 'vendors' and 'a boss'. There would be a huge amount of wasted verbiage if you told me which vendors, which boss, what the vendor does on weekends, and how much the boss loves to fish. For the purpose of your story, that doesn't matter -- for the purpose of discussing programmers, the extraneous stuff is not important.

"Resource" is never the purpose for which you are interacting with someone. I'd never even dream of calling the barista "The Resource Who is Making Me Coffee."

While it may not be a straightforward leap from "Resource" to "Code Monkey," both labels are born from the same carelessness: a lack of regard for how the person to whom you're referring will perceive your evaluation of their relative worth.

I do agree with you that it can be taken way too far in the name of not hurting feelings. To spend too much time on each person's unique qualities in passing conversation is a time-waster.

We should pick words that acknowledge that such qualities exist. I think "resource" does not, and "programmer" is slightly better.

My first degree is actually in Mech Eng, not CS. To us, a "resource" is something you use up and then discard. Coincidentally, that's also the HR definition.

But we are resourceful. Sometimes at justifying our own special, unique, boneheaded worldview.

Don't send a Stallman to do a Kay's work (or vice-versa).

Here is an easy workaround to the "programmer = resource" question. If I make 50/hr as a programmer than the cost per day of me as a programming resource is 508 = 400. Now we can add an "Efficiency coefficient" to account for how skilled I am. So, the default cost for our programming "resource" per day is:

ResourceCostPerDay = HourlyRate8EfficiencyCoefficient

If this coeff. defaults to 1 then in my example:

ResourceCostPerDay = 5081 = 400

If I am really super good we can change this to have a coeff. of 1.5 so

ResourceCostPerDay = 5081.5 = 600

If I totally suck we can change the coeff. to 0.5 so

ResourceCostPerDay = 508*0.5 = 200

So by having a simple "efficiency coefficient" the resource cost for a programmer can indeed be modeled fine, so with due respect to the person who posted this article, he is mistaken: a programmer or engineer (speaking as a test automation engineer myself) can indeed by quantified quite well as a "resource" like any other "resource" such as the number of application servers a company has. Reductionist? Yes. But this is a reductionist universe. Deal with it. :-)

Reply on news.ycombinator.com