
Programmer fungibility - dkarapetyan
http://www.scriptcrafty.com/programmer-fungibility/
======
modzilla
When people say "There is a shortage of great programmers." what they are
really saying is, "There is a shortage of programmers who are also great
problem solvers." or, "There is a shortage of great problem solvers who want
to program."

At least, this is how I have always interpreted it. I have never misunderstood
the fungibility of great problem solvers, and based on my experience working
at a large high quality tech company they don't misunderstand it either. In
reality there actually is a shortage.

------
geebee
Nicely expressed, and I agree that programming languages and frameworks aren't
quite as mysterious as HR sometimes seems to think they are ("sorry, we need 5
years with rails, not grails, so, you know, can't hire you… oh, and there's a
terrible shortage, we are having tremendous trouble hiring").

That said, I do think that programming languages and frameworks are only about
10% of what makes a programmer "fungible." Here's the line that stuck with me:

"Then you should just go ahead and hire the RoR person and give them a month
or so to figure out the Django conventions and vice versa."

I completely agree that a company may need to give at least a month over to
pure study and investigation (wait and see what the stakeholders have to say
about that, though - a very blunt discussion about reality may be in the cards
here). Here's the thing - depending on the existing code base, familiarity
with a new framework may be the least of your problems. If it takes a month to
get used to django instead of rails, it can take several more to get used to
the code base itself. So you're looking at a situation where a new programmer
may not be highly productive for the first 5-6 months after hire.

To me, this does stretch the notion of "fungibility." It means that if a
programmer leaves a project, you may be looking at 6 months before any
progress can be made - and that's assuming you can find a talented enough
programmer to get up to speed in the first place ( _that_ can take 6 months).
Often, a good previous developer will take copious notes, document well,
ensure easy and clean build and test practices… that can reduce the ramp up
time. But a lot of this is just building a very elaborate blueprint for a
system in your head. Good practices can make it quicker and easier, but in the
end, the transition just takes a lot of time.

There are tasks that would take a programmer with full context 1 week to
complete. Optimistically, it could take a new programmer 3 months + 1 week,
and that's for a well prepared programmer who understands the existing tech
stack or something closely related. Keep in mind there are are so many things
about an organization to understand - existing database systems, services,
security policies, auth systems. The amount of context you have to build up
can be massive.

Actually, that's not a bad way to measure fungibility. The ratio of how long
it would take a current worker to complete a task vs a "well prepared"
replacement. 1 week / 13 weeks ~ .077 fungibility.

~~~
dkarapetyan
Interesting measure. Putting in some of the other bits of your post into the
measure we could even say that low fungibility is a by-product of bad software
processes and design.

