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.
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
And when you get that new job with that new stack? Switching back to the windows laptop?
I learned early on in my career how to live off the land and use the tools I have given to be efficient because it is rare that I get to decide the tooling.
Cross platform tools? Usually can get away with them, but beside Jetbrains stuff its all over the place.
Seems like the difference b/w samurai and ninja. The samurai saw his sword as an extension of his soul - a disrespect to the sword was a disrespect to the man. The ninja used the sword like any other tool - and if it was helpful to use it to pry something open, there you go.
the samurai mentality doesn't make sense in today's economy.
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.
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.
I did that same circuit (except it was emacs to VS Code) for me - same experiences and reasons. I also used CLion for a couple of years for C++ - but in that case I never even bothered trying to use anything else. I could not get the bindings quite how I wanted in either VS Code or CLion, but I made it tolerable eventually.
I'm on neovim now, and the reason is coding agents. It ported my Spacemacs bindings to Astrovim in a few minutes.
Any feature I need to add, I just tell it and its done in a couple of minutes. Anytime I run into something that doesn't work quite how I want, I just tell the agent and boom, done.
I manage all my dotfiles this way now I think it totally changes the calculus. I'm even considering giving Nix another go.
This is why I tend to gravitate towards either fully bespoke tools (made by me, for me, nobody else) or tools with sane defaults.
Emacs -> (n)vim -> hx for CLI editor. Helix just works out of the box pretty much, no need for a Doom Helix or Oh-my-Helix to get it comfortable to use.
In terminals I finally ended up on Ghostty, I think the only significant configuration I have is setting `macos-option-as-alt`.
As for shell, fish + starship prompt has been my choice for years now. Very little customisation needed for either.
And for all software I pick the one that stores its configuration in a sane format in a XDG compatible location so I can shove it into chezmoi easily (looking at you iTerm2).
> 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.
I don’t know. I switch back from neovim to vim for some reason, but that vim setup has followed me for years even when I switched to emacs. And while I changed my emacs settings every once in a while, it has always been stable to me.
I’m not questioning your choice, and I do use IDE when the needs arise. But my emacs setup is mostly about dealing with every language and most tech interactions that I need. Not to be a full featured IDE for a language or a project.
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.
Both of you are describing a "waterfall model" of coding, where you conceive of the solution in its entirety before simply writing it down. I don't know if everyone else works this way, but I don't. I prefer to try things in the code and use those attempts to guide and refine my understanding. With the latter approach, being able to quickly and easily modify code is essential because it shortens the testing loop.
Edit: From GP:
> 90% of our time should be spent thinking, and most of that reading.
Reading what though? I assume you mean reading code. If you're reading code, being able to navigate through it quickly is important to maintaining context in your head. If the tool you're using makes navigation hard, it's easy to lose track of what you're doing. Obviously this can be taken to extremes, but spending some time investing in being able to navigate a codebase quickly is not wasted effort.
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.
> And yes, messing about with skills is the new messing around with setup.
I’ve been watching this play out at work. The people messing about with skills are invariably the people who have least impact on the actual shipping product. I suspect they hope that somehow, they’re going to hit on the magic formula that makes them productive.
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.
Paul Graham writes about this in an essay on procrastination.
Procrastination doesn't have to mean time on the couch, the person that keeps their house 'unreasonably tidy' is also procrastinating, albeit in their own special way, with feather duster and bleach. Yet they feel productive, plus there is that 'cleanliness is next to godliness' feeling after everything is spotless.
We have to guard against this with our coding setup, for example, I know people that have organised folders for their outbox emails. Management were impressed, however, I was quietly grumbling that real work needed to be done. Hence I search rather than organise email, to rarely impress management.
I like the 'contractor's desk' where there is just the laptop with no personal items, with the laptop having the default interface, wallpaper and terminal windows.
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.
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.
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
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
> 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).
> 90% of our time should be spent thinking, and most of that reading.
Three or four years ago I landed on a desktop that let me keep my tiling but never think about placement. It took a few disconnected days to get it just right, but I haven't changed more than the occasional line in the config since.
I hate thinking about configs now. My config lets me glide through using my computer without much thought, which IMO should be the point of configuring one's setup, so you don't have to think about it. People comment how fun it is to watch me navigate when I'm in a flow(mad at the computer). Sadly, with wayland taking over, my setup isn't long for this earth and I'm dreading the level of effort I'm going to have to put in to get a remotely comparable setup.
The biggest drawback of wayland/hyprland/etc is just how much bullshit one has to wade through for a working desktop. I don't want to learn desktop rendering just to have a dynamic wm that can open a file picker. I rather give an attacker my login creds than drop x11 at this point.
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
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.
I wonder where the people who spend hours and hours making the perfect gaming setup isntead of gaming, or the audiophiles who spend their lives in an eternal quest to get the perfect equipemnt instead of listening to music, end up in this analogy.
I've found that I get more done the less time I'm at the computer. My productivity also went up dramatically when I reduced from three monitors to one.
I solve most of my problems when I'm doing things like chopping vegetables or mowing the lawn. Sitting in the presence of shiny technology does not magically confer one with the ability to achieve higher quality decisions more quickly. I find the opposite to be mostly true. I can massively outperform the development team that my clients have simply because I am not a full time employee and can idle out long enough to think about their problems the slow way. The urgency to keep the status circle green in Teams (and related productivity theater) creates a lot of stupid decisions in many shops.
> I've found that I get more done the less time I'm at the computer.
Right on! For 15 years I worked for two companies that had their offices on the cliffs overlooking the ocean in La Jolla CA. I would spend a lot of time walking along the cliffs or in the park thinking about work, and for serious work discussions I would urge my colleagues to walk with me if we didn’t need a white board.
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 am an old man (mid-70s) and retired now except for personal research and writing, but fifty years in the business taught me to simply pay attention to what people actually get done.
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.
Java is too embedded in massive applications to go away, it'll be the COBOL of 2080s.
But what I'm more interested in is that do companies with no prior Java baggage start greenfield Java projects in 2026? If 90% of your stack is Java and you start a new project, of course you pick it.
But would you do it just based on technical merits?
I would and I’m someone who like C and Common Lisp. The Java ecosystem is full of good solutions, especially for building a web platform. I rather use something reliable than something lean or cool.
I hate Java and would still choose it for all sorts of distributed systems work. It has fantastic tooling and is robust, performant and well understood.
This is the difference between efficiency (that the author is aiming for) and effectiveness (that Bob has – solving the right problem and only that problem). The two are not measured on the same axis: while Bob could have become maybe 20% more efficient with a better setup, and thus increase the delivered value by 20%, the author was already saturated on efficiency, and no amount of better tooling would have made him win the hackathon, because he was throttled at higher levels of abstraction (such as direction, ideas, vision, market insight).
Similarly to how no amount of efficiency gains would make Microsoft produce quality software, because they optimize for other metrics.
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.
You can spend thousands on a carbon fibre hi tech bicycle, or do what the Dutch do and go everywhere in a 50 euros battered thing that may or may not have been metal at some point.
Bonus:
Do you know those people that spend tons on "high end" mountaineering gear and never make it to the peaks?
I 100% agree with this (and remember Bob from my time at Facebook, too!). Picking the right problem matters, but I also think there's an underlying quest for status that leads to a lot of productivity theatre.
People think -- and rightly in some environments -- that being busy will ensure they're valued. There's no better way to keep yourself busy than to insist on a new tool and become responsible for keeping the data in it up to date. Notion used properly can be invaluable but I've advised a couple companies where "tending the Notion garden" became someone's job despite there being no incremental value there.
The solution to the status problem is to focus on outcomes. No one cared that Bob's tool choice might've slowed him down when deciding the winner of the hackathon. And your manager shouldn't care if you use Superhuman and blaze through your mail or print it out and highlight important passages.
If you're working somewhere that gets that right, or close to right, then you can focus on picking productivity tools / approaches that genuinely matter and lead to better outcomes, ideally faster. In the era of agentic AI, there are more of them than ever before, though you have to choose wisely since there are plenty that could win a Tony for productivity theatre.
I think we just get obsessed with optimizing our environment because the link between concentrated effort and reward is very visible, tangible, and physical. But abstract learning? Not so much. If only one could make abstract learning or learning tasks feel more tangible? Especially since they vastly outnumber the number of chair optimization tasks you could do....
You have to make or use just enough productivity tools not to fall behind, but otherwise it's a trap.
I used to check once a quarter. With AI, I devote 1-2 days a week to the meta-task of improving my tooling, but I'm sure that will fade once AI tooling becomes more standardized.
It's not worth being one of those guys who gets too into the tools, because it can keep you from the actual valuable work. Plus, you are then judged not as a regular engineer, but as a person who is supposed to have some secret productivity sauce, and when people see that it doesn't make more of a difference they can start to discount your opinion.
The issue is recognition. Everyone can see and admire shiny tools. Very few people can look at an empty editor or stub and see a good new product/feature. So lots of focus on tools, because lots can see it, and little focus on the what, because it is obscure, difficult to see, etc by most.
I like to marie kondo my tools -- if it is not bringing me joy to use or making my life easier, I yeet it. If it is, it stays.
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.
In 2004 we (a small team of mostly very junior devs) were given a quite extensive and really excellent Java course.
Ahead of the course, we prepared by obsessing over our IntelliJ or Eclipse configs and had intense discussions about this.
To our surprise, the teacher urged us to use nothing but the basic JDK tools and Notepad. He wanted us to learn what's going on under the hood and also told us, that the productivity will probably be about the same.
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.
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 wonder if any old software companies like amazon, microsoft, apple, or google have data on how many prs a software engineer would produce per day over time. I wonder what that major spikes on the graph would be? live reload? vscode? faster and faster laptops? llms?
I have a hunch the amount of prs written per day per engineer is likely the same or only 10-15% higher.
I have that data for my small team starting from the pre-AI baseline, adding Github copilot doubled PRs/dev/day and adding Claude Code multiplied it by five (from baseline)
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?
It’s not really about speed (at least for me). It’s about mental friction. Because you’re fluent in your tooling, you don’t spend time thinking about them.
At the end it is more productive to be focused on the right target, than to gain 15% of productivity because you use whatever tools. Note that this is not mutually exclusive, but putting brain power in thinking about the product, rather than about the productivity hacks, is what matters.
The problem is that most companies don't care about thinking. You may have more chances to get promoted because you are sweating and running everywhere, instead of calmly thinking, looking through the window and developing mental models.
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
In it he talks about how making things easier to do via scripts is a good thing. He even has a system of using `,` as a prefix for all his own scripts just to make them discoverable with ,<TAB> :)
When I was a trainee at university, there was a math professor who worked similarly, with a bare text editor, when writing algorithms for his research. He said he wanted the coding to be slow, so he had time to think the problems through properly. When we automate all the routine away, there's no space for the creative thoughts that we get when our hands are busy.
It applies especially now, in the age of AI agents. When it's so fast to build things, I need to deliberately stop once in a while, and think if it's actually worth it to go down some rabbit hole, or if I should assess what the real problems are.
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.
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 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...
Yes. I wished we recognized more often that hyperproductivity exists for these engineers with different strengths too. It just looks very different than Bob's twenty feature launches per quarter
I agree, Bob is great. I think scaling a concept is also really really important. We need features but we need scalable frameworks and platforms to support these features. Bob's not going to write the distributed db system that makes his feature look good, but that also needs engineering. That too needs to be good enough to ship and no more btw, but it's more often the work of a team that has to slow down and think carefully about what it's doing, especially when evolving long-running platforms
Depends on what you compete on. If you compete on features and oncall is just some contractual obligation, then probably not, if you compete on customer service then perhaps yes
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.
Yes exactly. I'm not sure whether Bob is a hyper productive engineer, but in any case, Bob is an engineer hyper focused at shipping new stuff out the door quickly. Which is great! We need Bobs. But we also need the company to run and scale, and Bob might not just be the right guy for that.
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.
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.
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 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.
1. We had an engineer who worked remote (us in Silicon Valley, him in Central Europe) in the early 2000s. He was - and still is, I'm being vague to protect his privacy - massively productive. He generated reams of high-quality code at a shocking rate, and was an all around star performer: supporting others on the team, fixing bugs, writing docs, super nice guy. We joked that he must have been farming out work to the rest of his town.
We finally get him to visit after a lot of challenges securing a visa, and we are super excited when he shows up in the office. He brings a tiny laptop with a screen half the size of a 13" Macbook Pro and sits down and starts coding away. I can't remember which editor he used - vi(m) or emacs - but someone asks him after an hour what machine he used at home and if he'd like to borrow a larger screen / desktop? He's like, what are you talking about, this is my only computer.
You could hear the crickets as every member of the team has the same thought: if he's that productive on a teeny laptop...
2. Our company did the first Oracle ERP implementation on Linux, which in the early 2000s was a big deal. It was very painful - we had to fix a lot of bugs alongside the team from Oracle at every level of the stack. After many rounds of escalations we told Oracle we needed a lot more horsepower, and they agreed to send their best consultant, pitched like the Harvey Keitel cleaner in Pulp Fiction. The Oracle team in our office held him in awe: "Oh, X is exceptional!"
The guy shows up. Very friendly, soft-spoken, unassuming. I agree to be his handler for the first week. We sit him down at a Windows machine, and I'm like, what do you need? He's like, I just need access to various systems and this stock Windows installation is fine.
He opens Notepad. He can't touch type, he hunts and pecks. I'm thinking: zero percent chance this guy is The Wolf.
I watch him write SQL and PL/SQL, huge queries, with no reference material and no distractions, entirely in Notepad, slowly picking away at the keyboard. I realize: he does not make typos, he does not backtrack. He looks at the problem, thinks for a few minutes, talks to people, thinks a bit more, runs a few exploratory queries, grinds out some code, pastes it in and runs it, on to the next. Obviously not every query ran perfectly, but he did 90% of the work in his brain and and then just played out the tape.
He did more in a few weeks than the rest of the consultants did in six months. I'm not sure he ever touched the delete key, and I'm certain he used nothing but Notepad.
Long story short, you see a few of these people in action, and you stop assuming anything about what great looks like. Never underestimate the people who don't look like you / use a fancy editor / fit the idealized high-productivity image in your head. Judge them by how they treat other humans and what they output.
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.
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
> 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
I think a lot of this comes from beginners skipping some steps because they want to be accepted and taken seriously.
To be, rather than to seem, takes time, and you gotta earn your meals in the interim.
And when you get that new job with that new stack? Switching back to the windows laptop? I learned early on in my career how to live off the land and use the tools I have given to be efficient because it is rare that I get to decide the tooling. Cross platform tools? Usually can get away with them, but beside Jetbrains stuff its all over the place.
Seems like the difference b/w samurai and ninja. The samurai saw his sword as an extension of his soul - a disrespect to the sword was a disrespect to the man. The ninja used the sword like any other tool - and if it was helpful to use it to pry something open, there you go.
the samurai mentality doesn't make sense in today's economy.
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.
This!
Live to work? No!
Work to live? No!
Live and work to Emacs!
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.
I did that same circuit (except it was emacs to VS Code) for me - same experiences and reasons. I also used CLion for a couple of years for C++ - but in that case I never even bothered trying to use anything else. I could not get the bindings quite how I wanted in either VS Code or CLion, but I made it tolerable eventually.
I'm on neovim now, and the reason is coding agents. It ported my Spacemacs bindings to Astrovim in a few minutes.
Any feature I need to add, I just tell it and its done in a couple of minutes. Anytime I run into something that doesn't work quite how I want, I just tell the agent and boom, done.
I manage all my dotfiles this way now I think it totally changes the calculus. I'm even considering giving Nix another go.
This is why I tend to gravitate towards either fully bespoke tools (made by me, for me, nobody else) or tools with sane defaults.
Emacs -> (n)vim -> hx for CLI editor. Helix just works out of the box pretty much, no need for a Doom Helix or Oh-my-Helix to get it comfortable to use.
In terminals I finally ended up on Ghostty, I think the only significant configuration I have is setting `macos-option-as-alt`.
As for shell, fish + starship prompt has been my choice for years now. Very little customisation needed for either.
And for all software I pick the one that stores its configuration in a sane format in a XDG compatible location so I can shove it into chezmoi easily (looking at you iTerm2).
> 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.
I don’t know. I switch back from neovim to vim for some reason, but that vim setup has followed me for years even when I switched to emacs. And while I changed my emacs settings every once in a while, it has always been stable to me.
I’m not questioning your choice, and I do use IDE when the needs arise. But my emacs setup is mostly about dealing with every language and most tech interactions that I need. Not to be a full featured IDE for a language or a project.
I think you forgot to explain the false dichotomy part.
3rd paragraph
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.
Both of you are describing a "waterfall model" of coding, where you conceive of the solution in its entirety before simply writing it down. I don't know if everyone else works this way, but I don't. I prefer to try things in the code and use those attempts to guide and refine my understanding. With the latter approach, being able to quickly and easily modify code is essential because it shortens the testing loop.
Edit: From GP:
> 90% of our time should be spent thinking, and most of that reading.
Reading what though? I assume you mean reading code. If you're reading code, being able to navigate through it quickly is important to maintaining context in your head. If the tool you're using makes navigation hard, it's easy to lose track of what you're doing. Obviously this can be taken to extremes, but spending some time investing in being able to navigate a codebase quickly is not wasted effort.
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.
You are anthropomorphizing LLMs. They are just tools and cant build anything. He is responsible for the code, he built it.
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.
> And yes, messing about with skills is the new messing around with setup.
I’ve been watching this play out at work. The people messing about with skills are invariably the people who have least impact on the actual shipping product. I suspect they hope that somehow, they’re going to hit on the magic formula that makes them productive.
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.
Paul Graham writes about this in an essay on procrastination.
Procrastination doesn't have to mean time on the couch, the person that keeps their house 'unreasonably tidy' is also procrastinating, albeit in their own special way, with feather duster and bleach. Yet they feel productive, plus there is that 'cleanliness is next to godliness' feeling after everything is spotless.
We have to guard against this with our coding setup, for example, I know people that have organised folders for their outbox emails. Management were impressed, however, I was quietly grumbling that real work needed to be done. Hence I search rather than organise email, to rarely impress management.
I like the 'contractor's desk' where there is just the laptop with no personal items, with the laptop having the default interface, wallpaper and terminal windows.
> 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.
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.
90% of our time should be spent waiting for Claude to ask permission for something then!
Or waiting for your limits to reset ...
Or waiting for Claude's outages to clear up.
> 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.
> 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.
Yea, I get the empty page curse if I just think and think about something.
Scaffolding a shitty solution end to end lets me see the whole path and gives me something to ground my thinking with.
It's easier to polish a turd than to make a diamond out of nothing. =)
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
> 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
Occasionally it spills out to the codebase with the phenomenon of the Senior Linter Developer.
> 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 our time should be spent thinking, and most of that reading.
Three or four years ago I landed on a desktop that let me keep my tiling but never think about placement. It took a few disconnected days to get it just right, but I haven't changed more than the occasional line in the config since.
I hate thinking about configs now. My config lets me glide through using my computer without much thought, which IMO should be the point of configuring one's setup, so you don't have to think about it. People comment how fun it is to watch me navigate when I'm in a flow(mad at the computer). Sadly, with wayland taking over, my setup isn't long for this earth and I'm dreading the level of effort I'm going to have to put in to get a remotely comparable setup.
The biggest drawback of wayland/hyprland/etc is just how much bullshit one has to wade through for a working desktop. I don't want to learn desktop rendering just to have a dynamic wm that can open a file picker. I rather give an attacker my login creds than drop x11 at this point.
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
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.
Game developers put tons of effort into tooling, just not especially into text editors.
Not sure it’s a bubble so much as a story as old as time… signal hacking. Always has happened and always will
I wonder where the people who spend hours and hours making the perfect gaming setup isntead of gaming, or the audiophiles who spend their lives in an eternal quest to get the perfect equipemnt instead of listening to music, end up in this analogy.
I've found that I get more done the less time I'm at the computer. My productivity also went up dramatically when I reduced from three monitors to one.
I solve most of my problems when I'm doing things like chopping vegetables or mowing the lawn. Sitting in the presence of shiny technology does not magically confer one with the ability to achieve higher quality decisions more quickly. I find the opposite to be mostly true. I can massively outperform the development team that my clients have simply because I am not a full time employee and can idle out long enough to think about their problems the slow way. The urgency to keep the status circle green in Teams (and related productivity theater) creates a lot of stupid decisions in many shops.
> I've found that I get more done the less time I'm at the computer.
Right on! For 15 years I worked for two companies that had their offices on the cliffs overlooking the ocean in La Jolla CA. I would spend a lot of time walking along the cliffs or in the park thinking about work, and for serious work discussions I would urge my colleagues to walk with me if we didn’t need a white board.
Listen to Rich Hickey’s ‘hammock talk’ again…
Given your username, are you the Bob from the article?
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.
It's not about productivity, it's about having fun with your toys.
https://strangestloop.io/essays/things-that-arent-doing-the-...
Comes to mind.
Very good, pairs well with the linked article.
I am an old man (mid-70s) and retired now except for personal research and writing, but fifty years in the business taught me to simply pay attention to what people actually get done.
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.
Java is too embedded in massive applications to go away, it'll be the COBOL of 2080s.
But what I'm more interested in is that do companies with no prior Java baggage start greenfield Java projects in 2026? If 90% of your stack is Java and you start a new project, of course you pick it.
But would you do it just based on technical merits?
I would and I’m someone who like C and Common Lisp. The Java ecosystem is full of good solutions, especially for building a web platform. I rather use something reliable than something lean or cool.
I hate Java and would still choose it for all sorts of distributed systems work. It has fantastic tooling and is robust, performant and well understood.
I think most professionals are conservative when it comes to their tools. Mastering them took a long time and it's hard to change.
CS6 was peak, everything we needed, nothing we didn't. That's pretty much what photopea is, with improvements, which supports this view.
This is the difference between efficiency (that the author is aiming for) and effectiveness (that Bob has – solving the right problem and only that problem). The two are not measured on the same axis: while Bob could have become maybe 20% more efficient with a better setup, and thus increase the delivered value by 20%, the author was already saturated on efficiency, and no amount of better tooling would have made him win the hackathon, because he was throttled at higher levels of abstraction (such as direction, ideas, vision, market insight).
Similarly to how no amount of efficiency gains would make Microsoft produce quality software, because they optimize for other metrics.
me looking at my brand new mechanical keyboard ssshhh... it's OK, it's not about us.
For the most curious the kbd https://mastodon.pirateparty.be/@utopiah/117008257708036677
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.
More of that:
You can spend thousands on a carbon fibre hi tech bicycle, or do what the Dutch do and go everywhere in a 50 euros battered thing that may or may not have been metal at some point.
Bonus:
Do you know those people that spend tons on "high end" mountaineering gear and never make it to the peaks?
I 100% agree with this (and remember Bob from my time at Facebook, too!). Picking the right problem matters, but I also think there's an underlying quest for status that leads to a lot of productivity theatre.
People think -- and rightly in some environments -- that being busy will ensure they're valued. There's no better way to keep yourself busy than to insist on a new tool and become responsible for keeping the data in it up to date. Notion used properly can be invaluable but I've advised a couple companies where "tending the Notion garden" became someone's job despite there being no incremental value there.
The solution to the status problem is to focus on outcomes. No one cared that Bob's tool choice might've slowed him down when deciding the winner of the hackathon. And your manager shouldn't care if you use Superhuman and blaze through your mail or print it out and highlight important passages.
If you're working somewhere that gets that right, or close to right, then you can focus on picking productivity tools / approaches that genuinely matter and lead to better outcomes, ideally faster. In the era of agentic AI, there are more of them than ever before, though you have to choose wisely since there are plenty that could win a Tony for productivity theatre.
I think we just get obsessed with optimizing our environment because the link between concentrated effort and reward is very visible, tangible, and physical. But abstract learning? Not so much. If only one could make abstract learning or learning tasks feel more tangible? Especially since they vastly outnumber the number of chair optimization tasks you could do....
You have to make or use just enough productivity tools not to fall behind, but otherwise it's a trap.
I used to check once a quarter. With AI, I devote 1-2 days a week to the meta-task of improving my tooling, but I'm sure that will fade once AI tooling becomes more standardized.
It's not worth being one of those guys who gets too into the tools, because it can keep you from the actual valuable work. Plus, you are then judged not as a regular engineer, but as a person who is supposed to have some secret productivity sauce, and when people see that it doesn't make more of a difference they can start to discount your opinion.
Writing code has never been the hard part.
Writing code has never been the hard part.
Not for Bob, not for you.
The issue is recognition. Everyone can see and admire shiny tools. Very few people can look at an empty editor or stub and see a good new product/feature. So lots of focus on tools, because lots can see it, and little focus on the what, because it is obscure, difficult to see, etc by most.
I like to marie kondo my tools -- if it is not bringing me joy to use or making my life easier, I yeet it. If it is, it stays.
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.
In 2004 we (a small team of mostly very junior devs) were given a quite extensive and really excellent Java course.
Ahead of the course, we prepared by obsessing over our IntelliJ or Eclipse configs and had intense discussions about this.
To our surprise, the teacher urged us to use nothing but the basic JDK tools and Notepad. He wanted us to learn what's going on under the hood and also told us, that the productivity will probably be about the same.
Those features are the only I find useful in facebook, fb marketplace and local groups for buying or selling stuffs or services.
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.
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.
I wonder if any old software companies like amazon, microsoft, apple, or google have data on how many prs a software engineer would produce per day over time. I wonder what that major spikes on the graph would be? live reload? vscode? faster and faster laptops? llms?
I have a hunch the amount of prs written per day per engineer is likely the same or only 10-15% higher.
I have that data for my small team starting from the pre-AI baseline, adding Github copilot doubled PRs/dev/day and adding Claude Code multiplied it by five (from baseline)
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?
It’s not really about speed (at least for me). It’s about mental friction. Because you’re fluent in your tooling, you don’t spend time thinking about them.
100% with the OP:
At the end it is more productive to be focused on the right target, than to gain 15% of productivity because you use whatever tools. Note that this is not mutually exclusive, but putting brain power in thinking about the product, rather than about the productivity hacks, is what matters.
The problem is that most companies don't care about thinking. You may have more chances to get promoted because you are sweating and running everywhere, instead of calmly thinking, looking through the window and developing mental models.
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
I literally just closed a tab from a talk by Brandon Rhodes about Activation Energy: https://www.youtube.com/watch?v=pybtvFFRYFs
In it he talks about how making things easier to do via scripts is a good thing. He even has a system of using `,` as a prefix for all his own scripts just to make them discoverable with ,<TAB> :)
When I was a trainee at university, there was a math professor who worked similarly, with a bare text editor, when writing algorithms for his research. He said he wanted the coding to be slow, so he had time to think the problems through properly. When we automate all the routine away, there's no space for the creative thoughts that we get when our hands are busy.
It applies especially now, in the age of AI agents. When it's so fast to build things, I need to deliberately stop once in a while, and think if it's actually worth it to go down some rabbit hole, or if I should assess what the real problems are.
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.
Being busy is easy to measure; meaningful progress is not, which is why productivity often becomes performance rather than real output.
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.
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 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.
Yes. I wished we recognized more often that hyperproductivity exists for these engineers with different strengths too. It just looks very different than Bob's twenty feature launches per quarter
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.
I agree, Bob is great. I think scaling a concept is also really really important. We need features but we need scalable frameworks and platforms to support these features. Bob's not going to write the distributed db system that makes his feature look good, but that also needs engineering. That too needs to be good enough to ship and no more btw, but it's more often the work of a team that has to slow down and think carefully about what it's doing, especially when evolving long-running platforms
Do you even want your best and most prolific engineers wasting their energy on on-call duties?
Depends on what you compete on. If you compete on features and oncall is just some contractual obligation, then probably not, if you compete on customer service then perhaps yes
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.
Yes exactly. I'm not sure whether Bob is a hyper productive engineer, but in any case, Bob is an engineer hyper focused at shipping new stuff out the door quickly. Which is great! We need Bobs. But we also need the company to run and scale, and Bob might not just be the right guy for that.
Systems thinking wins again
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...
Sublime Text, that's all I've needed for more than a decade. DeepSeek, my new sidekick for the next.
Many comments were created by AI? Waste much time on them.
The main idea of the article is not clear, and the structure of it is not good to read
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.
My dad uses to this day a borland compiler and IDE to compile his C++ program.
No syntax highlighting at all.
And it is a commercial product, I'm not talking about a pet project or hobby.
It amazes me, really.
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.
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.
Ah the good old “he works differently thus he is wrong” fallacy. The best developers I know use a terminal and that’s it.
spent more time configuring my note-taking system than writing anything worth noting
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 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.
Replies here start to sound more and more like on Linkedin.
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.)
"story when browsing X. Every day"
I think thats exactly the problem
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
In other words careful not to spend all your time cargo cutting without realizing that you're not building substance
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.
Two stories:
1. We had an engineer who worked remote (us in Silicon Valley, him in Central Europe) in the early 2000s. He was - and still is, I'm being vague to protect his privacy - massively productive. He generated reams of high-quality code at a shocking rate, and was an all around star performer: supporting others on the team, fixing bugs, writing docs, super nice guy. We joked that he must have been farming out work to the rest of his town.
We finally get him to visit after a lot of challenges securing a visa, and we are super excited when he shows up in the office. He brings a tiny laptop with a screen half the size of a 13" Macbook Pro and sits down and starts coding away. I can't remember which editor he used - vi(m) or emacs - but someone asks him after an hour what machine he used at home and if he'd like to borrow a larger screen / desktop? He's like, what are you talking about, this is my only computer.
You could hear the crickets as every member of the team has the same thought: if he's that productive on a teeny laptop...
2. Our company did the first Oracle ERP implementation on Linux, which in the early 2000s was a big deal. It was very painful - we had to fix a lot of bugs alongside the team from Oracle at every level of the stack. After many rounds of escalations we told Oracle we needed a lot more horsepower, and they agreed to send their best consultant, pitched like the Harvey Keitel cleaner in Pulp Fiction. The Oracle team in our office held him in awe: "Oh, X is exceptional!"
The guy shows up. Very friendly, soft-spoken, unassuming. I agree to be his handler for the first week. We sit him down at a Windows machine, and I'm like, what do you need? He's like, I just need access to various systems and this stock Windows installation is fine.
He opens Notepad. He can't touch type, he hunts and pecks. I'm thinking: zero percent chance this guy is The Wolf.
I watch him write SQL and PL/SQL, huge queries, with no reference material and no distractions, entirely in Notepad, slowly picking away at the keyboard. I realize: he does not make typos, he does not backtrack. He looks at the problem, thinks for a few minutes, talks to people, thinks a bit more, runs a few exploratory queries, grinds out some code, pastes it in and runs it, on to the next. Obviously not every query ran perfectly, but he did 90% of the work in his brain and and then just played out the tape.
He did more in a few weeks than the rest of the consultants did in six months. I'm not sure he ever touched the delete key, and I'm certain he used nothing but Notepad.
Long story short, you see a few of these people in action, and you stop assuming anything about what great looks like. Never underestimate the people who don't look like you / use a fancy editor / fit the idealized high-productivity image in your head. Judge them by how they treat other humans and what they output.
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