HN user

beasthacker

213 karma
Posts2
Comments24
View on HN

I wonder whether government testing actually makes a material difference in food/beverage safety.

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.

I sanity-checked it with two headshots of the same third party and it swung ~2.5 points, so it seems to capture state (lighting/angle/expression) more than trait. Then I uploaded my own photo and got an unexpectedly high score, which conclusively validates the model and my rigorous n=2 study.

This framing has been helpful for me:

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.

Yes, this is exactly the distinction I was struggling to articulate.

“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

-tucky (2023) 7 months ago

The etymology I’ve heard isn’t even listed in the article. One theory traces “Kentucky” to early forms like Cantucky or Cane-tucky, referring to the region’s vast river-cane brakes, Kentucky River cane, North America’s only native bamboo, which early inhabitants associated with fertile, game-rich land.

A weak judgment betrays itself in the indiscriminate use of fine punctuation; for when the em-dash is made universal, it ceases to be distinguished, and becomes merely another form of hyphen.

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.

LearnixOS 7 months ago

I wanted to share a quick piece of feedback from a potential reader's perspective: There are several small inconsistencies in the intro text (e.g., inconsistent capitalization of 'Rust' vs 'rust', grammar typos).

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 U.S. federal government is bad at redactions on purpose.

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.

Hypothetical for you:

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.

I buy the productivity argument, but I’m not convinced “30 minutes reading/tweaking agent output” is equivalent for learning to building it yourself.

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.

If your last serious attempt was more than six months ago, your opinion is (I’m sorry to say, but) outdated.

I use ChatGPT/Claude/Gemini daily. My opinion hasn't evolved over the last 6 months:

- Huge productivity leverage, but the risk is confident, subtle wrongness, so you need to be vigilant in reviewing LLM output when using.

- Great for learning if you’re motivated; if not, it becomes reasoning outsourcing and skill atrophy.