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.
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.
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.
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.
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.
> 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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
> 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.
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.
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.
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 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.
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.
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).
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
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.
Is this just plain old rage baiting? I literally can’t tell any more.
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.
The "Unix Power Tools" book is an excellent source for Unix and shell usage tricks
[1] https://github.com/overflowy/zhist
I would find that annoying, however to not be seen as a jerk I wouldn't say anything.
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.
One is actually helping and the other is making yourself more visible to mgmt for promotions.
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.
Annoyance is a clue; not about them, but about you.
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.
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 shared a trick on slack every day with the engineering team
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.
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).
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.
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.
=====
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.
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.
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.
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
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.
https://adamfallon.com/til.html
Record a debugging terminal session including output to a file. Its pretty great.
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.
In the macOS terminal you can...
...and it'll undo your typing.Dunno about other OS keys!
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.
I'm fortunate I guess in that most of my work tasks have very loosely defined deadlines, if any at all.
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.
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.
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.
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 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
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
;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