This is a nice setup. It's got tmux and fzf and rg and zoxide and clean-looking nvim. I'd recommend atuin, starship, bat, glow, duf, dogdns, viddy, gum/sesh, dust, btop et all if you don't have them, there's a long tail. The Awesome Terminal XYZ lists on Github have them all.
atuin is make-or-break, its a bigger deal than zoxide and being a coder without zoxide is like being an athlete with shoes for a different sport.
asciinema is a better way to do terminal videos.
Its weird that this is weird now: having your tools wired in used to be called "being a programmer". VSCode and Zed and Cursor and shit are useful additions to the toolbox, you gotta know that stuff by heart now too and you have to know which LLM to use for what, but these things are the new minimum, they aren't a replacement for anything. Even with Claude Code running hot at 4am when the PID controller is wide open, sometimes its going to trash your tree (and if it doesnt youve got it on too short a leash to be faster than gptel) and without magit? gl.
If you think you're faster than OP with stock Cursor? Get them to make a video of how to use an LLM with chops.
Being a programmer is not about configuring your development environment. It never has been. I know a relatively accomplished programmer whose preferred development environment is Unix with the ex editor, and plenty of beginners whose whizbang IDEs completely fail to compensate for their lack of understanding.
That's not to say that tooling doesn't matter at all. Just that, historically, it's been a relatively minor factor. Maybe LLMs have changed that, or are about to.
An athlete with shoes for a different sport might run 5% slower. In a winner-takes-all competitive environment, that's fatal; a sprinter that ran 5% slower than the gold medalist is just another loser. Most programmers, however, win by collaboration, and on a relatively smooth fitness landscape, not a winner-takes-all spike. Even in winner-takes-all regions like startups, failure always results from bigger errors. I think nobody has ever said, "My startup would have succeeded if we'd used Dvorak keyboards instead of QWERTY", or vim instead of VSCode, or vice versa. It's always things like feuding cofounders, loss of motivation, never finding product-market fit, etc.
> Being a programmer is not about configuring your development environment.
You sure? Programming is an act of creation. Any [good] creative worker - artists, sculptors,
novelists, potters, bakers, et al. would agree that being an artist means finding joy in refining your technique, investing in your tools, searching for new recipes, and experimenting. Being a programmer is not about achieving better productivity percentages. As far as I know, most of the best-known programmers have never participated in competitive programming challenges. Tooling may not matter to building a product, yet the product is built by programmers, and tooling is very much everything to them. Good programmers do invest in their tooling, not because it's a universal rule they have to follow or because it gives them a competitive edge. They do it simply because they enjoy the process.
Though it's challenging to determine whether someone who loves exploring and refining their tools will excel in a specific team, one truth remains: those who don't engage with their tools likely aren't strong programmers, as they most likely fundamentally lack passion for programming itself.
That's kind of a weird point to make. I don't see why it would be a universal truth that a good programmer is someone who invests in their tools.
I could just as easily say that good programmers are the ones who don't have sophisticated tooling setups because it means that they spend more time programming.
I'm inclined to agree with other comments that the baseline for productivity is probably lower than we think. It's fine to enjoy the process of making a perfect setup, but I don't see it as a prerequisite or strong indicator for being a strong programmer.
> I don't see why it would be a universal truth that a good programmer is someone who invests in their tools.
I have never said that. However, since you decided to go that direction. I can bite and entertain you. Here is a list of programmers, some of them I'm sure you'd even recognize. Donald Knuth, Rob Pike, Ken Thompson, Steve Yegge, Gary Bernhardt, Paul Graham, Rich Hickey, Bram Moolenaar, Richard Stallman, Anders Hejlsberg, Guido van Rossum, John Carmack, Tim Pope, Drew Neil, Sindre Sorhus, TJ Holowaychuk, Guillermo Rauch, Ryan Dahl, Fabrice Bellard.
The pattern is clear: many of the best programmers are also prolific tool-builders.
I don't even understand what point you are making. The essence of programming is tool making. Of course the best programmers make tools as do the worst. Are you seriously comparing making a terminal hot rod configuration app to, say, creating Tex?
> Being a programmer is not about configuring your development environment.
My point is that being a programmer is also about configuring one's development environment. Exactly because like you said: "the essence of programming is tool making". I just don't understand how it is different - configuring a tool, extending its functionality, adding more features to it from developing a [different] tool from scratch? Both is programming. Shit done by programmers. You don't call one bunch "pseudo-programmers" and the other "alpha-programmers" or some shit like that, right?
Then I misunderstood your comment. I read it as "not invested in their tools => not a good programmer."
Reading the replies to my sibling comments, I don't think we really disagree but we probably have different pictures in our heads when reading the context of this thread.
> You sure? Programming is an act of creation. Any [good] creative worker - artists, sculptors, novelists, potters, bakers, et al. would agree...
Yes, I'm sure. Being a painter is not about decorating your studio and choosing paints and paintbrushes. Being a sculptor is not about using the best chisels and rasps. Being a novelist is not about configuring your word processor. Being a potter is not about the selection of clay bodies and kiln accessories in your workshop. Being a baker is not about where you place your oven or what brand of mixing bowls you use.
It's surely true that any accomplished potter will have enough opinions about clay bodies, glazes, wheels, scrapers, and other tools to talk about all afternoon. But that's not what being a potter is about. 99% of potters have never made anything as beautiful or as useful as many of the pots that María Poveka Montoya Martínez coil-built from clay she dug up near her house and pit-fired with dried cow manure. She engaged with her tools, and I bet she would have yelled at you if you left one of them in the wrong place, but she wasn't defined by them.
I see what you're saying, sure, it's an good point about craft and creativity. The essence of any art or craft lies in the actual doing - in the painting, sculpting, writing, throwing pots, or baking bread - not in endlessly optimizing the tools or workspace. It's easy to get caught up in perfecting the setup as a form of procrastination or because it feels safer than actually creating. The real work happens when you pick up the brush, the chisel, the pen, or get your hands in the clay or dough. The tools matter far less than the practice itself.
But, at the same time, sometimes, and quite often, working on tools IS the craft itself.
Building, configuring and improving programming tools is literally programming - you're writing code, solving problems, thinking about abstractions and interfaces. Every script you write, every editor configuration you tweak, every workflow you automate exercises the same skills you use in your "real" work. Understanding how tools work (and building your own) deepens your understanding of systems, APIs, and software design.
So, in essence, working on your tooling could actually make a better programmer out of you. In fact, many great, well-known programmers do actively work and maintain their tools.
Not in enterprise consulting, there is very little room for creation on the software sausage factory, it is all about social skills, and outputing something that mostly works within the project budget.
The craftmanship is better left for small businesses, or FAANGS with engineers playgrounds.
Meh. You can spend hundreds of hours honing your programming environment to get a slight edge on others, or you can learn a few basic (or not so basic) soft skills and blow most other engineers out of the water because they’re all obsessed with tech and don’t realise it’s not their bottleneck
I'm sure you're not talking "soft skills vs. tools", that's a false dichotomy trap - great programmers often excel at both, and tooling mastery can itself develop problem-solving skills that transfer elsewhere.
We are in a better world today specifically because of legendary programmers who invested heavily in tooling, and even created their own from scratch. Prof. Knuth spent decades perfecting typesetting, made TeX/LaTeX, METAFONT, and literate programming tools. Linus built Git and maintains his own terminal emulator and scuba diving log app among many other things. Ken Thompson is famous for building tools to build tools. Rob Pike created text editors, window systems and numerous Unix tools. Carmack built custom level editors and dev tools for each game engine he created, he is known for obsessing over development workflows.
Can you name one person who "blows most other engineers out of the water" while not "being obsessed with tech", using nothing but "the soft skills"?
I dunno about you, I, as a software developer, rather want to be like these guys, and I think any aspiring software dev would. I spent my last weekend figuring out my new WM. Not because I had to, forced to do it, offered money for it, or because I perceive it as my "bottleneck". I don't fetishize over my tools to "get a slight edge". I do it purely out of enjoyment for the process, nothing else.
And I have watched many of my peers going through their career ladders. Sure, many of them might be perceived as more successful because while I was busy "sharpening my sword," they went into "the real world" and "touched grass" and "talked to people." Most of those are no longer doing engineering. If the goal is to "grow out" of being a software engineer, sure, then focus on the tooling might be overrated. That's not for me though; I'm happy where I am.
These famous people you cite are famous because they are "devs for devs". These guys were working on a _product_ (be it LaTex, games, text editors...) for which the user happened to be developers: by improving devx a little they had a lot of impact. That has little to do devs with individually spending a lot of time on their own tooling (for whom improving their devx a little has a little impact).
> Can you name one person who "blows most other engineers out of the water" while not "being obsessed with tech", using nothing but "the soft skills"?
The best engineers I've worked with were comfortable with their tools (of course, that's a requirement) but wouldn't be spending much time on incremental improvements. They'd spend time talking to customers, to PMs, to support, to leadership, learning about their domain and about how other engineers in the industry approached it. They _would_ spend time investing in tools that might be a game-changer (10x or whatever), but not things like vim configs and keyboards.
It always comes down to the same thing: you can have the best tech skills and tooling, yet a (decent) engineer who understand the domain and can communicate effectively will build a better product than you. That's hardly controversial.
> That's not for me though; I'm happy where I am.
I don't agree that it's a question of "growing out of engineering" at all (in fact I'd say it's "growing into" engineering from programming), but at the end of the day I'd totally agree that you should do what makes you happy! If you enjoy what you do and don't want to be doing the other stuff, who cares, I certainly won't be the one to tell you to change your ways!
> The best engineers I've worked with were comfortable with their tools (of course, that's a requirement)
Yeah, that's all what I'm saying.
> but wouldn't be spending much time on incremental improvements.
What is "an incremental improvement"?
My tools change depending on the work I do, and it so happens, the type of tasks I do sometimes change. When I say "working on tools," to me it's like knife sharpening. Sure, it's not impossible to cook with a dull knife, but it's helluva uncomfortable; why just not sharpen it? For me, it's like a chore I can't avoid, the only choice I can make is how to respond to it - and I choose to enjoy it. It takes less than two minutes to sharpen my knife - I have an electric sharpener. It's not tiny, but small enough so I can hold it in my hand, and it's not expensive. I also have regular sharpening stones. That process takes longer. I think I enjoy it, why not; it feels like meditation. But I don't do it every day, or even every week. I think I like how knives feel after.
So basically, I don't even understand what we are arguing about. Some engineers like extending the tools they use. Some, maybe not so much. Some spend a good amount of time doing that. They do it because they love it, and there are mostly benefits.
Some don't sharpen their knives at all - they simply throw them away and buy new set - I just don't know anyone like that in my circles. And similarly, I have never met engineers who never cared about improving their tooling even a little bit.
At the end of the day, we can probably all agree that doing the work without nicely "sharpened" tools is like cooking with a dull knife - it's not impossible; it's just why would anyone do this to themselves? It sounds anguishing.
>Being a programmer is not about configuring your development environment.
I know what OP is referring to. Back in the day, a programmer was expected to have built their own toolbox of utility scripts, programs and configurations that would travel with them as they moved from project to project or company to company. This is akin a professional (craftsman, photographer, chef, electrician, etc.) bringing their own tools to a jobsite.
Sure, I have ~/bin and a .emacs.d that I've been working on since last millennium, and various other tools I've written that I use regularly. It's certainly a handicap to work in an environment that's unfamiliar, especially for the first day or two. And sometimes spending five minutes automating something can save you five minutes a day. Making grep output clickable like in Emacs, as demonstrated here, is a good example of that.
But, on the other hand, time spent on sharpening your tools is time not spent using them, or learning how to use them, and the sharpest tools won't cut in the hands of the dullest apprentice. And sometimes spending five hours automating something will save you five seconds a week. All the work I spent customizing window manager settings in the 90s, or improving my Perl development experience early this millennium, produced stuff I don't use now—except for the skills.
> All the work I spent customizing window manager settings in the 90s, or improving my Perl development experience early this millennium, produced stuff I don't use now—except for the skills.
If you enjoyed the process it was time well spent.
I find this line of argument really weird. Obviously mastering his tools is only one of many things required of a master craftsman, but the relentless pursuit of excellence in all dimensions of ones craft is the minimum possible criteria for ever attaining it, almost tautologically.
It's like when people complain that leetcode is nothing like the job: yeah, it's a pretty bad test, but you're making a bad argument about that because CS knowledge is extremely relevant to the job, unless the job is assembly-line library composition.
I've consulted for companies that had all their dev boxes on coder or something, and you get really good at vscode really fast or you don't have much luck. It's more than 5%, but even stipulating that it's 5%, whoa, 5 percent?! By installing a bunch of stuff off a list on GitHub and dropping some aliases in your bashrc or zshrc? in a few weeks you're five percent more effective? Anyone in any field from banking to bioinformatics would think you were joking or a scam artist if you offered them 5% more efficient outcomes at that price.
Regarding OG editors like ed and ex and sam and stuff? I can absolutely believe that someone with a lifetime mastery of one of those tools could smoke a VSCode user, it's not at all obvious that VSCode is an upgrade to vim/etc. along any dimension other than low barrier to entry. ditto emacs which is about 1000x more powerful than vscode and the difference in library/extension ecosystem is not measured by size: the emacs one is identical to the vscode one with bottom 90% by quality sliced off the vscode one.
And this stuff compounds, you get a bit better at the tools and you can read more code faster, read the right code faster, start moving the derivative of the derivative.
It's also extremely non-obvious that collaboration at the kinds of scales and complexities that make exceptional skills or experience in it a top 3-5 core competency for people doing most software. Study after study going back to Fred Brooks and the Mythical Man Month have demonstrated that relatively small teams of people who get along very well coordinated by a relatively small number of highly technical managers who take the offload on the high-complexity cross-org collaboration is the golden ticket. It's the same reason computers have dedicated routing tables in the NIC and that those things talk to even bigger and more specialized machines that do all routing all day: you don't want to scale O(n^M) with the communication overhead.
A hacker needs to work really well with their immediate team, and have a good dialog with a manager who is both technical (to understand the work) and who devotes a lot of energy to complex collaboration.
> I can absolutely believe that someone with a lifetime mastery of one of those tools could smoke a VSCode user
> And this stuff compounds, you get a bit better at the tools and you can read more code faster, read the right code faster, start moving the derivative of the derivative.
I think you're overestimating how much tool choice impacts developer productivity.
Yes, using good tools is important. Being comfortable with and knowing your way around your toolset will make your life easier. But it won't make you a better programmer. It won't "smoke" anyone else. It's not a competition.
The time we spend reading and writing code is relatively minor compared to the time we spend thinking, designing, communicating, and collaborating with others. Reading and writing code is not the productivity bottleneck. It's understanding what you're reading, making a mental model of the system, and thinking about how to translate your thoughts into working code. The mechanical aspects of it are relatively insignificant. Especially nowadays when we have LLMs to automate those mechanical parts, for better or worse.
If the time a programmer spends collaborating is more than the time they spend reading and writing code, they are optimizing for something other than software outcomes. And I appreciate that this is one of the lowest points for employment and advancement on the basis of demonstrated merit in the history of the business, maybe that's a smart play for people with certain priorities.
Not my cup of tea. I'm trying to become the absolute best I can be every single day at the absolute limit of my abilities and hopefully just a little bit past them as measured yesterday. I think competence as criteria is going to make a big comeback fairly soon.
the activities with the highest ROI for me has been into better navigation and searching, then executing some commands on the result. The gap from thinking about doing something to having the thing done has been reduced greatly.
Few hours later, 2 of these tools are in the front page of hackernews. So it's not that absurd! Sometimes you can just reference stuff here in the comments in order to summon them.
Nice list of commands. I would add fd (author: sharkdp) to the list. It’s a find replacement, and it has great ergonomics. Also, atuin is probably the single biggest upgrade to my cli. It helps me dig up esoteric incantations that I ran six months ago with ease.
A good dev can produce excellent results rapidly in an entirely "naked" environment. Sure, good tools might help, but you're looking at improvements in the margins - and a lot of this is about your personal joy, not productivity.
If the rate at which you generate value is noticeably gated by which IDE you use... well, you've got a long and exciting journey ahead of you. It's going to be fun, and I don't mean that facetiously.
"knowing your tools" was never called "being a programmer". Best devs I've ever worked with all did absolutely amazing work with more/grep/vi and a lot of thinking. And the thinking is where the value was created. That's still true, even if you throw an LLM into the mix.
I completely agree that being comfortable with basic tools is critical to a versatile software professional because you're routinely in situations where you don't have your kit with you, for every tool on that list there is a GNU userland equivalent that's had basically the same core behavior since the 90s and I switched from DOS and Windows to Linux and GNU, and I am routinely glad that I know how to write useful `find` and `awk` and all that because I'm trying to get some box brought up.
I'm not knocking the classic tooling, it was designed by geniuses who obsessed about tools and tools that build tools (everyone from Ken Thompson to John Carmack are on the record about the importance of tooling).
It's the stock VSCode and Cursor people with an extension or two that are accepting a totally voluntary handicap. Someone in the thread called me a "shell bro", and I mean, that's just asking to get rocked if it's ever on the line against someone serious.
atuin is make-or-break, its a bigger deal than zoxide and being a coder without zoxide is like being an athlete with shoes for a different sport.
asciinema is a better way to do terminal videos.
Its weird that this is weird now: having your tools wired in used to be called "being a programmer". VSCode and Zed and Cursor and shit are useful additions to the toolbox, you gotta know that stuff by heart now too and you have to know which LLM to use for what, but these things are the new minimum, they aren't a replacement for anything. Even with Claude Code running hot at 4am when the PID controller is wide open, sometimes its going to trash your tree (and if it doesnt youve got it on too short a leash to be faster than gptel) and without magit? gl.
If you think you're faster than OP with stock Cursor? Get them to make a video of how to use an LLM with chops.