It's awesome in both senses! How readable has it become for you over time? Because on first glance and without syntax highlighting it's a head-scratcher.
With syntax highlighting I instantly know what it is :) But to be honest it's just for when I find myself toggling something a lot during development.. but still am too lazy to make a variable.
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.
Usually what I do is writing these tricks down to a document that is easily accessible at a place where I know that I will look for when failing to remember them. I have a directory of docs where I write stuff like this down by language/tool/etc., so I can quickly look it up without having to search the internet. But I also have to actively remind myself that these things exist whenever I have a problem, stop me from just doing the inefficient thing.
I’ve read that if you’re trying to overturn a habit with a new habit, it’s best to undo whatever it is you did the old way, then redo it the new way.
So if you want to use ctrl-r, but you’re using the up key, use the down key to navigate back to a clear line, then use ctrl-r. Do it enough times and your brain will work overtime to find a shortcut (aka just doing it the new way).
> But I still used the up/down arrow keys for years or scrolled up when I was looking for a previous command
It's not even that bad of a habit with zsh either where it will only scroll through history matching a substring in your history, for instance if I type "rg -i" and then start pressing up arrow, it will only cycle through history entries starting with "rg -i".
if you enable history substring search in zsh you can get that feature anywhere in the command and not just the start. it's very useful if you remember some snippet of the command like it had the word debug in it etc. in fish that is built in and on by default.
though one function that i recently added will narrow your history down based on a space separated set of filters which i found useful
function hgrep
set -l cmd history
for pattern in $argv
set cmd "$cmd | grep -- "(string escape "$pattern")
end
eval $cmd | cat
end
use `hgrep ruby debug foo` would filter for a line that contained all the words ruby, debug and foo.
I am young enough that my entire career has been markdown files, screenshots, and photos on my phone. I (a)sync everywhere by pushing git lfs commits to my home server.
Seems like overkill until it saves my ass. It continues to do so almost half a decade into all the LLM hype. It hits the sweet spot between simplicity, convenience, reliability, and precision.
People strongly underestimate how good the git life can be, especially with all the blogspam on here trying to dethrone it lately.
The printed copy lets you build a spatial association with the command. You are more likely to be able to look up and have your eyes settle roughly where it is than write a query on a custom site.
I think for a digital solution to come close you need it permanently present on a nth monitor
and hook up a Bluetooth sensor so when you walk into the office it prints them off in individual sticky notes and assigns one of the humanoid robots to collect them and stick them on the monitor or cubicle walls of your chosen work desk.
reminds me of the time when you got strips of fn key binding cheat sheets for various popular software packages like lotus 123 and wordperfect, and keyboards came with a space to hold them.
Bonus: if you write all your tricks in a document, people will love your document. Whenever I offer a new student my CHEATSHEET.md file, their eyes absolutely light up.
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.
Or you can start typing and press up arrow to search with that. Atuin (or some Zsh extensions, etc.) fix the bad UI of having to remember a different key for "search history by order and text" and "search history by order".
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?
Not the parent commenter, but I also tried it a year or two ago and my recollection is that I had a similar experience. I have a really long history file that dates back like a decade and if remembering correctly I tried to import it, and it made using my shell very laggy so I ended up removing it. I'm not 100% positive that I'm remembering the exact way that I started experiencing the lag though, so if I have time tomorrow I'll try it out again and see if it's still something I encounter.
I've been using it happily for longer than that! I do remember having to tweak the default search behaviours when I first installed it but it's been largely problem free ever since.
Usually what I do is writing these tricks down to a document that is easily accessible at a place where I know that I will look for when failing to remember them.
People had this same problem last century. They would use templates that fit over their keyboards with all the common shortcuts and commands printed on them. Sometimes they were for a specific program, but you could buy blank ones to write your own notes.
Today, "keyboard templates" have an entirely different meaning, so the best thing for this is paper. Print your shortcuts out on a piece of paper and put it near your monitor. You could even categorize them by writing them on different-colored Post-Its.
It's quite true. Years ago, after `git switch` was released, I wanted to try to switch from `git checkout` to `git switch`. Ultimately I had to set up some bash nastiness to error and "scold" me when I typed `git checkout` from memory, while still allowing shell scripts to call `git checkout` just fine. It was a fun exercise, and at least now I know how I could do it again: https://github.com/lelandbatey/dotfiles/blob/99c08f81fc89710...
I remember when I was using JetBrains IDE they had this feature that would list all shortcuts and IDE features and how frequently I use them. This was excellent for feature discovery. I would regularly check it out and scroll to the list of features I never used and try them.
A lot more tricks can be learned from just watching AI work. Instead of allowing AI to work autonomously, go back to the old days where you manually approve every command the AI runs. Just recently while doing performance optimization work, I found Opus using the `perf` command in ways I didn’t know possible. Just give AI a real task and carefully read what commands are used by the AI to solve the problem; most likely the AI uses a trick or two that you didn’t know existed.
There are several keyboard shortcuts that you would never find out from watching an agent, but are mindblowing to new Linux users. I suck at remembering vim keybindings, but I have ingrained ctrl+a ctrl+e for jumping to the start/end of a string (which also works all over OS X). I had been a developer for an embarassing amount of time before I discovered those.
There are other terminal specific shortcuts for removing last word (ctrl+w) but they don't seem to be as portable.
The OS-wide Emacs bindings are one of the main things still keeping me on macOS; in editors like Helix (or Zed with Helix mode) I invoke these really cursed combinations of the Helix(vim-like) shortcuts in the editor with the Emacs ones from the OS and it feels really natural as a means of moving around text.
I haven't put in enough effort to replicate the experience on GNOME but once I jump ship from Apple I'll have to.
The way macOS treats shortcuts thanks to the separation of Command and Control is great. It even makes Google Docs pretty painless to use because it's mostly like Emacs. Word still tries to hijack the shortcuts so that's suboptimal.
Another one, not quite as handy but still awesome: ctrl s / ctrl-q. This freezes/unfreezes the terminal output so you can read it, without interrupting your program. Useful for very fast walls of text.
Oh so that is what this is for. I thought ctrl-q / ctrl-s are there as a nasty way to screw with users, who every now and then accidentally press one of these, and find their terminal frozen and no longer visibly reacting to input, for no apparent reason.
That's actually XON/XOFF - in the old days when computers could send serial data to your VT100 or whatever faster than it could handle it (and we're talking 9600 baud here), the terminal would send XOFF (ctrl-S) telling the computer to stop sending - then, when the terminal caught up, it would send XON (ctrl-Q) to let the system know it could resume sending.
The advantage of doing it this way ('software flow control') is it worked with just TX and RX lines, rather than having to connect up additional wires to indicate when the terminal was busy ('hardware flow control').
there was an old riddle I saw on usenet, "there is a key I use for one of its intended purposes several times a day, but when it stopped working I never missed it. what key was that?". the answer was the caps lock key, one of whose intended purposes was reverting back to normal after accidentally pressing it to go into caps mode.
I remember when the Pause key did that! It's long enough ago that I don't remember which systems did so, and most laptops don't even have a Pause key any more, but it was often very handy for reading fast-moving console output.
It can’t always not interrupt your program. Think about it: after you press Control S to trigger XOFF, the fast output has to be buffered in memory. That memory is certainly not unlimited. There’s no way for the program to keep outputting text. Indeed some programs (including Claude Code, at least a while ago) really don’t like it when you press Control S and let the terminal be frozen for a very long time.
This makes me think of something I hate about how LLMs write CLI scripts. Even with the same model on the same day, there's never any consistency with the way CLI arguments are written or handled. Sometimes they want to split on an equal sign, and specifically write that into the code. Other times they write code to pair keys and values based on spacing and order, even and odd.
--date=2026-09-16
--date 20260916
and all variations thereof. It's annoying enough to have to check which script expects what format that I probably should've wasted some time or tokens to align them all, or at least put it into an MD file. But it's just an illustration of how LLMs can make CLI commands more obscure than they need to be.
This is interesting, I also do this, it will not let me remember the commands, but, I will learn what is possible and roughly how. And in this day and age that is more important. Just like stamping knowledge into your head also became less important (but not 0 important) with books and the internet.
> go back to the old days where you manually approve every command the AI runs
Those are also the current days if you have any sense. It's a bad idea to run an LLM with access to your machine at all, but if you absolutely must, you better review everything it does to make sure it doesn't run anything insane.
So say people so afraid of LLMs they don't even use them :).
The rest of us picks a level between "approve some" and "YOLO" depending on how much they worry about having to clean up the workspace afterwards. Encouraging using the repo and some dedicated per-session storage, while discouraging changes to global state (like installing packages system-wide) reduces cleanup problem to "every now and then `rm -rf` some agent session dirs".
A lot of these tricks come down to knowing there is a better alternative program somewhere out there in the universe, and then installing it. I happen to keep a shell script handy for these situations, which automatically installs most of the options listed here:
Among other things, fzf gets installed with all the proper key bindings, ripgrep, fdfind... basically every papercut I could find between going from a vanilla Ubuntu or Debian box to a configured one is handled in this shell script.
Those were not programming tricks, but computing tricks or command line/sql tricks.
Anyways I find it mind boggling how many useful actions are not known by „normal people”. Most people are really using computers in a very inefficient way.
My idea is if we would spend time making people learn computers or software they use daily better - we wouldn’t need AI agents and we would triple GDP.
Maybe, but there's all sorts of habits and skills that would make us enormously more productive/healthy/etc. if only the masses would learn them. This is a very old problem.
For sure! It was on Hacker News too that I learned not that long ago via this thread[1] how to tie my shoes in such a way that the knot won't come undone by itself. It has definitely saved some time with some shoes with laces that would always undo themselves on their own with my old method.
> if we would spend time making people learn computers or software they use daily better - we wouldn’t need AI agents
There's no amount of skill/efficiency/productivity a human worker can reach that will make employers give up on the dream of one day replacing them with software. The AI companies looking to profit from renting out the collected works and creativity of humanity certainly wouldn't shut down if the GDP tripled either.
People should still take time to learn how to use computers though. As long as they're going to use computers they can save themselves a lot of trouble and anxiety by investing some time in learning about them a little. Same with many other things people use and depend on.
I use this often instead of chaining together multiple '../..'.
Also nice for when I use Zoxide to CD into a deep nested directory. I quickly found out unless you manually CD each hop, the different parent directories aren't added to your Zoxide DB. (I have come across snippits to recursively CD into all directories in a path to "prepopulate" Zoxide).
I made this to jump directly from say `/foo/bar/batz/abc/123` to `/foo/bar/batz`.
Somewhat along the same lines, as I regularly SSH to other hosts with the same network filesystem mounts, 'scd' starts an SSH session on a remote host in the same directory.
#!/bin/bash
# SSH to remote system and change into same (current) directory
DIR=$(pwd)
ssh -t $1 "cd $DIR; bash -l -i"
alias ..="cd .."
alias ...="cd ../.."
alias ....="cd ../../.."
Just keep typing period and hitting enter until you get where you want according to your prompt. I haven't found much use for more than four periods. One period would be well-defined but useless.
> At a previous company, I shared a trick on slack every day with the engineering team, both technical and company-specific, and folks found them pretty useful.
I would find that annoying, however to not be seen as a jerk I wouldn't say anything.
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 getting pretty creative with it, and at this point have a well polished setup that i can give a shitty sentence on a problem, not only does it understand the task, but theres a full ticket->branch->work->pr review->ready comment flow that it uses. My team also uses ai but they havent quite wrapped their head on ways to really work with it. I have built and shared a number of helpful things with the team to try and help them grow. One such thing was a doc i had my ai instance write, based on how ive been using my setup. This alone has started to get the rest of the team up to where i am.
My team doesnt share the same types of things i do, but they still share helpful things.
Call it what you will; I think if youre not helping your team grow by providing insights and helpful things, then youre not the kind of person i want to work with.
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.
I rather think the opposite. People who share tips and hacks are genuinely trying to help others, while people who hoard information are competing on an individual basis without regard for team.
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 (whatever, the list isn't exclusive), someone shares it.
That's the part that's not sharing knowledge for the benefit of others, but rather self-serving. I might even go so far as to say self-serving doesn't even need to be selfish; the person might genuinely believe they're doing good, but even there, self-serving.
TLDR: Share your knowledge, don't make sharing something every day, even when you don't have something valuable to share, your target.
PS - if this note irks anyone (are routine maxxers a thing?), make the goal to learn something every day, then share where appropriate.
> 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.
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 sharing knowledge, especially when seeing someone else do something that can be done better. But just leaving daily breadcrumbs to remind people you're the guy that teaches random trivia feels like attention seeking.
Because it's about the journey and not just the artefact. If you're not thinking of something that's useful and preparing snippets to share every day you are not practising it. Having to come up with something stretches your imagination and critical thinking skills. What's true for the writer is true for the reader - if you just shared a simple repository with tricks, exceedingly few are going to read that, and the ones who do will forget it. Daily practise is important.
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.
I think I would prefer an optional separate channel specifically for people to share such things with each other who wanted to see that exact sorta thing. Then nobody gets bothered by it who's not interested in such things, and people who are have a place that's dedicated to exactly that.
What I'm saying is I am not a jerk and actually do care about my coworkers, however I also don't want a bunch of noise in a chat app I have to use to do my job.
I thought it sounded like a nice gesture of trying to be helpful and making a small connection with their coworkers. One message a day is hardly "a bunch of noise". Even though you say you wouldn't have said anything at the company, you said something here, and that has a similar chilling effect on other people who might have been inspired by the OP to share their tips and tricks with their coworkers.
Sorry for the "personal attack" but my point stands, you may not think of yourself as a jerk, but I saw your comment and thought "this guy imagining himself being annoyed at a coworker for a daily message with a helpful tip might be more of a jerk than he realizes". As a jerk myself I judged myself qualified to make that assessment and commented accordingly.
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.
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!
Yes, because you don't have to pop in order. "zoxide <subpath>" is "search the history of working directories for a path ending in <subpath> and cd to that".
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).
Ctrl+r is great, sometimes. History saving sucks which can make using it difficult, but i usually use it out of laziness than trying to recall a command, especially with ssh or repeated iterations requiring flipping between two settings/states. Its hard to rely on it for other things, but its still super useful.
I use history | grep quite a lot, because of the non-fuzziness with default ctrl+r. If I know exactly what the substring is, then that's great, but sometimes I also want to see the sequence around the command too (e.g. two step processes like eval ssh agent + ssh add key)
If you want to level up your Zsh history experience, I built zhist[1] specifically for that. It uses fzf underneath, but provides considerably more context than simply using fzf. There's a demo video in the README.
I would love for someone to package up some kind of script or AI skill that evaluates your current terminal config/set-up and applies all of these tips and tricks. For instance, it might detect that you currently use ag, install ripgrep, and offer a short tutorial on how users accustomed to ag should use it. Or it might look at the history of git commands you've run and offer tips on efficiency improvements.
Going from ag to ripgrep is not unequivocally better. Sure ripgrep is faster, but its file filtering using -g is so much more cumbersome than -G in ag. The latter uses a regex and the former uses glob. I type many more characters to do the same search, and the same search is maybe 0.1s faster for a medium codebase. So no for me. Maybe it’s worth it for a larger codebase that isn’t large enough to require indexing.
ag is also a little more ergonomic with its default flex casing: your query is case-sensitive if it has any uppercase letters, otherwise case-INsensitive. rg defaults to case-sensitive (but does have flags for insensitive and flex casing)
I doubt you need a full script or skill for that. I would try something like this straight in Claude Code (and will as soon as my 5 hour quota resets :-):
Review this page: https://will-keleher.com/posts/small-programming-tricks-matt... Then, review my shell init scripts (both bash and fish) and shell history. Make recommendations based on the tips and tricks from the page.
I think it's a great way to stop understanding what's going on in your terminal.
IMHO the value of these nuggets is that you understand what you're doing and why; opening yourself to large amounts of non-default behavior likely will end up in a less than pleasant setup.
Not taking into account that different users might disagree on what is convenient and what is not, which is basically the point of making things configurable.
Folks need to be sufficiently motivated to learn it. All hell break loose when `RTFM` becomes taken offensively; What do I know - I am just a weird guy with a beard.
And folks always wanted to type the commands without RTFM'ing - now we have two problems instead of one.
Also, these were hard learned tricks YOLO'ing until 3.30AM debugging a failed DNS clusters or why the HSM suddenly decided to trip up at 5AM!
Nobody even cares about the things we learn these days - Google and then your AI agent already does 98% of what I know already. So, let them blow up the clusters and the racks - your pal AI agent knows. Go ask them instead.
Not exactly programming tricks, but there's also stuff you just recognize quickly because it's a pattern you've encountered before. Like yesterday I had to diagnose a bug where some newly deployed and barely tested software hung while generating a gift certificate. Customer's name was O'Brien. Anyone wanna guess the bug?
One of the things I frequently use with Emacs is writing/recording macros on the fly with F3 and running them. I am sure this is present in the other editors as well, but this has helped me a lot at times
I do this all the time with Vim. To the point that it astonishes me that this isn't like the third or fourth thing people learn about Vim.
You can just record and play back your exact keystrokes like a _Super Smash Melee_ game plays back your inputs to replay matches. If you can figure out how to do any mildly complex action once you can literally replay it a thousand times. Just like AutoHotKey! To my that's the essence of citizen programming!
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 expression, the code typically both becomes easier to understand for people and easier to run for the CPU.
>if you share stuff everybody knows you risk coming off as arrogant
I have always felt like my bar for publishing something (even just to internal wikis/channels) is too high due to being overly self-conscious. I think we should try not to validate that feeling by implying that there is a non-negligible number of readers who will think you have a personality flaw because you wrote down your personal collection of tips in a public place, or that those people deserve consideration in the first place.
There is no such thing as "the things everybody knows". There are just too many things. Even a list of basic tips is probably going to contain one thing I didn't know or perhaps forgot. Write-ups like this are where most of my practical knowledge comes from, not RTFM (which I do).
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.
Flow control is not always necessary. Other times it can be minimized. The point is not to never branch, but to avoid unnecessary ones.
It's not applicable to every situation, but one way to do this is some very basic fuzzy logic. You do a little math and then either choose a single branch at the end, or sometimes avoid a branch altogether. https://www.geeksforgeeks.org/artificial-intelligence/fuzzy-...
Another way to avoid some branches is to have specialized routines, maybe with multiple dispatch, rather than more general methods with a bunch of checks within them for slightly different situations.
A classic performance hack for critical sections is loop unrolling.
Most of the time, no. Branchless code is harder to read and easier to get wrong. Besides, compilers know a lot of tricks and already do a lot of this work for us.
Only when a profiler points at a hot loop, and the loop contains a branch on unpredictable data this technique can pay off big.
Yeah, I don't buy the premise that branchless code is intrinsically easier to understand. Maybe OP's point is that adding unnecessary branches makes code harder to read? But that's generally the case for any unnecessary code.
and skipping the if just makes the function shorter and simpler, while also not involving the CPU branch prediction. Another one that doesn't necessarily skip all branching but at least drops one - and more importantly makes the code simpler and easy to verify, is removing the if statement in code like
if (count == 0) {
return;
}
for (int i = 0; i != count; i++) {
puts("hello");
}
Both of your examples are optimized by the compiler (gcc 16.1 -O3).
In the first case, the compiler removes the first if/return
In the second case, if you don't have the first if/return the compiler will add it. That's because it will actually convert your loop into a do/while, with the test in the end, because it is more efficient. But it has to handle the count == 0 special case first, so it will do that early return even if it is not explicitly there.
That's the kind of optimization modern compilers are good at.
There's stuff like the "Command Pattern"/dispatching/subclasses etc that can make this nice, although it's not always a good fit.
Like imagine you have a few different classes of things A,B,C so instead of checking if the thing you're handling is an A,B,C you have like a shared interface across all and can call Thing.do_it or whatever.
Still branching conditionally but it's passing it off to language features instead of code you have to write.
well here is a branching strategy I often see, pseudocode, and often this is a really stupid example as I do not have the time to come up with a good one:
if Val === "A" then
Do funcA()
else if Val === "B" then
and so forth for lots of values, or using a switch statement or similar branching instead of
Object functions = {
"A": funcA() {does what funcA does},
"B": funcB() {does what funcB does}
etc. etc.
Actually writing it I remember now someone who did this, a junior who had to update a validation function for XML invoices based on their root namespaces, which there could be a large number of these, and so she wrote out
I can't remember all the details as this was almost 20 years ago, however while it was true that one branched on the schema, it made much more sense to look up what one was supposed to do based on the rule for branching and then just execute that one action rather than writing a bunch of branching logic.
So to make it more concrete: Once branching rules becomes sufficiently complex prefer query for what you should do rather than branching
on edit: note again, not real code, but should be understandable and translatable into real code to understand what is being said easily enough.
on 2nd edit: this is also just basically one of the things I prefer instead of getting a lot of branching logic. I have never seen any stats on any benefit to this model than just having a bunch of branching statements, but I feel that the benefit is there nonetheless.
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.
What people refer to when they say "branchless code" is something very particular, and it refers to not triggering the CPU's branch prediction. That is, don't make the CPU have to guess which fork in the code you're going to take. This is usually accomplished in one of two ways: either bit twiddling hacks or specialized instructions that do not affect the CPU's branch prediction, such as the 'cmov' family in x86. If you search for `examples of branchless code using conditional moves` using your search engine of choice, you'll find numerous examples.
A trivial example is actually written with a branch in C/C++, but relies on compiler optimizations to kick in. If you compile a ternary operator in C/C++ (and probably rust, C# and other languages) such as in:
int min_branchless(int a, int b) {
return a < b ? a : b; // Often emits cmov with -O2
}
With gcc/clang a -O2, one would expect the compiler to emit the following assembly:
cmp edi, esi
cmovle eax, edi ; select a if a <= b
ret
There's numerical tricks for other operations/comparisons, and compilers know a lot of them. But, I just suggest compiling your code and configuring your compiler to emit the generated assembly with references to the code it was generated from (you should be able to get it to emit source line references in the assembly). You'll likely be surprised at the optimizations applied at -02, and utterly confused by what you find at -03.
edit: Also, it doesn't mean to never branch, but to minimize branching, especially in tight loops. Branch outside loops, not inside, for instance.
e.g. don't do:
for (...) {
if (condition independent of loop variable) {
...
} else {
...
}
}
do:
if (condition independent of loop variable) {
for (...) {
...
}
} else {
for (...) {
...
}
}
Yes, and back when hand-writing vectorized kernels via intrinsics, one learned to do the equivalent of (pseudocode here - picture SSE, AltiVec, NEON, etc.):
where each lane of the conditionmask has either all bits set or all bits clear, depending on the outcome of the conditional test for that lane.
The processor obviously does execute both branches here, so there's going to be wasted work. But since it's just a linear sequence of operations it can often schedule them independently and run them out-of-order and in parallel. And of course, if there's any shared computation between the two branches, the compiler can do common subexpression elimination.
That said, that sort of approach where you go ahead and do both and then blend them was definitely the kind of optimization where you'd want to profile rather than doing it blindly. But it was a pretty common thing to do when hand-vectorizing code. (Thankfully, auto-vectorizers are pretty good at doing this sort of optimization for you these days. It's been a very long time now since I've had to hand-write vector intrinsics.)
Rust is an expression language and so it doesn't have "the ternary operator"† you can use conditionals like if anywhere in your expression anyway.
If you want to tell the Rust compiler that you're certain a branch predictor can't help here [be very sure, most often humans are wrong which is why historically these "I know better than the branch predictor" features get ignored by optimisers] you can core::hint::select_unpredictable(condition, a, b) rather than using a dedicated operator.
† That's not its actual name, some languages have an operator with three operands which does something else, such as fused multiply-add so in a multi-lingual context better to say explicitly you mean the ternary conditional operator.
The latter example, sounds like something trivially done by the compiler. I mean I would sometimes, adhere to it, but only if the loops afterwards become substantially different. If I would just repeat most of the loop body, I would prefer the former.
There are multiple ways to avoid branches. An early return, a lookup table are two that I use regularly and consider a code smell when the AI uses many if clauses or switches.
A (hopefully interesting) aside about avoiding branches is if you don't need an exact answer but need your code to make a decision based on an approximation over some known range, you can employ a basic fuzzy logic method. Serially add, subtract, or multiply to adjust a value by a handful of weighted inputs then use that value instead of branching repeatedly to choose the right action. You might branch once based on the final value where it would have otherwise been a larger tree of decisions. In fortuitous situations, you may avoid branching altogether.
v = setup()
if v == 1:
side_effect_1()
elif v > 1:
side_effect_1()
side_effect_2(v)
else:
raise Exception()
then we can "refactor"
v = setup()
if v < 1:
raise Exception()
side_effect_1()
if v > 1:
side_effect_2(v)
i know that this might seem "dumb" that the code was ever setup the first way but code can grow into that shape pretty easily. this refactor "removes" the v==1 branch. this new code also follows the "early return" pattern, which improves readability.
if you share stuff everybody knows you risk coming off as arrogant.
Or stupid, like all those vloggers posting "ZOMG! Go all in with these secret hidden weird trick iPhone life hacks to level up!" that are just regurgitating what's in the manual.
You might not need find due to advanced globs, but it's too easy to run into expansion limits when you match hundreds or thousands of files, so you're back to find for 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.
And I don't think that's a good thing. Especially because AI coding agents use it a lot. They only need to hallucinate a little to destroy your filesystem.
I'd wager that most people just don't get that the second "arg" (composed of multiple args) to find is an expression. Expressions are, somewhat unfortunately, code, so there's essentially a mini DSL there.
find -name '*.md' -and -not -type d
Of course, then it becomes more obvious why there are parens, why those parens must be escaped for the shell, etc. E.g.,
I think once someone groks the nature of the expression args, then find becomes easier to start working with.
The most messed up part in my mind though is that while most things in find are clearly helping the expression towards its goal of "true" or "false" on whether to include the file or not in the results, some, like -prune or -exec do so but with side-effects. And since they're usually invoked primarily for their side-effect, it isn't immediately obvious that they even return a value, or are participating in the expression itself. (-prune is true, and -exec depends.) And this is where it becomes important that `find`'s -and & -or are short-circuiting, too. (In a purely logical expression, it wouldn't really matter except as an optimization.)
People also sometimes omit -and, which I'm not a huge fan of the legibility of. (But using -and makes it not POSIX; you can do -a but ew. which brings me to the last bit…)
macOS: the find there requires the starting-point arg; so my examples above, on macOS, would all need to be,
find . [expression args...]
… which is lame. Brew install GNU find and be done with that.
While I agree with globbing (or fd) for interactive use, I think for scripting I'd still say "you might want find"; there are limits to arg list lengths (see xargs) that (esp. recursive) globs can exceed; unless you know you'll never glob the world, find might be appropriate. Also:
echo *nope*
Globs will betray you on the zero-match case. (`man bash` & cf. `nullglob`.)
Ctrl-l to clear the screen, Ctrl-p to select previous command, Ctrl-j to enter it again. I don't even use Enter key when in terminal anymore.
When you want to pause entering a command for a moment do Ctrl-a to go to the start of the line, and type # to comment out. Then Ctrl-j. You can return to that later with Ctrl-p, then Ctrl-a again and Ctrl-d to remove that comment.
To edit complex commands you might want to use Alt-e to enter $EDITOR.
While AI has made my life as a developer worse in many, many ways, I am conversely really glad the conversation has shifted past these types of tricks, framework wars, etc.
I switched from vi readline mode to emacs recently primarily for Ctrl-r and Alt-. (insert the argument from the last command). I love how interactive they feel.
You can accomplish the same things in vi editing mode (with ? and !!) but they’re not as interactive.
> In NodeJS, you can keep a connection open to an external resource by creating an https.Agent and then providing it to your http requests: fetch(url, {method, agent}). This can have a dramatic impact on latency.
Is it true that you can pass a nodejs agent to fetch ? I don't think so
Can't say enough good things about fish from a UI/UX experience. There's a reason Shell Bling Ubuntu [0] swaps out your underlying shell to fish. Unless you need a terminal up ASAP for scripting purposes or shelling out (in which case dash is still much faster than bash) it's just such a better experience.
Another option is to do a ‘git log -p’ followed by a string search ‘/‘. It can give more context and let you browse more easily, especially if the project has small commits. It won’t work well for every project or search though.
I would probably retitle this less as "programming tricks" rather instead make it "bash/zsh CLI tricks" as this only really tangentially refers to programming.
It’s sad, I used to love little tricks like this: optimizing my workflow, learning the keyboard shortcuts, reading the manual. But now I just prompt codex or cc. The appeal of “sharpening the axe” is greatly diminished. I fear much of this type of knowledge will soon be lost to time.
I prompt a lot, but I also still run a lot of commands and do quick edits with vim myself, not gonna prompt "increase X to Y" when it takes ~3 seconds to do myself vs ~30 seconds for even a fast model to do it.
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 programming tricks over the years. They would give me happiness: learning something new about nvim, or some new shortcut in the Fish shell, or a new Vim macro, or the difference between 1 bracket or 2 brackets in Bash scripts, etc. But now it seems like all of them are irrelevant, and I wanted to see how others think about the situation.
> 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 has an AI auto-complete which I do use for the 5-10% of the time that it can predict what I’m going to write next. But even the next-word/next-block-of-code prediction seems so hopelessly out of its depth (which is supposed to be LLM’s party piece), it’s genuinely shocking how wrong it is most of the time.
Disclaimer: I’m not writing vanilla line-of-business code or bog standard web apps, so I suspect I’m just not in the training data.
Well, there's my super-secret future-of-software-development-and-data-autonomy project, but we're not to talk about that, so shhh! (basically my next startup idea, once I've finished inventing it).
Then, there's language-ext [1], which is my large open-source functional-programming framework for C#. And although this isn't beyond the realms of an LLM: they know FP and they know C# and even my library has been around for more than a decade, so it'll be in the training data, when it comes to bending C# to my whims or to trying to eek out exceptional performance, they're all at sea.
A good example would be what I am working on at the moment, which I have in a standalone prototyping repo [2]. Basically I have introduced functional traits to C#, like `Functor<F>`, `Applicative<F>`, `Monad<M>`, etc. This brings more rigour to things like LINQ comprehensions and allows for the building of truly generic trait-based behaviours. Something that just doesn't really exist in C#.
In language-ext today I have `Foldable<F>`, which is a little bit like `IEnumerable`, but pure. I want to be able to provide a super efficient set of default implementations for any `Foldable` (or enumerable/iterable). For this I need an efficient lazy-stream or co-routine system. The one built-in to C# (`IEnumerable` and `IEnumerator`) is impure (it mutates as it enumerates), so I am trying to build an efficient iterator/enumerator that:
* Takes around 0.25 nanoseconds per-iteration-step for its housekeeping (this speed is then on a par with the mutable IEnumerators that are a core part of C#).
* Doesn't allocate any memory
* Is immutable
* Is lazy
* Can be stopped at any point and the iterator reference be passed around (because it's immutable)
* Can be composed with standard functional operators (functor map, applicative apply, monad bind, etc.) without performance degradation and without a large memory-allocation cost.
I've been building several prototypes to try different ways of bending C# to my whims. I've managed all but the last item on that list.
Not allocating memory means using value-types (stack allocated types), but that also means the entire state of the co-routine needs to be stored in the value-type as each value is yielded (because control needs to be given back to whatever code is processing the values). To solve it, I'm pretty much building my own runtime, stack-machine, and memory manager on top of the .NET CLR so that I don't have to submit to its rules. I'm trying to apply as many of my old-skool low-level engineering chops as I can (without making it brittle); but to do the last item on that list needs more space in a value-type than would be reasonable (to avoid copying costs), so I'm looking at other pooling strategies and into building lots of bespoke to-the-metal memory managers.
After all of that, it may be a fools errand, and not doable. The LLM wouldn't understand, and that's for just one feature! Also, it must be stated, I just love doing this shit, it's brain fuel. The idea of having this conversation endlessly with an LLM as it continuously gets it wrong is nightmare fuel.
I'm not anti-AI, I love the fact that people who can't, now can. But, at this point in my journey with code, I think quicker and can produce quicker than an LLM. I think it's akin to a virtuoso piano player. If the piano player had to describe what they wanted to an LLM, the magic would go, the enjoyment would go, and potentially the quality would go. It would it also take much longer than if they had just played.
That's how I feel with code. An LLM can maybe churn out more code than me, but I can build more value and I can invent. And when in my flow state, nothing can stop me.
I will certainly keep checking in though, I'm sure there'll be a point where I feel like it augments me rather than hinders. It's just not there for me yet.
I do hand-code for the most part. I will use LLMs as a "smart reference" when I can't recall how to do something or maybe to scaffold out a starting point if I'm working in a less familiar language or framework. I use them as a better search engine, where I would have probably have looked at Stack Overflow, mdn, or online docs in the past.
I'm fortunate I guess in that most of my work tasks have very loosely defined deadlines, if any at all.
Also in academia but I'm old and my real work is done withy students. I'm coding by hand much less than I used to (boo) but solving more problems with code myself than I used to (yay). Having an llm do things turns out to be similar to having a student do them but with fast turnaround and it's fine to have them work on your home automation system. ;)
Another academic. LLMs are great for opening searches. I state what I would like to get into and let it get some initial paper recommendations. It seems to solves a hard problem: discoverability. Maybe I'm just getting subjected to more subtle bias but it is extremely easy and fast now to get a nice selection of relevant literature to review.
Analysis and any artifacts are all handcrafted by me. I mean, that is the work. I have never seen papers or code as an outcome. What I want is to learn and enable other to learn. That I can only get from doing the work myself.
I still hand code backends and frontends. I also review code by reading it manually, and ideally running it and then screenshot'ing receipts of it working and attaching those in my PR approval.
I hand code entirely at work still, while almost all of my colleagues do not and I am still able to keep up. I do use coding agents on personal projects, but have not felt the impetus to switch to agent based coding at work.
I don’t mean this to brag, mostly to point out that in my line of work, actually writing the code is not the biggest bottleneck.
For context I work on greenfield network security appliances
While I mostly just do AI-assisted coding at work nowadays, after a long time yesterday I did some scripting in a python REPL on a remote server which didn't have any AI tooling. It felt rewarding. I was also surprised my programming muscle memory was still alive and kicking.
I write code by hand because LLMs do not provide any significant productivity gains. They turn out code fast, but then I have to review it to make sure the code is correct. That takes me about as long as it would to write the code myself in the first place, so I continue to write the code myself.
Im not TYPING a lot of code by hand anymore (still some, inference is slower than typing in a few cases) but im still in the shell zipping around doing other stuff like i always have, the LLM is helpful in a lot of ways but it in no way shape or form is the ideal way to interact with a computer.
So i still get daily use out of these tricks.
Are there people that are literally ONLY interacting with a computer via an LLM? thats crazy if its true
My coding by hand is always exploratory. Either I’m getting familiar with a new library/platform or I’m sizing up the architecture of the software. Then it’s a heavy dose of copy/pasting, snippets, and emacs-fu. What I spend most time on is reading docs. Apart from that, it’s thinking (mostly away from the computer).
> To what extent are people still coding by hand these days?
That's basically I all do. I might ask a few questions to LLMs here and there like Google/StackOverflow in the days of yore.
Still, every line in all my codebases are still hand-typed. I get everything I need out of the chatbots, and I cannot use any kind of agentic coding tools at work, oddly enough. Trust me, I'd love to have access to something like Codex at work. That way I could save my mental bandwidth for personal projects that I find interesting and enjoying.
People in academia generally doesn't code much. So I am not surprised.
LLM's have not affected us in the slightest when it comes to coding. Maybe we write a snippet, post it for llm to scrutinize, and usually LLMs spout bullshit and wrong suggestions and after enough verbal abuse it points to some issues with the code.
But I don't get this delegation to LLM's for your entire coding. I hope everyone delegates to LLM :) (sarcasm)
Can you explain that one (the logarithm trick)? I have no idea what it's trying do to. Is it saying that it's convenient or useful to know the order of magnitude of a number rather than its value?
I have the same feeling, there are new approaches and tricks to get things done, mainly from how to work with AI more efficiently. But the human brain still needs to be trained and learn new things to not get rotted
I am so proud of this (I'm sure others came up with it way before me, but I still came up with it all by myself!)
take away the the first slash to toggle the debug zone ON!It's awesome in both senses! How readable has it become for you over time? Because on first glance and without syntax highlighting it's a head-scratcher.
With syntax highlighting I instantly know what it is :) But to be honest it's just for when I find myself toggling something a lot during development.. but still am too lazy to make a variable.
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.
Usually what I do is writing these tricks down to a document that is easily accessible at a place where I know that I will look for when failing to remember them. I have a directory of docs where I write stuff like this down by language/tool/etc., so I can quickly look it up without having to search the internet. But I also have to actively remind myself that these things exist whenever I have a problem, stop me from just doing the inefficient thing.
I’ve read that if you’re trying to overturn a habit with a new habit, it’s best to undo whatever it is you did the old way, then redo it the new way.
So if you want to use ctrl-r, but you’re using the up key, use the down key to navigate back to a clear line, then use ctrl-r. Do it enough times and your brain will work overtime to find a shortcut (aka just doing it the new way).
Temporarily binding the up arrow in the shell to echo "Use Ctrl-R" is probably the quickest way to un-/re-learn
I’ve done this, nowadays asking Claude to rebind things so that I’m forced to learn. It comes with interesting side effects!
I learned to type `ls` properly the first time, every time, shortly after installing `sl`.
> But I still used the up/down arrow keys for years or scrolled up when I was looking for a previous command
It's not even that bad of a habit with zsh either where it will only scroll through history matching a substring in your history, for instance if I type "rg -i" and then start pressing up arrow, it will only cycle through history entries starting with "rg -i".
if you enable history substring search in zsh you can get that feature anywhere in the command and not just the start. it's very useful if you remember some snippet of the command like it had the word debug in it etc. in fish that is built in and on by default.
though one function that i recently added will narrow your history down based on a space separated set of filters which i found useful
use `hgrep ruby debug foo` would filter for a line that contained all the words ruby, debug and foo.This is a readline feature. You can enable it in bash (and other shells?) with:
bind '"\e[A": history-search-backward'
bind '"\e[B": history-search-forward'
Clearly I am missing some setting. On zsh on macOS and I tried what you just said and it doesn't work like this
FWIW I'm also on macos 15.7.9, zsh 5.9, oh-my-zsh - and I do get this behavior (TIL).
type eg "rg" then up or down arrow, and the history shown is filtered by that rg prefix.
Isn't oh-my-zsh one of those batteries-included distributions? It sounds like that's just one of the configurations that it provides.
I was missing it too. Google says it's a builtin zsh feature but mac doesn't turn it on by default, so you add these to `~/.zshrc`
So far it works. Thank you diath.I'm not really sure what "turn it on by default" even means in the context of a shell. I've had that manually in my config for years.
I was my most effective when I had a bunch of cheat sheets taped up in my workspace.
Hot-desking killed this practice. I now get desk anxiety on my in-office days
I am young enough that my entire career has been markdown files, screenshots, and photos on my phone. I (a)sync everywhere by pushing git lfs commits to my home server.
Seems like overkill until it saves my ass. It continues to do so almost half a decade into all the LLM hype. It hits the sweet spot between simplicity, convenience, reliability, and precision.
People strongly underestimate how good the git life can be, especially with all the blogspam on here trying to dethrone it lately.
> I (a)sync everywhere by pushing git lfs commits to my home server.
Don't let IT hear that unless you work on FOSS.
Have an AI agent compile the cheat sheets into a searchable website hosted on Github for your own personal reference.
The printed copy lets you build a spatial association with the command. You are more likely to be able to look up and have your eyes settle roughly where it is than write a query on a custom site.
I think for a digital solution to come close you need it permanently present on a nth monitor
and hook up a Bluetooth sensor so when you walk into the office it prints them off in individual sticky notes and assigns one of the humanoid robots to collect them and stick them on the monitor or cubicle walls of your chosen work desk.
what a time to be alive.
reminds me of the time when you got strips of fn key binding cheat sheets for various popular software packages like lotus 123 and wordperfect, and keyboards came with a space to hold them.
Bonus: if you write all your tricks in a document, people will love your document. Whenever I offer a new student my CHEATSHEET.md file, their eyes absolutely light up.
You have a link? :-) (Still a student)
You just have to do it so often that you’re annoyed by it and then you learn the shortcut and then you force yourself to always do the shortcut.
That's how I learned Emacs!
being annoyed and forcing yourself is how everyone learns Emacs
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.
Or you can start typing and press up arrow to search with that. Atuin (or some Zsh extensions, etc.) fix the bad UI of having to remember a different key for "search history by order and text" and "search history by order".
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?
(hi! I work on atuin!)
yes, it's improved a lot in the last couple of years! what in particular bothered you?
Not the parent commenter, but I also tried it a year or two ago and my recollection is that I had a similar experience. I have a really long history file that dates back like a decade and if remembering correctly I tried to import it, and it made using my shell very laggy so I ended up removing it. I'm not 100% positive that I'm remembering the exact way that I started experiencing the lag though, so if I have time tomorrow I'll try it out again and see if it's still something I encounter.
Ahh yes, we’ve done a lot of performance optimisation since then. We regularly test on >1m records and have no issues
Make sure you’re using the daemon (the install script will handle this) and you should be good to go
Very happy to help if you have any problems. Ellie at Atuin dot sh
Good to hear! Sounds like my history file might not even be that large compared to your tests now
I've been using it happily for longer than that! I do remember having to tweak the default search behaviours when I first installed it but it's been largely problem free ever since.
Usually what I do is writing these tricks down to a document that is easily accessible at a place where I know that I will look for when failing to remember them.
People had this same problem last century. They would use templates that fit over their keyboards with all the common shortcuts and commands printed on them. Sometimes they were for a specific program, but you could buy blank ones to write your own notes.
Today, "keyboard templates" have an entirely different meaning, so the best thing for this is paper. Print your shortcuts out on a piece of paper and put it near your monitor. You could even categorize them by writing them on different-colored Post-Its.
It's quite true. Years ago, after `git switch` was released, I wanted to try to switch from `git checkout` to `git switch`. Ultimately I had to set up some bash nastiness to error and "scold" me when I typed `git checkout` from memory, while still allowing shell scripts to call `git checkout` just fine. It was a fun exercise, and at least now I know how I could do it again: https://github.com/lelandbatey/dotfiles/blob/99c08f81fc89710...
What's the point of switching to switch? I've only ever used checkout and not sure what I am missing out on.
Your beef is with git, which is terrible, not a shell.
https://atuin.sh/
I remember when I was using JetBrains IDE they had this feature that would list all shortcuts and IDE features and how frequently I use them. This was excellent for feature discovery. I would regularly check it out and scroll to the list of features I never used and try them.
I always wanted the same for Vim, zsh, etc.
Do they still do this? I'm using PyCharm daily but have never seen it. Would indeed be pretty cool!
Ha! I just checked it out (had to install IntelliJ for this!) and it is still there!!! "Help" -> "My productivity".
It is probably this plugin https://github.com/halirutan/IntelliJ-Key-Promoter-X
A lot more tricks can be learned from just watching AI work. Instead of allowing AI to work autonomously, go back to the old days where you manually approve every command the AI runs. Just recently while doing performance optimization work, I found Opus using the `perf` command in ways I didn’t know possible. Just give AI a real task and carefully read what commands are used by the AI to solve the problem; most likely the AI uses a trick or two that you didn’t know existed.
> “the old days”
Is this just plain old rage baiting? I literally can’t tell any more.
It’s a figure of speech. I use that phrase for anything older than three months.
to shreds you say
There are several keyboard shortcuts that you would never find out from watching an agent, but are mindblowing to new Linux users. I suck at remembering vim keybindings, but I have ingrained ctrl+a ctrl+e for jumping to the start/end of a string (which also works all over OS X). I had been a developer for an embarassing amount of time before I discovered those.
There are other terminal specific shortcuts for removing last word (ctrl+w) but they don't seem to be as portable.
The OS-wide Emacs bindings are one of the main things still keeping me on macOS; in editors like Helix (or Zed with Helix mode) I invoke these really cursed combinations of the Helix(vim-like) shortcuts in the editor with the Emacs ones from the OS and it feels really natural as a means of moving around text.
I haven't put in enough effort to replicate the experience on GNOME but once I jump ship from Apple I'll have to.
The way macOS treats shortcuts thanks to the separation of Command and Control is great. It even makes Google Docs pretty painless to use because it's mostly like Emacs. Word still tries to hijack the shortcuts so that's suboptimal.
I think gnome just had this as an option somewhere. Asking chatgpt says that this was removed in GTK4, so maybe it's no longer a thing?
I can still do everything in gnome with a shortcut, but not in vim style.
Another one, not quite as handy but still awesome: ctrl s / ctrl-q. This freezes/unfreezes the terminal output so you can read it, without interrupting your program. Useful for very fast walls of text.
Oh so that is what this is for. I thought ctrl-q / ctrl-s are there as a nasty way to screw with users, who every now and then accidentally press one of these, and find their terminal frozen and no longer visibly reacting to input, for no apparent reason.
That's actually XON/XOFF - in the old days when computers could send serial data to your VT100 or whatever faster than it could handle it (and we're talking 9600 baud here), the terminal would send XOFF (ctrl-S) telling the computer to stop sending - then, when the terminal caught up, it would send XON (ctrl-Q) to let the system know it could resume sending.
The advantage of doing it this way ('software flow control') is it worked with just TX and RX lines, rather than having to connect up additional wires to indicate when the terminal was busy ('hardware flow control').
Ah this is also a fun default feature of Powershell, except it works on mouse click.
there was an old riddle I saw on usenet, "there is a key I use for one of its intended purposes several times a day, but when it stopped working I never missed it. what key was that?". the answer was the caps lock key, one of whose intended purposes was reverting back to normal after accidentally pressing it to go into caps mode.
You can disable this misbegotten feature with
stty -ixon
I remember when the Pause key did that! It's long enough ago that I don't remember which systems did so, and most laptops don't even have a Pause key any more, but it was often very handy for reading fast-moving console output.
It can’t always not interrupt your program. Think about it: after you press Control S to trigger XOFF, the fast output has to be buffered in memory. That memory is certainly not unlimited. There’s no way for the program to keep outputting text. Indeed some programs (including Claude Code, at least a while ago) really don’t like it when you press Control S and let the terminal be frozen for a very long time.
Interesting; I assumed the write to stdout would just hang for the writing program.
ctrl+u and ctrl+k (to delete the line forward/backward from the cursor) are super useful too
This makes me think of something I hate about how LLMs write CLI scripts. Even with the same model on the same day, there's never any consistency with the way CLI arguments are written or handled. Sometimes they want to split on an equal sign, and specifically write that into the code. Other times they write code to pair keys and values based on spacing and order, even and odd.
--date=2026-09-16
--date 20260916
and all variations thereof. It's annoying enough to have to check which script expects what format that I probably should've wasted some time or tokens to align them all, or at least put it into an MD file. But it's just an illustration of how LLMs can make CLI commands more obscure than they need to be.
This is interesting, I also do this, it will not let me remember the commands, but, I will learn what is possible and roughly how. And in this day and age that is more important. Just like stamping knowledge into your head also became less important (but not 0 important) with books and the internet.
> go back to the old days where you manually approve every command the AI runs
Those are also the current days if you have any sense. It's a bad idea to run an LLM with access to your machine at all, but if you absolutely must, you better review everything it does to make sure it doesn't run anything insane.
So say people so afraid of LLMs they don't even use them :).
The rest of us picks a level between "approve some" and "YOLO" depending on how much they worry about having to clean up the workspace afterwards. Encouraging using the repo and some dedicated per-session storage, while discouraging changes to global state (like installing packages system-wide) reduces cleanup problem to "every now and then `rm -rf` some agent session dirs".
They run in a container with no network access, no data access other than the project folder.
A lot of these tricks come down to knowing there is a better alternative program somewhere out there in the universe, and then installing it. I happen to keep a shell script handy for these situations, which automatically installs most of the options listed here:
https://github.com/hiAndrewQuinn/shell-bling-ubuntu
More readable presentation: https://hiandrewquinn.github.io/shell-bling-ubuntu/
Among other things, fzf gets installed with all the proper key bindings, ripgrep, fdfind... basically every papercut I could find between going from a vanilla Ubuntu or Debian box to a configured one is handled in this shell script.
Those were not programming tricks, but computing tricks or command line/sql tricks.
Anyways I find it mind boggling how many useful actions are not known by „normal people”. Most people are really using computers in a very inefficient way.
My idea is if we would spend time making people learn computers or software they use daily better - we wouldn’t need AI agents and we would triple GDP.
Maybe, but there's all sorts of habits and skills that would make us enormously more productive/healthy/etc. if only the masses would learn them. This is a very old problem.
For sure! It was on Hacker News too that I learned not that long ago via this thread[1] how to tie my shoes in such a way that the knot won't come undone by itself. It has definitely saved some time with some shoes with laces that would always undo themselves on their own with my old method.
[1]: https://news.ycombinator.com/item?id=48397028
> if we would spend time making people learn computers or software they use daily better - we wouldn’t need AI agents
There's no amount of skill/efficiency/productivity a human worker can reach that will make employers give up on the dream of one day replacing them with software. The AI companies looking to profit from renting out the collected works and creativity of humanity certainly wouldn't shut down if the GDP tripled either.
People should still take time to learn how to use computers though. As long as they're going to use computers they can save themselves a lot of trouble and anxiety by investing some time in learning about them a little. Same with many other things people use and depend on.
Simple trick I use almost daily for navigating backwards to an exact directory:
https://gist.github.com/GNOMES/6bf65926648e260d8023aebb9ede9...
I use this often instead of chaining together multiple '../..'.
Also nice for when I use Zoxide to CD into a deep nested directory. I quickly found out unless you manually CD each hop, the different parent directories aren't added to your Zoxide DB. (I have come across snippits to recursively CD into all directories in a path to "prepopulate" Zoxide).
I made this to jump directly from say `/foo/bar/batz/abc/123` to `/foo/bar/batz`.
Somewhat along the same lines, as I regularly SSH to other hosts with the same network filesystem mounts, 'scd' starts an SSH session on a remote host in the same directory.
For fish shell users, you get chronological directory traversal with Alt-Left Arrow and Alt-Right Arrow.
This is a neat and useful trick, and I will be borrowing it. Thanks!
Abbreviate moving up in the directory hierarchy:
Just keep typing period and hitting enter until you get where you want according to your prompt. I haven't found much use for more than four periods. One period would be well-defined but useless.I can recommend https://www.oreilly.com/library/view/unix-power-tools/059600...
The "Unix Power Tools" book is an excellent source for Unix and shell usage tricks
After 24 years and it is still useful. I would add Sed and Awk books as well.
> At a previous company, I shared a trick on slack every day with the engineering team, both technical and company-specific, and folks found them pretty useful.
I would find that annoying, however to not be seen as a jerk I wouldn't say anything.
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 getting pretty creative with it, and at this point have a well polished setup that i can give a shitty sentence on a problem, not only does it understand the task, but theres a full ticket->branch->work->pr review->ready comment flow that it uses. My team also uses ai but they havent quite wrapped their head on ways to really work with it. I have built and shared a number of helpful things with the team to try and help them grow. One such thing was a doc i had my ai instance write, based on how ive been using my setup. This alone has started to get the rest of the team up to where i am.
My team doesnt share the same types of things i do, but they still share helpful things.
Call it what you will; I think if youre not helping your team grow by providing insights and helpful things, then youre not the kind of person i want to work with.
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.
I rather think the opposite. People who share tips and hacks are genuinely trying to help others, while people who hoard information are competing on an individual basis without regard for team.
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 (whatever, the list isn't exclusive), someone shares it.
That's the part that's not sharing knowledge for the benefit of others, but rather self-serving. I might even go so far as to say self-serving doesn't even need to be selfish; the person might genuinely believe they're doing good, but even there, self-serving.
TLDR: Share your knowledge, don't make sharing something every day, even when you don't have something valuable to share, your target.
PS - if this note irks anyone (are routine maxxers a thing?), make the goal to learn something every day, then share where appropriate.
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.
Depends on the banality of the tips.
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 sharing knowledge, especially when seeing someone else do something that can be done better. But just leaving daily breadcrumbs to remind people you're the guy that teaches random trivia feels like attention seeking.
Because it's about the journey and not just the artefact. If you're not thinking of something that's useful and preparing snippets to share every day you are not practising it. Having to come up with something stretches your imagination and critical thinking skills. What's true for the writer is true for the reader - if you just shared a simple repository with tricks, exceedingly few are going to read that, and the ones who do will forget it. Daily practise is important.
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.
You’re right, a centralized repository would be good too.
Both a centralized repository AND a daily message, especially for new employees, would be ideal, imo!
Normalize chatting and sharing stuff in slack!
I think I would prefer an optional separate channel specifically for people to share such things with each other who wanted to see that exact sorta thing. Then nobody gets bothered by it who's not interested in such things, and people who are have a place that's dedicated to exactly that.
As long as they do that in separate channel and don't tag all, i'm fine with it.
s/seen as//
Annoyance is a clue; not about them, but about you.
Weird personal attack, thanks.
What I'm saying is I am not a jerk and actually do care about my coworkers, however I also don't want a bunch of noise in a chat app I have to use to do my job.
I thought it sounded like a nice gesture of trying to be helpful and making a small connection with their coworkers. One message a day is hardly "a bunch of noise". Even though you say you wouldn't have said anything at the company, you said something here, and that has a similar chilling effect on other people who might have been inspired by the OP to share their tips and tricks with their coworkers.
Sorry for the "personal attack" but my point stands, you may not think of yourself as a jerk, but I saw your comment and thought "this guy imagining himself being annoyed at a coworker for a daily message with a helpful tip might be more of a jerk than he realizes". As a jerk myself I judged myself qualified to make that assessment and commented accordingly.
You can mute the channel. Why would you want your teammates to communicate less ?
I think that it would be unwise to mute #engineering or whatever the main eng channel is
>I shared a trick on slack every day with the engineering team
An engineering team may have multiple channels.
The post writer is also a person that you attacked for no reason even tho he's not your coworker.
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.
this is a great idea, thanks!
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!
You don't need to use fzf. Zoxide has an interactive function too.
yes! zoxide is also probably my most used tool. I did not map it to cd yet, but I use the z command to jump into directories indexed by zoxide.
Is it much more powerful, than pushd?
Yes, because you don't have to pop in order. "zoxide <subpath>" is "search the history of working directories for a path ending in <subpath> and cd to that".
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).
Ctrl + R is great, you don't have to type out --dangerously-skip-permissions
Ctrl+r is great, sometimes. History saving sucks which can make using it difficult, but i usually use it out of laziness than trying to recall a command, especially with ssh or repeated iterations requiring flipping between two settings/states. Its hard to rely on it for other things, but its still super useful.
I use history | grep quite a lot, because of the non-fuzziness with default ctrl+r. If I know exactly what the substring is, then that's great, but sometimes I also want to see the sequence around the command too (e.g. two step processes like eval ssh agent + ssh add key)
I do that too. I am trying to use Mise. (Getting interested in Maak. Haven't done anything with it yet. My Scheme is pretty rusty)
Still, Zsh history with fzf fuzzy searching is fantastic. I have years of history I can recall commands with a few keystrokes.
Truly a second-brain.
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...
I’m lazy so With fish, I just type a part of the command and press up few times to get to where I want. There’s also fish-fzf.
I've relied on this so much that I copy my entire history between machines...
Self hosted Atuin would do this for you too. Unless you don't want the added tooling/complexity
Ahh I only do this when reinstalling or moving to a new laptop but it's good to know about Atuin for the future!
ctrl+r still great for targeting your make targets :)
If you want to level up your Zsh history experience, I built zhist[1] specifically for that. It uses fzf underneath, but provides considerably more context than simply using fzf. There's a demo video in the README.
[1] https://github.com/overflowy/zhist
I started writing little "that's useful to remember" tips on my website. Bit more durable than shell history, and you can share them!
https://adamfallon.com/til.html
I would love for someone to package up some kind of script or AI skill that evaluates your current terminal config/set-up and applies all of these tips and tricks. For instance, it might detect that you currently use ag, install ripgrep, and offer a short tutorial on how users accustomed to ag should use it. Or it might look at the history of git commands you've run and offer tips on efficiency improvements.
A lot of this kind of choices are rather opinionated and personal preferences. But anyway, I think the closets thing I can think of is oh-my-zsh.
Going from ag to ripgrep is not unequivocally better. Sure ripgrep is faster, but its file filtering using -g is so much more cumbersome than -G in ag. The latter uses a regex and the former uses glob. I type many more characters to do the same search, and the same search is maybe 0.1s faster for a medium codebase. So no for me. Maybe it’s worth it for a larger codebase that isn’t large enough to require indexing.
ag is also a little more ergonomic with its default flex casing: your query is case-sensitive if it has any uppercase letters, otherwise case-INsensitive. rg defaults to case-sensitive (but does have flags for insensitive and flex casing)
I doubt you need a full script or skill for that. I would try something like this straight in Claude Code (and will as soon as my 5 hour quota resets :-): Review this page: https://will-keleher.com/posts/small-programming-tricks-matt... Then, review my shell init scripts (both bash and fish) and shell history. Make recommendations based on the tips and tricks from the page.
I think it's a great way to stop understanding what's going on in your terminal.
IMHO the value of these nuggets is that you understand what you're doing and why; opening yourself to large amounts of non-default behavior likely will end up in a less than pleasant setup.
Not taking into account that different users might disagree on what is convenient and what is not, which is basically the point of making things configurable.
> You can SELECT without a FROM
welllll that depends entirely on the DB Software you're using. A certain IBM product certainly has opinions on this.
A small side note I want to raise:
Folks need to be sufficiently motivated to learn it. All hell break loose when `RTFM` becomes taken offensively; What do I know - I am just a weird guy with a beard.
And folks always wanted to type the commands without RTFM'ing - now we have two problems instead of one.
Also, these were hard learned tricks YOLO'ing until 3.30AM debugging a failed DNS clusters or why the HSM suddenly decided to trip up at 5AM! Nobody even cares about the things we learn these days - Google and then your AI agent already does 98% of what I know already. So, let them blow up the clusters and the racks - your pal AI agent knows. Go ask them instead.
Not exactly programming tricks, but there's also stuff you just recognize quickly because it's a pattern you've encountered before. Like yesterday I had to diagnose a bug where some newly deployed and barely tested software hung while generating a gift certificate. Customer's name was O'Brien. Anyone wanna guess the bug?
One of the things I frequently use with Emacs is writing/recording macros on the fly with F3 and running them. I am sure this is present in the other editors as well, but this has helped me a lot at times
https://www.gnu.org/software/emacs/manual/html_node/emacs/Ba...
I do this all the time with Vim. To the point that it astonishes me that this isn't like the third or fourth thing people learn about Vim.
You can just record and play back your exact keystrokes like a _Super Smash Melee_ game plays back your inputs to replay matches. If you can figure out how to do any mildly complex action once you can literally replay it a thousand times. Just like AutoHotKey! To my that's the essence of citizen programming!
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 expression, the code typically both becomes easier to understand for people and easier to run for the CPU.
>if you share stuff everybody knows you risk coming off as arrogant
I have always felt like my bar for publishing something (even just to internal wikis/channels) is too high due to being overly self-conscious. I think we should try not to validate that feeling by implying that there is a non-negligible number of readers who will think you have a personality flaw because you wrote down your personal collection of tips in a public place, or that those people deserve consideration in the first place.
There is no such thing as "the things everybody knows". There are just too many things. Even a list of basic tips is probably going to contain one thing I didn't know or perhaps forgot. Write-ups like this are where most of my practical knowledge comes from, not RTFM (which I do).
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.
Flow control is not always necessary. Other times it can be minimized. The point is not to never branch, but to avoid unnecessary ones.
It's not applicable to every situation, but one way to do this is some very basic fuzzy logic. You do a little math and then either choose a single branch at the end, or sometimes avoid a branch altogether. https://www.geeksforgeeks.org/artificial-intelligence/fuzzy-...
Another way to avoid some branches is to have specialized routines, maybe with multiple dispatch, rather than more general methods with a bunch of checks within them for slightly different situations.
A classic performance hack for critical sections is loop unrolling.
Here's an example of removing a branch that was posted to HN a little over a month ago: https://www.greyblake.com/blog/branchless-rust/
From the article:
=====
Should you go branchless?
Most of the time, no. Branchless code is harder to read and easier to get wrong. Besides, compilers know a lot of tricks and already do a lot of this work for us.
Only when a profiler points at a hot loop, and the loop contains a branch on unpredictable data this technique can pay off big.
OK, but the code with the branch is easier to understand.
Yeah, I don't buy the premise that branchless code is intrinsically easier to understand. Maybe OP's point is that adding unnecessary branches makes code harder to read? But that's generally the case for any unnecessary code.
I see stuff along the lines of:
and skipping the if just makes the function shorter and simpler, while also not involving the CPU branch prediction. Another one that doesn't necessarily skip all branching but at least drops one - and more importantly makes the code simpler and easy to verify, is removing the if statement in code likeBoth of your examples are optimized by the compiler (gcc 16.1 -O3).
In the first case, the compiler removes the first if/return
In the second case, if you don't have the first if/return the compiler will add it. That's because it will actually convert your loop into a do/while, with the test in the end, because it is more efficient. But it has to handle the count == 0 special case first, so it will do that early return even if it is not explicitly there.
That's the kind of optimization modern compilers are good at.
Generally agree. As with many optimisations, branchless code can easily be less obvious than the branchy equivalent.
That's a really nice example. Thanks.
Maybe they mean rather than:
if (thingThatIsTrue):
else: they mean:if (thingThatIsTrue):
return dothisWhenFalse()Just a simple example. I'm not sure if this is what you consider "obfuscating" the branches. Logically the same, but a bit more linear to understand?
Edit: I am bad at formatting comments here.
Putting two spaces before the line formats is as code.
Example:
No space before start of line.
One space before start of line.
Thus, you can put multiple lines of code with indentation as well as long as you put two spaces at the start of the line:int main() { return 0; }
See https://news.ycombinator.com/formatdocOh perfect, thanks!
There's stuff like the "Command Pattern"/dispatching/subclasses etc that can make this nice, although it's not always a good fit.
Like imagine you have a few different classes of things A,B,C so instead of checking if the thing you're handling is an A,B,C you have like a shared interface across all and can call Thing.do_it or whatever.
Still branching conditionally but it's passing it off to language features instead of code you have to write.
well here is a branching strategy I often see, pseudocode, and often this is a really stupid example as I do not have the time to come up with a good one:
if Val === "A" then Do funcA() else if Val === "B" then
and so forth for lots of values, or using a switch statement or similar branching instead of
Object functions = { "A": funcA() {does what funcA does}, "B": funcB() {does what funcB does} etc. etc.
}
runnableFunction = functions[val]; runnableFunction();
Actually writing it I remember now someone who did this, a junior who had to update a validation function for XML invoices based on their root namespaces, which there could be a large number of these, and so she wrote out
switch namespace == "somenamespace" { validatingscheme = "someschema"; doPreliminaryFunctionToDetermineifshouldvalidate(); }
I can't remember all the details as this was almost 20 years ago, however while it was true that one branched on the schema, it made much more sense to look up what one was supposed to do based on the rule for branching and then just execute that one action rather than writing a bunch of branching logic.
So to make it more concrete: Once branching rules becomes sufficiently complex prefer query for what you should do rather than branching
on edit: note again, not real code, but should be understandable and translatable into real code to understand what is being said easily enough.
on 2nd edit: this is also just basically one of the things I prefer instead of getting a lot of branching logic. I have never seen any stats on any benefit to this model than just having a bunch of branching statements, but I feel that the benefit is there nonetheless.
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.
What people refer to when they say "branchless code" is something very particular, and it refers to not triggering the CPU's branch prediction. That is, don't make the CPU have to guess which fork in the code you're going to take. This is usually accomplished in one of two ways: either bit twiddling hacks or specialized instructions that do not affect the CPU's branch prediction, such as the 'cmov' family in x86. If you search for `examples of branchless code using conditional moves` using your search engine of choice, you'll find numerous examples.
A trivial example is actually written with a branch in C/C++, but relies on compiler optimizations to kick in. If you compile a ternary operator in C/C++ (and probably rust, C# and other languages) such as in:
With gcc/clang a -O2, one would expect the compiler to emit the following assembly: There's numerical tricks for other operations/comparisons, and compilers know a lot of them. But, I just suggest compiling your code and configuring your compiler to emit the generated assembly with references to the code it was generated from (you should be able to get it to emit source line references in the assembly). You'll likely be surprised at the optimizations applied at -02, and utterly confused by what you find at -03.edit: Also, it doesn't mean to never branch, but to minimize branching, especially in tight loops. Branch outside loops, not inside, for instance.
e.g. don't do:
do:Yes, and back when hand-writing vectorized kernels via intrinsics, one learned to do the equivalent of (pseudocode here - picture SSE, AltiVec, NEON, etc.):
where each lane of the conditionmask has either all bits set or all bits clear, depending on the outcome of the conditional test for that lane.The processor obviously does execute both branches here, so there's going to be wasted work. But since it's just a linear sequence of operations it can often schedule them independently and run them out-of-order and in parallel. And of course, if there's any shared computation between the two branches, the compiler can do common subexpression elimination.
That said, that sort of approach where you go ahead and do both and then blend them was definitely the kind of optimization where you'd want to profile rather than doing it blindly. But it was a pretty common thing to do when hand-vectorizing code. (Thankfully, auto-vectorizers are pretty good at doing this sort of optimization for you these days. It's been a very long time now since I've had to hand-write vector intrinsics.)
Rust is an expression language and so it doesn't have "the ternary operator"† you can use conditionals like if anywhere in your expression anyway.
If you want to tell the Rust compiler that you're certain a branch predictor can't help here [be very sure, most often humans are wrong which is why historically these "I know better than the branch predictor" features get ignored by optimisers] you can core::hint::select_unpredictable(condition, a, b) rather than using a dedicated operator.
† That's not its actual name, some languages have an operator with three operands which does something else, such as fused multiply-add so in a multi-lingual context better to say explicitly you mean the ternary conditional operator.
The latter example, sounds like something trivially done by the compiler. I mean I would sometimes, adhere to it, but only if the loops afterwards become substantially different. If I would just repeat most of the loop body, I would prefer the former.
There are multiple ways to avoid branches. An early return, a lookup table are two that I use regularly and consider a code smell when the AI uses many if clauses or switches.
A (hopefully interesting) aside about avoiding branches is if you don't need an exact answer but need your code to make a decision based on an approximation over some known range, you can employ a basic fuzzy logic method. Serially add, subtract, or multiply to adjust a value by a handful of weighted inputs then use that value instead of branching repeatedly to choose the right action. You might branch once based on the final value where it would have otherwise been a larger tree of decisions. In fortuitous situations, you may avoid branching altogether.
In what context can you avoid branches?
Maybe something (contrived) like this providing no-op defaults?
versusOK, or maybe...
Or:
or:Didn't you just shift the branch to the calculateDiscount() function?
Not necessarily.
would also cut it.some initial function like
then we can "refactor" i know that this might seem "dumb" that the code was ever setup the first way but code can grow into that shape pretty easily. this refactor "removes" the v==1 branch. this new code also follows the "early return" pattern, which improves readability.if you share stuff everybody knows you risk coming off as arrogant.
Or stupid, like all those vloggers posting "ZOMG! Go all in with these secret hidden weird trick iPhone life hacks to level up!" that are just regurgitating what's in the manual.
As we used to say, RTFM: https://support.apple.com/en-us/docs/iphone
You might not need find due to advanced globs, but it's too easy to run into expansion limits when you match hundreds or thousands of files, so you're back to find for that.
Something about the find syntax never sat well with me, and I don't search often enough that I feel I need to learn it.
My "find" is almost always
head, of course, being optionalThe tradeoff is needing to learn regex, which is not any easier to learn than find arguments.
Was not expecting to see my per-directory-history project mentioned in this, glad the author found it useful!
`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.
find is absolute agony once you get a taste of fd.
> `find` does a lot more things than that.
And I don't think that's a good thing. Especially because AI coding agents use it a lot. They only need to hallucinate a little to destroy your filesystem.
I'd wager that most people just don't get that the second "arg" (composed of multiple args) to find is an expression. Expressions are, somewhat unfortunately, code, so there's essentially a mini DSL there.
Of course, then it becomes more obvious why there are parens, why those parens must be escaped for the shell, etc. E.g., I think once someone groks the nature of the expression args, then find becomes easier to start working with.The most messed up part in my mind though is that while most things in find are clearly helping the expression towards its goal of "true" or "false" on whether to include the file or not in the results, some, like -prune or -exec do so but with side-effects. And since they're usually invoked primarily for their side-effect, it isn't immediately obvious that they even return a value, or are participating in the expression itself. (-prune is true, and -exec depends.) And this is where it becomes important that `find`'s -and & -or are short-circuiting, too. (In a purely logical expression, it wouldn't really matter except as an optimization.)
People also sometimes omit -and, which I'm not a huge fan of the legibility of. (But using -and makes it not POSIX; you can do -a but ew. which brings me to the last bit…)
macOS: the find there requires the starting-point arg; so my examples above, on macOS, would all need to be,
… which is lame. Brew install GNU find and be done with that.While I agree with globbing (or fd) for interactive use, I think for scripting I'd still say "you might want find"; there are limits to arg list lengths (see xargs) that (esp. recursive) globs can exceed; unless you know you'll never glob the world, find might be appropriate. Also:
Globs will betray you on the zero-match case. (`man bash` & cf. `nullglob`.)It is just a query language for the filesystem, which is what "finding" means.
It's essentially like the SQL SELECT expression.
A few tidbits I wish I had known about sooner:
bash: Ctrl-L to clear the screen
VSCodium: Shift+Alt+[arrows|mouse click] to select a rectangular block
scp for moving files (instead of ftp)
Ctrl-lpj is ingrained in my fingers.
Ctrl-l to clear the screen, Ctrl-p to select previous command, Ctrl-j to enter it again. I don't even use Enter key when in terminal anymore.
When you want to pause entering a command for a moment do Ctrl-a to go to the start of the line, and type # to comment out. Then Ctrl-j. You can return to that later with Ctrl-p, then Ctrl-a again and Ctrl-d to remove that comment.
To edit complex commands you might want to use Alt-e to enter $EDITOR.
Yes, but try rsync instead of scp. Mind the slash though!
Both rsync -avz /path/to/file user@server:/another/path/to/ or rsync -avz /path/to/file/ user@server:/another/path/to/file
Will create directory named /another/path/to/file which will contain all contents of the original directory (/path/to/file/*).
Basically, if you include the trailing slash in the source path, only contents of the directory will be copied (useful when you need to rename it).
If you omit the trailing slash in the source path, rsync will create the target directory for you. See man rsync for more info.I miss posts like this
While AI has made my life as a developer worse in many, many ways, I am conversely really glad the conversation has shifted past these types of tricks, framework wars, etc.
Wrote "script" by accident once in my terminal. Turns out the unfortunate naming of that gnu tool from unix days makes it rather unknown.
Record a debugging terminal session including output to a file. Its pretty great.
I was using that a few days ago
I switched from vi readline mode to emacs recently primarily for Ctrl-r and Alt-. (insert the argument from the last command). I love how interactive they feel.
You can accomplish the same things in vi editing mode (with ? and !!) but they’re not as interactive.
> In NodeJS, you can keep a connection open to an external resource by creating an https.Agent and then providing it to your http requests: fetch(url, {method, agent}). This can have a dramatic impact on latency.
Is it true that you can pass a nodejs agent to fetch ? I don't think so
No. Node's built-in fetch uses Undici. The custom hook is dispatcher, with an Undici-compatible dispatcher: fetch(url, { dispatcher })
My main trick is to use fish and enable vi key bindings. Especially on mac where there is no Home And End functionality.
Can't say enough good things about fish from a UI/UX experience. There's a reason Shell Bling Ubuntu [0] swaps out your underlying shell to fish. Unless you need a terminal up ASAP for scripting purposes or shelling out (in which case dash is still much faster than bash) it's just such a better experience.
[0]: https://hiandrewquinn.github.io/shell-bling-ubuntu/
> git log -S pattern (”git pickaxe”)
Another option is to do a ‘git log -p’ followed by a string search ‘/‘. It can give more context and let you browse more easily, especially if the project has small commits. It won’t work well for every project or search though.
In Jetbrains I do secondary shortcuts and I name them as what they are in my hand:
Alt M + V = Move Alt E + C = Extract Component Alt S + E = Search Everywhere _ many more.
Or just vim combos.. with ideavim
I would probably retitle this less as "programming tricks" rather instead make it "bash/zsh CLI tricks" as this only really tangentially refers to programming.
Programming? You mean that clever trick people do to make progress on a code base slowly while Claude is down?
It’s sad, I used to love little tricks like this: optimizing my workflow, learning the keyboard shortcuts, reading the manual. But now I just prompt codex or cc. The appeal of “sharpening the axe” is greatly diminished. I fear much of this type of knowledge will soon be lost to time.
I prompt a lot, but I also still run a lot of commands and do quick edits with vim myself, not gonna prompt "increase X to Y" when it takes ~3 seconds to do myself vs ~30 seconds for even a fast model to do it.
> You probably don’t need find
I think for most cases `git ls-files` does this job quite well. If you provide pathspecs, this can be very powerful!
+1 for git log -S. Two I use daily: rg --hidden -g '!*.lock' to skip noise, and python3 -m json.tool to pretty-print API responses.
I wrote this about git log -S and other Git tools for code archaeology and debugging: https://lucasoshiro.github.io/posts-en/2023-02-13-git-debug/
You can see the discussion about it here: https://news.ycombinator.com/item?id=39877637
Another one I use often is <command returning output > | pbcopy on macOS. Pipes the the result directly into your clipboard
I've noticed the same thing with AI coding tools. Sometimes I learn more from the commands they use along the way than from the actual solution.
the biggest trick I have is to learn to use curl properly
Aside from the NodeJS "trick", these seem like system administration "tricks" not programming "tricks"
Of course shell scripting is programming according to some HN commenters
Perhaps others would call SQL a programming language
“Small programming tricks for webdev” - title
These bash commands along with similiar others makes a developer so productive.
For me, I personally use nothing fancy other than normal KDE Kate for backend development.
Function and variable names are chosen after putting a lot of thought into it which also includes being amenable to grep and sed.
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 programming tricks over the years. They would give me happiness: learning something new about nvim, or some new shortcut in the Fish shell, or a new Vim macro, or the difference between 1 bracket or 2 brackets in Bash scripts, etc. But now it seems like all of them are irrelevant, and I wanted to see how others think about the situation.
> 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 has an AI auto-complete which I do use for the 5-10% of the time that it can predict what I’m going to write next. But even the next-word/next-block-of-code prediction seems so hopelessly out of its depth (which is supposed to be LLM’s party piece), it’s genuinely shocking how wrong it is most of the time.
Disclaimer: I’m not writing vanilla line-of-business code or bog standard web apps, so I suspect I’m just not in the training data.
what are you writing? like - what type of programs?
Well, there's my super-secret future-of-software-development-and-data-autonomy project, but we're not to talk about that, so shhh! (basically my next startup idea, once I've finished inventing it).
Then, there's language-ext [1], which is my large open-source functional-programming framework for C#. And although this isn't beyond the realms of an LLM: they know FP and they know C# and even my library has been around for more than a decade, so it'll be in the training data, when it comes to bending C# to my whims or to trying to eek out exceptional performance, they're all at sea.
A good example would be what I am working on at the moment, which I have in a standalone prototyping repo [2]. Basically I have introduced functional traits to C#, like `Functor<F>`, `Applicative<F>`, `Monad<M>`, etc. This brings more rigour to things like LINQ comprehensions and allows for the building of truly generic trait-based behaviours. Something that just doesn't really exist in C#.
In language-ext today I have `Foldable<F>`, which is a little bit like `IEnumerable`, but pure. I want to be able to provide a super efficient set of default implementations for any `Foldable` (or enumerable/iterable). For this I need an efficient lazy-stream or co-routine system. The one built-in to C# (`IEnumerable` and `IEnumerator`) is impure (it mutates as it enumerates), so I am trying to build an efficient iterator/enumerator that:
* Takes around 0.25 nanoseconds per-iteration-step for its housekeeping (this speed is then on a par with the mutable IEnumerators that are a core part of C#).
* Doesn't allocate any memory
* Is immutable
* Is lazy
* Can be stopped at any point and the iterator reference be passed around (because it's immutable)
* Can be composed with standard functional operators (functor map, applicative apply, monad bind, etc.) without performance degradation and without a large memory-allocation cost.
I've been building several prototypes to try different ways of bending C# to my whims. I've managed all but the last item on that list.
Not allocating memory means using value-types (stack allocated types), but that also means the entire state of the co-routine needs to be stored in the value-type as each value is yielded (because control needs to be given back to whatever code is processing the values). To solve it, I'm pretty much building my own runtime, stack-machine, and memory manager on top of the .NET CLR so that I don't have to submit to its rules. I'm trying to apply as many of my old-skool low-level engineering chops as I can (without making it brittle); but to do the last item on that list needs more space in a value-type than would be reasonable (to avoid copying costs), so I'm looking at other pooling strategies and into building lots of bespoke to-the-metal memory managers.
After all of that, it may be a fools errand, and not doable. The LLM wouldn't understand, and that's for just one feature! Also, it must be stated, I just love doing this shit, it's brain fuel. The idea of having this conversation endlessly with an LLM as it continuously gets it wrong is nightmare fuel.
I'm not anti-AI, I love the fact that people who can't, now can. But, at this point in my journey with code, I think quicker and can produce quicker than an LLM. I think it's akin to a virtuoso piano player. If the piano player had to describe what they wanted to an LLM, the magic would go, the enjoyment would go, and potentially the quality would go. It would it also take much longer than if they had just played.
That's how I feel with code. An LLM can maybe churn out more code than me, but I can build more value and I can invent. And when in my flow state, nothing can stop me.
I will certainly keep checking in though, I'm sure there'll be a point where I feel like it augments me rather than hinders. It's just not there for me yet.
Too much information? :D
[1] https://github.com/louthy/language-ext
[2] https://github.com/louthy/iterator-prototype (this is messy prototype code, don't hate me).
I do hand-code for the most part. I will use LLMs as a "smart reference" when I can't recall how to do something or maybe to scaffold out a starting point if I'm working in a less familiar language or framework. I use them as a better search engine, where I would have probably have looked at Stack Overflow, mdn, or online docs in the past.
I'm fortunate I guess in that most of my work tasks have very loosely defined deadlines, if any at all.
Also in academia but I'm old and my real work is done withy students. I'm coding by hand much less than I used to (boo) but solving more problems with code myself than I used to (yay). Having an llm do things turns out to be similar to having a student do them but with fast turnaround and it's fine to have them work on your home automation system. ;)
Another academic. LLMs are great for opening searches. I state what I would like to get into and let it get some initial paper recommendations. It seems to solves a hard problem: discoverability. Maybe I'm just getting subjected to more subtle bias but it is extremely easy and fast now to get a nice selection of relevant literature to review.
Analysis and any artifacts are all handcrafted by me. I mean, that is the work. I have never seen papers or code as an outcome. What I want is to learn and enable other to learn. That I can only get from doing the work myself.
I still hand code backends and frontends. I also review code by reading it manually, and ideally running it and then screenshot'ing receipts of it working and attaching those in my PR approval.
I hand code entirely at work still, while almost all of my colleagues do not and I am still able to keep up. I do use coding agents on personal projects, but have not felt the impetus to switch to agent based coding at work.
I don’t mean this to brag, mostly to point out that in my line of work, actually writing the code is not the biggest bottleneck.
For context I work on greenfield network security appliances
While I mostly just do AI-assisted coding at work nowadays, after a long time yesterday I did some scripting in a python REPL on a remote server which didn't have any AI tooling. It felt rewarding. I was also surprised my programming muscle memory was still alive and kicking.
I write code by hand because LLMs do not provide any significant productivity gains. They turn out code fast, but then I have to review it to make sure the code is correct. That takes me about as long as it would to write the code myself in the first place, so I continue to write the code myself.
Im not TYPING a lot of code by hand anymore (still some, inference is slower than typing in a few cases) but im still in the shell zipping around doing other stuff like i always have, the LLM is helpful in a lot of ways but it in no way shape or form is the ideal way to interact with a computer.
So i still get daily use out of these tricks.
Are there people that are literally ONLY interacting with a computer via an LLM? thats crazy if its true
My coding by hand is always exploratory. Either I’m getting familiar with a new library/platform or I’m sizing up the architecture of the software. Then it’s a heavy dose of copy/pasting, snippets, and emacs-fu. What I spend most time on is reading docs. Apart from that, it’s thinking (mostly away from the computer).
> To what extent are people still coding by hand these days?
That's basically I all do. I might ask a few questions to LLMs here and there like Google/StackOverflow in the days of yore.
Still, every line in all my codebases are still hand-typed. I get everything I need out of the chatbots, and I cannot use any kind of agentic coding tools at work, oddly enough. Trust me, I'd love to have access to something like Codex at work. That way I could save my mental bandwidth for personal projects that I find interesting and enjoying.
People in academia generally doesn't code much. So I am not surprised.
LLM's have not affected us in the slightest when it comes to coding. Maybe we write a snippet, post it for llm to scrutinize, and usually LLMs spout bullshit and wrong suggestions and after enough verbal abuse it points to some issues with the code.
But I don't get this delegation to LLM's for your entire coding. I hope everyone delegates to LLM :) (sarcasm)
Additional tip:
In the macOS terminal you can...
...and it'll undo your typing.Dunno about other OS keys!
Didn’t know about that one, and can’t find any references, but works in my fish
I’ve always used Ctrl+U, it’s an Emacs shortcut, so it works in many shells and other prompts (especially since readline supports it) by default.
(For example Ctrl+Opt+- doesn’t seem to work in the Python REPL whereas Ctrl+U does.)
Good one.
:(){ :|:& };:
For today's lucky 10,000 who don't know what this is
https://en.wikipedia.org/wiki/Fork_bomb
(See in particular the "Implementation" section where there's an explanation of how it works)
My favorite is generating a sequential resultset of the numbers 1-4096 in SQL Server with this simple query:
;with [[[]][[[](_)as(select 1 union select 0),[[]][]][](_)as(select 1 from [[[]][[[] []]]][]]],[[[]][[[] _),[]][]][[](_)as(select 1 from [[]][]][] []]]][]]],[[]][]][] _),[[[[[]][](_)as(select 1 from []][]][[] []]]][]]],[]][]][[] _),[[[]][]]](_)as(select 1 from [[[[[]][] []]]][]]],[[[[[]][] _)select _ from(select row_number()over (order by _)from [[[]][]]])[[[]][[[](_);
/s
nice content
These bits of knowledge are becoming less useful to me now that AI is doing a lot of the work.
Almost all of these are irrelevant in the age of AI, except for the logarithm thing
Can you explain that one (the logarithm trick)? I have no idea what it's trying do to. Is it saying that it's convenient or useful to know the order of magnitude of a number rather than its value?
Using a computer is irrelevant in the age of AI, you should stop doing that.
I have the same feeling, there are new approaches and tricks to get things done, mainly from how to work with AI more efficiently. But the human brain still needs to be trained and learn new things to not get rotted