Productivity

Productivity. By far one of the most used words around the Dev.to community. Look at all the VSCode extensions that will make you more productive. Look at all the management frameworks that kill productivity. If you could get rid of all those pesky meetings you'll be more productive.

But what is productivity anyway? We should know, right? As a term, it comes out of the Industrial Age, when manufacturing took over the global economy. Factories powered by people and later machines would spit out good at increased rates, ushering the golden age of productivity. It was a pretty clear metric.

Productivity is defined by an aggregate of units of output over a period of time. It's a clear metric that can be applied to a worker (whether human or not) to track their output and allow decisions as to whether replacing a worker would benefit overall production, whether things could be done to improve the output of a worker and so on.

As an aggregate, productivity needs to be tracked over time. As such, its observability generally rests with the consistency of the unit of output. If I'm a worker making nails and I'm observed to make 100 nails a day, it says nothing about my potential of making screws. It also says nothing about the value of either nails or screws: that's something the market decides. My output can fluctuate in economical value, it can be nullified by late delivery but my ability to produce those units remains.

So what is productivity in software development? Whenever I hear the term, I cringe a bit because it generally reflects a desire from management to track output over time even though that output is not well defined and it's not self-container or constant.

A unit of output is by definition self contained. A car doesn't depend on the car previously manufactured. A nail doesn't depend on the nail before it (beyond moving the nail aside from the production line). That's what makes a unit. If A depends on B, neither are "units". They may be used to make a unit, somehow.

So what is the output of a developer? Well, we output code.
That's a bit misleading of course, because it hides the creative process (rarely negligible, regardless of any judgment of quality or maintainability) but the creative process itself matters to the extent it results in code that makes up a software product (so that it can be executed and thus used).

You can also say we output tasks, under the same points. We are given tasks and once they're done (under some definition of done), they are delivered and qualify as output.

But is code a unit of output? Code tends to depend on more code. You could view functions or classes as units. Some dependency notwithstanding, they can be self-contained (not to mention reusable, in the same project or others). It could work, but does it make sense? I can influence the number of functions I write, I can be very productive in outputting classes (hell, I'm sure I can do hundreds a day). Would you consider that as productivity? Much like I could produce nails that may or may not be needed in the end, I could produce classes of all shapes and sizes. I wonder if this isn't in fact what powers that Javascript world if you just look at all the NPM packages - some people are just very productive that way. Of course, code fails when it comes to being repeatable. If I wrote an API client class for Twitter, I won't do it again (not the same way). I might copy/paste it if I need it the same way or I will tweak it in some way. Either way, the process behind it will not be repeated.

What about tasks? Despite various recommendations on how to create a user story or a task or other unit of work, these "units" are rarely units. They're rarely independent, comparable or repeatable. For what it's worth, in the world of Scrum there's a lot of ink spilled over making user stories comparable in size - but size itself is a thorny issue. If you ballpark it enough (starting with T-shirt sizes, maybe) you can start talking about team productivity in making L or M's and how many you can do in sprint.

Tasks do fail though in the sense they're not a proper metric. They're not repeatable. Once X is done, it's done - similar to code. I will not do that exact task again, let alone 100 of them.

As a side-note, productivity in this context is never about the "value" of tasks. What's valuable from an economical point of view is what helps sell the application and that decision is removed from you and if it's not controlled by your ability then it's not a measurement of your activity. That's decided by marketing or management or someone else.

What about all those plugins / extensions / tools then? What do they improve?

My impression is that the "productivity" of tools is more of a feeling. I feel productive when I can develop solutions for the task at hand, which is generally split into being able to focus my "creative juices" and then implement the solution in code.

Whether it's autocompletion, AI assistance to code my solution (nudge-nudge Copilot), distraction-preventing stuff or concentration music, productivity extensions work only insofar I've already managed to kickstart the process. Sure, aid is aid and it's welcome (thank you, bracket coloriser!) - particularly those that remove tedious tasks (docblock generators!) but here's the takeaway ...

Software development is a creative job. Code is merely the realisation of a sometimes tenuous process. When people refer to software development as art, I take it halfway seriously because in lots of respects it does resemble writing.

If I had to make a parallel, I'd rather compare it to painting in the sense that most painters created their work for paying customers who pressured them to deliver on deadlines ... and yet their work is recognised today.

I'm not saying that's what will happen to my code (I can only imagine someone looking on Github in 100 years and saying "it's clear that the strokes of VSCode 1.58 only underlines the emptiness of the artists soul"), but what I'm saying is that what we produce, as software developers, are solutions. For small tasks or (on a higher level) for requirements, we produce solutions (and then implement them). If there's an unit of output, then that's the solution.

Sure, it also makes the point of "productivity" moot because of the uniqueness factor. That's probably why the closes such metric I found is the "velocity" of Scrum. I wonder if anyone remembers the difference between velocity and speed (since productivity is by all intents and purposes a speed-like measurement, units over time).

Yes, we measure the work done - as long as it brings us closer to the goal.