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
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.
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"
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.
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...
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.
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.
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.
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.
Seems like the difference b/w samurai and ninja. The samurai saw his sword as an extension of his soul - a disrespect to the sword was a disrespect to the man. The ninja used the sword like any other tool - and if it was helpful to use it to pry something open, there you go.
the samurai mentality doesn't make sense in today's economy.
And when you get that new job with that new stack? Switching back to the windows laptop?
I learned early on in my career how to live off the land and use the tools I have given to be efficient because it is rare that I get to decide the tooling.
Cross platform tools? Usually can get away with them, but beside Jetbrains stuff its all over the place.
I wonder if any old software companies like amazon, microsoft, apple, or google have data on how many prs a software engineer would produce per day over time. I wonder what that major spikes on the graph would be? live reload? vscode? faster and faster laptops? llms?
I have a hunch the amount of prs written per day per engineer is likely the same or only 10-15% higher.
I've found that I get more done the less time I'm at the computer. My productivity also went up dramatically when I reduced from three monitors to one.
I solve most of my problems when I'm doing things like chopping vegetables or mowing the lawn. Sitting in the presence of shiny technology does not magically confer one with the ability to achieve higher quality decisions more quickly. I find the opposite to be mostly true. I can massively outperform the development team that my clients have simply because I am not a full time employee and can idle out long enough to think about their problems the slow way. The urgency to keep the status circle green in Teams (and related productivity theater) creates a lot of stupid decisions in many shops.
I do agree with the author, in spirit. Not necessarily the possible implication that winning hackathons requires you to not have OPPD (obsessive productivity personality disorder) :) I mean the "possible" indication that you have to be a non-productivity-chasing savant to be a great coder/etc.
I stopped at this line
> he was responsible for shipping Facebook Groups
and wondered how can this be a compliment in any shape or form. I mean even considering Fb Groups from its day 1, not the bigger Frankenstein it has become today.
But I get it. "Shipping" was the achievement.
> massive productivity nerd
My "productivity" phase started at the start of college and since then it has a been tapering down every month/year and I don't complain at all.
I wish I did something else (I mean not even related to my studies or field..anything else) when I was actually exploring the shiny wide world of productivity porn. No, it didn't enrich me in anyway.
And I've seen so many seniors (at various levels of seniority over the years) who had stopped giving two hoots about tools or productivity tools in its entirety. It's like you have to reach city A from city B and few people just hop on the car available to them or public transport (this one not in USA) whenever they are ready to leave. But a lot of people go down the rabbit hole of best cars, best fuels, best routes (and then they obsess over their favourite coffee chains along the way), and get in fights with other people on car and other forums in the planning. By the time they could agree on their cars, the other folks who had just gone, had finished their works there, and even took an extra day or two to sightsee and shit like that and they might have even forgotten about that because it was weeks and months ago.
This is not too much of far fetching. This is actually quite important in early career states and habit and ideas set in during that time.
What has rather worked for me far more/better is a good place to work, environment, lighting, ambience, noise, temperature, material physical comforts available, maybe a bit of easy variation (as needed; not as forced upon) et cetera. But I think these things work differently for different people (and at different ages).
I think the most obvious aspect of this is that obsessingly customizing your environment for productivity is usually a sign of lack of focus and procrastination. So this story is not surprising
In the AI world you see it with the overly elaborate prompt markdown files where my agent gives performance reviews to 4 teams of agents each with its own quirky personality traits
64 comments
[ 16.9 ms ] story [ 1679 ms ] threadThe 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
"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)
How is this *not* real productivity gain?
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"
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.
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.
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.
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.
the samurai mentality doesn't make sense in today's economy.
Writing code has never been the hard part.
Not for Bob, not for you.
I have a hunch the amount of prs written per day per engineer is likely the same or only 10-15% higher.
I solve most of my problems when I'm doing things like chopping vegetables or mowing the lawn. Sitting in the presence of shiny technology does not magically confer one with the ability to achieve higher quality decisions more quickly. I find the opposite to be mostly true. I can massively outperform the development team that my clients have simply because I am not a full time employee and can idle out long enough to think about their problems the slow way. The urgency to keep the status circle green in Teams (and related productivity theater) creates a lot of stupid decisions in many shops.
I stopped at this line
> he was responsible for shipping Facebook Groups
and wondered how can this be a compliment in any shape or form. I mean even considering Fb Groups from its day 1, not the bigger Frankenstein it has become today.
But I get it. "Shipping" was the achievement.
> massive productivity nerd
My "productivity" phase started at the start of college and since then it has a been tapering down every month/year and I don't complain at all.
I wish I did something else (I mean not even related to my studies or field..anything else) when I was actually exploring the shiny wide world of productivity porn. No, it didn't enrich me in anyway.
And I've seen so many seniors (at various levels of seniority over the years) who had stopped giving two hoots about tools or productivity tools in its entirety. It's like you have to reach city A from city B and few people just hop on the car available to them or public transport (this one not in USA) whenever they are ready to leave. But a lot of people go down the rabbit hole of best cars, best fuels, best routes (and then they obsess over their favourite coffee chains along the way), and get in fights with other people on car and other forums in the planning. By the time they could agree on their cars, the other folks who had just gone, had finished their works there, and even took an extra day or two to sightsee and shit like that and they might have even forgotten about that because it was weeks and months ago.
This is not too much of far fetching. This is actually quite important in early career states and habit and ideas set in during that time.
What has rather worked for me far more/better is a good place to work, environment, lighting, ambience, noise, temperature, material physical comforts available, maybe a bit of easy variation (as needed; not as forced upon) et cetera. But I think these things work differently for different people (and at different ages).
In the AI world you see it with the overly elaborate prompt markdown files where my agent gives performance reviews to 4 teams of agents each with its own quirky personality traits