I'm gonna try. Productivity is the discounted future cash flow per hour of work.
Here's what it's not: It's not about how much code you write. It's not about the quality of the code. It's not about clever engineering solutions. All these can (and should) be part of the above, or they may not. Sometimes sucky code that can bring in a billion dollars is better than great code that brings in nothing. Technical debt is fine as long as the "interest" on that debt is << the profit you made by taking on that debt. Just like any other debt.
A business pays you $X an hour, what are they getting out of you $-wise?
To be clear, that doesn't mean that e.g. someone working on internal tooling can't be productive, but their productivity is measured by the impact on someone else who eventually uses the tooling to make money somehow.
This is incredibly difficult/impossible to measure perfectly, certainly on an individual level, but I still think it's worthwhile to look at it like this...
EDIT: I totally agree with the spirit of "sharpen your axe" and "be good at what you do". I spent a lot of time as a teenager learning to type fast. I did coding competitions to learn how to code real fast. This is part of what being a craftsman is about. But the leverage there is really limited. I liked what one of my ex-CEOs used to say, that just because he types fast doesn't mean he should do his secretary's work. So after you know what you're doing, you have the right approach, you're the right person to do this, all the other business factors, you should definitely excel at doing it.
> Productivity is the discounted future cash flow per hour of work.
That's not an unreasonable proposal, but isn't the whole point of startups that we're playing with upsides that are extremely huge and extremely unlikely? It seems like it would be extremely difficult to apply this definition to an engineer or a very small engineering team at an early-stage startup. Surely all the functionally equivalent restaurant delivery apps (at least those above some reasonable baseline of engineering competence) had very similar engineering going on in the early days, yet most of them you barely remember while a very small number of them are unicorns. But could you really have looked at an engineer in the early days and picked out the difference?
For sure. In that context, the engineer that got the product to work before the startup ran out of money and shut down by deciding to hack around some issues rather than "do it properly" is the more productive engineer. Another way to think about this is the engineer that better optimizes the expected present value (sure, there might be a pretty wide distribution of outcomes). At the very least I feel like this business/economic context is very important, and often ignored. Without it it's very hard to say because in a different context the engineer that creates the very same hack maybe just cost the company a lot of $'s in future maintenance work.
My point is more about the possibility that a big chunk of future cash flow is entirely independent of engineering work, at least for some reasonable bounds for what constitutes "engineering work" (e.g. you could argue that an engineer ought to judge whether their time is better spent cold calling potential clients or finding office space to rent, but those I would call "out of bounds"). Any easy example to illustrate this would be two engineers who each develop a functionally identical app for two different startups, but at one startup the founder later embezzles company funds, gets arrested, and the whole company falls apart, while the other company goes on to be successful. Was one engineer really more productive than the other in any meaningful sense?
That is a good point. I guess for the purpose of this definition we need to make some more assumptions. But decoupling software development from the business completely is going too far the other way.
Here's what it's not: It's not about how much code you write. It's not about the quality of the code. It's not about clever engineering solutions. All these can (and should) be part of the above, or they may not. Sometimes sucky code that can bring in a billion dollars is better than great code that brings in nothing. Technical debt is fine as long as the "interest" on that debt is << the profit you made by taking on that debt. Just like any other debt.
A business pays you $X an hour, what are they getting out of you $-wise?
To be clear, that doesn't mean that e.g. someone working on internal tooling can't be productive, but their productivity is measured by the impact on someone else who eventually uses the tooling to make money somehow.
This is incredibly difficult/impossible to measure perfectly, certainly on an individual level, but I still think it's worthwhile to look at it like this...
EDIT: I totally agree with the spirit of "sharpen your axe" and "be good at what you do". I spent a lot of time as a teenager learning to type fast. I did coding competitions to learn how to code real fast. This is part of what being a craftsman is about. But the leverage there is really limited. I liked what one of my ex-CEOs used to say, that just because he types fast doesn't mean he should do his secretary's work. So after you know what you're doing, you have the right approach, you're the right person to do this, all the other business factors, you should definitely excel at doing it.