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()
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.
Honestly, not a bad idea. I'd just have to deal with figuring out a good, standardized text-based format. I already use a git-backed Obsidian markdown knowledge base for most of my notes, so it would make a lot of sense to incorporate recipes too.
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.
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.
Meh, this was a survey conducted at 4 different companies. It only proves correlation, not causation. And even then, it only proves it at these 4 companies since they didn't use random sampling from a larger population. Most of the rest of the article is unfounded speculation about the cause of this correlation. Definitely not an impressive study by any means.
I have a cheap drawing tablet I purchased for about $20. It works wonders for whiteboarding and diagramming things for my remote coworkers. Especially when used in conjunction with tools like Google Jamboard, it's almost as good as an in-person whiteboard.
Doesn't seem to be a very credible article. There's an awful lot of pontificating about the disastrous outcomes of COVID-era policies without any supporting evidence. The whole thing reads a bit like a non-sequitur.
Also, there's an awful lot of talk about "we in the scientific community" for someone who is still in medical school.
Not the original commenter, but our team has recently been dealing with this exact thing. It depends on the specifics of your use case, architecture, etc., but there is a lot of value in keeping application Terraform code in the same repo as your applications. The main benefit is that it's a simpler developer experience to make infrastructure changes related to their specific app. You can still have a big repo with a bunch of internal modules and core infrastructure code, but having the apps have their own infrastructure code can lead to developers having more autonomy in the DevOps process.
As a transport I agree. But as a config file format? I'm a little skeptical.
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.
In a world where any change I want is a prompt away, writing high quality, simple software becomes an exercise in conscientious restraint.