In a world where any change I want is a prompt away, writing high quality, simple software becomes an exercise in conscientious restraint.

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.

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.

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

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

https://www.flocksafety.com/blog/axon-plans-to-sever-apis-wi...

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

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.

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

I think my current recipes app stores entries in the Recipe JSON Schema format[1]. This format is also useful since many websites will offer recipes in that schema. If I could make a conversion layer that transformed between a markdown version and the JSON recipe schema, that would probably be all I need.

* [1] https://schema.org/Recipe

Also, there's an awful lot of talk about "we in the scientific community" for someone who is still in medical school.

The main benefit of a flat file format for configs is that it can be added to source control and edited by any plaintext editor. If I kept config as protobuf, I would need special tools to handle it, which could be annoying (e.g. if I'm remoted into a remote system). It would also make it more difficult to see diffs between different config versions stored in git.