The peril of laziness lost
101 points by carlana
101 points by carlana
Take, for example, brogrammer-of-note Garry Tan, who has been particularly insufferable about his LLM use, bragging about his rate of thirty-seven thousand lines of code per day
Leadership bragging about lines of code? I'm shocked!
Funny enough, a story about a good friend of mine. His first job out of university (which wasnt exactly aligned with what he'd studied but was better than no job) had a lot of coordination work around organising volunteers, resources etc. The entire department basically ran by emailing excel spreadsheets around.
There was a lot of manual input, copy pasting etc. While not a programmer, my friend is pretty smart and knew it could be improved.
He looked into VB to automate some of it, just a sprinkling here and there as it was probably intended.
Management got wind and soon he was told to keep adding more and more to this automation. He told me at around 3000 lined he discovered loops, at 10,000 lines he discovered he could define his own functions.
He knew it was crazy, he told management they needed to hire a real developer, to pull it out of Excel and make a real app, with a real database instead of emailing spreadsheets around. But no budget, they couldn't do it.
He left after 6 months, finding a job more aligned with his studies. A couple of times a year he'd get emails asking him to come add more functionality, or adjust some behaviour. He hated it, he would tell them again it was a bad idea, but would offer to do it at a very high hourly rate over the weekend, and each time they said yes because no one else could go into his spaghetti.
People love to talk about sunk cost fallacies. But I know enough stories like this where I feel like the term "reverse sunk cost" is more appropriate.
While I understand the point about "laziness" here, the wider applicability of the term also means that you could apply it to programmers who do not review LLM output (this being "lazy" in delegating all the work to the LLM).
I personally prefer Ousterhout's tactical/strategic distinction as a a crisper formulation. Wall's notion of "lazy" is really strategic in disguise, because of the work needed to actually get the code in place. But then, earlier, you also had the option of being "lazy" (as in tactical) by just copy-pasting whatever random thing you found on StackOverflow. Now, StackOverflow is replaced by an untiring LLM.
"Laziness" is imprecise, but it's pithy and comedic, and so everyone's familiar with it; I haven't read Wall's book, yet I heard about the three virtues as a teen. (I've been meaning to read Ousterhout though—I assume tactical/strategic is from A Philosophy of Software Design?)
The "official" definition of laziness from Wall's book:
The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it.
How that applies to coding-without-thinking (misuse of LLMs, Stack Overflow, etc) is that it's a false economy. If you're using your tools unsustainably, you might save labor early on, and you might even make something useful to others! But it could result in a rat's nest of code that someday won't fit in your LLM's context window, or whose bugginess will alienate all your users. Digging yourself out from that will cost more labor in the long run.
(Assuming your goal is to build something that grows in scope/lifetime/reliability, of course. If those don't matter for the project at hand, I suppose you can be as reckless as you want and still be Lazy with a capital L.)
The old concept of laziness as a virtue, doesn't hold quite the same way in the age of LLM generated code as is it did in the last few decades.
I built my skill around the laziness virtue. Always looking for ways that could save me effort. Small and concise code. Simpler rather than complex. Thrive for canonical forms.
We don't know yet what the future holds. But LLMs for sure put all this into question.
The most prominent entry in my CLAUDE.md is the quote "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away".
It remains to be seen whether this actually helps avoid its natural tendencies to constantly add yet more code, but that along with aggressive review and refactoring cycles does help my claude-assisted code end up much closer to what I would have written manually.
Have you tested this context quote? Let’s say ten times on the same task, and then ten times on that task without the quote to see any impact?
I hear lots of people sharing their config tricks with zero idea if they work as intended or do anything at all. The people I have seen testing different prompts are the people doing live demos, which still mess up and are often presented as “annnd, fingers crossed <hits enter on prompt>”.
Some studies have shown that popular advice might reduce success rates, for example.. So, I understand the spirit of what you’ve shared, and also want to raise a caution flag that we tend not to know the true effects of these things and it can be counterintuitive.
No I haven't, and I agree and have experienced that adding things to CLAUDE.md can have the completely opposite effect of what was requested, so mine is very brief. My current setup seems to work pretty well, so I've left it alone.
The inability of the brogrammer crowd to shut up and actually ship things says it all. It’s just performative productivity.
I've observed the LLM version of hustle porn: "I'm keeping 10 agents running and switching between them, and making sure they run in the evening and at night too" just to demonstrate how busy you are.
Considering that LLM bill per token, the companies that run them have clear incentive to output more. This also affects input since the code that was output will be read by LLMs afterwards.
Even optimizations like consolidation at night and refactoring entail using more tokens.
The fact that more code means more maintenance and associated costs is well known by C-suites. I still don't know what actually goes through their minds (assuming happens there).
I think this “lack of laziness” does harm beyond producing bad implementations; along with more LOC is better, comes merging is the same as shipping, software is an asset, etc. The laziness should apply to not adding unnecessary features to current systems and not creating new ones. The cost of running them in production is being ignored (presumably because a lot of this software never gets to production or its original author is not the one held accountable for it).