Hey, you can say that the Dolans should/could spend more, but I don't think you really want an owner who has solidified the team in Cleveland, has the fourth-best record in baseball over the past 10 years, and has seven recent playoff appearances in the graveyard.
The Haslams? Yeah, they should really sell the team, but I figure in about 10-15 years, they'll move it out of Cleveland.
The prevailing narrative here is that the team was actively looking to lose to acquire draft picks. Hugh Jackson was extremely good at losing, so he stayed.
The owner of the Cleveland Browns uses the team to generate more revenue. For NFL teams, performance has little to do with their value or ability to generate additional revenue.
There is no strong financial incentive to win in the NFL, aside from the owner's ego. The Browns' owner's ego is driven by money, and the result shows on the field.
From doing more research about this, it seems they don't want to use the good draft picks, but to sell them on to teams that do want to win.
The draft pick is itself a commodity that can be traded*, so by losing they get a premium commodity, that they can sell on, and by selling their picks they ensure that they continue to lose to get the valuable commodity.
I've written a few small projects in Ada, and it's a better language than it gets credit for.
Yes, it's verbose. I like verbosity; it forces clarity. Once you adjust, the code becomes easier to read, not harder. You spend less time guessing intent and more time verifying it. Or verify it, ignore what you verified, then go back and remind yourself you're an idiot when you realize the code your ignored was right. That might just be me.
In small, purpose-built applications, it's been pleasant to code with. The type system is strict but doesn't yell at you a lot. The language encourages you to be explicit about what the program is actually doing, especially when you're working close to the hardware, which is a nice feature.
It has quirks, like anything else. But most of them feel like the cost of writing better, safer code.
Ada doesn't try to be clever. It tries to be clear, even if it is as clear as mud.
This isn't new. It's been the same problem for decades, not what gets built, but what gets accepted.
Weak ownership, unclear direction, and "sure, I guess" reviews were survivable when output was slow. When changes came in one at a time, you could get away with not really deciding.
AI doesn't introduce a new failure mode. It puts pressure on the old one. The trickle becomes a firehose, and suddenly every gap is visible. Nobody quite owns the decision. Standards exist somewhere between tribal memory, wishful thinking, and coffee. And the question of whether something actually belongs gets deferred just long enough to merge it, but forces the answer without input.
The teams doing well with agentic workflows aren't typically using magic models. They've just done the uncomfortable work of deciding what they're building, how decisions are made, and who has the authority to say no.
AI is fine, it just removed another excuse for not having our act together. While we certainly can side-eye AI because of it, we own the problems. Well, not me. The other guy who quit before I started.
Mediocre devs previously couldn't complete a project by themselves and were forced to solicit help and receive feedback along the way.
When all managers care about is "shipping", development becomes a race to the bottom. Devs who used to collaborate are now competing. Whoever gets the slop into the codebase fastest, wins.
What hurts the most is that the em dash used to be a small, rebellious literary act that I truly enjoyed employing. A simple, useful hinge in a sentence where it could change its mind. Now? It indicates when an LLM got too frisky with clause boundaries and maintains a phobia of semicolons.
This year, I decided to start opening up the tarball of random utilities that's been accumulating on my machine for years: stuff42.tar.gz.
The first thing I cleaned up was TCL-Edit <https://gitlab.com/siddfinch/tcl-editor>, a small Tcl/Tk text editor I wrote a long time ago. After seeing the Rust clone of Microsoft EDIT, I realized the obvious next step was to build a Tcl/Tk clone of the Rust clone of Microsoft Edit. Recursion shouldn't be limited to code.
I also built a tiny URL system in Perl <https://gitlab.com/siddfinch/perl-tiny-url>, meant to run locally. The idea is simple: short URLs for internal/VPN resources per client. I usually spin up a small daemon (or container) per client and get a dashboard of links I use frequently or recently.
Security is intentionally minimal since it's local, which conveniently lets me ignore authentication and other responsible behavior.
Goal for the year: Continue to open stuff42.tar.gz, pick something, clean it up just enough, and release it, and not have it by the end of the year.
Might even choose a language that might even be described as "modern."
reply