>I remember accidentally nuking history of a few years - that wasn't fun.
If you are on linux I can't recommend enough using a COW filesystem like btrfs and zfs with snapshots. I can't count the amount of times i have wiped or edited something by mistake and then restored it within seconds with it.
In case you haven't noticed, the era of sw devs being able to leave and find better conditions/pay anytime they want is gone. But even in the good old ZIRP days, leaving for better pay is not an action that can be taken collectively. OP said "workers" not "worker": if you want to improve conditions at a given company, collective bargaining is all you have.
> As of v9.0 in August 2024 the project relicensed from MIT to GPLv3+, with the explicit goal of staying copyleft and resisting future commercial capture of the codebase.
The value of copyleft for decentralization is too often overlooked.
Yes but ... people will sign that paper for almost any severance. Consider the alternative (don't sign, get a lawyer etc) -- many folks will just sign to get whatever's on offer
OMG I forgot all about cucumber, but wow the "cucumber cycle" of old sounds a lot like LLM psychosis of today. As in, the solution to cucumber problems was always to invest more into cucumber! Add more operations! Integrate more things into it!
Did cucumber go away? I never hear about it anymore.
> I was waiting for the "so I tried coding something with an LLM myself, and I found..."
Why? Most of the article was about the productivity of teams.
> This is a very academic approach to the subject - read what other people have written about it
Meta-studies have tremendous value. He's asking a simple question: if LLMs are changing the world, let's look at what studies are showing.
> My experience has been remarkable, and, like others, I'm finding real joy in being able to move past the code to actually design and play with whole systems and architectures
Great! What does that have to do with the age-old problem that software development doesn't scale to teams well? It is indeed a "50 year old problem", so please tell us how LLMs solve it.
I had to go re-read the article to make sure, but it doesn't address teams or scaling to teams at all, so I'm not sure why you're asking about that?
The article is talking about inherent vs accidental complexity, amongst other points, and if the author had actually tried developing with an LLM, they might have worked out how LLM coding does address some of this.
- The DORA report is about organizations not individuals
- Mythical man-month is about organizations not individuals
- No Silver Bullet: "I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation." Clearly he's NOT talking about the 10x dev building the whole thing themselves, which everybody knows is faster, better, probably doesn't even need a spec. Organizations are who need specs -- they have clients, business people etc. An organization with a single developer moves at light speed -- but this doesn't scale.
Nobody's disputing that LLMs give multiples for certain development tasks. The main thrust of the argument centers on how unimportant coding time is ... for organizations. Coding time is a HUGE lever if you're the one dev building everything, but that's not a repeatable pattern.
Meh, I'll concede that Fred Brooks was mostly writing about developing software within an organisation, and therefore writing about teams.
Coding time is important if it gates experiments and spikes. If you have to work out your architecture on paper because actually coding it up is a serious expense, then it becomes harder to experiment with different designs. In an LLM world where coding time is very cheap, it becomes easier to experiment and try things out. Developing an entire architecture and then abandoning it because it turned out that it didn't scale too well, or couldn't handle some edge cases, is not a major mistake or problem any more. There's no pressure to keep old code because it cost a lot of money to develop. You can spike an entire system, decide that it was a useful experiment, but didn't work, delete the repo, and go get lunch. This is new, and important.
I guess it's what you think the work of sw dev is.
> Developing an entire architecture and then abandoning it because it turned out that it didn't scale too well, or couldn't handle some edge cases, is not a major mistake or problem any more.
Cool, but I can count on one (two?) hands how many times in a 30yr career I had the opportunity to do this, except when I "made the opportunity" by coding the solution fast enough that the PHBs couldn't say no. LLMs should be even better for this of course.
But it's rare, and those times I forced the issue were good for my career but not always for the team. Most of the time, once an organization has a working product, you want to stay in the lanes, roughly, of that product, which is IMO where the coding time advantage vanishes.
My question is whether espresso-method coffee has all the same properties. The study itself clearly states "brewed coffee" and they brew the crap out of it ("extraction in boiling water for 8–10 min"), I can't take brewed coffee on the regular b/c it upsets my stomach.
Not sure about Ocaml but with Haskell you can use ghci/`cabal repl` and get blazing fast reload of a web app as you develop. Tbh a lot of haskellers don't take advantage of this IMO.
Ocaml seems to have a REPL as well, not sure how it works outside of Emacs (in Emacs with utop looks good what I am trying).
Haskell is so so correct that it tends to get a bit on the way and you tend to encode everything in the type system. This is a blessing for correctness and a curse for other stuff (tracing, debugging, adding side-effects).
This is the reason why I am looking at Ocaml instead of Haskell: not so pure, more pragmatic and supports imperative programming well.
I would counter that it was probably their startup-oriented fintech focus and execution that led to their success. I love good tech culture as much as the next HNer but I've seen companies with great tech die because of bad biz focus.
I might further argue that the startup-y fintech culture led to good tech culture. The fact that they didn't start as a bank (as opposed to say SVB) means that they didn't have to be as conservative, or integrate with some horrific ancient tech stack.
I'm pleased they've had such success with Haskell, but much like Jane Street and OCAML, I think the language choice is almost accidental*, as much as the companies would like you to believe otherwise.
I would like to know however what they're doing for front-end. I would guess that all of this Haskell is back-end only.
*EDIT by "accidental" I mean to the business side. Jane St had some good trades, Mercury had great focus and execution. They also have some good tech :)
Edit: I RTFA'd, containers can't adjust `privacy.resistfingerprinting`. Boo