> There is basically nothing the captain is legally barred from doing while the plane is en route.
This is pretty wide of the mark. They have a lot of authority, yes, as it's the flipside of the flight's safety being their responsibility. They still aren't allowed to assault a passenger, say, or commit tax fraud, or needlessly break the air laws.
Also, while the plane is en route? As in, the captain throwing someone out of the plane mid-flight?
That's completely wrong. Tailgating is prohibited in all 50 states. Driving fast while too close behind another vehicle is a major cause of serious accidents. This is real basic stuff that every driver is expected to know.
Trying to normalize tailgating, as you are doing, also tells us something about your attitude. Do you generally try to intimidate others into doing what you want, or only when driving?
Their final paragraph is straight up conspiracy theory. Little wonder they grumble about Wikipedia in their other comment, rather than linking to a serious source. Tough to do that when no credible sources support your absurd claims.
It was a private 2017 desert retreat where five wealthy tech and hedge-fund investors flew out media theorist Douglas Rushkoff, ostensibly for a speaking engagement.
Rushkoff wrote it up first as a Guardian essay and later expanded it into his 2022 book Survival of the Richest: Escape Fantasies of the Tech Billionaires.
The problem's super duper obvious if you studied history, but it is also pretty obvious if you can think about second order effects. In collapse the wealthy obviously need security forces to hold on to their stuff, but in a collapse your stuff will - presto changeo - become the security force's stuff. Essentially the singular founding story of all European royal families. Barbarian general took the house, banged the wife, now he's king. Or King-Sound. Kai- Zar
At the end of the day all these little lords and lordettes figured out the time honored lesson that to be actually safe you want to make friends with the locals. And that's part of being new king types as well. But "making people like you" isn't a popular notion with the Revenge of the Nerds types who love this "Lord of the Bunker" kind of thing.
I've seen zoo chimpanzees make a mockery out of this sort of device in VERY short order, and I would dread to impose it on a Delta Force psychopath who also has more higher degrees than I do. Because he's going to know who it was who did it and have all sorts of ideas about what he's doing about that. So the basic premise is also idiotic.
Sorry, I was a little more snide than I usually am on HN, it's been a long day.
This sounds a lot like the tactical tornado archetype.
From A Philosophy of Software Design by John Ousterhout:
> Almost every software development organization has at least one developer who takes tactical programming to the extreme: a tactical tornado. The tactical tornado is a prolific programmer who pumps out code far faster than others but works in a totally tactical fashion. When it comes to implementing a quick feature, nobody gets it done faster than the tactical tornado. In some organizations, management treats tactical tornadoes as heroes. However, tactical tornadoes leave behind a wake of destruction. They are rarely considered heroes by the engineers who must work with their code in the future. Typically, other engineers must clean up the messes left behind by the tactical tornado, which makes it appear that those engineers (who are the real heroes) are making slower progress than the tactical tornado.
> you never use “git annotate” or your IDE to see who wrote a line of code whose purpose puzzles you, and go to the commit message to see what they were trying to accomplish? This is invaluable to me as long as commit messages are clear.
You're thinking like someone with a mature understanding of version control. Plenty of developers seem set on going their whole careers using git like beginners.
That sounds clever until you remember tools exist to solve actual problems.
Treating simple workflows as inferior is like saying a carpenter is amateurish for not using every attachment in the workshop. Some teams don't have enough upstream issues that they need to lean on git in the way you do maybe?
Think of a major FOSS project in a technically challenging domain. Every single one of them insists on proper version-control discipline. [0,1,2,3,4]
If enough of the following apply strongly enough to your project:
* Very small codebase
* A one-person project, or a very small team where everyone can be expected know the entire codebase and you don't bother with code-review
* Not doing anything technically challenging
* You don't care about the other advantages of disciplined version-control, such as the ability to meaningfully revert a commit, or to more easily associate a bug with a feature
then sure, you can get away with sloppy use of version control, or even no version control at all. The same applies to various other aspects of software development. Skillful structuring of code doesn't matter in a very small codebase. The drawbacks of dynamically typed languages aren't a real problem in small codebases. Documentation might not be worth writing up. The list goes on. It makes sense that there's generally less call for the various aspects of the 'craft' of software development in such projects. The same applies to other disciplines. You don't bother with CFD modelling for your paper airplane.
I'm not convinced there's really any upside to the sloppy approach though. Developers with the skill to write decent commit messages (plenty of developers lack this), and otherwise make skillful use of version control, tend to make it a habit and always apply the disciplined approach. It's like NASA's old rules for software: The rules act like the seat-belt in your car: initially they are perhaps a little uncomfortable, but after a while their use becomes second-nature and not using them becomes unimaginable. [5][6]
> Treating simple workflows as inferior is like saying a carpenter is amateurish for not using every attachment in the workshop
I see it differently: what I'm proposing is developing mastery over a core tool of the craft, and applying it consistently in our work. We'd expect the same from a competent carpenter or cook.
Again, in my experience, that isn't it. It's like NASA's rules. People who write garbage commit messages and have a chaotic and unconsidered version control workflow, generally lack the skill to do otherwise. As they lack version control skills, they haven't had the opportunity to internalise the benefits. Those with the skill to make disciplined use of version control tend to do so on every project, as the effort required is modest and is repaid even on minor projects.
We're talking about low-hanging fruit here. It's not like adopting the MISRA C programming style, which really does severely restrict the programmer.
Sloppy use of version control doesn't make you more effective. It just doesn't work that way.
Torvalds himself writes up proper commit messages even for his toy projects. [0][1] I really doubt it takes him much time or effort. You really think he's not pragmatic?
This is pretty wide of the mark. They have a lot of authority, yes, as it's the flipside of the flight's safety being their responsibility. They still aren't allowed to assault a passenger, say, or commit tax fraud, or needlessly break the air laws.
Also, while the plane is en route? As in, the captain throwing someone out of the plane mid-flight?
reply