The problem I have with discussions about “productivity” (including 10x engineer chest-beating) is that no one ever defines what they mean by the word. Is it lots of lines of code? Is it clean design and architecture that’s easy to maintain and extend? Responding quickly to business needs? Making a lot of money in a short time?
Too often, people arbitrarily choose what they’re good at, or what someone else they admire is good at, call that “productivity,” and then come up with a post-hoc rationalization of why that’s good.
Note: I only skimmed the article, so consider this a comment on productivity discussions in general rather than the specific article.
(Oh, and a pet peeve: the agile concept of “velocity” originally introduced by Extreme Programming is absolutely not a measure of productivity. It’s a way of predicting your capacity for the next iteration. I’ve taken to calling it “capacity” instead of velocity for that reason.)
Too often, people arbitrarily choose what they’re good at, or what someone else they admire is good at, call that “productivity,” and then come up with a post-hoc rationalization of why that’s good.
Note: I only skimmed the article, so consider this a comment on productivity discussions in general rather than the specific article.
(Oh, and a pet peeve: the agile concept of “velocity” originally introduced by Extreme Programming is absolutely not a measure of productivity. It’s a way of predicting your capacity for the next iteration. I’ve taken to calling it “capacity” instead of velocity for that reason.)