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.

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

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 and attaching those in my PR approval.

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

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.

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 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.

so are you a time traveller from like, 2023 or something?

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.

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.

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

Generally agree. As with many optimisations, branchless code can easily be less obvious than the branchy equivalent.

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.

That's a really nice example. Thanks.

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.

Oh perfect, thanks!

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.

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.

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.

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.

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.

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.

Yes, and back when hand-writing vectorized kernels via intrinsics, one learned to do the equivalent of (pseudocode here - picture SSE, AltiVec, NEON, etc.):

    vector conditionmask = <some computation...>; // E.g., 11111111 00000000 00000000 11111111
    vector truebranch = <some computation...>;
    vector falsebranch = <some computation...>;
    vector result = (truebranch & conditionmask) | (falsebranch & ~conditionmask);

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.)

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.

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

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.

Or:

  total = calculateOrderTotal(user.order);
  total *= user.discount;

or:

  return 
         calculateOrderTotal(user.order)
       * user.discount;

Not necessarily.

   return 1 - user.isPremiumMember * 0.1;

would also cut it.

some initial function like

  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

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).

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 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.

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)

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.

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.

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.

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 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!

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.

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.

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 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.

As long as they do that in separate channel and don't tag all, i'm fine with it.

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

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.)

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 was using that a few days ago

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.

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

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)

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 :)

Ctrl + R is great, you don't have to type out --dangerously-skip-permissions

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...

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

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

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?

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

    tree -if | grep "<whatever-pattern>$" | head -1

head, of course, being optional

The tradeoff is needing to learn regex, which is not any easier to learn than find arguments.

Another one I use often is <command returning output > | pbcopy on macOS. Pipes the the result directly into your clipboard

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"

(yes I know about -exec; I find the loop easier to work with)

`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.

It is just a query language for the filesystem, which is what "finding" means.

It's essentially like the SQL SELECT expression.

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.,

  find '(' -name '*.md' -and -not -type d ')' -or '(' [...] ')'

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`.)

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.

to shreds you say

I find it a valid statement.

IT was always fast, and I explained my students what IDE cable was and they don't even knew about SWAP because they never had memory issues.

They run in a container with no network access, no data access other than the project folder.

The last time I did this, the AI was markedly worse and it took a few days of development time to undo it. Then Claude blamed me for it when asking about the root cause in a retrospective.

Mine is usually Esc or, when it’s an option, “Esc when pressed, Ctrl when held”.

You can disable this misbegotten feature with

stty -ixon

Ah this is also a fun default feature of Powershell, except it works on mouse click.

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').

Interesting; I assumed the write to stdout would just hang for the writing program.

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.

I can still do everything in gnome with a shortcut, but not in vim style.

ctrl+u generally works for lots of password prompts to reset/remove what was typed, wherever you come across a password prompt and a keyboard including those two keys.

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.

Eh sometimes it overcomplicates things. I have seen Opus 5 do mad shell gymnastics for something that could have been a simple `jq`.

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.

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.

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.

You don't need to use fzf. Zoxide has an interactive function too.

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".

After 24 years and it is still useful. I would add Sed and Awk books as well.

These bits of knowledge are becoming less useful to me now that AI is doing a lot of the work.

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.

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'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.

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'

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.

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".

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.

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

That's a funny (bad faith) angle you took it. I thought were talking about personal cheat sheets for general programming and tools, not work and proprietary stuff.

The alternative and typical options that nobody bats an eye at for doing this kind of thing (3rd-party big tech cloud) are much worse from a data hygiene perspective. If you're going to be that distrustful of personal phone usage by employees, you're running a prison instead of a workplace and replacing all thought with pointless checklists. That slippery slope never ends.

From your perspective, the best security posture is for employees to return to the office without any personal belongings so we can be extra super secure? It's too bad we can't erase their memories while we're at it since being a programmer is knowledge work.

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.

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.

https://atuin.sh/

Your beef is with git, which is terrible, not a shell.

What's the point of switching to switch? I've only ever used checkout and not sure what I am missing out on.

being annoyed and forcing yourself is how everyone learns Emacs

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`.

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)

Mine is unfortunately pretty specific to the HPC clusters we use. Maybe I should pick out the more general bits and make them public some day...

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

I have following lines

  "\e[A": history-search-backward
  "\e[B": history-search-forward

in my .inputrc for years. I think, this is how command line worked in tcsh.

It changes unconditional prev/next to prefix search. With empty command line it is the same as the old behavior. But if you enter "ls" and then press up-arrow, it will scroll through all commands in history that have "ls" as a prefix. I use it much more often than C-r.

on fish shell i never felt the need for any of this, since pressing up does a history search on what you have typed

the biggest trick I have is to learn to use curl properly

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.

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.

this is a great idea, thanks!

Was not expecting to see my per-directory-history project mentioned in this, glad the author found it useful!

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.

This is a neat and useful trick, and I will be borrowing it. Thanks!

I have a shell function called "up" that finds a project root and jumps back to it (e.g. a dir containing something like .git)

Now I have these to complement - thanks!

i made `rr` (remote run) for a use-case very similar to this.

it expects the remote fs is mounted under .../ssh/HOSTNAME/ and runs any command in that dir on the remote host. if it is not the root which is mounted, looks up mtab for the remote base directory.

https://codeberg.org/hband/hband-tools/src/branch/master/use...

For fish shell users, you get chronological directory traversal with Alt-Left Arrow and Alt-Right Arrow.

Thank you for mentioning this. Using claude, I created a up.zsh(https://gist.github.com/unbeschwert/c2287008734e8034f03e3dd7...) script and added it to $HOME/.oh-my-zsh/custom folder.

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

No. Node's built-in fetch uses Undici. The custom hook is dispatcher, with an Undici-compatible dispatcher: fetch(url, { dispatcher })

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!

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

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.

I agree... but also this is so wrong it's painful. If you do have a good worker, they don't cost money, they MAKE money. Of course if you as the CEO think you are smart enough to cover everything and anybody but you is just wasting money, then that doesn't work and optimizing makes sense. Corporations have grown in size to be mindless heartless engine, literally, and that comes at the heavy price of ... not thinking, just an automaton with a single goal, growing profit, leading to an even more inhumane setup within which removing costly humans makes perfect sense.

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

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)

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.

“Small programming tricks for webdev” - title

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.

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.

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/

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!

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?

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).

    rsync -avz path/to/old_dir/ user@server:/path/to/new_dir

If you omit the trailing slash in the source path, rsync will create the target directory for you. See man rsync for more info.

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.

It is probably this plugin https://github.com/halirutan/IntelliJ-Key-Promoter-X

Ha! I just checked it out (had to install IntelliJ for this!) and it is still there!!! "Help" -> "My productivity".

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.

C#:

#if DEBUG

    Console.WriteLine("This only compiles and runs in Debug mode.");

#else

    Console.WriteLine("This only compiles and runs in Release mode.");

#endif

I once took the time to figure these out for all the languages I use

here's python:

    #'''
      normal path
    '''
      debug path
    #'''

when I comment out python code I do it with ''' ... #''' so I can uncomment it with 1 keystroke

Programming? You mean that clever trick people do to make progress on a code base slowly while Claude is down?

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.

My bash terminal starts with my own shortcuts and

     ^a         ^e       \
  <-------   -------->    } Moving
    alt-b    alt-f       /
     <----   --->       /
       ^b    ^f        /
         <- ->z 

$ cp monfi[c]hier dir/

     <----   --->
     ^w     alt-d       \
  <-------   -------->   } Erasing
     ^u         ^k      /

precisely because combinatorial mindset and efficient navigation are so important to my workflow.

PS: visual adapted from https://gist.github.com/tuxfight3r/60051ac67c5f0445efee

I think it's wise to be a bit deliberate when turning on globstar in bash. The main cost is occasional slowness on big trees. It's OK to turn it on for general purpose things, but for scripts the bigger concerns are portability and the possibility of unexpectedly broad expansion.

(you'll have to handle the case where `userInGroupCount == 0` in the code given)

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.

For 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."

0 - https://linux.die.net/man/1/tcpflow

Good post. +1 for Julia Evans mention. Her work and vibes are worth anyone's time

I was about to mention C#, but I just checked and it’s coming to C# 15 in a couple of months.