I was going to mention this dark pattern too. So many sites have no way of removing a payment method. It should really be illegal, but until then I will use virtual card numbers.
Otherwise, in cases where you have a very pernicious party that will absolutely not stop charging your card, you can contact your bank and have them cancel that card. When they do, there is often a convenience feature that allows pre-existing subscriptions to continue to bill using the old card info. You need to make sure you tell the bank that you do not want that to happen for this card. They have a way to shut that feature off and that will remove the ability for the company to abuse that feature. You can still end up accruing a debt with them that they may try to collect on eventually so this is not a suggested method to get out of a subscription, but when you have tried everything else, it does seem to work in my experience.
“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.”
― John Ousterhout, A Philosophy of Software Design
I remember reading somewhere people can be broken down into 3 types. It applies in programming as well as in a restaurant kitchen or your family's garage cleanup.
*I'm probably remembering everything wrong but it was something like:
Cowboy: move fast and break things style. Sorta what you mentioned above.
Duct tape: most people are a form of this. Work on something just long enough to get it working but it's not beautiful and not prepared for the future or edge cases.
Professor: these get very little done because of the amount of planning put in and tend to over think most things. But almost never have to come back to a job since it's done properly and to completion.
Any team without a blend or with too many cowboys or professors is going to have a tough time.
That's why I refuse to touch code made by these tactical tornado. It's simple, you'll get all the blame, and none of the recognition. Anyone who is in that situation: Don't it even if it means you'll get fired. You'll get fired anyway.
The only exception is, if management come to understand what went wrong there and how it should be done. The chances of that are very slim, however.
Peer reviews catch tactical changes that are strategically poor. There are times when it won't get sign-off from reviews. In other times, when it gets merged, at least it is documented that the solution is tactical, people know it, and it was rationalized by the team. A plan may even be put in place to revisit the subject and do a proper job; there could be concrete ticket for that.
Reviews also slow things down. You can't move quite as fast and break as many things if everything goes through a review pipeline.
Test-oriented development helps. Sometimes people find it easier to develop a tactical solution that somehow gets certain tests working and then refactor for strategy. They don't have to feel they have wasted time on the tactical solution because they get to reuse parts of it, and use it as a jig to guide the improved solution.
Ron Garret's space debugging story from NASA has an element of this. They had a custom language in Lisp which made certain guarantees, like deadlocks being impossible. But some coder went around it, possibly due to a tactical reason, using some lower level code outside of that paradigm.
Sometimes people aren't being tactical; they really don't understand the system fully to know that some obvious solution will hit a snag.
This lines up with my experience. The person making constant "tactical" changes looks super productive. But they just deferred the productivity cost. You end up continuing to deal with their fragile mess for the rest of the lifetime of the product.
I fully understand that there are circumstances where true tactical changes do make sense, but the tradeoffs should be considered up front.
The way to handle this, I believe, is to make sure that the bug reports resulting from the "tornado"'s work end up back in their own lap. Don't let someone else fix them, especially not someone on another team. It has to be done non-antagonistically, of course. But it's the only way to make it clear to both management and (more importantly) the dev themself that there is a tradeoff for speed.
There used to be a bumble bee that, I was convinced, would come around to play with my dog, a Labrador. It was entertaining to watch. When the dog was outside the bumble bee would hover near his face to get his attention. Once he noticed the bee he would growl, jump, and bite at the bee but not in an aggressive manor. It was in his playful tone, the same as when I played with him and his toys. Every time he lunged at the bee it would dart back and always stay just out of reach. Then the bee would zoom in closer and they would repeat this for a few minutes until one of them would get distracted. As far as I know they never made direct contact. RIP good boy
At an old apartment there were some bumble bees that lived in my neighbour's fence (or at least that's what it seemed like) and every time I'd sit outside, they' come out and fly around all chill. Nothing aggressive ever, they'd just fly in front of me and sometimes I watched them and otherwise I'd just sit and work. I don't know what my point is anymore... bumble bees!
Yep. I hate all flying insects as they make me tense up like some fight or flight response... probably from being stung by hornets a billion times as a kid.
That said, I learned to tolerate the carpenter bees on my deck because they'd bonk all the wasps away.
Hover flies compete with other makes for the privilege of hovering in the 'best' spot over a bush or wherever. They'll fly at whoever invades their space and then return to hovering and defend it.
Think of a food chain, bugs are near the bottom meaning they are a food source for many other creatures like birds, reptiles, small mammals, fish. Fewer bugs means less food for mice, that means fewer mice, leads to less food for snakes, leads to fewer snakes, leads to less food for birds of prey, leads to fewer birds of prey.
There are many chains like this where bugs are a vital source of food. If there were zero bugs then these chains would collapse. Also, bugs are needed to pollenate many fruit bearing plants.
Maybe it is implied by being on lwn.net, but the list is limited to open source orchestration platforms. In a broader discussion I would expect to see AWS ECS mentioned.
An absolutist wouldn't have an issue with a teenager posting public flight data about his jet. Given his maturity level, it wouldn't surprise me if the entire stock purchase started as an attempt to shut down @elonmuskjet.
reply