Be Kind
briangilham.com
briangilham.com
i am a huge fan of the turn of the century dancer isadora duncan and her lover who she first had a child with, the theatre set design theorist, edward gordon craig who she affectionately called endymion
a complete aside, but if you have, or anyone reading this has, yet to read duncan's autobiography 'my life' i highly recommend it to anyone and everyone
she is a brilliant writer, lived an eccentric life, and she was and her writing is imbued with a mad passion for expression and both life's hardships and joys
1) Reversion to the mean. This is what the above person believes and that this likely won't happen again.
2) Indication of a trend. The pilot is actually incompetent, and this will happen more frequently with this pilot than an average pilot.
Regression to the mean is simply that any given datapoint is most likely to be the mean, or close to it. This means that any exceptional data point,up or down, can be expected to be followed up by the mean.
The example of this being misinterpreted that I am familiar with is that of a flight instructor's belief on training. When a pilot performed well, they wouldnt comment. If a pilot performed poorly, they would be punished. They believed this was better because when they praised a pilot, they would usually do worse the following run, and when they punish them they do better. This isn't technically wrong, they are just ascribing causation where there is none. I think I saw this example in Signal vs. Noise, but I'm not sure.
Basically, regression to the mean isn't a reason to pick someone who did poorly, it's a reason that that person will do no worse or better than they do normally.
https://www.google.com/#&q=%22how+to+win+friends+and+influen...
Flip 100 coins. Take the ones that 'failed' (landed tails) and scold them. Flip them again. Half improved! Praise the ones that got heads the first time. Flip them again. Half got worse :(
Clearly, scolding is more effective than praising.
While, of course, human performance is not always equal in the same way our coins are, the fact that performance (or whatever it is you are measuring) will still regress towards the mean still holds true. The coin example just gives an extremely obvious demonstration about what is happening when things regress towards the mean.
If labour is so abundant that there's little problem in replacing any given worker, people can and will be fired for trivial offences. If there's a shortage, or there's a considerable on-boarding process, less so.
The threat of a firing-at-any-moment also makes for a more tractable workforce, at least from a management perspective.
Humans aren't perfect improvement machines, but they surely beat a random variable?!
Neither the GP's quote, nor the OP, are making the statement "I understand that this mistake was an outlier, you'll probably never make this mistake again if you remain unchanged".
The claim being made is that acknowledging the mistake and learning from it can dramatically reduce the base probability of such mistakes happening again.
The question is: is the day-to-day random variation much bigger than the day-to-day average increase? If so, regression towards the mean makes total sense.
3) Out of remorse, pride, being shocked out of complacency or some combination of these, the man would do his absolute best the next day, especially for the very same pilot.
Not everything is a financial metaphor.
This is psychological insight, not statistical insight.
I think more appropriate in this context is learning though. And I would suggest here multi-armed bandits (with every arm representing a pilot).
https://en.wikipedia.org/wiki/Multi-armed_bandit
There is tradeoff between exploration and exploitation that has to be made.
The goal in this case corresponds to a particular type of bandit. It is to postpone death for as long as possible by pulling the right arm. I actually didn't find this type yet (a mortal multi-armed bandit has a birth-death process of the arms themselves).
Edit: This is only about the learning process on the non-pilot side, as one of the other commentators already articulated.
Or under external pressures they have no control over.
So I'd say it depends on your environment combined with the individual. Someone who is apathetic and/or lacks critical thinking skills will probably learn very little beyond avoiding that specific mistake again.
Shows the other meanings of the homophones - English huh!
A pattern of making mistakes can tell you somebody is careless, or sloppy, or in over their head. But a single mistake? That's just inevitable.
Or that you need to fix the process.
When that happens, I hope the people around you are more forgiving than you are.
I think it's especially true in tech jobs where there is a lot learned on the job. I would be deeply skeptical of any tech company that takes a fire first attitude. That just tells me they 1) treat devs as disposable and 2) they get rid of everyone that has a chance to learn from their mistakes
It would seem to me (somebody who knows squat about stock trading) that a warning screen would be much more beneficial for stock trading software than it is for an online video game.
I'd imagine in the case of the stock trader, where quick reaction is valued, he'd have quickly entered whatever key combo is necessary to dismiss it the warning and made the same mistake.
Alarm fatigue is an important design consideration, but not a reason to not put warnings at all (given that this isn't amenable to an "Undo" button, which is preferable when possible).
You shouldn't fix an issue like this with UI validation alone - it needs to go between the component that creates orders and the stock exchange, so that it also protects against software bugs. For instance, a possible bug is a developer multiplying the order size by the lot size in the backend, when it has already been multiplied in the frontend, causing huge orders to be sent. Sanity checks can catch this.
Automated trading systems have traditionally been under a lot of scrutiny, and nobody in their right mind would run one without sanity checks and a kill switch. That incident taught Mizuho that manual trading can, in fact, also be quite dangerous :)
"A perhaps-undesired recognition is the Hoover Nozzle used on jet fuel pumps. The Hoover Nozzle is designed with a flattened bell shape. The Hoover Nozzle cannot be inserted in the filler neck of a plane with the Hoover Ring installed, thus preventing the tank from accidentally being filled with jet fuel.
This system was given this name following an accident in which Hoover was seriously injured, when both engines on his Shrike Commander failed during takeoff. Investigators found that the plane had just been fueled by line personnel who mistook the piston-engine Shrike for a similar turboprop model, filling the tanks with jet fuel instead of avgas (aviation gasoline). There was enough avgas in the fuel system to taxi to the runway and take off, but then the jet fuel was drawn into the engines, causing them to stop.
Once Hoover recovered, he widely promoted the use of the new type of nozzle with the support and funding of the National Air Transportation Association, General Aviation Manufacturers Association and various other aviation groups (the nozzle is now required by Federal regulation on jet fuel pumps)." [1]
[1] https://en.wikipedia.org/wiki/Bob_Hoover#Hoover_Nozzle_and_H...
More generally it is very difficult to build highly reliable systems of any kind without having a very open culture where you focus on exposing problems and fixing them rather than blaming the message.
Everyone was chipping in with their theories about why the U.S and Silicon Valley were so good at what they do when Jobs lost his patience and butted in in true Jobsian fashion.
"Listen! Take a look around this table. Everyone here has a massive failure in their past. Big, epic failures. In the US, we think thats a good thing. In the UK you think it's a bad thing. Thats it."
Or soemthing like that, you get the idea.
Anyway, i've always liked that outlook regardless of wether it's true or not.
People lying about their progress however, that is hard to deal with.
Having someone rip into for lying when the spec was terrible to begin with is massively discouraging and the OP lesson applies just the same there.
Thankfully that situation is resolved now, though it lasted for too long, and miraculously didn't fall off the cliff it teetered on.
My opinion is that trusting people and giving them responsibility is one of the best ways to let them learn and grow. The bigger the mistake, the bigger the lesson. As long as it is possible to recover, it's a calculated risk which may well be worth it.
As beginners, we're over-confident in our ability, even if we actually suck and make lots of mistakes: https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
The opposite seems to become true - experienced engineers (who have learned from their mistakes) seem to be extra paranoid. I've seen also older engineers that seem to be confident still, talk a bit game, but they just never learned. It seems paranoia is a great indicator of experience, and over-confidence/arrogance is an excellent indicator of a lack of learning. Not to say those are the rules, as there are certainly arrogant engineers that are excellent but I'd rather work with the softer one personally.
I know as I have grown I have become softer, not harder, as I realize my humanness.
Many people reading the article think of a nice person that humbly tries their best but makes a bad mistake. But what if they're a hugely over-confident asshole?
I mean, not everyone likes everyone, so when someone you don't like to begin with is arrogant, you might easily label them as an asshole.
I think the deeper lesson of the article is not to consider other people assholes, and to be kind to them even if you don't like them at all.
Then they have absolutely no business working on a team effort.
They never should have been hired in the first place.
With respect, this doesn't tell us what to do if we run into a hugely over-confident asshole.
Fire them, if you can. Before they poison your entire talent pool with negativity.
I was also one of those developers and have since changed my ways :)
Absolutely however I do agree with you. If a young developer doesn't integrate into a team role immediately, that's no reason to not hire him.
A lot of great developers are so great because they've spent years alone with their computers just cranking out code. So the best ones won't have the greatest social skills.
But if the kid's still having trouble integrating into their team role after their 6 month probationary period, for example, I personally wouldn't vouch for them any longer.
The worst problems I've ever seen on teams spring from people that are arrogant and standoffish, followed closely by people that are too dogmatic about technical minutiae and best practices in the face of situations that require flexibility (my classic example is the prototyping team that spent two weeks setting up an automated testing and deployment infrastructure, even though they only had six weeks to do their game prototype).
I'd take a pleasant junior that's really green but is happy to learn how to code better over a more technically proficient asshole that needs to have manners jammed down their throat any day - tech skills can be taught to a newbie, personality cannot. People have had a couple decades to cement personality habits as junior programmers, so those are mostly fixed, whereas tech skills are super fresh and malleable.
But that's a risk; depending on that is ill-advised.
Of course, there are genuinely poisonous people, and I agree on your points with regard to them.
Softer in the sense that I want to foster an environment of respect. As a lot of the senior leadership that I've worked with has retired, I've noticed that the 30-40 year old crowd now is more brutal.
The trick - when getting to higher levels of technical management - is learning how to context-switch between being overconfident for the benefit of non-technical stakeholders and being paranoid with the technology so that the things that could go wrong don't actually go wrong.
Now of course donations in the past few months have been roughly double our expenses -- information which is also public. But it's very hard to project confidence during a problem solving session, because it gets in the way of actual problem solving.
I wish I knew where the balance point for secretiveness and openness was for public organizations. But given that all of the candidates for U.S. President seem to be at a bad place, I'm starting to wonder if a perfect balance point even exists.
Exactly. My feeling is that while perhaps many of us learned this the hard way, well at least I did--from experience--in hindsight it seems obvious that our emotional impulses and intuitions, while albeit valuable, are not fine-tuned to success in technical careers.
A manager that can't tell who on their team is good will (in the long run) take an average team and turn it into a bad team.
This is certainly true, and it isn't limited to the field of engineering.
It's strangely difficult to find this important piece of the methodology. Wikipedia's article doesn't even mention it, and this context is fairly critical to understanding the effect.
I think you're right that some amount of inexperience and youth makes the kids overconfident, but what has been demonstrated is that the task difficulty is a large determinant in how good people are at estimating their own abilities, and Dunning Kruger only applies to easy tasks [1]. For very difficult tasks, the Dunning-Kruger effect actually reverses and becomes Imposter Syndrome [1][2]. Software engineering may fall into the latter category -- something that is difficult enough that, statistically, on average, beginners are actually pretty good at knowing they can't do it.
[1] http://www.talyarkoni.org/blog/2010/07/07/what-the-dunning-k... [2] https://en.m.wikipedia.org/wiki/Impostor_syndrome
"Our studies replicate, eliminate, or reverse the association between task performance and judgment accuracy reported by Kruger and Dunning (1999) as a function of task difficulty. On easy tasks, where there is a positive bias, the best performers are also the most accurate in estimating their standing, but on difficult tasks, where there is a negative bias, the worst performers are the most accurate. This pattern is consistent with a combination of noisy estimates and overall bias, with no need to invoke differences in metacognitive abilities. In this regard, our findings support Krueger and Mueller’s (2002) reinterpretation of Kruger and Dunning’s (1999) findings. An association between task-related skills and metacognitive insight may indeed exist, and later we offer some suggestions for ways to test for it. However, our analyses indicate that the primary drivers of errors in judging relative standing are general inaccuracy and overall biases tied to task difficulty. Thus, it is important to know more about those sources of error in order to better understand and ameliorate them."
Burson KA, Larrick RP, & Klayman J (2006). Skilled or unskilled, but still unaware of it: how perceptions of difficulty drive miscalibration in relative comparisons. Journal of personality and social psychology, 90 (1), 60-77 PMID: 16448310
A few years later, in the same company, I was managing the middleware servers that handled all communications for the sales people in Europe. Here, when there was a failure, the sales people would have to fax in their copies of the data if there was a failure, so even more pressure. This is where I really learned to both appreciate the criticality of my mistakes as it could make several hundred people redo their work. However, the most important thing I learned with this was to slow down, and pause for a few minutes so that I could explain what was going on to the non technical managers and team leads. This was more important sometimes then actually solve the problem.
Both of these instances and a lot of others that happened over 11 years in that company thought me ot really double, triple and quadrouple check any change. It created a healthy paranoia, but also taught me that mistakes are ok, as long as you learn from them, but also, lean to communicate with higher ups that could not follow the technical jargo. I think the communication part is something that a lot of very confident people have problems with. However, it's very hard to teach this to younger techs, without letting them fail, so as a senior tech, I have seen problems from new juniors, but I have let them actually make the mistake, and feel the stress and pressure that they have messed up. I have found this to be the quickest method to teach responsibility, while standing by them and their mistakes.
Simple fact is, if you worked for me, I would have fired you for that. Junior devs are supposed to do bad things - that's why they aren't senior devs.
Well, no. It is the product of someone's work. Someone who is trying to learn and should be supported and taught how to make it better and why it is not as good as it should be.
Hell, every now and then I stumble across some idiocy in the code base and think "LOL, whoever did it this way is an idiot". git blame. "OH, hahaha, it was me, what an idiot past me was, amirite guys?" Everyone on the team takes levity about mistakes very seriously ;) It's healthy.
Mocking condescension on the other hand is a different thing entirely.
Amen. I don't know about firing, but I'd definitely be having a conversation about proper mentorship. We hire juniors because they show promise, but need to learn. Being snarky and shutting them down doesn't just hurt the individual dev – it hurts the entire company.
His statement could mean anything from cruelly laughing in the face of the junior dev during a face to face code review to having a quick heh under his breath from the privacy of his office at the developer's use of "if (foo === true)". Or anything in between.
There are such judgements in every thread.
It's even better when it is paired with the famous "I would not hire you" (or its variation "I would fire you") although the conversation does relate to this at all, the OP has shown no intent no be hired in any company, let alone the answerer's company, and, icing on the cake, the answerer is not in a position to hire anyone.
Harsh, withering treatment is quite common not just with developers but in all technical fields. I wish things were different, but that's the reality as I've seen it.
My wife used to work as a copy editor at a major newspaper and worked with one of those "laugh at and make rude comments about other people's work" kind of people. The copy editing checks had to be checked by another copy editor before it was allowed to be forwarded to the layout team for placement in the news paper. How the story checkin and checkout system worked was that your submitted checks were anonymous to other team members. So, there was this one guy on copy editing team who openly mocked and call other people's work "stupid" and "idiotic". He could never say the person's name that he was talking about, but since every copy editor was in the same room, you knew he might be talking about your work. Everyone hated the guy and everyone complained about the guy. My wife would say how much everyone just hated working with the guy and he was just one of those people that made the job unpleasant.
Then layoffs came around (Newspaper in the Internet Age). When this guy was laid off, champagne bottle were opened up and people celebrated. You know when someone is bad when there is a "sorry to see you go" bar get together and they are not invited. A strange thing happened though, productivity went up because people felt better about submitting their work for final approval. Less copy editor mistakes, less stress, more learning, more openness and more engaging with other team members happend. Barriers between teams fell and even with layoffs, people felt better.
It turns out that the person who mocks other people's work, make for a crappy work environment. You can be tolerant of failures on technical levels, but failure in personal level should not be tolerated. Be pleasant to work with, or should you should be fired.
Maybe an analogy would do better. In the Army, Soldiers go through basic training and are taught just that - the basics. Once they show up at a unit, they will have lots of questions and lots to learn. But if they show up with their name patch velcroed upside-down on their uniform, I guarantee their Sergeant is going to chuckle before they tell the Soldier to turn it right-side up.
I've seen people write things like: if (true == true)
I won't be mean to you about it, but I can't promise I won't chuckle a little before explaining why that's unnecessary. If you've been working in a professional setting for 3 years and are writing code like that, then yeah, I might struggle to be empathetic.
Which, if you make that an === in JavaScript, can actually make sense in some situations :)
I'm referencing a time when I was in school, and most everything was taught in Java, where that doesn't make sense. This was written by someone who was almost finished their degree and had already started at their professional job. Definitely junior, but I still feel like that's stretching the acceptable level of noobishness. That said, I have an EE degree, so maybe had to solve / reduce a lot more boolean algebra expressions than a straight CS major?
That is my defense and the only time I've laughed at someone's code. I guess the combination of him talking himself up big about all the amazing things he did at Amazon and the code vomit that he actually produced was too much for me.
I regret it, but he shouldn't really have been that junior after 3 years?
Though I guess I still write pretty shitty code now too on occasion.
Alright, I'll take the karma L in this case.
(I had a collegue at my last company who worked at Amazon before. His code was just fine.)
That said, I think the interpretation that "he had 3 years experience at a big company, he should have been better" is probably the correct one.
They are so bad that laughing is permissible.
Maybe you just don't spend enough time around arrogant people to interpret this sentence this way :)
Laughing in this situation is merely inappropriate. Firing someone for being inappropriate once or twice is incredibly toxic behaviour.
Keep in mind that I don't categorize laughing at someone's work as a "simple mistake." Bugs can be simple mistakes. Offensive jokes can be simple mistakes. Laughing at someone's work however is deeply troubling behavior that actively undermines trust and discourages cooperation in the workplace. That's why you have to kill it with fire.
Firing somebody based on your own subjective opinions is toxic for culture.
I've worked on amazing teams with plenty of good natured ribbing and I've worked on great high performing teams where you could say "this code is rubbish, you can do better". I've also worked on teams where saying that would really hurt people's feelings and impact moral.
Put aside your own pre-conceptions and look at how your team responds to an event/situation. That's the only way to build a high performing team.
Sometimes that will mean laughing at someone's code is toxic and needs to be addressed, other times it will be a non-issue and addressing it creates an issue, and other times it can even be a good bonding exercise.
I worked in a team where if you broke the build you had to put on a clown nose for the rest of the day. It worked well and was a bit of fun. We still catch up a couple of times a year even though I left that team more than 5 years ago.
I've worked in other teams where pressuring a team member to wear a clown nose would be harassment and deeply unsettling.
Extends far further than the workplace. A few minutes in some of the more popular IRC channels on Freenode, you'll get the same experience. It's extremely frustrating, especially seeing it happen as an outsider to communities you like.
I feel like, in the same way that power generally corrupts people, "feeling smart" can corrupt the same way, coming down to the same attitude of feeling like you have an advantage over other people. Regardless of whether you actually are smart or not.
But if the snark is heavy without being warranted at all, it more than pisses me off. It reflects poorly on whatever you're representing and it's just bad communication. If all you have to offer is a lmgtfy.com Link, don't bother. Those immune to that train of thought won't, the others already have.
A good way to detect these environments is when you observe those who have been there longer not asking obvious questions. That usually means the trust issue is there. When you start asking those obvious questions, at first you get that feedback loop of slight condescension. But then others start asking questions and you often get a fruitful conversation.
Having worked outside of the startup world and in the startup world, I think this is a little more prevalent in the startup world because there is another axis besides experience involved in these conversations: how long the person has been with the startup. It's common to have an official or unofficial hierarchy based on experience but in the startup world, there is another hierarchy based on how long you have been at the startup. That additional axis means it comes up a little more in the startup world (in my experience so far).
Anyone who treats someone else on the team in that way, regardless of seniority, is demonstrating that they're not really interested in the project as a whole. It takes a group of people to build something complicated, and someone who is antagonistic towards other people holds back the effort of the group. You're better off without them.
I will die on this hill.
What I don't find ok is to blame a person for an error going to production. Specially when the error is caused by the lack of supervision to the new hire code (code reviews) and probably QA.
"It is a good question why I caused this problem. It is weird to think there is a competent company that has been around for so many years, yet they have no procedures in place to stop this from happening. You would think that any changes that could cause downtime on a clients website would go through an automatic test suite and only after passing all tests would it be tested by human QA and finally made live. In this particular case I am the one who has made a mistake, and being a sensible person who is eager to constantly better myself, I will try and learn from this error, however I work alongside dozens of other people on my team who like me, have every chance of making a mistake at some point. It seems like a bad policy for us as a company to say that we should expect every person on the team to break a clients site and then rely on overtime from other people to fix it. So of course I will try and do better, but this is not fixing the root of the problem, the root of the problem is something that needs to be fixed at a much higher level. Have you, as my boss, not considered this problem already? What has the company learned from this? I would be happy to be part of the team that solves this problem by creating unit tests and creating policy to avoid this."
Of course I purposely make this slightly stand-off-ish, over the top, and written from a very specific perspective, to illustrate a point. But the reason I do this is I absolutely agree a single developer shouldn't feel bad about making a mistake (they should try not to, but these things happen), but the company should put measures in place to minimise the impact of mistakes. When the company fails to do this, the company has screwed up a lot more than the developer.
A single mistake shouldn't lead unconditionally to a mandatory multi-step process that involves multiple people and may take several months to finish. The examples of the "cover your ass" decision making overpowering the common sense engineering are abundant.
It's always best to do an after action analysis to see where things broke down, I think. Changing procedures or adding protections might be warranted, as long as it's not the "get my permission before ever putting a Y in that field again" kind of enhancement.
On a more personal level, if someone shows you kindness in the face of a mistake, the last thing you want to do is throw it back in their face and go on a tirade against them. That's a very quick way to make sure nobody ever wants to work with you again.
Why does the VP have that kind of access by default? I understand having a separate account if needs are there, of having some sort of priv-escalation.
In my new job as network engineer, all the RH boxes have SElinux off. I don't get it, nor can anyone give a cogent answer. And up 4 floors, we have a selinux kernel Dev.
I'd greatly like to even limit roots potential damage against users' data (in this case, DBs).
Two common reasons. First, because the VP or someone in a similar position resented not having such access; it's sometimes hard for people to accept that people who work "for" them hierarchically have permissions they don't. And second, because either they or the person who previously held their position had a legitimate reason for such access in the past, and didn't drop it when they no longer had such a reason.
But yes, even if they have a legitimate reason for such access, they shouldn't have that permission all the time, only when they intentionally don that hat.
Would you be comfortable moving something fragile by hand that is worth a lot of money? Maybe. Would you prefer if the fragile item being moved was done with an automated process that was shown to best protect fragile items? I would.
"I'm really sorry I caused that car accident." "That's okay, next time take Driver's Ed and don't drive on sidewalks." "Thanks, I'll make sure to do that... by the way, why can I even drive on the sidewalk in the first place? Why wasn't it required to take Driver's Ed?"
I'm very obviously using hyperbole here, but questioning a process, to me, often shows a level of maturity in engineering. It's not blame-shifting - you clearly still made the mistake - but it's fixing a root cause.
I do think it has to be brought up carefully and with the right tone at the right time though.
I hate making mistakes, but if more robust procedures are the result, well, it's an overall win!
His reasoning (later revealed) was that you can't give people fish and expect them to become expert fishermen. They have to experience hunger and ask to be taught to fish. If people don't have the soul-crushing experience that teaches them why something is really important, they never really internalize why it's important. That the reason why we appreciate that this stuff is so important is BECAUSE we suffered through something that taught us that it was important, and that if we don't give junior folks that same kind of experience, then good practice just becomes something on the list of priorities and not a moral imperative.
There's something to that, but at the same time, it's basically a defense of institutional hazing on the investor's dime. So take it for what it is.
I think you can, it's just not nearly as efficient. College and trade schools are essentially about mixing a very small amount of actual necessity (deadlines, tests, etc) with copious amounts of being told what's best and how to accomplish something. This works well because it's both more palatable to a wider audience of people, and it accounts for people's different interpretation of events. There may be multiple things to learn from any particular failure, and without some guidance you may come away having learned few or none of them the first time. Being told what to expect before hand, or what you could have done to mitigate problems afterward, goes a long way towards making sure you consider all the useful aspects of the problem.
Will you learn any one single lesson as thoroughly or as fast as you would in the real world when it affects you so much? Likely not, but then again, that assumes you actually saw a solution to the problem, and that still might just be one aspect.
I agree with the other replies that while you may be the 'technically right dev' kind of person, it still comes of as being a dick and you will likely not get a positive response from something like this, especially if you caused it.
What makes it more reasonable to say it's the company's responsibility to protect you from fucking up the site instead of you just being a good developer, and not fucking up the site?
I don't expect the folks who built my house to detach and reattach the door pefectly every day, I expect them to build a house that works.
Ideally you would have either test gates, or a staged rollout with automated rollback.
I used to work for this company where every single Friday we would go out for lunch and get tipsy (wine with the food, some digestive liquor shots just at the end, then maybe a mixed drink or a beer at another bar) because we were the only team not allowed to go home early on Friday... for no reason. Mind you, we were some kind of internal IT team and there would be no one to request anything from us, so we never had urgent stuff to do.
Back in the office we would enable the "fire extinguisher mode" which meant "only move if there's a fire" and watch silly videos in Youtube, have some coffee with Baileys because why not...
Saying that nobody should ever do it isn't realistic, sometimes things go wrong on a Friday, sometimes you can't afford to wait 3 days to watch them become even worse.
Don't deploy when you won't be around to support it is a better description; but it doesn't roll off the tongue as easily.
Really, it will come down to a cost/benefit analysis. Are your chances of the site going down due to being hacked over the weekend higher than the chances of a last minute update taking down the site?
The answer is almost always no (much to a sysadmin's chagrin). If the answer is yes (i.e. another heartbleed), then you are probably going to be working through the weekend anyways.
It's good to instill in your team that Friday deployments should be done only in special circumstances, or they become a habit (and people inevitably end up working Saturday). But yes, sometimes it's necessary.
"Only deploy on Friday if you like working weekends"
* It's the holiday weekend and your new website with its curated comparison feature needs to go live
* It's the end of the quarter and having this is the only way you can sign a deal now (enough of your partners will be bound to quarters that this is possible)
* You're in the business of live sentiment analysis from TV video and a critical bug needs to be fixed before this weekend's Presidential Debate or your news channel partner will be pissed
Reduce the tempo? Some of these can kill.
The changes are pushed and working in staging, the tests are passing, Q&A is done. Why hold off? So that you get your Good Practices™ badge? I'd say it's better that you don't have to deal with last week's work on a Monday if at all possible.
I think being down to earth, and keeping your good judgement is key. I don't recommend making world-shattering changes on a Friday, but even then, well, it really depends on the circumstances.
On weekdays you have the added pressure of other work.
(Of course depends if your business is mostly or evenly loaded on weekends as on weekdays. In most businesses I've know it's usually the lower load/customer visits period).
You should not be pulling people in from their time off to fix shit.
This also creates like a kind "brain latency" for developers I think. I'm coming at this from the operations side of things, so maybe my observations are a little biased here. I have observed that if people deploy changes and it breaks something immediately, it's a very clear correlation and they can fix the bug generally pretty quick. If they deploy and then it breaks 72 hours later, any number of things could be the culprit, especially in a fast moving environment (times 1 billion percent if it's a microservices architecture without a strong devops culture, which most of 'em are). Debugging then takes much much longer. This is made worse if the person who deployed the change is not quickly available when their thing breaks, and it makes being on call for someone else's unproven feature very stressful.
So instead I think it's better to make sure deployment and build systems are rock solid, and deploys are as accessible and as idempotent as possible. Chatops type systems are good here. Then you can roll out big changes during peak traffic and be confident that you can quickly revert if it goes bad, and that the changes were reliable under load if it goes good. I also think it's critically important that big changes are behind rollout flags, such that you can dial up or dial down traffic at will. This is also useful when introducing new cache systems or something like CDN if you need to warm up slowly.
This is a better approach I think than trying to use the time of day to modulate user traffic. I would rather developers can control traffic to their feature themselves and have the person deploying the change with their hands on the wheel until they are confident they can take them off. That way people can do stuff independently, and everyone can trust everyone to deploy and yet still feel safe.
[Client, Friday 4PM] "We are having a big sale this weekend we told nobody about. Could you quickly deploy a fix where all the product's prices are red and bold? That shouldn't take you long, right?"
[Project manager, Friday 4:45PM] "Hey team, X just released an important security fix for Y platform. I need you to deploy it right now or the client could get hacked."
1) If you try to hide the mistake I'll be mad. As soon as you know there's a problem, we can mitigate the damage by addressing it immediately.
2) I want to see that you're learning from it. A pattern of repeated mistakes may take some explaining.
I did however once work at a company that was very metric-focused. Turns out that the metric they used for our team was closed tickets, and they felt that given my salary I didn't close enough of them. No understanding whatsoever that others on the team were able to close more tickets because of my help (let alone that the tickets that made their way to me tended to be the complicated ones that others couldn't solve). After the first talking to, I stopped helping out my teammembers (I explained why) - and jumped on the first opportunity to get out of there.
I miss construction. Back then, I could just tell someone "Hey! You! Don't fuck that up, I'm pouring concrete around it tomorrow!" And we would still be cool at lunch break.
I have one simple rule for myself - which is to never deploy anything at night before I go to bed. I've made several critical mistakes which I deployed to production and then went to bed only to wake up and find out that users couldn't use my products.
Thesedays, I do all deployment in the morning - that way, even if there is a critical bug, I am awake to catch it and fix it quickly.
I was in Seattle and I took a public bus. The fee was $1. It was my second day in the US and I didn't have a dollar bill in my wallet (nor a transit card). I was assuming that I can pay with a larger bill just like Japan. Big mistake. The driver yelled at me but nonetheless she let me ride for one time. Then the guy sitting next to me suddenly offered a dollar bill and said "take this, so that you can pay for it by yourself." I probably looked at his face with amazement. "Thank you very much, sir." The guy got off the bus in a few stops later and I never had a chance to say this, but I know it's my turn now. I want to thank the nameless person who slightly changed me. Kindness is contagious.
So sure enough I got into a taxi cab and asked him to drive me to the airport, but make a stop at an ATM. When I went to withdraw the money for the cab, I noticed my payment didn't go through, it was still pending. I was desperate, didn't know what to do.
I kid you not, the guy withdrawing money from the ATM next to me somehow managed to notice my despair and got a chunk of money bills out of his pocket and said: "how much do you need?". I think I just stared back at him for a minute or so. "What?", I replied.
He told me that one day I'd have the opportunity to do the same for another person. I always remember this and always help strangers any time I can. And I realized that we are the ones that gain the most when we help.
EDIT: somehow somehow
It's now 4 years since I was fired from that job and I'm still in development, despite that incident nearly causing me to decide it wasn't for me.
I was extremely happy to read this post, it gives me hope. I try and take a similar approach when working with newer developers, or those that are inexperienced in areas.
- With a system outage, don't lose your cool. Rationality is what's needed at the time.
- Elevating "perfection" at the expense of potential breakage will ensure nothing ever moves forward and your team doesn't grow.
Instead, this manager leaves his engineer with thoughts about how to avoid that problem in the future. Always remember -- an outage is eventually fixed, but a damaged relationship continues forward.
The level of stress matters a lot. If a team is being run in a standard “everyday crisis” mode, they quickly reach the point where there is very little they can take. Every tiny mistake wears people down, reminding them of how much more there is to do, and turning them sour. Managers seem to panic and cut into their team’s time even more by starting to have long, daily meetings to “fix” things.
If you want “nice” people, you have to set them up for success. Reward completing the whole chain, not just hacking away (e.g. for software, not just coding but also testing, documentation, and seeking peer review). Keep meetings to a minimum. No overtime. When short-cuts were taken to meet hard deadlines, open up your schedule and scribble in the exact window after the deadline where you will stop everything and clean up the mess that the short-cut created. Give your people the best equipment that money can buy. And so on.
Though, in my opinion I think it's kind of insulting to be asked something like "What did you learn?". The question isn't really necessary. You know that you screwed up.
That kind of dynamic between an engineer and a team lead is off-putting to me.
I think the proper way for a team lead to handle it is to instead work with the engineer to help find ways to eliminate the human error by implementing tooling or processes. The conversation should go something like this:
Lead: "I wonder how we can make sure none of us break XYZ widget again"
Engineer: "We can build out ABC and run that, also generally just test better before pushing to prod".
Lead: "Cool, do you want to go ahead and take care of that?"
“Great. It sounds like you get it. I know that you can do better.”
Giving folks a chance to communicate what they learned, and then encouraging them to "do better," is the best way to lead.
If people are "blame-first, ask questions later" types, the person at the top is inevitably running the show by focusing on mistakes and miss-steps and their people follow suit. As result, people become wary of taking risk and run to assign blame, even before existence of an issue can be validated.
As a result, I don't think you can change these organizations. If their temperament doesn't match your own, you have to live with it or craft an escape plan.
To the junior devs, when you screw up (and you will) own it and learn from it. Like public scandals, the cover up is almost always worse than original issue.
Other times, though, some developers need a very stern review. Things like: "Don't name your tests test1, test2, test3. Give them descriptive names," "Follow style," and "this does not belong in the dependency injector," and "don't screw with event publishing logic, filter this out in the event handler in the UI" are warranted when a developer isn't taking the time to think through his/her changes.
This is important when dealing with junior contractors.
The very rare times when I have to be stern is with consistency issues. Usually though, that's even softened with a "Yes this might be a better way to do it, but it is not consistent with how it has been done so far. We'll make some time in the future to change it everywhere, but for now stay consistent." Often times the biggest issue with juniors or even mid level people is they are only looking at their immediate piece, and not thinking about the larger application or system level picture.
"Can you think of names for these tests that would be more helpful when we need to debug why they're failing?"
"Check out the styleguide for indentation like this; consistent code is easier to maintain"
"Here's a place where we did something similar. See how this logic goes over here instead? That helps us keep x, y, modular"
Phrasing things a little differently can make feedback feel like a learning opportunity instead of a criticism.
I think just saying what you think but with a bit of humility and the attitude that you need to justify yourself is best. Especially since even the best seniors often get hung up on pointless crap during code reviews.
If someone is humble, they'll naturally tend to ask questions as described. What you've written isn't what they expect, but they assume you're not an idiot and there's a reason for it, so they ask why.
But if someone assumes they know better, the socratic method is likely to be just as condescending as just saying you're wrong.
This is exactly why I ask questions. It's important in a code review to understand the frame of mind of the code writer. I presume the person is not an idiot and did things for a reason or will respond with a doh! it was late/that was careless/thanks I'll fix it.
IMHO, code reviews should be clear and concise. They aren't a place to go out of your way to soften blows. I expect the same when my code is reviewed.
Edit:
It occurs to me the parent may have been referring to an informal review or one with the intent of mentoring. Asking questions, like the sibling mentioned is a great way. My comment is geared more towards a formal review.
A far worse situation though is when a mid-level or senior developer is defensive about code reviews and won't cooperate in the code review process.
Conversely, I've come out of reviews from other people, where they've been fundamentally happy with my code, feeling depressed and miserable.
Communication skills are vitally important. I've been trying to learn from the first reviewer; next time they visit I should actually grab them for coffee and talk about it...
To me, the biggest thing is don't lie to save feelings. You need to tell the truth or they will feel a whole lot worse later. Loosen yourself up. Don't go into that ridged pose. Talk evenly, and if you can manage it act in a jovial mood as you walk in. For the love of all you hold holy, know what they did code-wise, and take some damn notes before hand. Winging it will be the death of their trust. Teachers you don't trust aren't going to teach you anything.
I had a job where I was the C code reviewer, but was not allowed to program in C[2]. One developer, a fairly senior one, wrote some of the worst code I've ever seen. My code review was basically C 101 and it really was a tough chore to keep myself following good body language and words while still indicating the code needed a lot of changes to be acceptable. I really do blame the employer for setting the developer up to fail (no C training, just read a book and wing it). I did it ok, but I really wish I had a mentor of some sort in the room to give me a critique of my critique.
1) I really don't mean design patterns, more like the general pattern of code with that project / workplace.
2) Well, obviously I couldn't write C code since there would be no one to code review mine. Not obvious? Wasn't to me either to tell the truth. I got to spend my days programming in a reporting language and AWK. I only lasted 9 months (my 3 seasons in heck).
https://www.amazon.com/Father-Son-Co-Life-Beyond-ebook/dp/B0...
"Oh you don't know that?"
"Oh you don't know about that tool?"
"Oh you use PHP?"
Listen, I am completely guilty of this behavior myself. Howerver, after reflecting I am going to try to be more helpful to peers. Remember that we are all constantly learning, and the knowledge and experience that you have took you time. That newbie was once you.
Finally, let's think about this in terms of rapport. If your dismissive and arrogant toward a peer when they ask a question, they are probably going to think you're a total tool and jerk. Howerver, instead if you have the knowledge and experience and show and teach them, they are going to admire and respect you. It is really the best option.
The only time I would allow myself to react that way, and even that's a stretch, is if I was interviewing someone who claimed to have worked with something for several years, hands-on, and would've indicated to be a guru level expert on whatever it is, and then over the course of the interview couldn't answer even basic questions. You've just flat out lied to me and my team in order to waste everyone's time in an interview.
Kevin sure sounds like a great guy. But there was a simpler lesson to be learned: never, ever push changes on a Friday.
I think this goes a little too far.
I personally push code every Friday morning, and keep my Friday schedule relatively open so I have time to deal with any surprises.
Many successful companies brag (justifiably) about their continuous deployment systems and speed of deployment. I can't believe they suspend all of that every Friday.
http://product.hubspot.com/blog/how-we-deploy-300-times-a-da...
https://github.com/blog/1241-deploying-at-github
https://www.wired.com/2013/04/linkedin-software-revolution/
https://www.facebook.com/notes/facebook-engineering/ship-ear...
However, most likely that have many stages in their deployment with testing and monitoring that exponentially deploys and if any of those stages don't pass, they auto-rollback.
The End game: minimizing risk with code changes.
1. Deploying more often allows easier root cause analysis to identify the code breaking change.
2. exponential deployment allows developers to monitor their services as it partakes in more variation (more users = greater chance of edge case breaking bug)
3. proper monitoring and test coverage while using auto-rollbacks allows developers to deploy without fear as any unintended effects will be detected at the soonest possible moment while minimizing cost to the users of that breaking change. Then, auto-rollbacks will redeploy code changes that previously worked which should automatically mitigate that code breaking change.
I was a bit bemused when a young guy who had just gone into devops and sysadmin gave me a mini lecture on the importance of open source and contributing to it if you have the skills, and that I really should give it a go one day, because open content is amazing.
I didn't have the heart to tell him I'd gotten into a few of the LibreOffice release notes for work I'd done on the project. Nor did I feel like telling him I'd made significant contributions to Wikipedia. I think I sort of weakly smiled and tried to change the subject.
Good on you for being patient and not letting them drag you into a place that would have humiliated them, though.
I had a similar situation - where alerts based on bad data went out to customers, and hundreds of customer support tickets started flooding in. The VP, Director, and my manager all came to my desk.
Instead of chewing me out, or telling me how much I had messed up, they calmly figured out the issue, told me that mistakes happen, and thanked me for helping them figure out how unreliable the underlying data we were using was.
Senior developers who make the same mistakes over and over and never learn? I've kindly pointed out the mistake and invited them to avoid it in future. After a few more failures, I sometimes talk to them sternly, but the sad thing is that they won't learn from either kindness or harshness. I'm not in a position to fire them. Does anyone have an idea better than "Just suck it up?"
One developer writes huge methods or functions with a tangled mass of if-else. The inevitable result is that an else case missed and the whole thing fails spectacularly in some situations. Discussions with the developer are basically "That's how I've always done it and I don't want to change. I'll just add that missing else".
Another developer constantly forgets to terminate servers that he started in our cloud hosting provider. This costs the company money and thus should be avoided. When its noticed that they're still running, he gets asked to terminate them but he doesn't do it right away and forgets again. Someone else ends up doing it. He's been asked repeatedly to make sure to terminate the servers. Suggestions to help include setting a timer, writing a script that will check for unused servers, etc. Those suggestions aren't heeded or I guess he forgets to remember to set the timer.
Another developer says in a meeting that he'll perform a task, but forgets before he gets out of the meeting. When he's asked to write it down, he does so, but never looks at the paper later.
There are more cases, but it seems to boil down to people not learning. You need to learn how to structure your code, you need to learn how to manage your time, you need to learn how to remember to do something.
But maybe I'm the slow learner and I'm missing something. Thus I'm open to suggestions. So far my strategy is to accept that these other developers behave this way, and setup ways to protect myself from their failures.
Animals will have ingrained habits, many of these will be maladaptive. People though can create systems and systems can adapt for those habits. Do some cost/benefit analysis to enacting policies within the system that is your software development lifecycle. Assign people tickets, tag machines with their desired longevity and kill machines past their designated life span (or a default minimum), hold code reviews for new highly conditional methods and include drawing out truth tables and checking the desired behavior for each row.
Lots of teams either expect everyone to be be an ideal spherical engineer and stumble when that proves not to be, or expect nothing of anyone and are doomed to achieve that expectation. The middle path of expecting excellence but tolerating failure is a lot of work but has plentiful advantages. How much failure you have to tolerate and how complex the systems designed to provide that tolerance are depend on the makeup of your team and its size (the larger your team the closer to the mean you'll have to be, and with more individuals a wider variety of behaviors will be represented).
I suppose I'll just have to do my best to expect excellence and tolerate failure. I appreciate the insight.
- Don't criticize, condemn, or complain. - If you're wrong, admit it quickly and emphatically.
There are many good anecdotes like this in the book, including endymi0n's example.
This is why I love being a developer.
Terrified, I ran to a senior engineer, who calmly and efficiently proceeded to restore everything in a few minutes. The only thing he said to me was "happens to everyone, don't worry about it, just be more careful next time."
I was extremely thankful and a LOT more careful next time, and each time after that.
> The choice to be kind can be hard, especially when you’re frustrated or when, thanks to your gifts, you know that someone has made the sort of error you could easily have avoided. It’s easier to be direct; to not concern yourself too heavily with the emotions of others; to want to be unequivocal in your rejection.
Being kind is hard, and being an asshole is easy. People have a natural tendency gravitate towards the easy choice, the path of least resistance. Making the more difficult choice to be kind takes time, effort, and lots of empathy, but I firmly believe what you get in return is worth all that.
By being kind, you help create a more trusting, inclusive, and generally more pleasant atmosphere for you and your team to work and grow in. People also tend to respond to kindness in kind (bad pun intended, sorry!), and kind people tend to prefer working with other kind people, so in many ways kindness literally begets more kindness. Being an asshole also comes with similar feedback loops, but I know which one I want working for my team!
Disclaimer: I'm working at CircleCI now. :)
Computers are unforgiving. Humans err. This really needs to be at the forefront when selecting personal - developers and managers. The answer can't be all forgiving. It can't be you are fired. And it probably should not be ad-hoc all the time. Company values matter if they are lived by.
And, can take those lessons learned, and establish practices to help prevent and minimize such mistakes in the future.
I've seen lots of teams totally embrace the first, but inexplicably, don't follow through with the second step. They go through the motions of "learning" without actually learning.
Since I don't have insight into their heads, and I can't tell if something was a sloppy mistake because they were inexperienced, or a sloppy mistake because they were trying to get out the door to a camping trip and prioritized their personal life over the team or client.
Clear example of why it's bad to deploy on Fridays, why it's bad to have single-person deployments, why it's bad to leave your laptop at home, etc.
But how would the kindly Senior know the Junior dev just made a mistake vs. was a fuckup and was thinking, "I don't give a shit, Senior will catch it and I just want to be on a beach now. Fuck it, I'm 'done' -- now to just sneak out and put my phone in the glove compartment for the next 3 hours while this blows over..."
The answer is he wouldn't.
So here's the other issue. Let's say I trust one person more than another. And Junior A -- who I believe to be a superior talent -- gets the benefit of the doubt, but Junior B gets scolded.
Now let's say there's even the slightest difference in hair length or eye color between A and B... and presto that's an HR discrimination complaint I now have to deal with. As it turns out, Juniors don't have insight into the minds of Seniors either.
So, some good advice... Be humble, do what you can to not make things worse for others, set up good practices that let everyone thrive (the best way you can do this is to avoid failure opportunities -- i.e. don't deploy on Fridays), and do what you can to treat everyone fairly and equally based on perceived actions and offenses.
We can't know what goes on in someone's head.
There is a dash-cam filming the inside cockpit of a plane when the pilot abruptly finds himself in one of those "death spirals" or "flat spins".
The pilot doesn't say a word.
He immediately reverts to his training, rights the plane, glides it towards the ground, and only grunts a bit when he crash-lands.
I found that absolutely amazing. To have that level of poise when you are literally facing death is unbelievable.
It is very similar to the simple advice given in the linked blog post.
Staying calm in difficult situations is the most efficient course of action.
Stressing out, raising your voice, yelling about things, or blaming others isn't going to do a damned thing when your plane is literally spinning out of control and going to kill you in a few minutes.
> "death spirals" or "flat spins".
A spiral and a spin are two very different things, and a spin and a flat spin again are very different.
In a spiral you actually still fly, in a spin you are not, you are in a continuous stall situation. That means from a spiral you can recover simply by "flying out of it", for a spin you have to do stuff you would not do when "flying", like full(!) and sudden rudder.
This heavily depends on the airplane, but a flat spin can be really dangerous, getting out of one often is much harder than from a "normal" spin. No problem in an aerobatic airplane, but in a jet it can be an unrecoverable situation.
This is why I really dislike road rage - people take dangerous situations and make them worse, usually saved by instincts alone.
So in case of a critical error/melt-down you should first of all blame yourself and think about why you set up a process and an environment that let this happen in the first place.
Think about what went wrong and how you can prevent it from happening again. When I started at my current place of work, they had a horrible manual deployment process that was the cause of 99% of all problems they experienced. Rarely critical problems, but still annoying and unprofessional. So we implemented automated build, test and deployment process that got rid of almost all of these problems.
Now, whenever something bad happens, we realize it is a problem with the process (not the individual) and correct/improve it as needed.
You cannot run a team without some measure of criticism or feedback.
One of them was really kind and a nice guy that was getting along with everyone else in the office (other teams etc). Also he was a very good dev. Nice personal projects, knew what he was talking about, humble and hardworking.
The other developer was aweful. He was slacking a lot, all day on facebook and doing his personal home-owned business over his actual work, not caring to help me at all on any request. We didn't get along, and at first I thought it was my own issue. Later on I realized and having a talk with my manager that noone really was getting along with him. At some point he thought it was a great idea to make an education session, I was like ok he is putting time into it. He then proceedeed telling me that he is gonna teach me the very basics of programming as "we" didnt go to uni, I told him I went to uni and I finished with a Distinction but sure he could tell me whatever. He was trying to teach me things he didnt even understand and I was taught about them at uni. (I understand this is a basic mistake junior devs make think that they know it all, this wasn't the case here, he was trying to teach me some basic CS concepts, I went to uni for it he never went to Uni for it, he was just a programmer, nor he had the interest or hobby to go more intellectual on the matter) This lead me into not trusting him at all, in anything, while the other developer was really kind and he let me on his own to understand that he was a really good developer and I should listen to him.
A year later my performance was really good in the yes of the company, I was producing a lot of stuff etc. The developer that didn't like me was clearly angry at me. He was producing things that could be done in a week in like 3 months. Well long story sort, the company wanted to fire him, although it wasn't very viable at that moment as they would have to pay him cause he was with them for a very long time, so they started a formal process against him by keeping schedule giving him a formal warning etc. He improved etc.
I stayed at the company till I became a developer and a year after. I was working alone on mobile apps, and I remember having a chat about an issue I had for the app and some ios apis and how I tackled it and I remember that dev still trying to tell me what to do and how although he never ever working in a mobile app in his life or any experience in that field whatsoever.
Anyways, please don't be like the 2nd developer, be nice and let junior developers believe in you and understand your actual skills and capacity on their own. You don't need to brag or try to showoff because you might end up making them not trusting you.
Don't deploy to production on Friday! Queue it up in staging for Monday morning. Make a team policy for it!
http://michelbaudin.com/2012/10/27/deming_8_of_14_drive_out_...
Trying to become that same engineer in my own way, but I definitely own a lot to him. And to other professors from uni/school that were extremely kind as well.
> Access to production
> With clients that need the service running 24/7
Oh boy... is he used to work on facebook? when i was a jr dev, i didn't have access to production everything went to source control and then tested by my project technical leader and qa. This ensure that i won't do this things since my changes getting reviewed and tested plus we have reproducible builds that anyone can verify and continue working.
Case in point: No JR Dev ever need access to production ever, period.
The very first day of my first 'proper' job, I made a total mess of something that cost the company around $5000. But my manager was like 'don't worry, we'll sort it, just learn to ask if you don't know how to do something'.
Many years on and I lead a development team. Now I always try my best to 'be kind', to coach and mentor, and it almost always pays back.
That one guy's kindness had a lasting impact.
So that is another lesson learned in addition to being cool when someone messes up once in a while. In ego driven teams sometimes it turns into the blame game and throwing under the bus, that is not kind.
Everyone is a peacock here. The bumbling programmer should thank his stars his boss does not appear to be the typical agitatedly infallible HN commentator or monday would be a different day.
I was really surprised to get the coveted desk in the 60° server room. Coming in off those 90° 100% humidity streets to put on a parka and sit at my workstation wearing fingerless gloves.
Man, anybody should be so lucky to apprentice with that guy.
But some people take things very personally, even if you try to be very polite and respectful.
Sometimes people, especially people with narcissist traits or people obsessed with rank, will not accept any feedback coming from a someone from a "lower rank".
Much better is: "Shit happens." That's an empathetic attitude that reflects experience in our field.
kindness doesnt automatically emerge to replace a lack of negative outcome.
"My father didnt hit me with his belt" is not kindness. "My boss didnt fire me" is not kindness.
Good god, this should be taught in high school.
I find it really unfortunate when an engineer is fired because of a mistake. All the company is really doing is giving a more experienced engineer to someone else.
Never push changes on a Friday PM. Ever.
Let it be a deployment free day!
Yeah, Brian screwed up. But the company has at least some fault for letting him get that far unchecked.
Edit: spelling.
This reads almost like a fairy tale.
People who can handle serious mistakes in others are some of the best partners you can have in your efforts. IMHO they aren't fairy tales.
Instead of blasting people for mistakes they set about fixing the immediate problem, and then instead of demanding "accountability" from those responsible, they set about fixing the root cause.
A few excerpts from the linked article:
"Aside from the fact that there was immediate chatter about who might have made such a dumb move, the discussion quickly moved right on to how to fix the problem."
"Instead of dwelling on pinning the blame or lamenting the loss of time and effort, the team made sure to alter the backup strategy so that something like that didn’t happen again, and it went about making up for lost time."
[0] http://thenextweb.com/media/2012/05/21/how-pixars-toy-story-...
A minority of people are toxic, you start by cutting them slack as you'd do anyone else, then you cut them off. It's not really a problem.
To those people the mindset is:
If I do X I might gain something (or feels good) and no mater what I'll never suffer any retaliation for it. Why shouldn't I do it?
Those figures of 4% are fairytales, not unlike what most psychologists said before knowing the outcomes of the Milgram experiment.
Almost no one believed that the vast majority of subjects would take the experiment to its end.
By assuming you know why people are doing things, you've already biased yourself against future information that may contradict that. Maybe sometimes they aren't doing it to be a dick to you, and maybe sometimes what you view as gloating isn't directed at you, or isn't actually gloating.
They'll do it in private so that their social standing doesn't suffer but they are very explicit about it.
Not a lot of room left for assumptions after this.
Downvote away.
How many, out of all the people you interact with? It's safe to make your assumption the people who revealed their workings to you, but not with everyone else.
So with your mindset, it's no wonder people react to you the way you describe it. But believe it or not - most probably you are the problem, not them.
Giving into anger is the easy thing to do, but in doing so we become emotionally blinded to more practical courses of action which we may have realized if we had kept our cool.
You are obviously free to decide to detach the threads that you see fit, but not detaching at the parent level strikes me as incomprehensible and discretionary.
...he said, before his final fatal flight. Apparently some people DO do the same mistake twice.
([Edit] to avoid confusion: My addition is about giving a different twist to the story, to show that it's not a given that people who made a mistake will not be prone to repeat it. Some people seem to be extra prone in repeating certain mistakes. It's not saying Hoover actually died or anything... I mean, isn't it obvious?)
That's why in the except I kept, I didn't keep any reference to Bob Hoover. It's about the idea in the story, not some particular pilot.
There's a world of difference in how you should treat someone you know almost nothing about that makes an mistake that is almost fatal for you and someone you know to be fairly responsible. That doesn't mean don't be nice if you can, relative to the situation ("nice" when someone has almost killed you doesn't necessarily mean be cordial, it may mean cool down for a sec before attempting to get them fired), but it would be stupid to assume the same mistake won't happen again without knowing a bit more about how it happened in the first place.
I could tell a story about purple moon dragons, but it wouldn't "show" anything.
The point wasn't to give a true example, it was to add a twist to the ending of the story told by the parent to make those reading it fathom an alternative way things could have gone that goes contrary to its message.
>I could tell a story about purple moon dragons, but it wouldn't "show" anything.
Why not? That's what allegories, parables, zen koans, fables and 200 other forms of fictional stories used in making a point do.
Oh good, a bunch of useless platitudes.