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.
Exactly. It matters that you enjoy working with your tools. Even if they don't make you 10x more productive, focusing on what you're working on and enjoying the process is the most important part.
Especially in the age of LLMs I think a lot of us hate the current tools that force you to context switch between N agents and terminals. Constant context switching takes the joy out of work and prevents you from getting into a flow state. I hope someone figures out the solution.
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.
> 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.
Any software engineer who proclaims "90% of my time is spent typing" does not understand two fundamental industry axioms:
Software is the manifestation of a solution to a problem.
Define the problem which needs to be solved.
When making software, remember that it is a snapshot of
your understanding of the problem. It states to all,
including your future-self, your approach, clarity, and
appropriateness of the solution for the problem at hand.
Choose your statements wisely.
"Coding", when performed at the appropriate time, is little more than reifying a solution to a problem already understood. Also known as "a typing exercise."
All of this is to say; I agree with your position.
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.
I think the downvotes are for saying positive things about AI. HN doesn't like that ;)
And yes, messing about with skills is the new messing around with setup. It's a rabbit hole.
I'm a massive, massive, believer in The Cult of Done [0] especially "the point of being done is not to finish but to get other things done". Allowing myself to finish something badly so that I can move on to the next thing was a game-changer for me. And, of course, I found out that it doesn't have to be what I would call perfect for others to appreciate it. Getting something shipped is way, way more important than getting something perfect, and often my procrastination around the fear that it wasn't perfect was stopping either.
I'd say the downvotes are for: "No fuckin' shit we can just AI." This is clearly an article about the (and I can't believe I'm saying this) "classic" style of programming from, like, a few years ago. This is clear as day. There is not a single person here who doesn't realize this.
If you really must bring up AI here, a more relevant comment would be how you may over-complicate your AI workflow, over-focus on promots, or something along those lines.
> 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.
This is somewhat misguided thinking in that, while very true that people who care more about their setup than getting actual work done do exist, "Optimizing for typing" really means: "optimizing for how quickly you can get back to thinking."
I've seen some experienced programmers use simple editors extremely quickly and others use IDEs very slowly. This short article does not dive into things like: "Does Bob need to right-click his mouse in the right place and choose 'split vertical' or does he just make that shit happen in an instant?" I've done a lot of pair-programming in my career and many people, even if they are good developers, feel like I'm watching my boomer parents use a computer.
Of course, in the end your output is all that matters (which I realize is the argument of this article), but there is definitely something to being able to use your tools of your choosing efficiently (which it sounds like Bob does).
Its kind of funny but non technical people imagine coders to only be productive when they are typing away like those typical "hacking into the mainframe" scenes. I actually made a satire art thing on this where it was a fake news release that companies are going to start making engineers dance when the ai agent is coding to "improve spirit" but meanwhile they use that data to create training datasets for their upcoming dancing bot
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.
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’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 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 something of a circular argument. Bob doesn't waste energy on on-call duties, so he implements more features, so he's a prolific engineer, so he doesn't have to waste energy on on-call duties.
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"
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
Writing code has never been the hard part.
Not for Bob, not for you.
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.
Especially in the age of LLMs I think a lot of us hate the current tools that force you to context switch between N agents and terminals. Constant context switching takes the joy out of work and prevents you from getting into a flow state. I hope someone figures out the solution.
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.
Any software engineer who proclaims "90% of my time is spent typing" does not understand two fundamental industry axioms:
"Coding", when performed at the appropriate time, is little more than reifying a solution to a problem already understood. Also known as "a typing exercise."All of this is to say; I agree with your position.
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.
And yes, messing about with skills is the new messing around with setup. It's a rabbit hole.
I'm a massive, massive, believer in The Cult of Done [0] especially "the point of being done is not to finish but to get other things done". Allowing myself to finish something badly so that I can move on to the next thing was a game-changer for me. And, of course, I found out that it doesn't have to be what I would call perfect for others to appreciate it. Getting something shipped is way, way more important than getting something perfect, and often my procrastination around the fear that it wasn't perfect was stopping either.
[0] https://medium.com/@bre/the-cult-of-done-manifesto-724ca1c2f...
If you really must bring up AI here, a more relevant comment would be how you may over-complicate your AI workflow, over-focus on promots, or something along those lines.
I don’t know if that’s accurate for most of us, who are simply humble CRUD app developers.
https://www.youtube.com/watch?v=urcL86UpqZc&t=112s
This is somewhat misguided thinking in that, while very true that people who care more about their setup than getting actual work done do exist, "Optimizing for typing" really means: "optimizing for how quickly you can get back to thinking."
I've seen some experienced programmers use simple editors extremely quickly and others use IDEs very slowly. This short article does not dive into things like: "Does Bob need to right-click his mouse in the right place and choose 'split vertical' or does he just make that shit happen in an instant?" I've done a lot of pair-programming in my career and many people, even if they are good developers, feel like I'm watching my boomer parents use a computer.
Of course, in the end your output is all that matters (which I realize is the argument of this article), but there is definitely something to being able to use your tools of your choosing efficiently (which it sounds like Bob does).
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.
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.
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.
The easier part is maintaining and tweaking that code, but do not underestimate the value of the former.
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?