The mistake is that you did a system update when you wanted to use the computer. Not implying that system updates should be a dangerous thing to do, but just something learnt from experience - I’ve had similar issues, especially with Nvidea drivers and kernel versions getting updated at the same time. The take away is keep the updates to when you have an hour to debug or get comfortable rolling back updates.
I think a core thing that's missing is that code that performs well is (IME) also the simplest version of the thing. By that, I mean you'll be;
- Avoiding virtual/dynamic dispatch
- Moving what you can up to compile time
- Setting limits on sizing (e.g. if you know that you only need to handle N requests, you can allocate the right size at start up rather than dynamically sizing)
Realistically for a GC language these points are irrelevant w.r.t. performance, but by following them you'll still end up with a simpler application than one that has no constraints and hides everything behind a runtime-resolved interface.
Isn't understanding how to use your tools part of being effective at getting work done?
Sure, recloning and cp your changes to a fresh local repo will _work_, but what happens on the day you don't have access to the remote? What happens when you have to work on a repo that takes minutes to clone from the remote? All of those lost minutes because you don't understand how to use your tools means you aren't getting work done.
> memorize an obscure set of incantations like some kind of D&D wizard
If you're using Git then you're probably someone that works on software, isn't our whole job memorizing and reproducing permutations of obscure incantations to produce business value? Knowing how to use your tools provides business value, that's not some hot take but literally how you provide value to whoever pays you.