%E5%9B%BE%E7%89%87.jpg

program
Meng To on Twitter
I didn’t write a single line of code for this 🤯 pic.twitter.com/0Xyp17UbXH— Meng To (@MengTo) August 2, 2022
Why programmers are not paid in proportion to their productivity
The most productive programmers are orders of magnitude more productive than average programmers. But salaries usually fall within a fairly small range in any company. Even across the entire profession, salaries don't vary that much. If some programmers are 10x more productive than others, why aren't they paid 10x as much? Joel Spolsky gave a
My Terminal Setup: iTerm2 + ZSH + Powerlevel10k
My Terminal Emulator
On rebooting: the unreasonable effectiveness of turning computers off and on again - Keunwoo Lee's Minimum Viable Homepage
“Turn it off and on” is a pretty normal recommendation when a computer isn’t working. It is one I don’t like, because in some way it seems like giving up on finding the solution to what went wrong. This article walking through the various state progression of the computer is a good way to think about this.
At this point, any attempt to bring your system back directly from the broken state into a working state is improvisational. We are no longer like the classically trained violist from Juilliard performing a Mozart sonata after rehearsing it a thousand times; we are now playing jazz. And in the engineering of reliable systems, we do not want our systems to improvise.
So, what should we do to fix the system?
Turn it off, and turn it on again. Anything else is less principled.
I like the “various layers of abstraction” view. Killing a process is just a smaller version of turning it off and on again.
And yet, of course, we do not throw out our computers and buy new ones every time a program does something wrong. So the story of system repair is one of “turning it off and on again” at various layers of abstraction. At each layer, we hope that we can purge the corruption by discarding some compartmentalized state, and replacing it with a known start state, from which we can enter a highly reliable reinitialization sequence that ends in a working state.
The ultimate conclusion of the article is that software that is more brittle, will break faster, and thus get fixed sooner. Ultimately an overall better thing for the system itself. While it is not referenced, this is a strong argument for strongly typed languages, amongst other things.