Any substantial use of a system or solution will usually result in some sort of workarounds where users will try to get what they want if it’s not officially or adequately supported. Chris Siebenmann documented an example of users running heavy jobs on the university’s login server, something it’s not designed to do. This undesired usage was described by him as a desire path:
In a university, what you get in practice is more like a field with a certain amount of desire paths in it. You can build paths and exhort people to not step on the grass, but they’re going to do it anyway. And obviously, the more pathways you don’t build, the more people are going to make their own paths.
Read more...
Software
In general, I’m in favour of disclosing AI-generated or assisted code in commits. In recent months, I’ve been seeing more and more of them across various open source repositories, and it’s a good indicator to me on how the project was developed and is being maintained. I want to actively avoid using, relying on, or contributing to repositories that are AI-generated or heavily AI-assisted.
Disclosing these tools, or at the very least mentioning they were used, in a commit message allows me to judge the work that was done. If the AI use is excessive, it’s a signal that any contributions I make would be insignificant to the overall project, or would be overrun by agents. It’s also a signal that the author might not care much for the project.
Read more...
There are scripts that are designed only be run a handful of times, or maybe even once under rare circumstances. They are usually tested a lot of more times than they are intended to be executed, or when they are executed, their actions could be detrimental, this is where --no-dry-run option comes in.
In my career, I seem to have worked on a lot of system, or application migrations. I’m not sure if this is very common outside of the places I’ve worked at or if I’m just a harbinger of change. Depending on the migration the approach changes but there usually comes a time when a cut over to the new solution needs to be done. The steps leading up to, during and after the migration are typically crucial with rollback procedures in place in case something goes wrong. These steps would have been tested thoroughly before hand by mocking the system in various states. But here’s the thing, the actual cutover happens once. To prevent prematurely executing the script it’s nice to have a second layer of acknowledgement, the --no-dry-run option.
Read more...