molsongolden

Sort of tangential to the rulemaking discussion but I’ve had two flight attendants note that unbuckling the carrier during takeoff and landing is required due to the risk of breaking the child’s back.

If the adult is pitched forward with the child strapped to their chest (facing inward) then they risk bending the child’s spine backwards.

I once ended up on a team where not a single other person had seen Hackers…

Adding to the chorus of “this looks like X old thing”.

This reminds me of Clipper/dBase software tools. One of my favorite pieces of software was a tiny program file + flat-file .dbf for storage. Drag and drop the folder to install or share.

Just in case this isn't a compliment, I'll note that I think Dex has been pretty good about admitting when they were wrong, explaining why they were wrong, and what they're doing now instead.

There are much cheaper ways to acquire a bank charter though?

Agreed and I think the author agrees with this too. One of the ideas is that the devs should be discussing and documenting their intent outside of the code then letting AI tools generate the code as specified. "Engineering" should occupy the time that was previously occupied by "coding" and the context and writing should exist as intentional written context, not just poorly documented code.

I wonder if the reception is so variable due to differing exposure to 1) infra as code and 2) engineering teams that don't produce any artifacts outside of their code.

> When starting on a new codebase, how do you make yourself into a helpful contributor as quickly as possible? I go straight for the humans and their human docs. What problem was the system originally built to solve? What was the original design, and what were its biggest problems? Who is currently using it? If you know these, reading the code is much easier because you can guess why things were done the way they are.

This is the way but plenty of engineering teams don't have any human docs at all. Decisions are made in one engineer's head or in a chat that isn't saved. The spec was just a few notes in a ticket that was deleted during cleanup or lost when the team changed trackers. There's no map of the codebase or features, no ADRs, minimal observability. All you have is the code. You read the code to try and figure out what is going on then ping an engineer who made a recent commit to a specific area to ask if they remember why something was done the way it was. Someone makes a change and it breaks something on the other side of the codebase that they thought was totally unrelated, etc.

I think the point is that there are better engineering artifacts to review instead of lines of code. Encoding the decisions, structure, requirements, testing, monitoring, then reviewing those and having AI generate and regenerate code based on them. The code itself doesn't matter if enough thought and rigor has gone into the structure that produces the code.

> What does "ideal" mean here? When I was growing up "show your work" was the rule for all examinations. Why? Because we're working to improve mental models and thought processes for the next generation, not just products we will release tomorrow.

They're saying that the mental models and thought processes are incredibly important but that code is not the place for that work to live.

Has anyone seen evidence of lower levels in other countries? I searched for recent studies and it sounds like Canada and the EU have also reported similar findings but there isn't much widespread testing or totally comparable testing across locations.

A lot of these articles and social media discussions miss by not contemplating the fact that by increasing productivity and incomes we have also increased the cost of leisure.

In the vein of The Harried Leisure Class, the more opportunities that are available to you, the more likely you are to feel like you are wasting time, need to optimize everything, etc. People are also pushed to be even more individualistic because the cost of slowing down and interacting with the community has increased.

There are many other factors at work but this one seems pretty clear but doesn't seem to see enough discussion.