jason_oster

9 ms·

1.
by jason_oster 17d ago
What I'm trying to get at is that age and stability are only loosely correlated with correctness. I'll give you credit for calling out the tautology, and I don't think there is a way around it. Any code that is written withou
2.
by jason_oster 18d ago
A literal interpretation of the claim is, quoted directly, "old code has fewer bugs than new code". Now you've clarified that you meant "stable code", which is fair. But stability is not a guarantee of correctness.
3.
by jason_oster 18d ago
I'm ashamed to admit I had trouble reading this, because I came here to say it.
4.
by jason_oster 18d ago
Stop making sense! This is HN, for crying out loud.
5.
by jason_oster 19d ago
> A study I read a few months ago showed that old code has fewer bugs than new code, which seems intuitive but it's nice to have actual data on it as well Which study? Old software has bugs that live for decades, even security bugs.
6.
by jason_oster 23d ago
If that is representative of your personal experience, then I'm saddened to hear it. I believe your article is an argument from incredulity [1]. You may not personally know anyone who thrives in learning from and applying knowledge wit
7.
by jason_oster 23d ago
As always, the innovators will thrive and become the new experts in the field. Everyone else will die out. It's impossible to buy the FUD that expertise will somehow vanish because people use AI. People come in a variety of capabilit
8.
by jason_oster 1mo ago
It does happen, but having the ability to pivot quickly is almost always more valuable than dealing with "the devil you know". There is nothing wrong with evaluating something new and discovering it doesn't work out as expect
9.
by jason_oster 1mo ago
Compare to what happened to Python. That will cheer you up!
10.
by jason_oster 1mo ago
This advice holds up, but there are caveats to keep in mind. Two off the top of my head: 1. I once worked for a company that had a large Cassandra cluster that was primarily serving the role of a distributed append-only log. This role is as
11.
by jason_oster 2mo ago
The story is clearly fictional. It is full of factual errors. Freeing a heap-allocated block of expert weights does not magically result in a dangling pointer referencing the program's .text section, much less successfully targeting th
12.
by jason_oster 2mo ago
I'm a slow reader. It took 9 minutes! Foul, I say!
13.
by jason_oster 2mo ago
It depends on what is to be analyzed. How many requests per second are being served? How many error codes were delivered to clients? How quickly the service responded? Service logs without PII? All perfectly fine to aggregate and analyze wi
14.
by jason_oster 2mo ago
It's safe to say that most people romanticize their past experience. Anyone's "golden age" is someone else's "end times". Software has always sucked [1]. "Software crisis" was coined in 1968. The
15.
by jason_oster 2mo ago
> It can come up with something novel, but only by combining whatever present That's what artists do. Long before LLMs, Kirby Ferguson made this observation in "Everything is a Remix" [1] in the context of Copyright and IP
16.
by jason_oster 2mo ago
> Rather show me the engineers who want to become management. You're talking to one. Wanting agency and responsibility and having the drive to put in the work (for potentially brutal hours) is not exactly a common trait. It's a
17.
by jason_oster 2mo ago
Taking out the trash is not populist slop. If you have a bad product org, the right thing to do is replace it. If you have a bad engineering org, the right thing to do is replace it. It is difficult to draw any conclusions other than you li
18.
by jason_oster 2mo ago
I don't know if that's what agile was supposed to do, but replacing management with "anyone but leading engineers" is exactly opposite of what GP proposed.
19.
by jason_oster 2mo ago
I love opinioned software. If an idea of what the software is supposed to do conflicts with what the software does or intends to do, then the idea is wrong. What product people do (even good ones) is stretch the product to scratch every i
20.
by jason_oster 2mo ago
It's a get-what-you-pay-for thing. If coding is cheap, you get a low-effort, likely low-quality product. The conclusion is that coding is not cheap, only managers and business-minded decision makers are.
21.
by jason_oster 2mo ago
Coding is anything but cheap. You speak like someone who has completely forgotten how difficult it was to learn everything you now know by heart.
22.
by jason_oster 2mo ago
> The solution is to gut your product org, replace management with leading engineers, and hire some of your most fanatic users. They don't need to do anything other than give their opinions, and use the product every day. Put them i
23.
by jason_oster 3mo ago
FWIW, San Francisco was one of only three counties that voted against Prop 13.
24.
by jason_oster 3mo ago
It can, but you don't want to hear about it: Hand writing recognition is an application of AI.
25.
by jason_oster 3mo ago
Or pay publishers for textbooks?
26.
by jason_oster 3mo ago
> Your right to 3d print whatever you want is about to be taken away (in California). What are they going to do? Fine me for not updating my printer's firmware?
27.
by jason_oster 3mo ago
> but it's much easier to kill 10 people with a gun than it is with the other instruments - well except perhaps a car. Or explosives. https://en.wikipedia.org/wiki/Bath_School_disaster
28.
by jason_oster 3mo ago
> It's not just the time it takes to make the feature, you also have to consider documenting the feature, making sure it works well with the other features, making sure it's something customers actually want, making sure it&#x2
29.
by jason_oster 3mo ago
Discovering bugs and exploiting them is anything but laziness. We used to call that property cleverness. Being too clever has always had a negative connotation. My best guess is that there is sort of an XY problem happening in these cases.
30.
by jason_oster 3mo ago
Disobeying the rules makes perfect sense when the rules cannot or will not be enforced. If that isn't motivation enough to shore up problems in the evaluation environment, nothing is. Poor behavior will always result when code can be m

More ›