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.

To what extent are people still coding by hand these days?

I write everything myself. After 41 years of coding, I think in code — code flows from my brain through my fingers effortlessly: translating my thoughts to English for an LLM to then translate back to code is much, much slower than me.

JetBrains Rider has an AI auto-complete which I do use for the 5-10% of the time that it can predict what I’m going to write next.

Disclaimer: I’m not writing vanilla line-of-business code or bog standard web apps, so I suspect I’m just not in the training data.

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.

Yeah, I don't buy the premise that branchless code is intrinsically easier to understand. Maybe OP's point is that adding unnecessary branches makes code harder to read? But that's generally the case for any unnecessary code.

That's a really nice example. Thanks.

Maybe they mean rather than:

if (thingThatIsTrue):

  // a bunch of logic here...

else:

  // different logic here...

they mean:

if (thingThatIsTrue):

  return doThisWhenTrue()

return dothisWhenFalse()

Just a simple example. I'm not sure if this is what you consider "obfuscating" the branches. Logically the same, but a bit more linear to understand?

Edit: I am bad at formatting comments here.

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.

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.

OK, or maybe...

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

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.

Going from ag to ripgrep is not unequivocally better. Sure ripgrep is faster, but its file filtering using -g is so much more cumbersome than -G in ag. The latter uses a regex and the former uses glob. I type many more characters to do the same search, and the same search is maybe 0.1s faster for a medium codebase. So no for me. Maybe it’s worth it for a larger codebase that isn’t large enough to require indexing.

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

I rather think the opposite. People who share tips and hacks are genuinely trying to help others, while people who hoard information are competing on an individual basis without regard for team.

Weird personal attack, thanks.

What I'm saying is I am not a jerk and actually do care about my coworkers, however I also don't want a bunch of noise in a chat app I have to use to do my job.

My favorite is generating a sequential resultset of the numbers 1-4096 in SQL Server with this simple query:

;with [[[]][[[](_)as(select 1 union select 0),[[]][]][](_)as(select 1 from [[[]][[[] []]]][]]],[[[]][[[] _),[]][]][[](_)as(select 1 from [[]][]][] []]]][]]],[[]][]][] _),[[[[[]][](_)as(select 1 from []][]][[] []]]][]]],[]][]][[] _),[[[]][]]](_)as(select 1 from [[[[[]][] []]]][]]],[[[[[]][] _)select _ from(select row_number()over (order by _)from [[[]][]]])[[[]][[[](_);

/s

Additional tip:

In the macOS terminal you can...

  Ctrl + Option + -

...and it'll undo your typing.

Dunno about other OS keys!

I started writing little "that's useful to remember" tips on my website. Bit more durable than shell history, and you can share them!

https://adamfallon.com/til.html

Wrote "script" by accident once in my terminal. Turns out the unfortunate naming of that gnu tool from unix days makes it rather unknown.

Record a debugging terminal session including output to a file. Its pretty great.

These bash commands along with similiar others makes a developer so productive.

For me, I personally use nothing fancy other than normal KDE Kate for backend development.

Function and variable names are chosen after putting a lot of thought into it which also includes being amenable to grep and sed.

+1 for git log -S. Two I use daily: rg --hidden -g '!*.lock' to skip noise, and python3 -m json.tool to pretty-print API responses.

Ctrl+r is great, sometimes. History saving sucks which can make using it difficult, but i usually use it out of laziness than trying to recall a command, especially with ssh or repeated iterations requiring flipping between two settings/states. Its hard to rely on it for other things, but its still super useful.

I’m lazy so With fish, I just type a part of the command and press up few times to get to where I want. There’s also fish-fzf.

ctrl+r still great for targeting your make targets :)

Almost all of these are irrelevant in the age of AI, except for the logarithm thing

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

`find` does a lot more things than that.

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.

“the old days”

Is this just plain old rage baiting? I literally can’t tell any more.

I miss posts like this

The most useful shell trick I've used to date is mapping the 'cd' command to 'zoxide', which is a more powerful version of cd that remembers folders you've been to.