3 ms·

"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 val

"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.

wodenokoto 4mo ago
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.
- m463 3mo ago
  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.
lifeisstillgood 4mo ago
>>> 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. Fantastic
KolibriFly 4mo ago
The real trick is recognizing when "disposable" code has quietly become infrastructure
- toss1 4mo ago
  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 the road to a true final spec, and you can use that real information to design the real system to scale up on. One Test Is Worth A Thousand Opinions. This plan first tests your ideas against the real world of users, hardware, and data flows, and keeps a lot of technical debt out of the scaling system. I discovered it a bit by accident, having previously been really big on early abstraction and planning, but sort of having to do this in one startup, and it was a real eye-opener how well it worked.
  - kaffekaka 4mo ago
    So you rediscovered "build one to throw away", popularized in The mythical man-month, afaik?
- dhruvmittal 4mo ago
  Law of disposable infrastructure: The more temporary a fix is intended to be, the more likely it is to become load-bearing permanent infrastructure
  - RetroTechie 3mo ago
    General rule: temporary lasts longer than you think. (in today's context: especially if you upload temporary Thing to GitHub & co)
- Terr_ 4mo ago
  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 principles like loose-coupling and modularity, but the framing changes how people apply them: Instead of trying to create durable Amazing-Thing which will be used for many years by people amazed at your foresight making it "flexible" and "modular" and "customizable", you focus on creating Inoffensive-Thing which can be easily killed off or dismantled for useful parts.
gota 4mo ago
> 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. Well, It's really early in the morning and I've got the quote of the day already
- minitoar 4mo ago
  This is a slightly modified version of the serenity prayer of AA fame.
  - gota 4mo ago
    Yes, I know, but I substituted that one in daily usage for just shouting "SERENITY NOW" at maximum volume.
    - narag 4mo ago
      That seems similar to the "God give me patience, but I need it RIGHT NOW" prayer.
    - Terr_ 4mo ago
      > shouting "SERENITY NOW" at maximum volume. I'm imagining the Silicon Valley scene where the character Gilfoyle has set up a loud death-metal automated noise that plays whenever the price of Bitcoin meets certain conditions... except the trigger is some kind of code-quality metric, the effect is my machine shouting at me to become serene.
- douglee650 4mo ago
  live, laugh, cruft
  - cgriswald 4mo ago
    Though I walk through the valley of technical debt I shall fear no eval
    - 4mo ago
stuaxo 4mo ago
We used to keep it in it's own separate thing: Microsoft Excel.
delecti 4mo ago
Part of why I like "tech debt" as a term. Much like actual financial debts, some tech debt has a low enough interest rate or is easy enough to declare bankruptcy on that it's not worth paying off.

wodenokoto 4mo ago

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.

m463 3mo ago
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.

lifeisstillgood 4mo ago

>>> 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. Fantastic

KolibriFly 4mo ago

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

toss1 4mo ago
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 the road to a true final spec, and you can use that real information to design the real system to scale up on. One Test Is Worth A Thousand Opinions. This plan first tests your ideas against the real world of users, hardware, and data flows, and keeps a lot of technical debt out of the scaling system. I discovered it a bit by accident, having previously been really big on early abstraction and planning, but sort of having to do this in one startup, and it was a real eye-opener how well it worked.
- kaffekaka 4mo ago
  So you rediscovered "build one to throw away", popularized in The mythical man-month, afaik?
dhruvmittal 4mo ago
Law of disposable infrastructure: The more temporary a fix is intended to be, the more likely it is to become load-bearing permanent infrastructure
- RetroTechie 3mo ago
  General rule: temporary lasts longer than you think. (in today's context: especially if you upload temporary Thing to GitHub & co)
Terr_ 4mo ago
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 principles like loose-coupling and modularity, but the framing changes how people apply them: Instead of trying to create durable Amazing-Thing which will be used for many years by people amazed at your foresight making it "flexible" and "modular" and "customizable", you focus on creating Inoffensive-Thing which can be easily killed off or dismantled for useful parts.

gota 4mo ago

> 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. Well, It's really early in the morning and I've got the quote of the day already

minitoar 4mo ago
This is a slightly modified version of the serenity prayer of AA fame.
- gota 4mo ago
  Yes, I know, but I substituted that one in daily usage for just shouting "SERENITY NOW" at maximum volume.
  - narag 4mo ago
    That seems similar to the "God give me patience, but I need it RIGHT NOW" prayer.
  - Terr_ 4mo ago
    > shouting "SERENITY NOW" at maximum volume. I'm imagining the Silicon Valley scene where the character Gilfoyle has set up a loud death-metal automated noise that plays whenever the price of Bitcoin meets certain conditions... except the trigger is some kind of code-quality metric, the effect is my machine shouting at me to become serene.
douglee650 4mo ago
live, laugh, cruft
- cgriswald 4mo ago
  Though I walk through the valley of technical debt I shall fear no eval
  - 4mo ago

stuaxo 4mo ago

We used to keep it in it's own separate thing: Microsoft Excel.

delecti 4mo ago

Part of why I like "tech debt" as a term. Much like actual financial debts, some tech debt has a low enough interest rate or is easy enough to declare bankruptcy on that it's not worth paying off.