←back to thread

How I use my terminal

(jyn.dev)
538 points todsacerdoti | 3 comments | 23 Jun 25 15:14 UTC | HN request time: 0s | source
Show context
benreesman ◴[23 Jun 25 18:51 UTC] No.44358830[source]▶
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.

replies(4): >>44359187 #>>44359220 #>>44360720 #>>44361128 #
kragen ◴[23 Jun 25 19:29 UTC] No.44359187[source]▶
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.

replies(6): >>44359633 #>>44359847 #>>44360078 #>>44360254 #>>44360492 #>>44360591 #
iLemming ◴[23 Jun 25 21:46 UTC] No.44360492[source]▶
> 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.

replies(4): >>44360608 #>>44360963 #>>44360982 #>>44364257 #
williamdclt ◴[23 Jun 25 21:59 UTC] No.44360608[source]▶
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
replies(1): >>44360973 #
1. iLemming ◴[23 Jun 25 22:46 UTC] No.44360973{3}[source]▶
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.

replies(1): >>44365909 #
2. williamdclt ◴[24 Jun 25 13:15 UTC] No.44365909[source]▶
I don't agree at all with your assessment.

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!

replies(1): >>44373901 #
3. iLemming ◴[25 Jun 25 05:29 UTC] No.44373901[source]▶
> 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.