Live data from Hacker News

The difference between "today's task" and "accretive work"

pluralistic.net

71–80 of 82 posts

Re: The difference between "today's task" and "accretive work"

#71
post #69

Earlier quoted context omitted.

The real trick is recognizing when "disposable" code has quietly become infrastructure

Over many years I've tried to (unsuccessfully) coin the phrase "Design for deletion." The code in front of you works today, but will become unfit for purpose and un-salvageable, and we want to ensure that when that inevitable end happens, there is a sane and safe way to systematically chop it out and replace it with something else, something you are not capable of predicting. There's substantial overlap with general…

Love this framing, thank you.

Re: The difference between "today's task" and "accretive work"

#72
post #59

Earlier quoted context omitted.

I could write more, but I think it actually is different. The addictive nature and the way it makes you more and more dependent on it is quite different from other tools. I've never met a builder who is addicted to their circular saw. These AI companies have stumbled upon the new cigarette. Did you know athletes in the 1920s would smoke cigarettes because they thought it improved performance? Cigarettes are just a to…

I use AI a lot but am not addicted to it. I know it seems something every addict would say, but simply it makes things faster. You can't really take responsibility for something it makes that you don't already know how it operates, or how should operate. That's the line between what you can sell to your client, or your boss, without it blowing up in your face when things go wrong. In theory everything I build with AI…

I've been telling myself these lies too. The truth is it sometimes gets it right, but you can't predict it. Yet you still try, every time. It nags at you to try another spin if you try to quit it. I know what addiction feels like and I've never felt it before from a tool.

Re: The difference between "today's task" and "accretive work"

#73
post #50

Earlier quoted context omitted.

The real trick is recognizing when "disposable" code has quietly become infrastructure

Exactly THIS! I found an excellent way to avoid premature abstraction and optimization and to write better software in general was to explicitly consider v1.x a throw-away. Build something expedient that works well enough to deploy in the field, get actual user feedback and system metrics (e.g., where are the actual bottlenecks). Do a few iterations on user feedback and system metrics. NOW , you are much further down…

So you rediscovered "build one to throw away", popularized in The mythical man-month, afaik?

Re: The difference between "today's task" and "accretive work"

#74
post #70

Does this read a bit incoherent and hard to follow for anyone else? This pluralistic website itself seems a bit chaotic..

Yes, the way the URLs are interspersed between short passages makes reading it difficult. It's like reading an article on a news site without an adblocker.

Re: The difference between "today's task" and "accretive work"

#75
post #69

Earlier quoted context omitted.

The real trick is recognizing when "disposable" code has quietly become infrastructure

Over many years I've tried to (unsuccessfully) coin the phrase "Design for deletion." The code in front of you works today, but will become unfit for purpose and un-salvageable, and we want to ensure that when that inevitable end happens, there is a sane and safe way to systematically chop it out and replace it with something else, something you are not capable of predicting. There's substantial overlap with general…

This is one of the pragmatic reasons that microservices can be a useful tool in a complex system. The enforced boundaries at every level - build, deployment, API, and team responsibility - make it easier to swap out, deprecate, or eliminate microservices than tends to be the case when the code is embedded in some larger context.

Re: The difference between "today's task" and "accretive work"

#77
post #52

Earlier quoted context omitted.

I could write more, but I think it actually is different. The addictive nature and the way it makes you more and more dependent on it is quite different from other tools. I've never met a builder who is addicted to their circular saw. These AI companies have stumbled upon the new cigarette. Did you know athletes in the 1920s would smoke cigarettes because they thought it improved performance? Cigarettes are just a to…

You haven't met a builder with a really top-notch tracksaw.

Don't get me wrong, I totally understand being in love with tools, because I love tools too. I fell in love with Emacs some 15 years ago and it's still going strong. I also love my santoku knife and if I had a tracksaw I'd definitely relish cutting boards. But those tools still need to prove their worth. Nobody is using the tracksaw for crosscuts because they can't imagine using a mitre saw any more. That's not how it works. But despite LLMs getting it wrong about as often as they get it right it's just try again, tweak prompt, try again, without ever questioning whether this is really the right tool for the job, because, unlike normal tools, it's hitting those dopamine spots again and again, for very little input. It's an absolute classic recipe for addiction.

Re: The difference between "today's task" and "accretive work"

#78
post #70

Does this read a bit incoherent and hard to follow for anyone else? This pluralistic website itself seems a bit chaotic..

Yes, the way the URLs are interspersed between short passages makes reading it difficult. It's like reading an article on a news site without an adblocker.

It's a bit jarring, but after reading a couple of articles from the site (it gets posted here often) you adapt to its rythm

Re: The difference between "today's task" and "accretive work"

#79

"There's plenty of space for "disposable and single use software." Sure, to a trained software engineer, this might be "bad code" but doing today's task has value, even if the code that performs that task isn't "accretive."" Grant me the serenity to accept the bad code i shouldn't fix, the courage to change the code I can, and the wisdom to know the difference.

That quote also resonated with me. It reminded me of "Perl, the write-only language"-meme of yore. And I think there is a place for perl, just like there is a place for bash one-liners. The authors example is personal software. The things we write to scratch our own little itches, that do not need to be shared or developed together with other people.

I also think there are areas where automating things is clumsy.

My pet peeve is that macos is really unfriendly to people solving their own problems.

It is really hard to script anything.

I know that there are shell scripts. I know that there is applescript and automator.

In my experience, if you want to do some script-level task to make your life easier - the effort required is high and the chances of success are uncertain.

Is this by design? Do they want you to buy your tools and scripts instead of easily creating them yourself?

If you have the perseverance to automate things, you have to dig deep into the apple-invented compiled languages objective-c or swift.

Now with ai, I suspect people will be able to leapfrog over the no-scripting canyon and do the things they want.

Post reply on HN