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.

People in academia generally doesn't code much. So I am not surprised.

LLM's have not affected us in the slightest when it comes to coding. Maybe we write a snippet, post it for llm to scrutinize, and usually LLMs spout bullshit and wrong suggestions and after enough verbal abuse it points to some issues with the code.

But I don't get this delegation to LLM's for your entire coding. I hope everyone delegates to LLM :) (sarcasm)

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.

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.

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)

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!

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.

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)

I've relied on this so much that I copy my entire history between machines...

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

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?

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.

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

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

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

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

So say people so afraid of LLMs they don't even use them :).

The rest of us picks a level between "approve some" and "YOLO" depending on how much they worry about having to clean up the workspace afterwards. Encouraging using the repo and some dedicated per-session storage, while discouraging changes to global state (like installing packages system-wide) reduces cleanup problem to "every now and then `rm -rf` some agent session dirs".

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.

It can’t always not interrupt your program. Think about it: after you press Control S to trigger XOFF, the fast output has to be buffered in memory. That memory is certainly not unlimited. There’s no way for the program to keep outputting text. Indeed some programs (including Claude Code, at least a while ago) really don’t like it when you press Control S and let the terminal be frozen for a very long time.

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 think gnome just had this as an option somewhere. Asking chatgpt says that this was removed in GTK4, so maybe it's no longer a thing?

ctrl+u and ctrl+k (to delete the line forward/backward from the cursor) are super useful too

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.

FWIW I'm also on macos 15.7.9, zsh 5.9, oh-my-zsh - and I do get this behavior (TIL).

type eg "rg" then up or down arrow, and the history shown is filtered by that rg prefix.

I was missing it too. Google says it's a builtin zsh feature but mac doesn't turn it on by default, so you add these to `~/.zshrc`

    bindkey '^[[A' history-search-backward
    bindkey '^[[B' history-search-forward

So far it works. Thank you diath.

(hi! I work on atuin!)

yes, it's improved a lot in the last couple of years! what in particular bothered you?

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

I am young enough that my entire career has been markdown files, screenshots, and photos on my phone. I (a)sync everywhere by pushing git lfs commits to my home server.

Seems like overkill until it saves my ass. It continues to do so almost half a decade into all the LLM hype. It hits the sweet spot between simplicity, convenience, reliability, and precision.

People strongly underestimate how good the git life can be, especially with all the blogspam on here trying to dethrone it lately.

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.

You just have to do it so often that you’re annoyed by it and then you learn the shortcut and then you force yourself to always do the shortcut.

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.

I keep a ~/scratch.txt file and a bash alias "scratch" that will just grep it. Then I put a lot of relatively infrequently-used but often-forgetten command recipes in there, so that I can just do "scratch keygen" or whatever and it will find it. It persists longer than bash history.

If anything, I wish I had paid a lot more attention to this in the early days and made a nicer shell environment full of my own utilities, as I felt my skills just kind of slowly erode over the years with each migration. Make a nice little nest for yourself and curate those tools as your own (text) UI.

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!

Abbreviate moving up in the directory hierarchy:

  alias ..="cd .."
  alias ...="cd ../.."
  alias ....="cd ../../.."

Just keep typing period and hitting enter until you get where you want according to your prompt. I haven't found much use for more than four periods. One period would be well-defined but useless.

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!

Maybe, but there's all sorts of habits and skills that would make us enormously more productive/healthy/etc. if only the masses would learn them. This is a very old problem.

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

Good one.

:(){ :|:& };:

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.