←back to thread

How I use my terminal

(jyn.dev)
538 points todsacerdoti | 2 comments | 23 Jun 25 15:14 UTC | HN request time: 0.472s | 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 #
macspoofing ◴[23 Jun 25 21:57 UTC] No.44360591[source]▶
>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.

replies(1): >>44361033 #
1. kragen ◴[23 Jun 25 22:54 UTC] No.44361033[source]▶
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.

replies(1): >>44363572 #
2. pantulis ◴[24 Jun 25 07:05 UTC] No.44363572[source]▶
> 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.