It is a universal undo command. It works for every change in your repository. You don't need to memorize/google/ask claude how to revert each individual kind of operation (commit, rebase, delete branch, etc.). You try a jj command, look at your repo, and if you don't like what you see, you `jj undo`.

The biggest downside for me is that no longer have the necessary expertise to help coworkers who get themselves into trouble with git.

Occasionally, I need to see more changes. It is not obvious to me how I get jj to show me elided changes. I mean, sure, I can explicitly ask jj to show me the one ancestor of the last visible change, and then show me the ancestor of that one, etc. Is some flag to say: "just show me 15 more changes that you would otherwise elide"?

Personally, I absolutely hate instructing agents to make corrections. It's like pushing a wet noodle. If there is lots to correct, fix one or two cases manually and tell the LLM to follow that pattern.

https://www.humanlayer.dev/blog/writing-a-good-claude-md

In my time using Typst, I found that Typst makes it possible/easy to make content even more abstract: write the content as a "data structure" and then present parts of it in various places around your document. For instance to list quantity/weight of a parts description in a parts index at the end.

This is an example where ownership semantics would have prevented that bug. (references to the cached HashSets could have only been handed out as shared/immutable references; the mutation of the cached HashSet could not have happened).

The ownership model is about much more than just memory safety. This is why I tell people: spending a weekend to learn rust will make you a better programmer in any language (because you will start thinking about proper ownership even in GC-ed languages).

Code completions are fine. Driving code through chat is a complete waste of time (never saves time for me; always ends up taking longer). Agentic coding (where the LLM works autonomously for half an hour) still holds some promise, but my employer isn't ready for that.

Research/queries only for very low stakes/established things (e.g., how do I achieve X in git).

Exploratory/introductory/surface-level queries are the ones that get handed to auto-complete.

I like how Kagi lets me control whether AI should be involved by adding or omitting a question mark from my search query. Best of both worlds.

Login forms are a war zone. Looking for patterns that indicate the other party is a bot and serve them (and only them) a captcha is a technique that is quite effective. But it is not perfect. Especially business customers often get forced to solve captchas in our system.

If you know of a better solution (other than: don't be a big online shop), I'm all ears.

Keyboards are such a good hobby project. The scope is comparatively small, yet within that scope you get in contact with many different and highly interesting subjects and challenges. And you can more or less pick and choose, which ones you engage with (wireless vs wired, soldering vs hand-wired, custom firmware vs. ZMK/QMK, split vs. traditional).

That said, I have kept the number row labelled. These keys are not obscured by your hands and they can give you the necessary frame of reference. The ideal trade-off for me.

[1] https://docs.zfsbootmenu.org

- a single solution that covers the entire storage domain (I don't have to learn multiple layers, like logical volume manager vs. ext4 vs. physical partitions) - cheap/free snapshots. I have been glad to have been able to revert individual files or entire file systems to an earlier state. E.g., create a snapshot before doing a major distro update. - easy to configure/well documented

Like others have said, at this point I would need a good reason, NOT to use ZFS on a system.

    
       preview
    

On a more serious note, I'm not sure that ECC RAM should be an important distinguishing factor. If your workstation actually produces an artifact that is used further down the line (a model, a binary or even just a number, a decision based on a simulation), then yes, definitely, it should run ECC RAM.

I feel like it's a different story for software engineers. What they use their "workstations" for is not what will eventually get shipped. That artifact is (hopefully) getting built on dedicated build machines (and those better have ECC RAM). ECC RAM won't have much impact on running IDEs and local compile-test-run cycles, right?

1: https://doc.rust-lang.org/std/vec/struct.Vec.html#method.int...

    if foo(args)
        == 0 then "null"
        |> abs
            > 100 then "large"
            < 10 then "small"
            else "medium"

The ability to easily work on top of an octopus merge and then push changes "down" into the contributing branches has been a live saver when my team had to do a big refactoring in a mono repo and split the changes into small PRs for individual teams (code owners).

The auto committing behavior is a bit weird at first, but now I don't want to go back to git. It feels a bit like the step from SVN to git back in the the day. ("this feels weird" -> "how did people ever tolerate the old way?")