I’m was working on software that doesn’t exclusively target windows. Windows is only a decent dev environment if you’re targeting nothing but Windows. Any other kind of development is a worse, potentially way worse experience than it is on Linux. Using docker on Windows is painful. Using git is painful. Using bash is painful. The list goes on forever.

I didn't say never copy and paste. I'm saying when you push a commit you should understand what all the LOC in that commit do (not counting vendored dependencies). If you don't understand how something works, like crypto (not sure what Hamilton or Euler refers to in this context), ideally you would use a library. If you can't, you should still understand the code sufficiently well to be able to explain how it implements the underlying algorithm. For example if you're writing a CRC function you should be able to explain how your function implements the CRC operations, even if you don't have a clue why those operations work.

Marketing. People expect to see different things on a website vs Twitter/X so the same content won't perform the same on each. So for a business it makes sense to post different things on your website vs Twitter/X.

If I designed the schema it is most certainly going to be structured. Unstructured databases are awful.

That seems like a good guess, I can see why async hashing could be useful. But it would be nice if there was an alternative API that was blocking so my code wouldn't get infected with async/await all over the place...

A competent mid-level developer in San Francisco should be making in the ballpark of $120k salary. There are approximately 50 work weeks in a year (2 weeks of vacation) so 40 hours a week means 2000 hours a year or $60 an hour (for a full time employee). 2x for being a contractor and adjust appropriately for your level of competence/expertise and cost of living.

For references within a scope, you’re probably right. For references that cross scope boundaries (i.e. function parameters), they necessarily must consume memory (or a register). Passing a parameter to a function call consumes memory or a register by definition. If a function call is inlined, that means its instructions are copy-pasted to the call location so there’s no actual call in the compiled code.

I think the author's primary point is, "Merging changes sucks, don't make your users do that," with a corollary: if your program loads configuration from a directory that is only populated by the user, there's nothing to merge and thus never any merge conflicts. Case in point: /etc/polkit-1/rules.d. I can add whatever rules files I want in there and they're never going to conflict when I update. If PolKit makes breaking changes to the format, it will log errors somewhere and I can look at those errors, look at my rules, and figure out how to fix them. That's a hell of a lot easier than merging conflicting changes to code/configuration.

Additionally, switch performs extra sanity checks that checkout doesn't, for example switch would abort operation if it would lead to loss of local changes.

What checks? Under what situation does checkout lead to loss of changes? If I make changes and attempt to checkout a ref that would overwrite them, I get the following error:

error: Your local changes to the following files would be overwritten by checkout:
        some/file
Please commit your changes or stash them before you switch branches.
Aborting

To my knowledge it's not possible to overwrite changes when switching branches/refs (git checkout <ref> without any other arguments or flags) so I guess what the author really means is, "If you use checkout incorrectly you can overwrite local changes." As far as I can recall I've never accidentally git checkout <ref> <some/file> so I don't see a reason to retrain my muscle memory. I do use git restore since it's behavior is a lot more obvious than checkout/reset though sometimes I still use git checkout <ref> -- <some/file> because muscle memory.

GitLab already has stellar CI/CD, far superior to GitHub Actions IMO

But evidently git rev-parse - will not print out the previous branch 😔 that would have been useful for scripts

It seems to me that programming evolves too quickly for this to be a significant occurrence. Granted my dad switched careers away from programming when I was 3, but his experience and mine are radically different. Though the first programming I ever did was on one of his old programmable HP calculators.