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.

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

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

I'm struggling to comprehend how branches can be avoided (or why one would want to, as they are the cornerstone of programming). I can only think how to obfuscate them, which is rarely useful.

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

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 universally better. Sure ripgrep is faster, but its file filtering using -g is so much more troublesome 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 small codebase. So no for me. Maybe it’s worth it for a medium-sized codebase.

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 think that "everyday" would be a stretch, but i dont understand why youd think thats annoying, someone took the time to consider helping the rest of the engineering team grow, by posting something useful.

I frequently do the same, but not everyday; only when i think its something actually useful/helpful beyond the everyday crap. Most recently, we have had a huge push to use ai (just like everywhere else), ive been getting pretty creative with it, and at this point have a well polished setup that i can give a shitty sentence on a problem, not only does it understand the task, but theres a full ticket->branch->work->pr review->ready comment flow that it uses. My team also uses ai but they havent quite wrapped their head on ways to really work with it. I have built and shared a number of helpful things with the team to try and help them grow. One such thing was a doc i had my ai instance write, based on how ive been using my setup. This alone has started to get the rest of the team up to where i am.

My team doesnt share the same types of things i do, but they still share helpful things.

Call it what you will; I think if youre not helping your team grow by providing insights and helpful things, then youre not the kind of person i want to work with.

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.

I find myself using ctrl-r less and less as I make sure that anything of value that I work out goes into a Makefile or the app tooling, for me this is the basis of the dev-ops approach to work (make sure everything is scripted, not worked out on the fly).

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