

We’re not “resources” - reazalun
http://blog.markturansky.com/archives/95

======
markturansky
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.

~~~
Tamerlin
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.

------
byrneseyeview
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?

~~~
pjackson
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.

~~~
byrneseyeview
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.

~~~
pjackson
"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.

------
gaius
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.

------
MaysonL
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).

------
Allocator2008
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
50 _8 = 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 = HourlyRate_8 _EfficiencyCoefficient

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

ResourceCostPerDay = 50_8 _1 = 400

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

ResourceCostPerDay = 50_8 _1.5 = 600

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

ResourceCostPerDay = 50_8*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. :-)

