And the details involved in closing some of the rest of that loop do not seem THAT complicated.

Because my own introduction was through combinatorial game theory, I always get excited to see some hackenbush diagrams and rarely do when the subject is mentioned.

And... Then I remember it's rage bait.

Better to just read a book.

Avoiding tax through various loopholes that Capital gets a seat at the table to help craft, while benefitting from externalizing the costs to taxing labor is just corruption.

IEE754 does a good job explaining the representation, but it doesn't define all the operations and possible error codes as near as I can tell.

Is it just assumed "closest representable number to the real value" always?

What about all the various error codes?

It's one thing of we're talking food production and housing. Completely different if we're talking McDonald's happy meal toys.

Like, does the same argument apply to noise pollution? Are we alright installing a factory next to the symphony hall so long as the factory "owns" their land?

I think as our technology and understanding of the world grows we ought to change with it.

For me: I decided I could just slow down a bit. Standing out isn't worth the stress. I don't want to slack, but I don't feel compelled to cram productivity into every moment.

A few years in and I feel "back on my feet", but it was harder for being older.

"Assembly Theory" is a sort of applying (kolmogorov-esque) complexity theory to physics and other natural sciences. I don't know much else beyond that it's a "real thing".

So with that extra background, I give it a pass. I think it's an interesting idea at least.

Morality isn't a consideration.

The system must be understandable or people wouldn't incorporate and collaborate on extracting an edge. Slack in the system represents a lower price point, which will be corrected by a corresponding purchase order.

An individual has an effect, but it's miniscule compared to the massive forces in play. Unless you have a TRULY novel analysis of a situation, you are going to have a very low probability, success rate and out competing the market.

My understanding is the notion is about getting an application to "work" without any underlying theory of operation or evaluation of the imported context.

Becoming expert at a tool like git involves building familiarity with the concepts involved. While it's not entirely hidden in the --help and manual pages, the descriptions provided there do not consistently use higher levels semantic descriptions of the transformations. You are REQUIRED to look elsewhere to understand or worse -- develop a privately held theory of what's actually happening.

Culturally, a lot of engineers have a basic ethos of "getting things done". Getting the job of the moment done is a "win". There are tons of how do do XYZ articles that are separated from "why" and unmarried from useful additional context.

Like, one should be proud of learning a new tool, but it shouldn't be a personal endeavor to conquer Everest. I think it would do a LOT of good for tools -- especially collaboration tools -- to have completely standard introductions that the community enforced in collaboration. "Oh you don't know XYZ? You probably haven't read the standard introduction."

I think the reality is less like a switch and more like there are just certain jobs that get easier and you just need fewer people overall.

And you DO see companies laying off people in large numbers fairly regularly.

If you're an engineer focused on shipping product, probably not. It's not TERRIBLY useful for most day to day coding tasks.

I would argue some understanding of theory is absolutely necessary if you want to make any significant tide change in CS. It's just that most people won't (myself included).