I've been thinking about that recently too. The original drive behind the whole "worse is better" movement was that the software should remain simple and solve a simple problem. It's better for the software to do one small thing well than get bloated with unneeded features.
In a world where any change I want is a prompt away, writing high quality, simple software becomes an exercise in conscientious restraint.
Yeah, there were a couple good points, but a lot that felt off when I read this article (beyond the fact it was largely LLM-generated).
That said, I will say I personally love an optional --wait flag. I've written so many bash scripts where I have to do the status looping manually when all I want is to just do the operation, then do something else once it's complete. For the most part I'm willing to sacrifice a little control there for simplicity.
I 100% agree with your take on the "Two Way I/O". I hate having to figure out how to coerce tools to give me the right output file when all I want is for them to cleanly write the output to stdout, the progress messages and errors to stderr, and let me deal with how they get redirected. This is a core principle that's existed in CLI tools since forever. Agents and humans are both very capable of stringing together other tools to get the results you want.
It's really a shame. I grew up in a frugal household that venerated Dave Ramsey, and there was a ton of moralizing of finances that didn't need to be moralized. Stuff like "debt is always evil, buying frivolous things like fancy coffees is stupid", etc.
There are unfortunately a lot of people that base their spending and saving decisions not on what they actually value or what their goals are. Rather, they base them on fear of breaking the moral rules.
This is one of the reasons I like YNAB (both their app and their method). One of their core principles is to align your spending -- including future spending, aka saving -- with your values. Spending on the wrong things isn't good, but neither is saving without clear purpose.
My wife and I both came from fairly frugal households growing up, so frugality is often our default. It's been a helpful exercise to periodically ask ourselves "what do we actually value, and what tradeoffs should we make", then update our plan to match.
It's not inherently contradictory, just like using a calculator could be considered cheating depending on the context. If you're just learning basic arithmetic, a calculator is cheating since it shortcuts the path to learning. OTOH in calculus, a calculator is necessary. You still have to have a deep understanding of the concepts and functions to succeed.
It's still a new tech so I'm not surprised a lot of teachers have different takes on it. But when it comes to education, I feel like different policies are reasonable. In some cases it's more likely to shortcut learning, and in other cases it's more likely to encourage learning. It's not entirely one or the other.
Yeah I was getting the same feeling. I wonder if an equivalent request to California police agencies that contract Flock technologies would work though.
Sounds like a similar approach to this service: https://addy.io/
I use it all the time in conjunction with Bitwarden to generate unique emails per site. You can have notes in each email, and they show up in a small banner on in the forwarded email. And each one is individually disable-able, so you can easily cut it off if you see spam from it.
I was really interested in this space and made my own homegrown tool for this. I used it for a while until I discovered Addy and switched over. IIRC there are similar services by Mozilla, Apple, and Proton.
The 90-90 rule may need an update for a POST-LLM world
"The first 90% of the code accounts for the first 9% of the development time. The remaining 10% of the code accounts for the other 9000% of the development time"
A while ago when I was working with PowerShell a lot, I got spoiled by the easy inclusion of `-DryRun` flags in all my scripts.
Nowadays I still use the technique for a lot of the tools I make. I typically do a Terraform-like approach: create a plan, validate the plan, render the plan to the user, exit early if we're in dry-run mode, and apply the plan as the final step. Whether dry-run is enabled by default depends on the risk of the operations and who will be using the tool.
This makes it exceedingly clear what actions the tool will do. Plus it has the added benefit of being able to split the plan and apply steps into two separate steps. For example, you can create a plan, serialize it to JSON, store it (e.g. in VCS, Jira ticket, whatever) then apply it during a change window.
plan = createPlan()
print(plan.string())
if (dryRun){
return
}
plan.apply()
In a world where any change I want is a prompt away, writing high quality, simple software becomes an exercise in conscientious restraint.