5 ms·

> 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

by zmj 14y ago

> 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 http://en.wikipedia.org/wiki/Fundamental_attribution_error

barrkel 14y ago
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 14y ago
  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.
  - 14y ago

by zmj 14y ago

barrkel 14y ago

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 14y ago
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.
- 14y ago