The Productivity Mirage

firasd

I’ve been thinking of the term ‘gearhead’ lately. Everyone saying bro put this skill in your agent harness to change everything is significantly motivated by the same urge as the person in the car mod culture tweaking their exhaust system etc The hobbyist tinkering with the programming setup has its benefits (enjoyment) but it’s a mistake to think it matters at all to the end user or indeed — as this post argues — to actual quality and quantity of work when compared to the benefits of actually thinking about the product and the code

blizdiddy

It sucks how much of the world is built by people who glorify putting in 6 days and 4 nights a week, then put that effort towards stuff like Facebook. It’s so uncool to be critical thinking at all with these types. Accept the mission statement at face value and get paid.

smitty1e

Ah, yes, the difference between the tool and the wielder is an old observation: "If the iron be blunt, and he do not whet the edge, then must he put to more strength: but wisdom is profitable to direct." (Eccl10:10)

raincole

The best artist I talked to in-person still uses Photoshop CS6. (And a Wacom without a display).

nsoonhui

Not entirely what's the point of the article is, because with AI I can clear my backlogs way faster than without it. How is this *not* real productivity gain?

kelvinjps10

Those features are the only I find useful in facebook, fb marketplace and local groups for buying or selling stuffs or services.

readthenotes1

I think this is something almost straight out of Fred Brooks mythical Man month set of essays, from observations in the 1960s. Iirc, one of the essays had the moral " many software developers would rather work on the infrastructure to solve the problem than actually solve the problem"

4m1rk

It's not about productivity, it's about having fun with your toys.

YouWhy

The OP implicitly raises the question of why does "productivity" exist. I've been giving that some thought lately, and the hypothesis I arrived at was that of diminishing suffering. Many types of performance optimization work, including "programmer productivity" are really the engineer's getaway from having to contend with the ambiguity of the problem domain, the politics, the vagueness, the risk of failure and other kinds of suffering. Alas, solving a problem coming from the world requires confronting the world - a couple of examples are the tedium of mentally working through a user workflow, getting somebody else to cooperate by articulating and proposing a joint strategy and more. I do not believe in pain for pain's sake, but good delivery has an inherent quality of athleticism, and one cannot be an athlete without accepting that training for the track means proficiency at managing pain - and at the track rather than elsewhere.

kfse

I bet you Bob was great at launching new concepts but that taking oncall responsibility for crusty old code that he didn't personally write wasn't for him...

marcus_holmes

This is so important. I've seen so many fellow technologists (and I've skated this myself) obsess about their setup to the point that they're spending more time on that than the actual thing they're building. The whole "90% of my time as a coder is spent typing, so I should optimise my ability to type fast" is so, well, wrong. 90% of our time should be spent thinking, and most of that reading.

fallous

You can buy $100,000 of the best fishing equipment in the world, but if you don't know how to fish it won't do you much good. Of course, if your goal is to collect great fishing equipment then you have no need to fish... but then you shouldn't consider yourself a fisherman.

4lx87

The most productive programmer was able to choose the most impactful problem to solve and how to solve it? There's a lesson in there...

arjie

Sure. That’s the theory of it. But when I wrote myself an app that helps me author blog posts I ended up writing more of them. Turns out that image uploading and then naming and description is slow but I kind of have the image and etc handy usually and can stay in flow state. There are superstar product developers. Pieter Levels of the world. History has taught me that I don’t have that level of insight. But improving my flow gives me sufficient performance boost to be able to be useful to people who pay me for that.

nine_k

I think it's a false dichotomy. A good craftsman cares deeply about their tools. But the tools are a means to an end, not a toy. I have a bunch of small productivity tools I made to match my workflows: tiny shell scripts and functions, custom Emacs functions and settings, small tools to control windows placement, etc. Cumulatively I spent many days building and adjusting it. But when I need to jump into a task, things just work. Syntax highlighting is there, code navigation is there, code analysis is there, I can rearrange things in my area of attention the way I want with a couple of keystrokes, I can drive git the way I want with a couple of letters. I don't have to tweak anything. Nothing bothers me, nothing distracts me, nothing wastes my time and breaks my concentration by requiring legwork. (Same applies to my mechanical and electrical tools. Mostly.) Invest in your work environment. Adjust your chair. Adjust your shell prompt. Adjust your editor settings. Comfortable? Good. Now you can forget about them all, they are just there working for you. Concentrate on the real problem you have. Godspeed! The skill of concentrating on a problem is much harder though. Endless tweaking of your tools that eats all your time can be a sign that you are just trying to avoid that daunting and uninspiring task. But this is not the tools' problem, not that simple.