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.
> 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.
This is just my opinion so maybe im describing something other than what you are observing.
This was me, until I got AI. Now im building cool stuff that I never would have built (but also slowly destroying what little skill I had and not knowing much about the underlying code). Of the code I do know about well, I am fixing and improving my old code and being amazed (but probably not deeply learning) with new tricks and techniques. The focus on setup to me was always my mind playing a trick on me. The AI reduced the "hump" I need to cross so I just try it. Its really another form of perfecting your setup.
Focusing on the setup for some might be a way to avoid the hard thinking part that comes with immense practice and focus. Its a hump everyone has to cross. It comes easier to some but not others. I remember doing exactly this when I was unemployed traveling Europe wanting to get into a software engineering role after being boxed into a QA testing role for years. I was a CS grad and did this same stuff in college to my detriment(thats how I ended up in QA I guess). I paid for InterviewCake and spent countless days in European hostels and cafes doing nonsense like perfecting my setup or editor instead of focusing deeply on the problem set. This might also be a symptom of ADHD. Recently started medication and the immense change in productivity has recently made me weep that I wasted half my life doing things like perfecting my setup instead of actually doing something.
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.
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.
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
> motivated by the same urge as the person in the car mod culture tweaking their exhaust system etc
to be fair, the car mod people's end goal is just modding their cars mostly. there's no end goal like there is with software (a product).
I think people just get preoccupied with things that make them feel good and are simple and have immediate feedback. Not to be pedantic, but I would argue the more accurate analogy to this is the photography community. I had a period where I was really obsessed with photography and realized the majority of people love just...buying shit. All they did was just collect cameras and lenses and took extremely mediocre pictures. Turns out actual creativity is a lot harder and less immediately satisfying than the dopamine hit of buying some new lens, or changing your vim colorscheme and updating some alias for the 100th time. I'm sure there's some psychology behind people being too afraid to actually produce something because then they actually put themselves out there whether that's through some website or a photograph.
I’m not an engineer (by trade) so I am not as deep as many of you in the tooling.
But this article mirrors my thinking on every new notes app, or new “second brain,” or somehow new or better version of Jira, etc. There are real productivity gains and losses and a lot of theatrics.
Nah, man. I would be a LOT more productive if I didn't have to wait all day for Jira tickets to load every single time, or that dropdown to load, or that popover to show, …
That’s fair and I’m not saying there isn’t room for improvement. It’s a more general feeling - JIRA just being one example that I hear people hate (and try to make better). My gut in using or looking at JIRA told me the biggest problem was organization within JIRA and sticking to that system.
Eh, I think the urge is similar but maybe the rationality a bit less. i.e. there is some measurable increase in… whatever you’re trying to maximize with a car mod, volume or performance or whatnot. It’s more opaque with these harness optimizations and tools.
To be fair I mess with “how” I use or orchestrate the harness myself, I still can’t say anything I do that benefits me is more than placebo. At least from my projects. I think it matters easily for the things that can be patched like Context7 helping with API knowledge, and less for those that can’t like whatever “prompting style” attempts to address.
Maybe for those, you can say it matters in making agent use more subjectively ergonomic? So less of a correctness thing and more of reducing fatigue.
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"
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...
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.
Not sure what the point of this comment is because even the cheapest LLM summary of the article would have told you clearly that it’s not about The AI Discourse (if anything, an avid AI user’s takeaway should be more along the “elaborate custom harness and router vs just use whichever subscription’s popular with its bundled app” axis)
Did your AI post this comment? It seems to be getting downvoted so I'm wondering if the productivity is positive in this case or negative? The same happens with AI clearing your backlog
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.
https://www.youtube.com/watch?v=urcL86UpqZc&t=112s
This was me, until I got AI. Now im building cool stuff that I never would have built (but also slowly destroying what little skill I had and not knowing much about the underlying code). Of the code I do know about well, I am fixing and improving my old code and being amazed (but probably not deeply learning) with new tricks and techniques. The focus on setup to me was always my mind playing a trick on me. The AI reduced the "hump" I need to cross so I just try it. Its really another form of perfecting your setup.
Focusing on the setup for some might be a way to avoid the hard thinking part that comes with immense practice and focus. Its a hump everyone has to cross. It comes easier to some but not others. I remember doing exactly this when I was unemployed traveling Europe wanting to get into a software engineering role after being boxed into a QA testing role for years. I was a CS grad and did this same stuff in college to my detriment(thats how I ended up in QA I guess). I paid for InterviewCake and spent countless days in European hostels and cafes doing nonsense like perfecting my setup or editor instead of focusing deeply on the problem set. This might also be a symptom of ADHD. Recently started medication and the immense change in productivity has recently made me weep that I wasted half my life doing things like perfecting my setup instead of actually doing something.
I don’t know if that’s accurate for most of us, who are simply humble CRUD app developers.
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 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
to be fair, the car mod people's end goal is just modding their cars mostly. there's no end goal like there is with software (a product).
I think people just get preoccupied with things that make them feel good and are simple and have immediate feedback. Not to be pedantic, but I would argue the more accurate analogy to this is the photography community. I had a period where I was really obsessed with photography and realized the majority of people love just...buying shit. All they did was just collect cameras and lenses and took extremely mediocre pictures. Turns out actual creativity is a lot harder and less immediately satisfying than the dopamine hit of buying some new lens, or changing your vim colorscheme and updating some alias for the 100th time. I'm sure there's some psychology behind people being too afraid to actually produce something because then they actually put themselves out there whether that's through some website or a photograph.
But this article mirrors my thinking on every new notes app, or new “second brain,” or somehow new or better version of Jira, etc. There are real productivity gains and losses and a lot of theatrics.
Nah, man. I would be a LOT more productive if I didn't have to wait all day for Jira tickets to load every single time, or that dropdown to load, or that popover to show, …
To be fair I mess with “how” I use or orchestrate the harness myself, I still can’t say anything I do that benefits me is more than placebo. At least from my projects. I think it matters easily for the things that can be patched like Context7 helping with API knowledge, and less for those that can’t like whatever “prompting style” attempts to address.
Maybe for those, you can say it matters in making agent use more subjectively ergonomic? So less of a correctness thing and more of reducing fatigue.
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"
"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?