HN user
https://www.dvrax.com
Feels very related to the idea of refinement culture: https://lindynewsletter.beehiiv.com/p/refinement-culture
While the connectedness of our world allows for great ideas to be spread and shared, there’s a huge reduction in actual variety. I don’t know what the solution is.
Obviously it isn’t totally impossible, but it becomes challenging to know if it’s required or not. It’s hardest when it isn’t just throwing an error but instead defaulting to something only half-sensible. For example replacing a negative number with 0 or overflowing rather than panicking.
When it comes to assumptions about the input, ideally model them in the type system. If you can’t, explicit checks and throws are OK in my book. But don’t check-and-hide any errors. You’ll be hard pressed to debug the issues they’ll cause down the road, since it will usually be far from the implementation that you see the impact.
Yet even with a lot of manual steering, that type of code does not come out of LLMs naturally, and even if the code comes out naturally like that, they will still attempt to handle now impossible errors.
This is something I’ve struggled to fight against in many PR reviews. Especially once already written, convincing someone that their excessive null checking is harmful is an uphill battle. Short of better modeling (and languages that allow for sum types to enable it), I haven’t been able to come up with a universally convincing argument against this kind of “shotgun parsing.”
Maybe it really just isn’t that big of a deal? But when actually reading through and refactoring a codebase I’ve always found it frustrating to manage these unnecessary checks. Sometimes they’re nearly impossible to delete safely once present without first adding some kind of logging or broad investigation.
Do you have a source for how little maintenance this will need? I imagine there will be teams of people continually employed for regular maintenance and operations. Concrete does develop “bugs” in the form of cracks, chips, or other damage that needs to be repaired.
While software engineering certainly deals with different constraints, I don’t think this is a fair comparison. When stakes are low (as they are for most software engineering), different precautions are appropriate. The aerospace or financial software engineering worlds might be more comparable here, and the engineering for those systems looks quite different as a result.
See also: https://www.jerf.org/iri/post/2026/programming_is_engineerin...
This is an excellent article, I’ve seen almost all of the issues it calls out in production for various APIs. I’ll be saving this to share with my team.
I’ve seen two separate engineers implement a “generic idempotent operation” library which used separate transactions to store the idempotency details without realizing the issues it had. That was in an organization of less than 100 engineers less than 5 years apart.
One other thing I would augment this with is Antithesis’ Definite vs Indefinite error definition (https://antithesis.com/docs/resources/reliability_glossary/#...). It helps to classify your failures in this way when considering replay behavior.
This article reminded me a lot of a previous HN post[0] which hinted at choreographic programming[1]. While this post is light on details, I think this is an interesting space and deserves much more attention than it gets today. I'm excited to watch what comes from this space.
[0] Distributed Systems Programming Has Stalled: https://news.ycombinator.com/item?id=43195702
[1] Choreographic Programming: https://en.wikipedia.org/wiki/Choreographic_programming
This is so cool, going to have to check out all of the posts in this series. I recently got a manual knitting machine (a basic round one, non programmable) and have really been enjoying the process.
Learning about the more advanced machines, even the manual ones, is fascinating. If computers weren’t around, I’m sure I’d be doing something with knitting professionally instead of programming.
This feels about as useful as the evil bit: https://www.rfc-editor.org/rfc/rfc3514
This is a topic I’ve been wanting a book on for a long time. We’ve done so much work to eliminate the need for maintenance for the masses through things like planned obsolescence, renting instead of owning, and appeasing the hedonic treadmill. I can’t help but feel through this we’ve lost a lot of collective skills in patience and ownership as a result.
I’m looking forward to reading this.
Worse, many behaviors of the system don’t necessarily have a lot of conscious intent behind them (or any)
This is one of the key reasons why I’ve ingrained the “You Ain’t Gonna Need It” principle into my development philosophy. Many times I see engineers build a system that can support a dozen different use cases, but only two are used in practice. A few years down the road when several other new features have been added and the codebase needs a refactor, the extra complexity of those ten unused features become hurdles. And anyone who knows better has moved on or been reorg’d away. I’ve lost too many hours bending over backwards to support a feature that I learn much later was never used.
Note that this applies to features that increase complexity. Sometimes you can support more with less complexity through a simpler abstraction, which I’m all in favor of.
The biggest cause of these issues isn’t style-related or something that can be easily documented ahead of time.
A recent example: an engineer wrote a custom caching layer for a service call, then called the service wrapper every time the data was needed, relying on caching to avoid hitting our dependency too often. I suggested fetching the data once and passing it around, but the engineer pushed back, citing the feature’s launch deadline and the effort required to update multiple interfaces. Their solution ultimately has more failure modes and is harder to test (requiring mocking of the service wrapper in several places), but it isn’t terrible and we probably won’t encounter cache overflow issues.
Another persistent example is function parameter length. Inevitably, there’s always “just one more argument” needed until we hit our configured linter limit. About 70% of the time, engineers add a suppression and push the change through as-is. Refactoring to reduce parameters can require significant work (and simply stuffing them into a parameter object doesn’t solve the underlying problem).
I could respond to these patterns by expanding our coding standards guide. It could document that caching shouldn’t be relied upon within a single request’s scope, or reinforce that functions should have fewer than 7 parameters (already enforced by our linter). But in my experience, these guidelines are rarely consulted before contributing. As the parameter example shows, people often push for exceptions rather than follow standards rigidly.
I do think standards guides can work well for open source projects, where contributions should never block someone from delivering value. Contributors always have the option to fork and use their changes as-is, which undermines arguments for “just getting something in.” Internal service codebases don’t have that luxury. When you’re changing a service to launch your feature before a major sales event, delays have real costs, and there’s no “I’ll fork this and maintain it myself” alternative.
It might take me an hour, but communicating the idea to the engineer, convincing them it’s better, guiding them to the solution, and then having them build it will take far longer wall clock time.
I briefly try to think of which chucklefuck I could blame this design on, but truth be told I rubber-stamped enough questionable pull requests in my time here that a fair amount of this situation is a mess of my own damn making.
This one really rings true. Every individual change you don’t push back on makes things slowly, incrementally worse until you end up with a pile of garbage. But do you really want to block someone’s change because they wrote some awkward, hacky code? After all, they’ve solved some problem for the business and it might only take an hour to clean up later.
Later never comes. Hacks get built on top of other hacks and that one hour improvement would now be a week long refactor. No one can justify that.
After few rounds of this you start to become the type of person who blocks changes for code clarity and things others view as nitpicks. Now you’re the asshole stopping people from getting work done. You ask yourself if it’s really so bad to let it slide this one time.
Repeat.
Did Anthropic ever use the term unlimited? I understand the general frustration with the pattern, but it seems weird to put unlimited in quotes when it wasn’t the way Claude was sold.
In 2024, 551 tech companies laid off nearly 152,922 employees, according to data from Layoff.fyi. The pace has accelerated dramatically this year. In just the first six months of 2025, 151 tech companies have already laid off over 63,823 people. On average a tech company cut 277 workers in 2024. If that rate is maintained for the rest of the year, the average number of layoffs per tech company in 2025 would soar to 851, roughly three times the 2024 average.
Am I missing something with this analysis? It seems like 2025 is on pace for fewer workers laid off, not more.
Reading this felt very similar to watching “Pitch Perfect 237” (Anna Kendrick 9/11 conspiracy) https://youtube.com/watch?v=MiC9X_MoE1M
There are important reasons to have domestic manufacturing even if automated and not creating jobs.
incrementally builds my credit rating
Most BNPL plans are not reported to credit agencies and therefore don’t build credit. But “financing” by paying with a credit card and paying the balance in full would build your credit, still with no interest.
I’m curious if .NET can compare here, though I have limited experience with rails or ASP.NET both seem to give you a lot to work with. Though the overlap of rails devs with .NET devs seems minimal.
A small amount of lead makes its way out of the chamber in the form of dust and fumes after shooting. It’s quite easy to breath this in or get it on your hands and accidentally ingest it. Not enough to matter for someone who occasionally goes to the range, but significant for those shooting nearly daily, especially if shooting indoors.
Just look at the millionaire CEO of your own company. Do they have 6 kids? They probably don't even have 4 kids.
Couldn’t this also be evidence that money is the issue? i.e. you can’t get to that millionaire CEO spot if you have a lot of kids you need to pay for. Instead the successful are those having fewer kids.
GnuPG/PGP and the web of trust[0]. A lot of things I see blockchain being used for today (e.g. NFTs) seems like it would be better solved using standard OpenPGP signatures with no backing chain.
Additionally, as machine-generated content proliferates, I think having services use something like the web of trust concept for membership would be super powerful. The problem is, of course, the terrible UX of cryptographic signatures. But I think there's a lot of opportunity for the group that makes it easy to use.
Timewarrior (https://timewarrior.net/). It makes it super easy to correct mistakes (i.e. forgetting to start/stop tracking), which is pretty critical for me as I'm never 100% on remembering to track
One of my favorites is Peter Norvig's spelling corrector in less than 30 lines of python
Probably related to effect size? Two thirds of the US are overweight or obese.
There was an article posted on HN a few days ago indicating such: https://news.ycombinator.com/item?id=28438315
Almost necessarily less harmful than the complete virus, but the spike protein isn’t entirely harmless it seems.
This is likely due to the source data being vended in whole number increments in degrees Celsius. Converting between Celsius and Fahrenheit using only whole numbers would not allow for 60 to show up (it is between 15 and 16 degrees C, which would convert to 59 and 61). There was a large story around this same issue in the Apple weather app, not showing 69 degrees F prior to iOS 15.
Since others are using this as a forum to share great CS papers, here’s one of my favorites: Programming as Theory Building - Peter Naur
Is discrimination based on current location illegal? I’m curious what case they would have given that many companies require certain time zones for remote employees.
While I don’t have sympathy for the cheaters who were caught, I really dislike this method of trying to catch them. When encountering an impossible problem, an honest student winds up not only wasting time trying to solve it, but also may get discouraged by the failure to do so. Both of these can result in underperforming for honest students.
All that makes me wonder why the teacher didn’t do what most would (and what is common across standardized tests): prevent using the bathroom during the test.