Live data from Hacker News

The peril of laziness lost

bcantrill.dtrace.org

71–80 of 148 posts

Re: The peril of laziness lost

#71
post #36

Earlier quoted context omitted.

I think we put too much negative emphasis on people who aren’t as gifted intellectually. In reality, the world works because of human automotons, honest people doing honest work; living their life in hopefully a comforting, complete and wholesome way, quietly contributing their piece to society. There is no shame in this, yet we act as though there is.

I'm not blaming you here, but I think "automatons" may be inaccurate. A lot of the jobs that seem menial would be utterly bollixed if done by an automaton. The people continually handle the edge cases and tiny discrepancies between formal procedures and how things actually work. Consider the many stories of people experience AI bots when they try to get vendor support for products. "Please let me talk to a real perso…

Anyone doubting this need only spend 15 minutes watching people using the self-checkout lines at the grocery store to see how good a good checkout person is...

Re: The peril of laziness lost

#73
post #63

Earlier quoted context omitted.

The Horizon IT scandal was not caused by poor code quality, the scandal was the corrupt employees of the UK government/Post Office. Poor quality code might have caused the error, but the failure to investigate the errors and sweep them under the rug was made by humans.

> Poor quality code might have caused the error, but the failure to investigate the errors and sweep them under the rug was made by humans. That's not quite correct. The root set of errors were made by the accounting software. The branch sets of errors were made by humans taking Horizon IT's word for it that there was no fault in the code, and instead blaming the workers for the differences in the balance sheets. If…

It was worse than that. Higher ups in the post office knew the system was buggy and still doubled down on it. Yes, if the accounting software wasn't terrible the whole issue would not have happened, but there were so, so, many chances for the post office to do the right thing afterwards that it's not at all fair to blame the results on the poor quality software, which very notably did not prosecute thousands of people for fraud while telling each of them they were the only ones being flagged by the system.

(THERAC-25 was a little more towards 'just bad software', but there were still systemic failures there as well).

Re: The peril of laziness lost

#74

Similar to bragging about LOC, I have noticed in my own field of computational fluid dynamics that some vibe coders brag about how large or rigorous their test suites are. The problem is that whenever I look more closely into the tests, the tests are not outstanding and less rigorous than my own manually created tests. There often are big gaps in vibe coded tests. I don't care if you have 1 million tests. 1 million e…

Yes, I've found tests are the one thing I need to write. I then also need to be sure to keep 'git diff'ing the tests, to make sure claude doesn't decide to 'fix' the tests when it's code doesn't work.

When I am rigourous about the tests, Claude has done an amazing job implementing some tricky algorithms from some difficult academic papers, saving me time overall, but it does require more babysitting than I would like.

Re: The peril of laziness lost

#75
Being a somewhat lazy individual myself, I'm wary of this statement. It feels too... comforting. "It's okay that I wasn't productive today, because laziness has merits".

I consider my laziness a part of who I am, and I don't demonize it, but I also don't consider it my ally - to get the things I care about done I often have to actively push against it.

Re: The peril of laziness lost

#76
post #65

Earlier quoted context omitted.

It's a struggle to get LLMs to generate tests that aren't entirely stupid. Like grepping source code for a string. or assert(1==1, true) You have to have a curated list of every kind of test not to write or you get hundreds of pointless-at-best tests.

> have a curated list of every kind of test not to write I've seen a lot of people interact with LLMs like this and I'm skeptical. It's not how you'd "teach" a human (effectively). Teaching (humans) with positive examples is generally much more effective than with negative examples. You'd show them examples of good tests to write, discuss the properties you want, etc... I try to interact with LLMs the same way. I cer…

It's going to be difficult for anyone to have any more "data" than you already do. It's early days for all of us. It's not like there's anyone with 20 years of 2026 AI coding assistant experience.

However we can say based on the architecture of the LLMs and how they work that if you want them to not do something, you really don't want to mention the thing you don't want them to do at all. Eventually the negation gets smeared away and the thing you don't want them to do becomes something they consider. You want to stay as positive as possible and flood them with what you do want them to do, so they're too busy doing that to even consider what you didn't want them to do. You just plain don't want the thing you don't want in their vector space at all, not even with adjectives hanging on them.

Re: The peril of laziness lost

#77
software engineering - let's break it down.

engineering is about applying rules of thumb to solve problems.

however what's not usually stated to most people in the profession - that 'software engineering' is also an art - which means do the most you can with constrains. at the edges that's when you create things that are notable.

do LLMs spitting code - fit the 'Engineering or Art' part. NO

Re: The peril of laziness lost

#78
post #3

> Generally, though, most of us need to think about using more abstraction rather than less. Maybe this was true when Programming Perl was written, but I see the opposite much more often now. I'm a big fan of WET - Write Everything Twice (stolen from comments here), then the third time think about maybe creating a new abstraction.

>WET - Write Everything Twice I've always heard this as the "Rule of three": https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...

Antymony with DRY

Re: The peril of laziness lost

#79
Oh spare me the cult of Larry Wall. His language was crap, and his pontification was unbearable.

That said, he's not wrong about laziness. I'd state it less cutely: Good software takes time, so be patient. The same can be said of most things created by people. Sure, there are flashes of inspiration, like Paul McCartney sitting down and just coming up with Get Back. But those are quite rare. And even in those cases, it often takes time to refine the idea to its final form.

Re: The peril of laziness lost

#80
As a counterpoint, perhaps there is a sort of "natural selection" which will drive better abstractions due to being more token-efficient. Albeit perhaps a relatively smaller effect.
Post reply on HN