Lone wolves are not happy animals, though. They are less successful in hunts, they can’t take down large prey at all. They don’t generally produce offspring. They’re an unfortunate effect of the social structure of wolves, where young males who cannot find a place in the pack are expelled.
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.
Whether or not the natural world has such wolves, its a well formed fictional archetype.
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.
you need to think in a different plane of isolation. i would say the pure machiavellian manager is a lone wolf in that the relationships hold no weight as interpersonal relationships, only as functional relationships - no different to how you would manage and integrate code.
I like that idea! For an application like Terraform, Ansible or the like, it seems ideal.
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.
No need to overthink it. In any semi-modern language you can (de)serialize anything to and from JSON, so it's really not that hard. The only thing you need to do is have a representation for the plan in your program. Which I will argue is probably the least error-prone way to implement --dry-run anyway (as opposed to sprinkling branches everywhere).
> you can (de)serialize anything to and from JSON, so it's really not that hard
First, it is hard, especially in at least somewhat portable manner.
Second, serialization only matters if you cannot (storage, IPC) pass data around in-memory anyway. That's not the problem raised, though. Whatever the backing implementation, the plan, ultimately, consists of some instructions (verbs in parent) over objects (arguments in parent). Serializing instructions any other way than dropping non-portable named references requires one to define execution language, which is not an easy feat.
> The only thing you need to do is have a representation for the plan in your program.
That "only" is doing lifting heavier than you probably realize. Such representation, which is by the way specified to be executable bidirectionally (roll back capabilities), is a full blown program, so you end up implementing language spec, godegen and execution engines. In cases of relatively simple business models that is going to be the majority of the engineering effort.
> First, it is hard, especially in at least somewhat portable manner.
I'm curious what portability concerns you've run into with JSON serialization. Unless you need to deal with binary data for some reason, I don't immediately see an issue.
> Such representation, which is by the way specified to be executable bidirectionally (roll back capabilities), is a full blown program
Of course this depends on the complexity of your problem, but I'd imagine this could be as simple as a few configuration flags for some problems. You have a function to execute the process that takes the configuration and a function to roll back that takes the same configuration. This does tie the representation very closely to the program itself so it doesn't work if you want to be able to change the program and have previously generated "plans" continue to work.
> I'm curious what portability concerns you've run into with JSON serialization.
The hard part concerns instructions and it is not technical implementation of serializing an in-memory data structures into serialization format (be it JSON or something bespoke) that is the root of complexity.
> You have a function to execute the process that takes the configuration and a function to roll back that takes the same configuration.
Don't forget granularity and state tracking. The opposite of a seemingly simple operation like "set config option foo to bar" is not a straightforward inverse: you need to track the previous value. Does the dry run stop at computing the final value for foo and leaves possible access control issues to surface during real run or does it perform "write nothing" operation to catch those?
> This does tie the representation very closely to the program itself so it doesn't work if you want to be able to change the program and have previously generated "plans" continue to work.
Why serialize then? Dump everything into one process space and call the native functions. Serialization implies either strictly, out of band controlled interfaces, which is a fragile implementation of codegen+interpreter machinery.
Right, but you still have to define every ”verb” your plan will have, their ”arguments”, etc. Not need to write a parser (even Java can serialize/deserialize stuff), as you say, but you have to meta-engineer the tool. Not just script a series of commands.
It's not strictly related to the original theme, but I want to mention this.
Ansible implementation is okay, but not perfect (plus, this is difficult to implement properly). For cases like file changes, it works, but if you install a package and rely on it later, the --check command will fail. So I am finding myself adding conditions like "is this a --check run?"
Ansible is treated as an idempotent tool, which it's not. If I delete a package from the list, then it will pollute the system until I create a set of "tearing-down" jobs.
I worked in telecoms back then, and I don’t recall 3G having any precise location mechanism. Most handsets back then did not have GPS receivers, and as such they could only tell you a pretty rough estimate of your position, based on multiteration from nearby cell towers. The best I could get was within a couple of hundred meters in an urban area.
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.
Because if they take Amazon to court, they no longer have a business. Amazon effectively is a large part of American retail, which they cannot afford to not be on.
I'm fairly sure they don't; at least historically, the goal has been to improve the situation on the ground, not to move production elsewhere. (I think this was the post in which they explained that thinking, but I didn't reread it just now: https://www.fairphone.com/en/2025/10/15/lets-talk-about-fair...)
Universities in the Netherlands usually do not have the free cash for stocking up on parts, in general they take them in your get a loaner and they repair it afterwards or send it back to the manufacturer. But i guess it is a plus the design team is in the same country.
They’re hardly pioneers; my wife’s employer switched from Apple to Fairphone as the pre-selected option a few years ago. They have about 10k employees.
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.
reply