3 ms·

And yet, people talk about productivity all the time because they can feel it. People say: "oh I am much more productive with C# than I am with Python". Or: "

by d--b 2y ago

And yet, people talk about productivity all the time because they can feel it. People say: "oh I am much more productive with C# than I am with Python". Or: "This guy is one of the most productive engineer I know". But the issue here is that value is subjective. But is that really a problem? "Value" is not better defined than "urgency" or "criticality", yet we prioritize tasks all the time based on the perceived urgency/criticality of task A vs task B. So in the same vein, we could assign a "value score" of project X, that would amount to something like "usefulness * difficulty * quality" (to be discussed), and define productivity as that over time spent.

andrelaszlo 2y ago
I think that's a good point. Say it's your company, then you need to decide if you want to build the product in C# or Python. It's going to affect productivity, but it's very difficult to say how. If you pick Brainf* of course most people can tell you productivity will suffer, but in the C#/Python example you might start building in C# since it's what you're familiar with, then have problems recruiting developers in your area a few years down the line, since most people are now doing Python (say). Technically, your original choice might be "correct" in some ways, but who knows? Perhaps the discussion should revolve around how we make decisions better in complex, rapidly changing environments, with limited information? It feels like we're clinging to the need for things to be predictable and measurable even when they're not, and we end up in more or less delusional discussions about which of two almost identical programming languages is better, or even tabs vs spaces :D
- neonsunset 2y ago
  Perhaps this specific comparison is flawed. It's the same as if comparing "Do we build it in Rust or TypeScript?" (not in terms of hiring pool but in terms of specific language used - picking either Python or C# will result in products with massively different grade of performance and quality).
Juliate 2y ago
The hint that productivity is perceived (subjective, qualitative), but not measured (quantitative), is good. Productivity is argued, in the end, not demonstrated; or only within a very specific, limited framework (a very productive endeavour locally may reveal to be counter-productive on a higher or later scale). For instance, heavily relying on fossile fuel while pushing CO2 in the atmosphere has proved very successful in a specific time frame, the past century, let's say. But if (if) that means that Earth becomes inhabitable by current life forms within the next century, from an external observer, it was rather an error, or mismanaged, so not so productive.

by d--b 2y ago

andrelaszlo 2y ago

I think that's a good point. Say it's your company, then you need to decide if you want to build the product in C# or Python. It's going to affect productivity, but it's very difficult to say how. If you pick Brainf* of course most people can tell you productivity will suffer, but in the C#/Python example you might start building in C# since it's what you're familiar with, then have problems recruiting developers in your area a few years down the line, since most people are now doing Python (say). Technically, your original choice might be "correct" in some ways, but who knows? Perhaps the discussion should revolve around how we make decisions better in complex, rapidly changing environments, with limited information? It feels like we're clinging to the need for things to be predictable and measurable even when they're not, and we end up in more or less delusional discussions about which of two almost identical programming languages is better, or even tabs vs spaces :D

neonsunset 2y ago
Perhaps this specific comparison is flawed. It's the same as if comparing "Do we build it in Rust or TypeScript?" (not in terms of hiring pool but in terms of specific language used - picking either Python or C# will result in products with massively different grade of performance and quality).

Juliate 2y ago

The hint that productivity is perceived (subjective, qualitative), but not measured (quantitative), is good. Productivity is argued, in the end, not demonstrated; or only within a very specific, limited framework (a very productive endeavour locally may reveal to be counter-productive on a higher or later scale). For instance, heavily relying on fossile fuel while pushing CO2 in the atmosphere has proved very successful in a specific time frame, the past century, let's say. But if (if) that means that Earth becomes inhabitable by current life forms within the next century, from an external observer, it was rather an error, or mismanaged, so not so productive.