“It’s Easier To Ask Forgiveness Than To Get Permission”
quoteinvestigator.com
quoteinvestigator.com
Which makes me wonder, are there cultures wherein permission is easy, but forgiveness is not?
Weird dances like that are one of the reasons why it's difficult for foreigners to fit in :-)
Western cultures have them too but they are so ingrained you don't notice them. This video highlights some of the more interesting ones (e.g. refusing to accept an apology being offensive): https://www.youtube.com/watch?v=pfO9gL28pAs
I didn't catch that. He only offered a somewhat contrived example of it being rude to "take back" an apology (which is, of course, not a thing) after being told it "wasn't owed".
His thesis was, AFAICT, that this is an example of empty gestures, that we don't really mean it.
However, that falls flat with the apology example. An apology that is actually sincere isn't something that can be taken back, so it could only be empty if it were insincere, and in his anecdote, he did not even imply insincincerity.
He talks about the words not making sense when analyzes, which I assume is in reference to the fact that "you don't owe me an apology" sounds like a rejection of the apology, but, it isn't. If it's truthful and can be interpreted literally, then no offense was taken in the first place. If it's untruthful, then offense was taken but the apology was accepted (and presumably the insincerety was a lie told to spare further bad feelings). Either way, no offense remained on the part of the apology recipient.
None of that was empty gesture, and there was only one opportunity for lying to spare someone's feelings (though this was not called out in the video).
The rest was about Japan and the old Soviet bloc.
I think you need to come up with a better example of a "weird dance" in Western culture, preferably with more observers than just the (usually two) participants.
In WW2 that generally was up until the squad level, with a focus on NCOs (non-officers leading ~10 men) taking initiative; in earlier times infantry required a bit larger formations to be able to fight efficiently, so initiative of relativerly lower-ranking officers.
That's not how I've seen "ask forgiveness" used in industry. Usually it's a self-confident maverick who goes off and does something that breaks the rules of organisation or process. I did it once; I thought I was doing the company a favour. Information Security came down on me like a ton of bricks, with good reason, and I nearly lost my job. There was no forgiveness. The Director ensured that it was well publicised and a lot of people learned from my hubris.
The phrase is a crock and should never enter your mind. If you're sure Your Way is best, ask for permission or get consensus. If you get neither, lodge your protest with your superiors and get on with something else. Then in a year's time perhaps people will look back and consider you a visionary, or a hot-headed fool...
That said I think your cautionary tale is really valuable and your uncompromising view toward the phrase actually serves to emphasize how serious everyone should take it. If I were you I wouldn’t change a thing. Actions can have real and sometimes dangerous consequences.
We should always try to understand what we’re putting at risk (as much as we can) so at the very least we can weigh the unknown risks even when asking permission. If you can’t even list the risks off mentally that’s probably a good sign that you should stick to asking permission.
I could have used the US as an example too, as well as Russia by the end of world war 2, they went on to have a bit too loose of a command structure with their nuclear arsenal.
In what way were these successful warfighting organizations exemplars of the merits and nurturing of independent thought and initiative, though?
I don't know that I agree with any of this argument trying to relate business practices to military practices -- civilians and soldiers have some fundamental differences -- just trying to imagine it philosophically.
Perhaps the entirety of the European continent (or most of the world re: Germany) fighting back meant the war was essentially unwinnable no matter what, but perhaps the successes they did have were due to the process they used.
I do agree that trying to draw business practice conclusions from the very different military setting. This includes the quote of the OP.
Stealing that.
(Assuming you didn't actually mean "wax poetic"?)
See "The influence of Arab culture on Arab military effectiveness", Kenneth D. Pollack (https://dspace.mit.edu/handle/1721.1/11219). Pollack pulls up examples that don't even involve materially superior Western armies, such as conflicts against ill-equipped Iranian, Kurdish, or Sub-Saharan African forces.
Sounds really interesting, any examples?
An excerpt is below; what I can say from my understanding is that upper echelons of officers are deliberately understaffed, and superiors are encouraged to give general objectives (or sometimes even just areas of operation) to their subordinates rather than detailed orders; and much planning and communication is done peer-to-peer among officers of the same rank.
========
Among the many lessons that can be taken from the history of the Israeli Defense Force (IDF) in combat, one key issue is the high degree of officer casualties, often proportionally up to three times higher than enlisted casualty rates. Hence, leaders in the IDF regard initiative as not just a point of pride, but an absolute necessity to overcome leader casualties during battle. IDF Officer Candidates undergo training designed to force them to develop initiative (some of these training techniques will be recommended in the final chapter). In training, it is also emphasized that the commander will accomplish his mission according to the general spirit of the command. Additionally, IDF standing orders promote initiative (as well as aggressiveness an ' offensive spirit):
1. When orders can't get through, assume what the orders would be.
2. When in doubt, hit out. The short route to safety is the road to the enemy hill.
The stat about 3x officers casualty rate is surprising, I would have imagined the enlisted would generally become cannon-fodder (for lack of a less demeaning word). I guess that's what makes the Israeli forces unique.
Not only does it apply in a company setting but if you were to build something on your property without permission from neighbours / government you will have to tear it down and face the fines even if in the end no one have an actual problem with it.
Like "planning permission"? Don't they have this everywhere?
Seems fair enough to me. Built structures have such an impact on the environment it absolutely makes sense to regulate construction.
Fences don't require planning permission nor do temporary structures [0].
If you build a house without seeking permission though they will make you tear it down again.
[0] http://www.dublincity.ie/main-menu-services-planning/frequen...
It would mostly tie in with European environmental regulations too.
That's not to say these regulations are flauted from time to time, or if you were out of site on your own estate you could do what you want. But there have been cases of people being told to demolish their houses.
Here's an example [0] where it should be clear why planning laws are needed ...
[0] https://www.irishtimes.com/news/crime-and-law/courts/supreme...
It's the degree to which people in a society capitulate to power and to which those in power are aloof to their subordinates.
There are some very interesting patterns in that measurement indeed.
[0] http://www.clearlycultural.com/geert-hofstede-cultural-dimen...
That's a really loaded and almost certainly inaccurate premise.
For example, here in the US teenagers usually tell their parents that they are going out. In my culture, teenagers usually ask their parents if they can go out.
And I cannot remember ever been denied when I was teenager. I think if I had simply told my parents that I was going out, they would have stopped me to ask more question or even stopped me from going out.
In an institutional context when we ask for permission from higher ups, especially publicly, we put them on the spot to clarify some rule or make a pronouncement which rules will be enforced and which won't. Sometimes you have to break rules, or perversely are even expected to, just to get things done. Asking permission means the boss has to tell you that you cannot break the rule officially, even though they know the rule has to be broken for the task to be accomplished. So not only do they deny the permission, they also resent you for forcing them to make the pronouncement and preventing anyone in the near future from accomplishing the task at hand efficiently. In other words even as they respond with "No, Peter, you cannot bypass filling out 10 TPS reports just to fix this bug" in their head they are thinking "Why the fuck didn't you just do it. Why did you have to ask me about it in front of everyone..."
Large power structures usually have rules you cannot break, you can break if you want to, and perversely enough, you should or are expected to break. Winning or losing the politics game often comes down to simply understanding which rules belong to each set.
Most requests for permission are probably going to direct managers at the bottom because that’s who most employees report to. I can’t imagine taking every request to my director. He’d ask me why I’m wasting his time and tell me to do my job.
Case in point, years ago we used CVS for version control. I had a strong feeling that if I asked to research how could we make the switch to git, it would be allowed but relegated to the back of the backlog, which usually means never to be done. So I did it without asking permission in between tasks, and when I proposed we switch to git I already presented our many dozens of repositories in a git server with the full history preserved. I didn't even need to ask forgiveness.
Managers are very wary of comming any resources to ground breaking things since they are unproven. I’ve experienced this multiple times. If you feel strongly about something, just go do it!
If it's expected that a rule is to be broken to get a task done, the risk of the backfiring will be borne by the rule breaker. If i am am employee, i will not risk breaking any rule that i have not gotten in writing from somebody higher up that they're OK'ing.
Or, i will have to be paid more for taking on the risk.
True but irrelevant. In my experience organizations are just like people in that every single one of them is dysfunctional in some capacity. You find ways to work around the dysfunction when it can't be fixed and life goes on.
Totally. But there are many organizations like that.
> the risk of the backfiring will be borne by the rule breaker.
But the higher up is in a better position to defend him/her. If you ask for permission then both of them are at fault.
Asking for permission (or asking anything), in a complex domain is difficult and always carries a cost.
In two-way-door decisions, forgiveness IS easier. But an incorrect, one-way-door decision is hard to "forgive" ("accountability" and the like).
Well-run companies (e.g. Amazon) understand this very well and have processes to only require permission only in one-way-door decisions.
I'm curious about how one decides whether a decision even is one-way or two-way? I can think of some contrived examples (demolishing a building is one-way, deciding where to get lunch today is two-way) but what about more complex and realistic examples? Is it that the cost to reverse that decision is so high that it's effectively a one-way choice? And can you make a one-way idea into a two-way idea in some scenarios?
It is memorable, but wierd.
As opposed to a two lane road with traffic flowing in either direction.
That can be seen by some management as "getting things done". And quite often that person feels vindicated when her solution works.
But that person is not able to realize the cost of the mistrust of the team and detachment of the job nor to think about the possibility that the other solution not only have worked, but it will have been way better.
At my job, I have to arbitrate between team members and teams. I will flag anyone that decides to "ask for forgiveness instead of permission" and notify their manager. I don't like to work with people that think that they are so good that don't need to present their arguments like the rest.
So when going for forgiveness instead of permission, it is wise to think:
a) If your way is so good, you should be able to get what you want with arguments.
b) If you force everyone else to follow your way without their consent, you are not a leader you are just abusing the system.
c) That it works does not mean that was the best option.
d) That other people can also have done the same does not mean that they are worse than you, it may be that they see a bigger picture that you can't see.
It is still possible to go for it. But you need to be accountable for the consequences.
a) Arguments don’t work because team doesn’t listen and/or doesn’t want to change because they wish to stay in their comfort zone.
b) The responsible manager is incompetent and/or does not understand the things he/she’s responsible for and/or is a micromanager which kills any spontaneous action.
c) Those who see a bigger picture do not care to or cannot explain it and/or keep it a secret.
d) Sometimes the best option is to just do it (and improve it later) instead of going through a slow and energy consuming process of gathering consent etc.
e) Software architects
You can make such actions visible (and hold people accountable after the fact), but blocking engineers from taking action is a no-no!
It is a problem if there is no communication. To bypass all formality only hides the real problem is not solving it. It is not easy to know who is right. That is part of my job when one person is in a fight with the rest of the team my job is to listen to everybody and help to get a decision thru. I have seen all combinations, the team is right the lone ranger wrong, the lone ranger is right and the team is wrong, all are right and one path needs to be decided, all are wrong and I help them to find a different solution.
> c) Those who see a bigger picture do not care to or cannot explain it and/or keep it a secret.
Again this happens and it is a big problem that needs to be addressed. To hide it doing things rogue stile only perpetuates the problem. Sometimes is better to get everything to a halt until information is shared than to tag along for years of painful fights.
> e) Software architects
Yes. I am one. And my main problem is the arrogance of other architects, not the managers, product owners or developers in the teams. :P
As greedo mentions in another reply to my points, you really can't have "lone rangers" on a team who do this without a valid excuse.
The point about architects was somewhat joking; of course there are good ones (such as yourself judging from your comments), but in my experience most of them are at best a useless burden and at worst an utterly destructive influence on teams.
There is no right and wrong. There are only opinions and stylistic preference. There are solutions that are better and there are ones that are worse. But when you black box it and look at it from the outside, it either works or it doesn't.
Everything is a spectrum, but there are also clear parts of the spectrum that contains death, and clear parts of the spectrum that are better than the others.
Works is not an acceptable standard. Imagine if we built bridges with the criteria that “well I crossed the river on it, so it works”. What tonnage can it support, how many years can it stay viable, does it fail gracefully if we drive something heavier than intended over it, what amount of wind can it take... none of those things are captured by “it works”.
Similarly for code. If your answer is “well something changed, so we need to refactor” or “well that wasn’t in the requirements so we can’t do that” then your solution didn’t work in the first place, because works implies scalability, extensibility, reliability etc.
Those are not style or opinion. Making anything “work” in the now is trivial. Building things that are not fragile to change and time is engineering.
My team just had an coworker leave for another team. This coworker was very smart, very hardworking, and very dedicated. But he continually chafed against any sort of documentation or communication. He also chafed against any established standards or policies; pretty much did what he wanted, and was never really called on the mat for these issues.
He got away with this because he was a "rockstar." He could solve some pretty hairy problems fairly quickly. But explaining these fixes to others was difficult for him, and many of his solutions were MacGyver-esqe. He had come from a small shop where he wore many hats; we're a large enterprise with lots of teams. This means that communication is probably the most vital skill for team success.
Since he didn't share or document his changes and fixes, the remaining team members are now left trying to divine what he did. While I blame him for a lot of this behavior, I primarily blame his manager who continually tolerated it. Ironically, this manager is shocked and confused as to why he lost his rockstar.
Someone will say "false dichotomy", to which I say, "maybe".
Undocumented code and decisions are just a more slowly accumulating cost, it is no less costly than bad or failing code.
This is a reason I love having outspoken and extroverted devs. The guys who love to talk so much that they will explain in extreme detail and at length.
I was reading through an old bug yesterday, and the guy who had done some work in that area had left a 5 paragraph explanation of what had gone wrong, what he thought may have caused it and some things he was planning on doing. Having that written down was invaluable when I got to the thing a year later.
Process rigour is not the goal. Communicating what is strange and different is. If you have guys who do that naturally, great. If not, you need some process.
In my experience, the devs that talk the most, know the least about how things actually work. They churn off trying to explain something and are either subtly or blatantly wrong, and you've got to reel them in before they get down the rabbit hole and misrepresent reality too badly. It can be catastrophic if they are interfacing with management or customers.
It seems to be a manifestation of the classic "baffle them with bullshit" strategy for dealing with ignorance or incompetence.
Coming up with innovative solutions to complex technical problems requires you to be in the weeds, and think non-linearly (e.g. using intuition); while communication requires abstraction to (preferably) only the most important elements, and linear composition of the ideas into speech or text.
How does this relate back to forgiveness over permission. Because with forgiveness the person is humbling themselves to the superior or group and falling back in line. That's more psychologically pleasing as the superior or group gets to reassert their will over a person again. Permission (especially if its not related to something they were assigned to do) can come across as diverting off course and pulling peoples will towards theirs, more so if the request requires action on their part.
Often the outcomes play out as much on power and us as social beings as we are rational.
That's so true. I feel like most of the time asking for permission also comes with request to take responsibility for your actions and help. You ask for permission, they have to trust and help you. Too much to ask.
Honestly, I've been living for 25 years and I'm not sure I've EVER seen anybody give permission in this sense to anybody. If it happens, it's something different. Either the person giving permission doesn't care or the person asking for permission really notifying in the form of asking permission. Or somebody didn't have time or energy to think properly. Or was deceived. So on. I don't know, maybe I'm taking in too far. But in any case asking for permission is weak and rude coming from position of lesser authority, and nice otherwise.
Also I should note that this authority dynamic changes with rapid pace from context to context. Everything affects it: one moment you are supposed to be meek subordinate programmer and the other you're expected to be highly qualified professional with key domain knowledge. I belive there can even be dozens conflicting beliefs, each with different strength. Those are in short memory, then there are thousands more withing short reach, and millions possible depending on what happens in the next few seconds.
It means you're are not doomed and can navigate your way out of many difficult social situations and get what you want anyway, regardless of your social status. Most likely your status is fine. Most likely all this dynamics can be circumvented with a few jokes and uplifting remarks.
Now I think I've contradicted myself somewhere...
Involving more people in a decision is usually going to result in better decisions, as it will benefit from more viewpoints, experiences, and critical review.
The tradeoff of group decision making is that it is expensive and slow. Even just a single hour meeting with 8 people is a whole man day of work.
On the other hand, distributed decision making (where individuals or smaller groups make decisions) is faster and cheaper, though on average probably produces less optimal decisions.
Whether centralized or distributed decision making is optimal depends entirely on factors like how much better the centralized decision is than the distributed one, at what cost that improvement comes, and the cost of later correcting a sub-optimal decision.
In other words, the real world is complicated. Soothing bromides like "It's Easier To Ask Forgiveness Than To Get Permission" or whatever its opposite is don't have very much value.
That's not an excuse to just go ahead from the start and say "eh, finding a consensus is too hard, I will just do it", but it is a reason to accept that at some point everything has been said, just not by everyone. And then a decision has to be made or you will talk forever.
> It is still possible to go for it. But you need to be accountable for the consequences.
This works in both directions: Are they also accountable for the success or is it a team success then? I see this pattern of not being able to get any decisions made, then hope that someone makes a decision and when it pans out "aren't we a great team? yes, yes, we are" and if not "They decided to just do it, it's their fault" and so on - you either share the wins and losses or you share neither.
That's why IMHO you need very small teams with a lot of freedom to decide. Then this small team can find consensus much more quickly. The most effective teams I've worked in were 2-4 people.
You are right. People that think of themselves as 10x developers are the ones that do that and will slow down everybody else.
Really productive developers help others and speed up all the company.
I have worked with some people that one can call "10x developers", even that I don't agree with the term. They were good, they were friendly and willing to help the business and their fellow developers.
And they ask for permission and share their ideas with everybody. Their product owner was also amazing and they had a great synergy. Back then I was a manager. And my job was to make sure that things did not change.
Its application is to achieve your goal or enforcing your decision regardless of superior's stance.
Other wording i know is (loosely transtalted) to put somebody against a fact (as opposed to decision).
It precisely because overriding a done deed is harder that arguing against or disallowing it.
If I decide to go out and code a prototype without asking anyone anything, where is the harm in that? You can criticize it after it is done. You could have done the same thing. And you can always throw it out.
And in my view, this precisely is "leading by doing". Linus Torvalds didn't seek consensus before he wrote Git.
In another response, you write, arrogant people are the biggest problem. I don't think doing something on your own is arrogant at all.
And I think, "being accountable for consequences" is exactly the "forgiveness" part. Although I am not a fan of hierarchical decision making systems.
I don't understand this point. Are you suggesting coding a prototype on your own time? Otherwise if everyone in a team is free to choose to code prototypes who gets the actual work done?
Bringing those prototypes to production is another matter. In any organization, there are processes that need to be followed to onboard a new application, platform, pattern, etc. If those aren't followed, the implementation won't be nearly as effective—especially long-term.
Indeed production is another matter.. "I'll just slip in this new crypto routine I wrote and ask for forgiveness later..."
It's the office responsible for processing TPS reports.
This is at a 25,000 employee healthcare system. Bureaucracy is inevitable, but agility is still essential.
Our manager doesn't have a clue how systems work, so it's up to us to find the best way. I know the various areas we need to develop to push the system forward and it is up to me to find the best way to do it. If I learn something new that makes me rethink something, then I am more than welcome to revisit it and try out some new things. If it ends up with a better system then we all benefit. At the end of the day the work that needs to get done does get done.
Obviously I do have to use my judgement to allocate time appropriately. If there is a customer screaming at accounts because they were overcharged or whatever, then it is quite obvious I need to resolve that issue rather than work on a new way to style our buttons, but for the majority of the time it is up to me.
I do also spend quite a lot of my own time working on various things where it is a bit ambiguous as to whether it is 'proper' work or not. I enjoy the work I do because I don't feel like I am working in a sweat shop..
Maybe I'm just lucky to have always found a job where management trusts the developers.
When solving pretty much any problem that I don't have an existing cookie-cutter solution for, I do some prototyping as part of the process of figuring out how it works. Sometimes I do this for arbitrary things that are irritating me, or that I think might be worth looking at.
Nobody is sitting over my shoulder looking at everything I do and I'd be right out the door if that was ever the case. I'd expect professional software engineers to spend at least a bit of their time working on this sort of stuff!
Well, of course this is how normal development works. This is the work I am talking about that would _not_ get done because the OP was working on a prototype to solve some _other_ problem.
I think the key thing here is to ask "What is the impact on other people if I just do the thing?"
In the case of building the prototype, its either "Well, now they need to spend time looking at the prototype", which would be the case no matter what communication medium you used or its "Well now JS spent 4 days doing that instead of what was on the roadmap. On the other hand, we have a prototype of X" which is a bit of a gamble and depends on what people were depending on you for.
Working code is the easiest part. No one every throws it out and we are doomed to maintain the shitty prototype code for years. I find for internal software / consulting: "working code, ends arguments" but for enterprise software it is exactly the opposite.
It's idiosyncratic code that doesn't scale to a team developing it. It's has no tests and no thought to broader usage. There is no documentation. It fails apart after you put load on it, want HA, load-balancing, disaster recovery. Almost all code works at the small scale. It's so hard to prove to even mid-range developers why an architecture that "works" doesn't really work.
When you mix developers coming from the opposite spectrum it is disastrous.
I'm confused why you seem to be so sure that in the anecdote you shared, this isn't exactly what was going on. Could it be you have some unconscious bias against the person who took that action, leading you to see them as a rogue cowboy instead of a wise leader?
The rest of the team was pissed off. A leader is followed, a rogue cowboy leaves everybody else behind and without the information that they need to do their jobs.
But I agree that it is difficult to say if it is one or the other from the outside. That is why it is so important for management to be present and to have direct communication with all the development team. "Lazy" management tends to trust whoever screams the loudest instead of expending the time to fully understand the situation and listening to everyone involved.
You are right. With just my description, it is not possible for anyone to know if it was one or the other. And in fact, it was more grey that I have described. Taking into account all the information I gathered, I still believe that it occurred as I described.
A corporate entity should have someone who has authority to do so, is willing to make those decisions, and accepts responsibility for their consequences even when bad. In principle this is the CEO role.
But much more often the right choice is essential, paralysis is better than the wrong choice, at least for a while, so we can afford to dither while we get the choice right. Of course if you're sure you're right this is frustrating - why wait for others to see your POV. But I have very little trust in anybody who hasn't noticed that they're often wrong. Such a person is inevitably short-sighted and their judgement untrustworthy, whereas those who know they're sometimes wrong should be patient to find out if this is one of those times.
Knowing whether you're facing a "any choice is better than no choice" situation is much easier than knowing the right answer, and I think "easier to ask forgiveness" is about people who take this approach when they know that permission is an option and choose not to take it. We should try to make permission easier, and forgiveness harder to avoid rewarding this undesirable behaviour.
Finally though sometimes choice is an illusion. It is not worth anybody's effort to give or deny permission for the inevitable, and we shouldn't praise the "decision" to accede to it. Recognising that something is inevitable and thus not subject to choice is trickier, and you can waste a lot of time discussing whether to do A or B when everybody in the discussions knows actually C will happen and the choice won't matter. Learn to let it go.
That said, doing that is a calculation and is done to achieve the organizations mission. That may be restore a customer out of service (sorry, we’ll do it tomorrow, busy) or hit a milestone that matters on time (we’d love to, but expediting some change process is a lot of work).
Unfortunately, in these situations I’m empowered to make tactical changes, but not to make more valuable strategic change. From my perspective process and controls are there to make things go faster, not as a weapon to make sure folks leave at 4. The trains need to run.
This can also be ego and attention seeking behavior masquerading as trying to 'get things done'. It seems to be driven more by the need to stand out than accomplish anything and puts everyone in peril for individual glory.
Casual references to 10X have no credibility without performance metrics. 10xers will have to earn the trust of the team and will automatically have it with a track record like Linux Torvalds on Linux or Ussain Bolt on 100m or its just hubris and posturing that will damage team productivity.
No doubt the quote by itself it broad generality is not helpful. Does that quote apply to assault or murder? Definitely not.
The quote is probably most helpful is risk-averse, at least moderately dysfunctional bureaucracies, and where the forgiveness-asker is actually right.
Applied to the wrong thing in the wrong way, or on the wrong day (there are no rules)... it's wrong. This (ironically) makes proverbs and religion a bad mix.
Don't argue with the devil. Measure twice, cut once. Grab the bull by the balls. Great company at a fair price, not fair company at a great price. Show must go on. Show, don't tell. It's how you use it that matters. Who cares what colour the cat is. Quality over quantity. There but for the grace of...
If you like your statements airtight, you don't like proverbs. Airtight statements require too many words. We can find exceptions to all these rules.
EDIT/PS: reading over what I wrote, proverbs are interesting. proverb meta analysis required.
Horns.
If you are the type of person who is comfortable going in an independent direction in a group effort, you need to be able to assess the skills of those around you objectively, and you need to be able to ask good 'meet in the middle' questions when your objectivity needs re-evaluation.
A team member may do what is best for one instance you observe versus the thousands of other times you ignore them following instructions in spite of the fact that they may potentially have valuable information that could be very useful for the team as a whole.
>It is still possible to go for it. But you need to be accountable for the consequences.
We all do. Whether it's forgiveness or permission it's still the same problem when you work on a team.
> I will flag anyone that decides to "ask for forgiveness instead of permission" and notify their manager.
I don't know your dynamic and I'm not pretending to. But it's pretty easy for me to say "aren't you doing exactly the same thing you are calling out?" except from a managerial perspective, instead of whatever you consider 'ground zero' to be for business decisions.
> I have seen this abused.
I'm sure you have, and I'm not doubting that either, and no, that's not sarcasm. I'm sure your experience is relevant, but it's important to weight your entire set of a priori information / observations / inferences and assumptions with a 'maybe that's all wrong?' perspective too, at least in my opinion.
> And quite often that person feels vindicated when her solution works.
Try to exist in a world where you force yourself to assume everyone is just smarter than you, because you just assume they all have more information and greater awareness in their heads than you do. People wind up judging themselves more carefully, and people wind up taking note of their errors more carefully, without it having to be explicitly pointed out to their detriment and embarrassment (IMO)
Vindicated might be just another word for "thank god I finally did something unique and correct"
For some of the other examples, such as marrying someone, if you go ahead and get married without asking, it signals a higher mutual commitment. In some sense, it more strongly suggests you love each other and are not merely social climbing.
I think an article about the logic and practicalities behind this could be fascinating.
Asking for permission puts the responsibility of the decision on the person being asked, which makes everything slower and more conservative.
Just doing it and rationalizing it afterward tends to be more efficient, and helps to captures upside sooner rather than wasting time worrying about the downsides.
Moreover, after the report has been fired, there's probably still a mess to clean up. Obviously it's not the report who needs to take care of it. It's whoever is responsible for that area, meaning the manager or whoever they can assign to that task.
I'm not saying there are no consequences for an individual contributor who makes a mistake. I'm just pointing out that, at the end of the day, a manager is responsible for the actions of their reports. That's the whole point of their job.
Once married, it would be infinitely easier to ask her father’s forgiveness, than to beg his permission beforehand.
It was tradition at one time to ask the permission of the woman's father.
“I asked God for a bike, but I know God doesn't work that way. So I stole a bike and asked for forgiveness.”
-Emo Philips-
If I can get by without permission and instead ask forgiveness, the total time spend on meta-work is significantly less, and ironically we do a better job because we don't want to do something unsanctioned that goes wrong.
I can see why this phrase caught on, I'm surprised there's no reference from before 1842, since this feels like one of those pre-industrial slogans.. Something you'd find more related to police or a parent than an institution of work.
Many monumental breakthroughs were accomplished by disregarding permission, and rebellious attributes are attributed to people like Stephen Wolfram[0] and Albert Einstein. The MIT Media Lab even has an award for disobedience [1].
This mindset, though, can manifest into an unhealthy obsession with breaking the rules. An uncontrolled expectation to "ask forgiveness" can lead to murky moral territories. Where do you draw the line between accepting rebelliousness and enforcing the law?
[0] https://en.wikipedia.org/wiki/Stephen_Wolfram#Education_and_...
"The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man."
Forgiveness will always be given for a "great success."
Oftentimes, I will contact someone associated with the community for a product I am building and ask them if they want to help promote the product once it's out. They take this as some sort of partnership where I have to get their permission to publish my products or go in the direction they want to go, just because they might help me out.
And usually these companies are slower moving than I am, so doing the back-and-forth and getting feedback would take forever. With mobile apps, you have no idea if the thing will ever take off, and I have found it is best to just launch the thing and see what happens.
I'm not sure what some of these people think. I'm an independent businessman. I have the right to do whatever I want with my own products, and yes, I can choose to launch something whenever I damn well please. If you like it, go ahead and promote it. If you don't, don't. I honestly don't care.
So I take this saying more as "Doing anything at all will always be perceived as offensive to someone. You might as well do it and let them get offended."
And I know that soundbite lacks nuance and could easily be taken to mean something else, but then it wouldn't be a cool soundbite either. Obviously don't murder, rape, etc, and do take others into consideration when you are working on a team and you need their help longterm.
But I think the essence of the saying is that nobody is purely innocent and anything worth doing will probably ruffle some feathers. If you're overly cautious, you won't ever accomplish anything significant.
> EAFP > Easier to ask for forgiveness than permission. This common Python coding style assumes the existence of valid keys or attributes and catches exceptions if the assumption proves false. This clean and fast style is characterized by the presence of many try and except statements. The technique contrasts with the LBYL style common to many other languages such as C.
edit: Sorry to bring programming to the table again, the 'philosophical' side is also interesting of course!
[0]: https://www.python.org/dev/peps/pep-0020/ [1]: https://docs.python.org/3/glossary.html
This probably have to do with that in the second case you ask your manager to make a decision, causing them cognitive load. In the first case you already made that decision for them.
He use it to summarize Chinese reform and opening. You cannot get any permission from goverment, but you can try it first. If something bad happens, ask forgiveness. It maybe the core reason of Chinese speed.
Sometimes your methods ask for forgiveness. For sake of argument, they accept a bunch of pointers as parameters and blindly start dereferencing them without any null checks. This is done because it is a small implementation and the caller is completely trusted and is known as fact they would never be null. Those checks are redundant and a performance cost.
It's really a judgement call to known when to get permission and when to ask forgiveness.
https://www.goodreads.com/book/show/1111.The_Power_Broker
Moses was a genius and accumulating and wielding power. His playbook wasn't "take initiative then hope for the best", it was "take initiative then destroy lives and careers until you get your way."
Sometimes it's best to ask someone local and knowledgeable for unofficial permission and just do it than to run up and down the full command chain and paperwork. (a paper trail makes this impossible so do not leave one - if you need forgiveness later this option is still open then)
If you’re lying in stand ups about what you are working on, I won’t forgive that.
If you expose us to liability by incorporating OSS with egregious terms after I said no, I won’t forgive that.
If you break contract terms with our partners because you think you know better than I do what the contract says, I won’t forgive that.
If you implement an awful solution because you were fighting with the architect or UX, I might forgive that, once.
But it sure made me grin, a most fitting and clever response!
But then we have the quotes that are quite banale in nature, but where the use of said quotes have been taken as validation by extremists, bolstering them in their rather dangerous belief, that secretly everyone agrees with then, and thus the ends justifies the means.
For now I brandish unattributed quotes with reckless abandon in settings where I know everyone, but try to do some basic research in public settings, not because attribution is important, but because others might.
Though for me the quick quips of quotes is a lens which can be used to shine some light on some aspect of our lives and world, it's as much a folly to rely on them as anything else. They capture is a single snapshot of an almost infinitely complex world and are as such almost always exactly as wrong as they are right, although in unusually interesting ways.
Write a compiler, then feel free to come up with your own idioms.
I wish she were more remembered for her backward clocks and the fact that she would let you have it if your answer was "Because that's the way we've always done it."
And, while she may not have originated the word "bug" for a computer problem, she was probably the first to document an actual insect causing a problem in a computer:
https://www.wired.com/2013/12/googles-doodle-honors-grace-ho...
I'm not necessarily a big fan of the "Ask forgiveness rather than permission" route as it only really works when the result either direction doesn't really impact anybody further than the person carrying out the action.
I currently have to step over a half-dozen bicycles every morning because some venture capital funded companies decided permission was just too difficult, and I hope they don't get forgiven and have to pay really expensive fines for not obtaining permission.
I'm pretty confident that social pressure or technology can solve the littering issue, too, leaving forgiveness approach with no drawbacks at all. I would be happy to step over the bicycles, seeing it as a sign of an actual innovation in society that people are really using and benefiting from.
Capitalist Democracy means that the weak get used as a resource by the powerful by the permission of the weak.
having said that. I have no idea how to do it better, so pass me the yoke so i can have my turn.
https://en.wikiquote.org/wiki/Winston_Churchill#Post-war_yea...