The point was that developers (or indeed people in general) do not work the way wolves do, and I’m not reading great arguments to the contrary.
The point was that developers (or indeed people in general) do not work the way wolves do, and I’m not reading great arguments to the contrary.
You assume "lone wolf" types are "one trick ponies" who can't learn. You also assume the only interesting problem space for these people is technical/code.
The lone wolf has a big limitations in transitioning to scale: 1. managers do what the article suggested, and stay out their way. The lone wolf never gets the experience of being managed, so it is difficult to transition to manage others. 2. they don't get why others don't "get it". e,g the solution is clear , the code can be done in a day, the comprehensive system model in their head should be shared by everyone.... it takes time to understand that the average engineer works slow and steady on a small scale understanding.
I will suggest there is a lone wolf type manager too. This is not a productivity skill, but an adaptivity and mobility skill.
Hint: think of the widespread expression used in terrorism debates: "Lone wolf". It's a self radicalized/motivated individual acting independently and alone.
There are plenty of lone wolf developers, but you won’t find them in large teams. Or if you do, they’re dysfunctional. On their own, a lone wolf engineer is not generally able to complete large, important pieces of work. Some do! But they are exceptions.
The tool tells you what it would do in the current situation, you take a look and confirm that that's alright. Then you run it again without --dry-run, in a potentially different situation.
That's why I prefer Terraform's approach of having a "plan" mode. It doesn't just tell you what it would do but does so in the form of a plan it can later execute programmatically. Then, if any of the assumptions made during planning have changed, it can abort and roll back.
As a nice bonus, this pattern gives a good answer to the problem of having "if dry_run:" sprinkled everywhere: You have to separate the planning and execution in code anyway, so you can make the "just apply immediately" mode simply execute(plan()).
For something like in the article, I’m pretty sure a plan mode is overkill though.
Planning mode must involve making a domain specific language or data structure of some sort, which the execution mode will interpret and execute. I’m sure it would add a lot of complexity to a reporting tool where data is only collected once per day.
With that being said, my 10th floor apartment has a 5g radio installed by one of the major carriers and I am still placed one block wrong when looking on Google Maps.
4G (LTE) networks had more cell sites so could give better precision multilateration, but by then smartphones were taking over the market and they usually had GPS receivers.
So, no one competent is going to do this, domains are not encrypted by HTTPS, any sensitive info is pushed to the URL Path.
I think being controlling of domain names is a sign of a good sysadmin, it's also a bit schizophrenic, but you gotta be a little schizophrenic to be the type of sysadmin that never gets hacked.
That said, domains not leaking is one of those "clean sheet" features that you go for no reason at all, and it feels nice, but if you don't get it, it's not consequential at all. It's like driving at exactly 50mph, like having a green streak on github. You are never going to rely on that secrecy if only because some ISP might see that, but it's 100% achievable that no one will start pinging your internal host and start polluting your hosts (if you do domain name filtering).
So what I'm saying is, I appreciate this type of effort, but it's a bit dramatic. Definitely uninstall whatever junk leaked your domain though, but it's really nothing.
Btw, in this case it can’t be paranoia since the belief was not irrational - the author was being watched.