Live data from Hacker News

Small programming tricks

will-keleher.com

101–110 of 192 posts

Re: Small programming tricks

#101

The most useful shell trick I've used to date is mapping the 'cd' command to 'zoxide', which is a more powerful version of cd that remembers folders you've been to.

I go a step further. When I press Alt + j, it sends all the directories in zoxide to fzf (in order of frequency), and I quickly choose the directory and jump to it.

I rarely type "cd" anymore. A huge quality of life improvement!

Re: Small programming tricks

#102

I find myself using ctrl-r less and less as I make sure that anything of value that I work out goes into a Makefile or the app tooling, for me this is the basis of the dev-ops approach to work (make sure everything is scripted, not worked out on the fly).

Yes, but how do I know what should go in the justfile? When I've realized I've used Ctrl-r for the same thing a few times :-)

And as another commenter said, you often forget the target, and use Ctrl-r to find it. Although just does support fzf...

Re: Small programming tricks

#103

Earlier quoted context omitted.

I think that "everyday" would be a stretch, but i dont understand why youd think thats annoying, someone took the time to consider helping the rest of the engineering team grow, by posting something useful. I frequently do the same, but not everyday; only when i think its something actually useful/helpful beyond the everyday crap. Most recently, we have had a huge push to use ai (just like everywhere else), ive been…

I think there's a fine line between helping your team grow and the sorta annoying self promotion I've seen people do in overly broad slack channels. One is actually helping and the other is making yourself more visible to mgmt for promotions.

We work in very different places. Wherever I've worked, the guy who knows all these tricks is not the guy getting promoted. Senior management doesn't care about your shell or scripting skills. Sure - they make you more productive, but at a very local level (may be good for a single promotion early in your career).

Most senior engineers I've worked with have forgotten all these tricks, and they actively tell you that while you should try to get better at these things, career gains lie elsewhere. Focus on things with higher impact.

Re: Small programming tricks

#104
I keep a ~/scratch.txt file and a bash alias "scratch" that will just grep it. Then I put a lot of relatively infrequently-used but often-forgetten command recipes in there, so that I can just do "scratch keygen" or whatever and it will find it. It persists longer than bash history.

If anything, I wish I had paid a lot more attention to this in the early days and made a nicer shell environment full of my own utilities, as I felt my skills just kind of slowly erode over the years with each migration. Make a nice little nest for yourself and curate those tools as your own (text) UI.

Re: Small programming tricks

#105

Earlier quoted context omitted.

I think that "everyday" would be a stretch, but i dont understand why youd think thats annoying, someone took the time to consider helping the rest of the engineering team grow, by posting something useful. I frequently do the same, but not everyday; only when i think its something actually useful/helpful beyond the everyday crap. Most recently, we have had a huge push to use ai (just like everywhere else), ive been…

Why just one each day then? Why not a shared knowledge base? Do you start with a "bag of tricks" and then hand them out one by one each day to remind people you're the guy with the bag of tricks? "Oh, yeah, I know a cool trick, but y'all have to wait until tomorrow to find out what it is." "Look! It's a way to evaluate SQL expressions with a select with a from! Oh, you already knew about it?" I have nothing against s…

I don't think that's a generous way to interpret it.

I see it more as: every day they will go on the slack channel and pause, wondering "Is there a neat trick I've learned or used recently?" then they share it. It's like a ritual to remember that you can share things because it's easy to forget other people don't work the same way you do. Writing it all at once is difficult (you have to remember a lot of stuff at once) and it tends to go unread.

I also think every single day is a stretch, but it's nice to pause once in a while to think about how you could help other people with something you've learned.

Re: Small programming tricks

#106
post #65

Earlier quoted context omitted.

Please take this in good faith, as I hope your own post is, but I interpret the thread you're replying to as focusing on the "everyday' part. Share knowledge? I don't think anyone here is arguing against that in any way (or conversely arguing for hoarding knowledge). The concern, one I share, is where the sharing has to happen publicly "every day" - so no matter how trivial, useless, niche, overly-specific the tip is…

Yep, crop dusting knowledge in a public space without at least tying it to something relevant is a faux pas in my book. Offering to teach someone something proactively? Sure, go ahead. Sharing stuff freely when asked and arming someone with the tools to investigate further? Amazing! Treating a public channel like ye olde facebok wall? Mildly annoying.

> Treating a public channel like ye olde facebok wall? Mildly annoying.

Every team/department/org/whatever should have channels everyone should subscribe to, and channels individuals set up that are optional for everyone. The appropriate way to handle this is for the OP to write a few tips once in a while in the public channel, and if people seem to like it, announce that all future tips will be in that channel.

Re: Small programming tricks

#107

Only a few of these are actual programming tricks. The problem with sharing them is that they'll typically seem obvious to you, since you know them. It's difficult to know what is actually unknown to other people, and if you share stuff everybody knows you risk coming off as arrogant. Here's one that I think more people should know: avoid branches. If I can do the same thing without an if statement and even a logical…

I'm struggling to comprehend how branches can be avoided (or why one would want to, as they are the cornerstone of programming). I can only think how to obfuscate them, which is rarely useful.

Probably by using various convenience functions.

A common pattern in an old C++ job I had: People writing for loops, coupled with if conditionals, for things that could just be done by chaining functions in the algorithm library.

Don't do a for loop, check for a condition, and break. Use find_if.

Re: Small programming tricks

#108
post #37

`find` does a lot more things than that.

Definitely. The whole Unix philosophy of each command doing one thing and being easily composable always seemed to break down in my mind when it came to find. find does a lot.

similar to ripgrep, though, fd is a modern replacement that’s a bit friendlier to use.

Re: Small programming tricks

#109
post #93
post #77

The thing with a lot of these tricks is that you have to get into the habit of using them. I knew `Ctrl+r` for history since I learned about the command line. I even have a nice shell integration with fzf. But I still used the up/down arrow keys for years or scrolled up when I was looking for a previous command, because I never remembered the shortcut and just took the path of least resistance to find something. Usua…

atuin kind of fixes this habit, when you click up you get a list of the latest commands, and you can just start typing to search. It's extremely natural.

I found atuin way too hard/slow to use, I think I went two days before I nuked it and went back to pure omzsh. Has it gotten any better in the past 2ish years?

Re: Small programming tricks

#110
post #61
post #2

This reminded me to ask: To what extent are people still coding by hand these days? In my profession (academia), literally no one codes anymore. On one hand, it sucks because the joy and fun of programming has been replaced by constant agent orchestration tasks, but on the other hand, it's hard to go back to the way things were before because the productivity gain is so good. I remember learning a lot of these progra…

> To what extent are people still coding by hand these days? I write everything myself. After 41 years of coding, I think in code — code flows from my brain through my fingers effortlessly: translating my thoughts to English for an LLM to then translate back to code is much, much slower than me. And once my hyperfocus kicks in, the last thing I need is to be jolted out of it by an LLM prompting loop. JetBrains Rider…

what are you writing? like - what type of programs?
Post reply on HN