terrabitz

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.

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()

I feel like the distinction between the two is fairly contrived these days. I'm an SRE, and we're constantly building tooling to help us better manage infrastructure, improve reliability, improve DX, etc. On the flip side, we also push a lot of the responsibility for infrastructure management to our devs: we maintain the modules and IaC pipelines, and the developers hook up the building blocks they need. It can actually help avoid burnout because our team doesn't become a bottleneck for infrastructure provisioning.

Say what you want about IaC in Go or other programming languages, but it can definitely help strengthen the whole "developers own their infrastructure" since they don't have to learn an additional language syntax.

> The best rule of thumb is, if you’re not sure whether something needs to be said right now, hold off and see what happens. You can always say it later if it turns out there’s no way for the conversation to move forward without your correction.

From the context, it sounds like it's not so much about "don't correct people" as much as it's about "don't uselessly correct someone to showcase your own knowledge and not advance the conversation".

Nice, that's a big differentiator! I use git sync with my mobile vault, but it's very hacky (using a Termux cronjon) and it's often flaky. Plus I have to open up Termux any time I need to troubleshoot, which is a bit annoying.

I like having my recipes in digital format, but the lack of notes, annotations, and editing history is a big weakness in most of them. I would love one that offered a git-like interface for recipes: it could track the "diff" of a recipe as you tweak it, and you could "commit" each variation along with notes about the outcome.