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.
I agree. after a certain point, let's say, post-mastery of a craft, nice tools can be a great joy to work with. But, same for less ideal stuff, some days. working with unfit toolsay even yield surprisingly desirable results for the post-master craftsman.
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.
I don't think they force you to do that. Not trying to be pedantic, but you can also just wait for a single agent to finish its work.
Nowadays I often feel that that is a better spend of my time. Especially because it allows my mind to wonder about the next thing and what I could have missed. Before I was doing the context switching dance I felt I was going at 10x, but realized I was only perhaps going at 2x. Now I have severely reduced the number of threads, mostly to a single thread, and ask smaller questions. My sense is that I am probably now going at 2.5x but with my sanity restored and with a much firmer grasp of what is going on.
I also find myself coding more skeletons and letting an agent finish it, because I am again taking the time to think of the shape of the solution. The end result is better then when I allow the LLM to flail about in the codebase.
> 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.
Don't do that if it bothers you? My best experience for "agent produces good code following good design" essentially been to always work with one agent, at most two, but in the same project. And while the agent works, I continue taking my notes of what I'm doing, what's next, what the design/architecture needs to evolve to do and so on.
Of course if you switch between five projects, you'll suffer the context switching cost. The best to avoid that? Don't context switch, find other related things to do close to the task you're "outsourcing", or start planning how to validate, or...
> And while the agent works, I continue taking my notes of what I'm doing, what's next, what the design/architecture needs to evolve to do and so on.
That is still context switching for me. I do the same. While the agent works, which may be 10 minutes, I start planning follow up tasks, etc. But then eventually I still need to come back to the original task to review the agents work.
I don't switch across projects usually. But I can never get into a flow state like that. But I also don't want to sit there for 10 minutes doing nothing
I truly believe a lot of people don’t really realize how good it is when you have a good environment for development work. It’s straight thinking to doing. And it’s not even about vim/tmux or emacs. You can do so with sublime or IDEA. In the pragmatic programmer book, it’s called editor fluency.
It’s a balance. It’s easy to spend more time dickering with tools than you save by having those tools. I used to have this amazing neovim setup that worked exactly like I wanted it to. Unfortunately, it was fragile, and while it was theoretically infinitely flexible, practically, it was too big of a PITA to change to be flexible on the run. Then a couple of unrelated plugin changes caused some big problems with my setup at the end of a big project and I pivoted to jetbrains stuff— specifically Rider, PyCharm, and WebStorm. There was a bit of a learning curve, but the discoverability of functionality was waaaaay better, and with a few single-click-install plugins for languages or environmental integrations, it did everything I needed it to do within 5 minutes on any machine I sat down at. I’ve moved on to other IDEs except for Rider, but I discovered that _for me_, learning how to do what I wanted to do in a well-designed batteries-included environment had a much bigger payoff than trying to manage a mini infrastructure project on my machine in parallel with whatever else I was working on.
There's a bubble where VC backed companies are not producing anything that people are really using or paying for. So to justify their valuation they instead try to show just how productive they are. Surely if they are this busy and productive they must be worth something? (This could also explain the hype around AI which is all about "productivity/how" and nothing about "what")
This article compares these kinds of companies ("nihilists") with game developers who are producing things that people pay for and use. The game developers don't pay much attention to productivity tools because they are too busy producing things.
> the perennially unprofitable venture-backed startup, for which faux productivity is connected to the generally immaterial nature of its high valuations, versus the game studio that lives and dies by the profitability of its products.
> In a sector of the economy where "it's not about how much you earn, but about how much you're worth," the labors of the companies whose workflows are built on the kinds of productivity apps that today comprise nearly 40 percent of Product Hunt's output are not actually directed at the creation of a thing, but at the appearance of the creation of a thing.
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.
I think for me customizing my setup isn't time away from "real tasks" - I do the customization when I don't feel like doing the work or I'm doing some background thinking on how to proceed in the real task. It's an interesting way to keep my mind warmed up for programming through times when I'm not in the mood, and I'd guess 80-90% of the customization is waste of time, but the ones that I end up sticking with can be really useful and save time/effort dozens of times per day
There's also the dissonance between actual productivity and perceived productivity. Being fluent in vim/emacs to navigate code may feel you're hacking the matrix etc, but that in itself does not mean you're productive. Spending a morbillion tokens on orchestrating a dozen AI agents may make you feel like God, but it doesn't mean whatever they're building actually works or solves a problem. etc
This is how I feel when I ctrl-click something to jump to definition and a vim user tells me they can easily do the same thing by navigating to it with the arrow keys and pressing some obscure combination.
What are those supposedly easy CRUD apps that you are working on? The most CRUDy platform I worked on (it was really a collection of forms and lists) was packed full with integrations to external services. To create a new page, you just had to copy and paste. But to bring in the actual feature requires to write multiple files of business logic and more integration modules to third parties.
My experience with CRUD backends is that you get bogged down in really convoluted business logic and abstraction layers, and most of your time is neither spent writing or thinking, but debugging. (Of course debugging involves thinking, but it requires you to step around, print, inspect, and explore how data flows, rather than exclusively thinking up new solutions). And in my opinion, debugging is easier if you can faster navigate your code and more quickly type or edit small changes.
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.
> 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).
Are you building it if the LLM does it? I'd say the negative reaction comes from this.
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.
I used to smoke a lot, and every time I went to smoke outside I'd think about what I was coding and find some stupid mistake just from thinking about it away from the keyboard.
Now I go for a walk and 9 times out of 10 it's the same, I write better code because I thought about it away from the keyboard.
This also works with vibe coding, I find - I think of better approaches to the codebase when I'm not in front of it
> 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).
Thinking and typing often happen at the same time. Its much easier for many people to reason about a problem by writing and changing the code, and it's also why LLMs can significantly reduce code understanding even if you read everything they wrote.
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
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.
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 always admired people who spent hours configuring their local setup, but this was never me. For me I was always looking for the one script setup that would just get me 80% home and that was good enough. I’ve never had the patience to configure my vim or tmux bindings so I’d always use what out there. It’s not that I think it doesn’t matter but I could never find the motivation to spend that amount of time with it. I guess I always preferred to get from someone who already spent the time on. Open source is beautiful
There's an "expert trap" in here I think, at least this is something I experience. When you are good at something, it's a lot less effort to draw on that stuff, and you usually get instant easy positive feedback from non-experts. So, for an engineer, that's code and tools and the like, but also productivity systems and other abstract thinking modes that are useful in programming. On the flipside, actually thinking about your product and domain is hard. So, it becomes psychologically easy to get caught up in technical things that are comparatively easy mental and social reward per unit effort, and you feel productive. But it's not always objectively the best use of time.
Just the other day I found out about a study that measured coding productivity. They compared CLI tooling to simple actions. The CLI users _felt_ more productive, but they were not.
Then again, the question is, if the simple action needs to be changed, how hard will that be?
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.
If it ain't broke, don't fix it. This is also why e.g. Java or Python isn't going anywhere anytime soon; they're fine, but there's armies of software developers who are well-versed in them. Newer languages may be "better" (by whatever measure), but experience trumps novelty.
Yea I'd agree. I hate configuring things or setting up custom scripts that could make things easier for me and yet I still work productive on my day 2 day tasks.
Also used neovim for 2 years or so and hated every minute of it having to configure LSPs and wwhatnot. I now use a mixture of VS Code and IntelliJ and its good enough for me.
same, although I also bothered to learn the standard keybindings of the most popular IDEs of my kind of work (intellij, eclipse, netbeans, vs code). As a plus, I can get started right away on just any dev machine I come across, no expensive customisation needed.
Don't be in love with your code or your workstation. Only the endresult matters.
The important part is figuring out what time is spent on solving the actual problem and what is spent on everything else. In my case, I spent stupid amounts of time waiting for an app to start up, checks to run, CI to run, etc. And nowadays I get context switched by waiting for AI to finish their stuff too.
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.
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 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).
You need to see the facebook part in context, back then it was actually a hot place to be, the company and the platform, and devs were dedicated to leave a mark. Zuck was also perceived as the nerd buddy that disrupted the industry. Well until people found out he is a lizard.
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.
What incredible problem did FB/Meta solve with the Marketplace, anyone care to elaborate? What did they (this guy do) that was not there before or else hard to conceive?
>What incredible problem did FB/Meta solve with the Marketplace
They adapted something that people were already using in great numbers, and provided a good interface for an extra hot flow without compromising what facebook was. (so that people would keep using facebook for this purpose, and not go to another platform with a dedicated workflow, e.g. craigslist or freecycle)
So they did actually provide value to end users here, and arguably captured some for themself too. I know the last n times I've opened facebook have been exclusively for buy/sell groups
Well my ask is in the context of narrative as presented by author in his blog post. This super productive guy writing code blindfolded seems to have reinvented the wheel in a very mature environment… not quite a breakthroughs business, even if we can assume certain level of engineering feat. Which is also not unheard of at time of release.
Wait, where is the half of the article where he explains what Bob is doing differently ? I'm pretty sure everyone else in the hackathon was working on something "that mattered" (although, it's facebook, so "what matter" mean "putting more people in front of ads sprinkled with cat pictures while setting personnal data to dystopian law enforcement", or something like that.)
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"
When I was a teenager, I was a big fan of the show (and books), Red Dwarf. One part of the story describes one of the characters, Rimmer, preparing for an exam. He spends so much time preparing his revision timetable and improving it iteratively, over and over again, that he completely forgets to revise and the night before the exam realises he has a beautiful revision timetable, but no time left to revise. "Rimmer's Revision Timetable" was a shorthand in several places I worked for "we're doing too much preparing, not enough doing, let's get on and just do".
I once spent 9 months trying to figure out how a piece of software should be built - I wanted it to be perfect - while my bosses agonised over the delay. One night, in a bout of anxiety and just trying to get something to show my bosses, I sat down at around 7pm and just started riffing away in the editor. I ended up working through the night. By 5am it was done. By 9am it was in production. By 11am the first customers were giving us money. I didn't need to edit it again for 3 months. That was the moment I decided to ignore an old quote I'd been handed and had until the point believed had real truth in it:
"Give me six hours to chop down a tree, I'll spend the first three sharpening the axe" - attributed widely to Abraham Lincoln, but as the other saying goes "90% of the quotes you read on the Internet are misattributed to the wrong person" - Mark Twain.
There are some situations where the preparation is necessary. If your axe is blunt, it'll never cut down the tree, even in 6 hours. Getting it sharp in the first 3 hours means you might finish the task early, for less physical effort.
But more often than not, you're just procrastinating. You could go find another axe. You could find that the axe you have is just fine and gets your tree down in an hour rather than three hours of sharpening followed by half an hour of chopping. But by spending your time sharpening, and not chopping, you have the illusion of telling yourself you're working towards your goal, but you're not. And guess what, sharpening is a lot easier and a lot less sweaty than chopping, so it's more comfortable too - what's not to like?
YAGNI, Yak Shaving, axe sharpening, Rimmer's Revision Timetable, they all bring into focus different perspectives of the same problem:
Doing a thing that isn't the thing, isn't doing the thing.
Yes, if your editor config is distracting and you want to fix something, go find a quick thing and move on. Installing a tiling window manager and a global keyboard shortcut app of some sort might make things flow a little better, but spending days optimising is likely poor ROI.
Just try and do the thing. Build something. Stop planning to build something. If you aren't sure what to build, spend 5 minutes trying to build something and figure out what's actually in your way (hint: it's not your editor, it's not your lack of gdb knowledge, it's not that you're not using the hottest new programming language or that new agent/skill/model people are talking about), and find the possible quickest way to get back to making progress.
Yes, you need to think about prod. The more senior you are, the easier this comes naturally, but writing tests is doing the thing, not procrastination. Putting in operational and business metrics is doing the thing, not procrastination. Why? Because those are part of the thing. Your prompts are not part of the thing, and neither is your tmux config.
As an aside, LLMs can maybe help here (but don't over-engineer the harness): I have a side project where I feel I need to pick up a lot of theory on reinforcement learning, I could do with a refresher on partial differential equations, and I also want to learn some more advanced socket programming in C (trust me, all these things combine into a single thing).
I could have spent the next three months reading books and doing courses and then started on my project, but what I've done instead is get Fable to build out a curriculum where I build the relevant parts as I'm learning.
The first spec it came back with told me I had about 7-10 months of work ahead of me, but I could see (at least in the early stages which I understand better than the later stages), I'd be in a virtuous cycle of learning → applying → learning → applying → ... and within the first couple of weeks I'd have some basic harnesses that showed progress and have some of the theory down too.
This, I think, is a valuable way to structure the learning without procrastination. A personalised tutor who can help you fill in the gaps in your knowledge as you build, so you build the right thing and learn, but you're not just procrastinating up-front, feels good. And, if I get 3 months in and have enough knowledge to realise the next three months are not quite right, I will have the knowledge to re-prompt, re-draft and move forward.
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
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.
The article isn't about AI though, it's about developers and their extensive coding setups being beaten by a guy in a plain editor. You're not personally under attack.
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
This is why AI will never replace human commenters.
...unless they are instructed to use poor grammar.
Actually I'm surprised they do use good grammar given how much poor grammar would be in their datasets. But that's probably why they don't just blindly train these things on internet comments.
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.
I agree. after a certain point, let's say, post-mastery of a craft, nice tools can be a great joy to work with. But, same for less ideal stuff, some days. working with unfit toolsay even yield surprisingly desirable results for the post-master craftsman.
at one time I wrote Huffman compression in LambdaMOO, just because I could. This is a line editor akin to 'ed' accessed over telnet.
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.
I don't think they force you to do that. Not trying to be pedantic, but you can also just wait for a single agent to finish its work.
Nowadays I often feel that that is a better spend of my time. Especially because it allows my mind to wonder about the next thing and what I could have missed. Before I was doing the context switching dance I felt I was going at 10x, but realized I was only perhaps going at 2x. Now I have severely reduced the number of threads, mostly to a single thread, and ask smaller questions. My sense is that I am probably now going at 2.5x but with my sanity restored and with a much firmer grasp of what is going on.
I also find myself coding more skeletons and letting an agent finish it, because I am again taking the time to think of the shape of the solution. The end result is better then when I allow the LLM to flail about in the codebase.
> 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.
Don't do that if it bothers you? My best experience for "agent produces good code following good design" essentially been to always work with one agent, at most two, but in the same project. And while the agent works, I continue taking my notes of what I'm doing, what's next, what the design/architecture needs to evolve to do and so on.
Of course if you switch between five projects, you'll suffer the context switching cost. The best to avoid that? Don't context switch, find other related things to do close to the task you're "outsourcing", or start planning how to validate, or...
> And while the agent works, I continue taking my notes of what I'm doing, what's next, what the design/architecture needs to evolve to do and so on.
That is still context switching for me. I do the same. While the agent works, which may be 10 minutes, I start planning follow up tasks, etc. But then eventually I still need to come back to the original task to review the agents work.
I don't switch across projects usually. But I can never get into a flow state like that. But I also don't want to sit there for 10 minutes doing nothing
I think you forgot to explain the false dichotomy part.
3rd paragraph
I truly believe a lot of people don’t really realize how good it is when you have a good environment for development work. It’s straight thinking to doing. And it’s not even about vim/tmux or emacs. You can do so with sublime or IDEA. In the pragmatic programmer book, it’s called editor fluency.
It’s a balance. It’s easy to spend more time dickering with tools than you save by having those tools. I used to have this amazing neovim setup that worked exactly like I wanted it to. Unfortunately, it was fragile, and while it was theoretically infinitely flexible, practically, it was too big of a PITA to change to be flexible on the run. Then a couple of unrelated plugin changes caused some big problems with my setup at the end of a big project and I pivoted to jetbrains stuff— specifically Rider, PyCharm, and WebStorm. There was a bit of a learning curve, but the discoverability of functionality was waaaaay better, and with a few single-click-install plugins for languages or environmental integrations, it did everything I needed it to do within 5 minutes on any machine I sat down at. I’ve moved on to other IDEs except for Rider, but I discovered that _for me_, learning how to do what I wanted to do in a well-designed batteries-included environment had a much bigger payoff than trying to manage a mini infrastructure project on my machine in parallel with whatever else I was working on.
There's a bubble where VC backed companies are not producing anything that people are really using or paying for. So to justify their valuation they instead try to show just how productive they are. Surely if they are this busy and productive they must be worth something? (This could also explain the hype around AI which is all about "productivity/how" and nothing about "what")
This article compares these kinds of companies ("nihilists") with game developers who are producing things that people pay for and use. The game developers don't pay much attention to productivity tools because they are too busy producing things.
https://components.news/the-gamer-and-the-nihilist/
> the perennially unprofitable venture-backed startup, for which faux productivity is connected to the generally immaterial nature of its high valuations, versus the game studio that lives and dies by the profitability of its products.
> In a sector of the economy where "it's not about how much you earn, but about how much you're worth," the labors of the companies whose workflows are built on the kinds of productivity apps that today comprise nearly 40 percent of Product Hunt's output are not actually directed at the creation of a thing, but at the appearance of the creation of a thing.
Not sure it’s a bubble so much as a story as old as time… signal hacking. Always has happened and always will
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:
"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.
I think for me customizing my setup isn't time away from "real tasks" - I do the customization when I don't feel like doing the work or I'm doing some background thinking on how to proceed in the real task. It's an interesting way to keep my mind warmed up for programming through times when I'm not in the mood, and I'd guess 80-90% of the customization is waste of time, but the ones that I end up sticking with can be really useful and save time/effort dozens of times per day
There's also the dissonance between actual productivity and perceived productivity. Being fluent in vim/emacs to navigate code may feel you're hacking the matrix etc, but that in itself does not mean you're productive. Spending a morbillion tokens on orchestrating a dozen AI agents may make you feel like God, but it doesn't mean whatever they're building actually works or solves a problem. etc
This is how I feel when I ctrl-click something to jump to definition and a vim user tells me they can easily do the same thing by navigating to it with the arrow keys and pressing some obscure combination.
> 90% of our time should be spent thinking, and most of that reading
I don’t know if that’s accurate for most of us, who are simply humble CRUD app developers.
It's 2026. There are no such developers. LLMs haven't solved programming (yet), but they have solved the common CRUD apps perfectly.
90% of our time should be spent waiting for Claude to ask permission for something then!
Or waiting for Claude's outages to clear up.
Or waiting for your limits to reset ...
What are those supposedly easy CRUD apps that you are working on? The most CRUDy platform I worked on (it was really a collection of forms and lists) was packed full with integrations to external services. To create a new page, you just had to copy and paste. But to bring in the actual feature requires to write multiple files of business logic and more integration modules to third parties.
My experience with CRUD backends is that you get bogged down in really convoluted business logic and abstraction layers, and most of your time is neither spent writing or thinking, but debugging. (Of course debugging involves thinking, but it requires you to step around, print, inspect, and explore how data flows, rather than exclusively thinking up new solutions). And in my opinion, debugging is easier if you can faster navigate your code and more quickly type or edit small changes.
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.
[0] https://medium.com/@bre/the-cult-of-done-manifesto-724ca1c2f...
> 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).
Are you building it if the LLM does it? I'd say the negative reaction comes from this.
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.
> 90% of our time should be spent thinking, and most of that reading.
Not sure about you, but I do a lot of thinking by typing code...In fact, I think it would be very hard to think without actually typing code..
I don't think this is exclusive to coding. Even general ideas are refined if one tries to put them in writing.
I literally can't do this.
I used to smoke a lot, and every time I went to smoke outside I'd think about what I was coding and find some stupid mistake just from thinking about it away from the keyboard.
Now I go for a walk and 9 times out of 10 it's the same, I write better code because I thought about it away from the keyboard.
This also works with vibe coding, I find - I think of better approaches to the codebase when I'm not in front of it
Yea, that works for me as well. But I can't do that from blank state. I need to be walking away from a long coding session for that to work.
Occasionally it spills out to the codebase with the phenomenon of the Senior Linter Developer.
> 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.
https://www.youtube.com/watch?v=urcL86UpqZc&t=112s
> 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).
> 90% of my time as a coder is spent typing
> 90% of our time should be spent thinking
Thinking and typing often happen at the same time. Its much easier for many people to reason about a problem by writing and changing the code, and it's also why LLMs can significantly reduce code understanding even if you read everything they wrote.
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
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.
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 always admired people who spent hours configuring their local setup, but this was never me. For me I was always looking for the one script setup that would just get me 80% home and that was good enough. I’ve never had the patience to configure my vim or tmux bindings so I’d always use what out there. It’s not that I think it doesn’t matter but I could never find the motivation to spend that amount of time with it. I guess I always preferred to get from someone who already spent the time on. Open source is beautiful
It's not about productivity, it's about having fun with your toys.
me looking at my brand new mechanical keyboard ssshhh... it's OK, it's not about us.
There's an "expert trap" in here I think, at least this is something I experience. When you are good at something, it's a lot less effort to draw on that stuff, and you usually get instant easy positive feedback from non-experts. So, for an engineer, that's code and tools and the like, but also productivity systems and other abstract thinking modes that are useful in programming. On the flipside, actually thinking about your product and domain is hard. So, it becomes psychologically easy to get caught up in technical things that are comparatively easy mental and social reward per unit effort, and you feel productive. But it's not always objectively the best use of time.
Just the other day I found out about a study that measured coding productivity. They compared CLI tooling to simple actions. The CLI users _felt_ more productive, but they were not.
Then again, the question is, if the simple action needs to be changed, how hard will that be?
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.
The best artist I talked to in-person still uses Photoshop CS6. (And a Wacom without a display).
If it ain't broke, don't fix it. This is also why e.g. Java or Python isn't going anywhere anytime soon; they're fine, but there's armies of software developers who are well-versed in them. Newer languages may be "better" (by whatever measure), but experience trumps novelty.
I think most professionals are conservative when it comes to their tools. Mastering them took a long time and it's hard to change.
Writing code has never been the hard part.
Writing code has never been the hard part.
Not for Bob, not for you.
This is not 'productivity mirage' this is just 'tooling mirage'.
Yea I'd agree. I hate configuring things or setting up custom scripts that could make things easier for me and yet I still work productive on my day 2 day tasks.
Also used neovim for 2 years or so and hated every minute of it having to configure LSPs and wwhatnot. I now use a mixture of VS Code and IntelliJ and its good enough for me.
I kept using vim motions however.
same, although I also bothered to learn the standard keybindings of the most popular IDEs of my kind of work (intellij, eclipse, netbeans, vs code). As a plus, I can get started right away on just any dev machine I come across, no expensive customisation needed.
Don't be in love with your code or your workstation. Only the endresult matters.
The important part is figuring out what time is spent on solving the actual problem and what is spent on everything else. In my case, I spent stupid amounts of time waiting for an app to start up, checks to run, CI to run, etc. And nowadays I get context switched by waiting for AI to finish their stuff too.
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.
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 guess many people don't know that Sublime pretty much made file navigation good again with fuzzy search.
Back then every IDE needed minutes to load a tiny project and it was still much less efficient to open a file.
Being busy is easy to measure; meaningful progress is not, which is why productivity often becomes performance rather than real output.
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).
You need to see the facebook part in context, back then it was actually a hot place to be, the company and the platform, and devs were dedicated to leave a mark. Zuck was also perceived as the nerd buddy that disrupted the industry. Well until people found out he is a lizard.
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 think you the nail on the head. Go to any hobby sub on Reddit and you see the same story play out.
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.
> better version of Jira
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.
Just whatever you do, don't open the network tab in your browser devtools.
We have GAS (Gear Acquisition Syndrome) and Productivity Procrastination.
https://en.wikipedia.org/wiki/Shopping_addiction#Gear_Acquis....)
https://stanforddaily.com/2025/05/27/productive-procrastinat...
Buying ever more elaborate keyboards and endlessly tweaking syntax highlighting and Kanban boards will always loose to just getting on with it.
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.
After many years you care less about how cool your setup is and move to the best developer experience (dx) which in most cases is the default.
I am a fan of taking the time to set this stuff up once well and then not touching it again until at least a couple of years down the line.
What incredible problem did FB/Meta solve with the Marketplace, anyone care to elaborate? What did they (this guy do) that was not there before or else hard to conceive?
>What incredible problem did FB/Meta solve with the Marketplace
They adapted something that people were already using in great numbers, and provided a good interface for an extra hot flow without compromising what facebook was. (so that people would keep using facebook for this purpose, and not go to another platform with a dedicated workflow, e.g. craigslist or freecycle)
So they did actually provide value to end users here, and arguably captured some for themself too. I know the last n times I've opened facebook have been exclusively for buy/sell groups
It was just the heyday of facebook and groups being popular. If a company sees something is popular, they will of course add more crap to it.
The hard part is that companies don't hire creative thinkers, but specialists. So you let people try stuff until you think something good happened.
Well my ask is in the context of narrative as presented by author in his blog post. This super productive guy writing code blindfolded seems to have reinvented the wheel in a very mature environment… not quite a breakthroughs business, even if we can assume certain level of engineering feat. Which is also not unheard of at time of release.
spent more time configuring my note-taking system than writing anything worth noting
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...
Wait, where is the half of the article where he explains what Bob is doing differently ? I'm pretty sure everyone else in the hackathon was working on something "that mattered" (although, it's facebook, so "what matter" mean "putting more people in front of ads sprinkled with cat pictures while setting personnal data to dystopian law enforcement", or something like that.)
Ah the good old “he works differently thus he is wrong” fallacy. The best developers I know use a terminal and that’s it.
Those features are the only I find useful in facebook, fb marketplace and local groups for buying or selling stuffs or services.
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...
Thats unfair. There is no way to say either way from the article.
Well that’s where other people with different strengths will shine.
More often than not, what matters is transforming a concept into working code that is good enough.
The easier part is maintaining and tweaking that code, but do not underestimate the value of the former.
Do you even want your best and most prolific engineers wasting their energy on on-call duties?
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"
More people want to write game engines than actual games.
When I was a teenager, I was a big fan of the show (and books), Red Dwarf. One part of the story describes one of the characters, Rimmer, preparing for an exam. He spends so much time preparing his revision timetable and improving it iteratively, over and over again, that he completely forgets to revise and the night before the exam realises he has a beautiful revision timetable, but no time left to revise. "Rimmer's Revision Timetable" was a shorthand in several places I worked for "we're doing too much preparing, not enough doing, let's get on and just do".
I once spent 9 months trying to figure out how a piece of software should be built - I wanted it to be perfect - while my bosses agonised over the delay. One night, in a bout of anxiety and just trying to get something to show my bosses, I sat down at around 7pm and just started riffing away in the editor. I ended up working through the night. By 5am it was done. By 9am it was in production. By 11am the first customers were giving us money. I didn't need to edit it again for 3 months. That was the moment I decided to ignore an old quote I'd been handed and had until the point believed had real truth in it:
"Give me six hours to chop down a tree, I'll spend the first three sharpening the axe" - attributed widely to Abraham Lincoln, but as the other saying goes "90% of the quotes you read on the Internet are misattributed to the wrong person" - Mark Twain.
There are some situations where the preparation is necessary. If your axe is blunt, it'll never cut down the tree, even in 6 hours. Getting it sharp in the first 3 hours means you might finish the task early, for less physical effort.
But more often than not, you're just procrastinating. You could go find another axe. You could find that the axe you have is just fine and gets your tree down in an hour rather than three hours of sharpening followed by half an hour of chopping. But by spending your time sharpening, and not chopping, you have the illusion of telling yourself you're working towards your goal, but you're not. And guess what, sharpening is a lot easier and a lot less sweaty than chopping, so it's more comfortable too - what's not to like?
YAGNI, Yak Shaving, axe sharpening, Rimmer's Revision Timetable, they all bring into focus different perspectives of the same problem:
Doing a thing that isn't the thing, isn't doing the thing.
Yes, if your editor config is distracting and you want to fix something, go find a quick thing and move on. Installing a tiling window manager and a global keyboard shortcut app of some sort might make things flow a little better, but spending days optimising is likely poor ROI.
Just try and do the thing. Build something. Stop planning to build something. If you aren't sure what to build, spend 5 minutes trying to build something and figure out what's actually in your way (hint: it's not your editor, it's not your lack of gdb knowledge, it's not that you're not using the hottest new programming language or that new agent/skill/model people are talking about), and find the possible quickest way to get back to making progress.
Yes, you need to think about prod. The more senior you are, the easier this comes naturally, but writing tests is doing the thing, not procrastination. Putting in operational and business metrics is doing the thing, not procrastination. Why? Because those are part of the thing. Your prompts are not part of the thing, and neither is your tmux config.
As an aside, LLMs can maybe help here (but don't over-engineer the harness): I have a side project where I feel I need to pick up a lot of theory on reinforcement learning, I could do with a refresher on partial differential equations, and I also want to learn some more advanced socket programming in C (trust me, all these things combine into a single thing).
I could have spent the next three months reading books and doing courses and then started on my project, but what I've done instead is get Fable to build out a curriculum where I build the relevant parts as I'm learning.
The first spec it came back with told me I had about 7-10 months of work ahead of me, but I could see (at least in the early stages which I understand better than the later stages), I'd be in a virtuous cycle of learning → applying → learning → applying → ... and within the first couple of weeks I'd have some basic harnesses that showed progress and have some of the theory down too.
This, I think, is a valuable way to structure the learning without procrastination. A personalised tutor who can help you fill in the gaps in your knowledge as you build, so you build the right thing and learn, but you're not just procrastinating up-front, feels good. And, if I get 3 months in and have enough knowledge to realise the next three months are not quite right, I will have the knowledge to re-prompt, re-draft and move forward.
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
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.
as opposed to posting comments on forums in the evening for free? at least facebook groups is impactful one way or another.
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)
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?
The article isn't about AI though, it's about developers and their extensive coding setups being beaten by a guy in a plain editor. You're not personally under attack.
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)
Note entirely what's the point of your comment, but AI bros have the reputation of making every discussion about AI.
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
Nah the AI would have used proper grammar.
This is why AI will never replace human commenters.
...unless they are instructed to use poor grammar.
Actually I'm surprised they do use good grammar given how much poor grammar would be in their datasets. But that's probably why they don't just blindly train these things on internet comments.
The quickest way to clear your backlog is deleting them. /s