Honestly, a lot of programming is just knowing the right little trick at the right moment. You don't need to know everything, you just need to know where to look.
Small programming tricks
251–260 of 265 posts
Re: Small programming tricks
#252Earlier quoted context omitted.
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.
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 rebind capslock on all my new computers, usually to ctrl or cmd.
Re: Small programming tricks
#253The thing with a lot of these tricks is that you have to get into the habit of using them. I knew `Ctrl+r` for history since I learned about the command line. I even have a nice shell integration with fzf. But I still used the up/down arrow keys for years or scrolled up when I was looking for a previous command, because I never remembered the shortcut and just took the path of least resistance to find something. Usua…
I've found Spaced Repetition (via Anki etc) to be great for remembering these things.
Was originally turned on to this by Derek Sivers: https://sive.rs/srs
Re: Small programming tricks
#254Earlier quoted context omitted.
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
ive just done this, thanks for the suggestion:
"Use Ctrl-R for fuzzy history, or Ctrl-P/Ctrl-N for history entries"
(I have those bound to bindkey '^P' up-history and bindkey '^N' down-history instead of up and down arrow's "up-line-or-history" which is really annoying with multiline commands)
Re: Small programming tricks
#255A 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 likel…
That is indeed a good way to pick up new tricks with AI! But I'm afraid a lot of us will just end up mindlessly pressing "Approve".
I doubt people will have the energy to pause and look at the reasoning behind each output when they're overwhelmed by the sheer volume and speed of AI output.
And more fundamentally, I know it can be fun to learn new tricks, but I agree with phforms that if you don’t use them often enough, the novelty wears off quickly. And with AI taking over more of the work that used to help us learn by doing, we may end up with even fewer chances to actually internalize those skills.
Re: Small programming tricks
#256Earlier quoted context omitted.
I think that "everyday" would be a stretch, but i dont understand why youd think thats annoying, someone took the time to consider helping the rest of the engineering team grow, by posting something useful. I frequently do the same, but not everyday; only when i think its something actually useful/helpful beyond the everyday crap. Most recently, we have had a huge push to use ai (just like everywhere else), ive been…
Why just one each day then? Why not a shared knowledge base? Do you start with a "bag of tricks" and then hand them out one by one each day to remind people you're the guy with the bag of tricks? "Oh, yeah, I know a cool trick, but y'all have to wait until tomorrow to find out what it is." "Look! It's a way to evaluate SQL expressions with a select with a from! Oh, you already knew about it?" I have nothing against s…
Sharing an hundred tips one tip a day has certainly more chance to be shared correctly than pointing to a page containing those hundred tips.
Personally I don't care if the guy looks for attention or not. IMO people that do care have likely some jealousy issues ("I don't want other to get more attention than I do"). Lose-lose attitude.
Re: Small programming tricks
#257For people asking "do these small tricks/trivia really matter??" I have an example of when they do:
- having strange networking issues on the blue side of a blue/green deployment
- networking engineers are involved
- nobody seems to be able to figure out what's going on despite LOTS of tcpdump/wireshark etc
- I suggest tcpflow[0] (which I used for protocol analysis of chat services etc)
- (there is some skepticism as I was SRE and not networking)
- Turns out that the TCP messages were getting truncated on the problem side
- Networking guys realize the config issue and fix it
I have other examples but this is why it's always good to learn new commands/tools etc.
This, in turn, reminds me of a quote from an army jungle survival expert: "People ask me if it's a good idea to read survival books. I say: 100%. You would be surprised how many people survive an emergency situation because their brain pops out some critical piece of information from a book or article they read 10 years ago."
Re: Small programming tricks
#258I 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).
atuin for me has replaced ctrl-r.
well not specificlly but its bound to it. Having durable history stored in an SQL database (with secrets filtering and option syncing) you can search global history, or local. (as in if you have two terminals open, you can just search the commands you've typed in one terminal for that session, that session plus history or that session plus what you've just typed in any other session. )
Its awesome
Re: Small programming tricks
#259Earlier quoted context omitted.
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.
I tried fd but it seems to ignore so much that it's basically useless. If I wanted `git ls-files|grep` I would `git ls-files|grep`
yells at cloud
..it's probably ok actually and I should give it a real go, but I'm too used to find and even have a keybinding in my ~/.inputrc to insert a find + where loop
"\e\C-f": "find . -type f -print0|while read -rd '' f; do ; done\e-b\C-b\C-b\C-b\C-b\C-b\C-b"
Re: Small programming tricks
#260This reminded me to ask: To what extent are people still coding by hand these days? In my profession (academia), literally no one codes anymore. On one hand, it sucks because the joy and fun of programming has been replaced by constant agent orchestration tasks, but on the other hand, it's hard to go back to the way things were before because the productivity gain is so good. I remember learning a lot of these progra…
The code I check in at work is nearly all hand-written. I'll often send files and functions and snippets and questions and `git diff`'s to an LLM. In particular the code review is very helpful for catching silly mistakes. But if it generates code, even if it looks fine, I always end up manually moving it around and rewriting and renaming things. I need to understand the code I maintain, and those "prosaic" changes and refactorings that I do while incorporating the code help ground me deeply in how it works.
Also, I'm mostly not very happy with the architectural choices the LLM makes. It can be good at little details, and sometimes I learn about language features or idioms or libraries by reading its code, but I find it often uses wrong patterns. E.g. just this week I saw it creating two huge intermediate data structures for parsing something in a "cleaner" way, completely missing how the library it had suggested actually had something builtin (and prominently featured in the tutorial) that obviated the need for those intermediate structures and was both safer and more readable.
When I've tried full agent coding, I kept getting distracted while waiting. I also have the feeling that my questions to the LLM were getting "dumber" as I lost contact with the code. And I don't have the hardware for local LLM's, so giving full repo access is out of the question for work.
Altogether I feel like I've found a fairly good balance in how to use them in such a way that I can avoid a lot of the downsides and still have a tool that gives me much value that I didn't have before: I check in fewer bugs, I waste less time picking libraries/methods, I have a better rubber duck, I learn little tricks all the time, I never send LLM-generated text to humans.