[barrkel]

I've seen developers who create, rather than reduce technical debt; who take longer to get familiar with codebases; have a hard time focusing in the presence of distractions; and who seem to have difficulty ramping up solution domain knowledge (i.e. programming / software engineering techniques). And all of these things seem to be down to individual ability or motivation, i.e. something about the person, rather than external factors.

Most developers suck at programming (and that's actually OK). 90% of the code they write is copy and pasted from elsewhere in the codebase or from the web, and then tweaked until it does something approximately correct. They usually need help when solving a new pattern of problem. What they do often have is domain knowledge not related to programming, and produce just about acceptable results out of the machine in a labour-intensive way that doesn't really scale over time or problem size, but they muddle through with determination.

I don't know about a 10x productivity differences though. I'm not really arguing in favour of that hypothesis. Rather, if anything, I've seen step differences in potential; that is, there are developers that can do things other developers can never do, not in 10x the time, not in 1000x the time.

[zmj]

> I've seen developers who create, rather than reduce technical debt; who take longer to get familiar with codebases; have a hard time focusing in the presence of distractions; and who seem to have difficulty ramping up solution domain knowledge (i.e. programming / software engineering techniques). And all of these things seem to be down to individual ability or motivation, i.e. something about the person, rather than external factors.

I don't entirely disagree with you, but watch out for the Fundamental Attribution Error: http://en.wikipedia.org/wiki/Fundamental_attribution_error

[barrkel]

My worthless opinion is based on about 20 years of newsgroup / forum membership, but the few years I spent working in companies whose software product was a cost centre for its customers was particularly enlightening. We (the guys working on framework / architecture stuff) tried to grow some of the people from the domain-specific side of things into roles on our side of things. It was an uphill struggle; these people weren't interested in it. Code didn't excite them, at all. They might as well have been shovelling fast food for all the love of craft they had. They came in at 8:30, got their work done, and went home at 5:30.

But the work they did? It would have bored me to tears. I would have quit had I had to do it; or perhaps, I would have surreptitiously built a framework or macro system or something to remove the redundancy and repetition from the tasks and indirectly reducing the tedium of the workload, rather than doing it more explicitly in what I was actually doing (developing the v.next framework for the company). But there's only so much redundancy you can squeeze out of many of these things (turning business rules from specifications into code) before you create too much complexity elsewhere. We still need lots of these people doing this boring work (most software development does not occur in software companies), and it's good that they're expert in the business rules they're translating. At the end of the day, it's OK that they're not great at producing code.

Of course, my opinions are completely invalid because they are generalized from limited experience, have no scientific value, etc. But it's the world I've lived, so I'd have to see decent studies and censuses to convince me otherwise.

[jdlshore]

That's the tricky thing about productivity, isn't it? You said that those domain-specific programmers were "not great at producing code," but I would argue (with tongue firmly in cheek) that in fact they were the productive ones, and you were not.

Let me explain. Productivity is defined as output over input. Programming input is activity--usually, time working--and output is software capability (or, more generally, business value). As architects, I'll bet that you didn't produce much that the company used. You probably produced designs, frameworks, or other tools for domain programmers to use. But the real software capability was produced by those domain experts you're criticizing, which means that they were the important actors and you were assistants at best. At worst, you could have been an impediment; I've seen "core" teams whose architecture-astronaut frameworks actually have to be subverted in order for the domain teams to get their work done.

I'm playing devil's advocate here, and I'm not entirely serious, but it's with a point: skill in coding isn't important unless it leads to tangible business results. In the short term, in my experience, business savvy outweighs coding skill.

(In the long term, technical debt becomes an overwhelming cost, so programmer skill does matter. But keeping technical debt low is more about maintainability, tests, and boringly understandable design than the kinds of things I see "rock star programmers" emphasize.)

[barrkel]

Please don't patronize me.

I tried to be specific in what I said; I said that it was OK, and good, that these people existed. I was not making an argument that these people are necessarily less productive; but rather, that there was a qualitative difference in how they approached code that made a difference in what they could accomplish with it.

(Though I think in the medium to long term, they will end up less productive, because of a lack of abstraction and leverage of existing code beyond copy and paste. Probably, we don't disagree that much.)

[jdlshore]

Sorry, I didn't mean to come across as patronizing.

[tetha]

At this point, the terms grow a bit wonkey though, and I am struggling to communicate this properly in upcoming interviews. The big, underlying question is: How productive is a programmer that enables other programmers to be productive. Especially if the enabling programmer works slower and only outputs things no customer will ever see and especially if the work done with the framework outweighs the time spent creating the framework by magnitudes?

[gruseom]

You pointed out that productivity can't be measured (though that hasn't stopped you from invoking the concept). Something else that can't be measured? "Business value".

Let alone the "business value" of an individual programmer's commits.

[jdlshore]

Yes, I completely agree. Why do you mention it?

[gruseom]

Well, statements like "skill in coding isn't important unless it leads to tangible business results" seem to suggest that there is a way of linking the two. But there isn't. So it's misleading to talk this way. In practice, people just use it to confirm their prejudices (specifically about who is and isn't productive), which they've arrived at for other reasons.

I think "business value" is a particularly bad phrase because it sounds like something that can be quantified and has a clear implication about which class of people will do the quantifying (namely, business people as opposed to technical people). In reality, it can't, and the term is really about power dynamics within companies.

[batista]

>Something else that can't be measured? "Business value".

If it makes money, it has business value, in my book. If it makes MORE money, it has more business value.

Actually it might be the ONLY measurable thing in the whole discussion.

[gruseom]

Well of course, but that's just a trivial restatement of the problem. Anyone can measure dollar amounts once they have them; money is a measure. The question is how to assign such amounts.

For business value to be measurable means you have a function M(x) that maps x to money. The trouble isn't with the range of that function, it's establishing what the domain is and how to compute M.

People often talk about business value on software projects as if they have such an M when they don't. What they have is an imaginary M whose domain is "what I care about" and whose output is "what I want to believe". Such discourse is dysfunctional.

The truth is that you have M for the business as a whole and maybe for specific products (though I can cite cases where even that was dubious) and it typically breaks as you try to get finer-grained.