4 ms·

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 (wit

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 14y ago
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 14y ago
  Sorry, I didn't mean to come across as patronizing.
gruseom 14y ago
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 14y ago
  Yes, I completely agree. Why do you mention it?
  - gruseom 14y ago
    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.
    - jdlshore 14y ago
      Hmm... I can't agree. "Business value" is a useful term for describing sources of value beyond revenue. It's extremely fluffy and usually unmeasurable, sure, but it's still a useful way of talking about things that are worth doing that don't produce revenue, such as competitive differentiation, market research, brand promotion, philanthropic efforts, and relationship building. For software that doesn't produce direct revenue (the majority, in my experience), what better term is there? I don't know why you say business value is actually about power dynamics, unless you mean that people use the term to promote their pet projects. If so, I think that has more to do with human nature than the term "business value."
      - gruseom 14y ago
tetha 14y ago
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?

barrkel 14y ago

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 14y ago
Sorry, I didn't mean to come across as patronizing.

gruseom 14y ago

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 14y ago
Yes, I completely agree. Why do you mention it?
- gruseom 14y ago
  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.
  - jdlshore 14y ago
    Hmm... I can't agree. "Business value" is a useful term for describing sources of value beyond revenue. It's extremely fluffy and usually unmeasurable, sure, but it's still a useful way of talking about things that are worth doing that don't produce revenue, such as competitive differentiation, market research, brand promotion, philanthropic efforts, and relationship building. For software that doesn't produce direct revenue (the majority, in my experience), what better term is there? I don't know why you say business value is actually about power dynamics, unless you mean that people use the term to promote their pet projects. If so, I think that has more to do with human nature than the term "business value."
    - gruseom 14y ago

tetha 14y ago

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?