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.
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 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.
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).
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.
Im not TYPING a lot of code by hand anymore 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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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 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.
[delayed]
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).
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.
Im not TYPING a lot of code by hand anymore 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
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.
nice content
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.
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.
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 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.
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.
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 would find that annoying, however to not be seen as a jerk I wouldn't say anything.
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.
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
Additional tip:
In the macOS terminal you can...
...and it'll undo your typing.
Dunno about other OS keys!
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
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.
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.