For example, when I worked for U.S. Customs and Border Protection, I was surprised to discover that the percentage of imported food/beverage actually tested for safety is very low. Like comically, microscopically, unbelievably low.

In the United States, I suspect concerns over reputation and civil litigation do more to keep our food safe than government testing.

Aims to cement fundamentals needed before leet code.

Your workday isn’t a monolith; it is a series of tiny tasks. Try deconstructing your job to identify intrinsic motivation.

Which micro-tasks do you look forward to? Which raise questions you think about and work on in your free time?

Which tasks do you avoid, put off, or find immediately draining?

If you can’t identify interesting tasks, you are likely looking at too high a level of abstraction. Break “working with clients” down until you find the specific unit of work (e.g., “debugging edge cases” vs. “proofreading emails”) that sparks interest.

After sorting tasks into intrinsically motivating or not, look for a role that involves about 20% more time on the interesting micro-tasks and 20% less on the boring ones. If you do this every few years, you drift toward a career you enjoy without needing a radical “reset.”

This approach led me down an unexpected path: law firm attorney -> government attorney -> regulatory consultant -> small-business operator. Now, I am looking at moving to a role that involves at least 20% more time on software development (intrinsically interesting to me) and 20% less time chasing unreliable people (particularly draining to me). I never set out to change my “identity,” but focusing on the micro-tasks I actually enjoy has allowed me to engineer a career I enjoy on a day-to-day basis.

https://en.wikipedia.org/wiki/AlphaSmart

https://andyjohnson.uk/blog/2025/03/17/eigiau-walk/

“Online” has collapsed into a single bucket that includes friends-only play, strangers, stores, chat, downloads, etc. What I want (and what you’re describing with running servers) is a way to scope online access: friends-only communication, no discovery, no stores, no strangers.

The frustrating part is that many platforms either (a) force these things to come as a bundle, so saying “yes” to playing with friends implicitly says “yes” to a much larger surface area; or (b) make the unbundling process so complex that well-meaning parents fail and exhausted parents give up.

jonathaneunice put the incentives behind this more sharply than I did here: https://news.ycombinator.com/item?id=46465547

Comments URL: https://news.ycombinator.com/item?id=46464652

Points: 451

# Comments: 456

Comments URL: https://news.ycombinator.com/item?id=46448809

Points: 4

# Comments: 0

Let the em-dash remain upon the height of style. Let the hyphen toil in the shade of the valley. And let the en-dash—patient, capable, and unjustly overlooked—at last be admitted to polite society, where it may properly mediate matters of form–function.

In a domain like OS development where extreme precision is required, these small errors can subconsciously signal to readers that the technical details might also be imprecise. A quick polish of the documentation would go a long way in establishing authority and trust for the rest of the book.

The offices responsible for redactions are usually in-house legal shops (e.g., an Office of Chief Counsel inside an agency like CBP) and the agency’s FOIA office. They’re often doing redactions manually in Adobe, which is slow, tedious, and error-prone. Because the process is error prone, the federal government gets multiple layers of review, justified (as DOJ lawyers regularly tell courts) by the need to “protect the information of innocent U.S. citizens.”

But the “bad at redactions” part isn’t an accident. It functions as a litigation tactic. Makes production slow, make FOIA responses slow, and then point to that slow, manual process as the reason the timeline has to be slow. The government could easily buy the kind of redaction tools that most law firms have used for decades. Purpose built redaction tools speed the work up and reduce mistakes. But the government doesn't buy those tools because faster, cleaner production benefits the requester.

The downside for the government is that every so often a judge gets fed up and orders a normal timeline. Then agencies go into panic mode and initiate an “all hands on deck.” Then you end up with untrained, non-attorney staff doing rushed redactions by hand in Adobe. Some of them can barely use a mouse. That’s when you see the classic technical failures: someone draws a black rectangle that looks like a redaction, instead of applying a real redaction that actually removes the underlying text.

Learn more if you tried to figure it out yourself for 3 hours then used the LLM for the last hour to unblock/check your work? Or learn more by utilizing LLM for help the whole four hours?

My own experience is what I learn from an LLM sticks better if I take the former approach.

If your goal is the feature, then yes: letting the agent do the heavy lifting and reviewing the diff afterward is a huge win.

But if your goal is understanding / skill-building, the hard part usually isn’t seeing a working solution. It’s doing the messy work of (a) making design choices, (b) getting stuck, (c) debugging, and (d) forming the mental model that lets you reproduce it later. Reviewing a correct implementation can create a feeling of “I get it,” but that feeling often doesn’t survive a blank file.

I’ve noticed this in my own hobby coding: LLMs are great for familiarity and unblocking progress, but the learning “sticks” much more when I’ve had to struggle through the failure modes myself. I’m watching the same dynamic play out with my son using ChatGPT to study for physics/calculus . . . it feels deep for him in the moment with the LLM, but exam-style transfer exposes the gaps.