
Be Kind - bgilham
https://www.briangilham.com/blog/2016/10/10/be-kind
======
endymi0n
When he returned to the air field, Bob Hoover walked over to the man who had
nearly caused his death and, according to the California Fullerton News-
Tribune, said: “There isn’t a man alive who hasn’t made a mistake. But I’m
positive you’ll never make this mistake again. That’s why I want to make sure
that you’re the only one to refuel my plane tomorrow. I won’t let anyone else
on the field touch it.”

~~~
pfarnsworth
There are two schools of thought, especially in stock trading.

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.

~~~
wyago
I know you're probably not implying regression to the mean is causational, but
that was my initial reading so I want to clarify for those who may not be
familiar with the concept.

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.

~~~
cortesoft
Yeah, I always make an example with coin flips to show how this is true....
lets say heads is success and tails is failure.

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.

~~~
abhi_kr
Except, coins are not humans with emotions, and neither can they dupe
probability to improve their outcome. The 50 heads(success) that you left are
not going to do any better than the 50 tails you scolded. You are just
changing the sample space in a biased fashion to prove your point.

~~~
cortesoft
I think you are totally missing my point. The whole point I am trying to make
centers on the fact that the coins are all actually equal. The observed
difference in performance is entirely due to chance.

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.

[https://en.wikipedia.org/wiki/Regression_toward_the_mean](https://en.wikipedia.org/wiki/Regression_toward_the_mean)

------
gavman
This was so nice to read. I think back to my very first coding internship
after my freshman year of college when I messed up big time. I made a bad
mistake that ended up forcing my supervisor to put down everything he was
working on for a full afternoon and do an emergency fix. I so vividly remember
sitting down in his office, trying to just calm down and keep it together. He
never got upset or annoyed (at least he never showed it), instead he listened
to me explain what I had done, figured out what was wrong, showed me what my
mistake was, fixed everything up, and calmly walked me through the entire
process, turning it into a learning experience. At the end he asked me some
questions to make sure I understood everything that happened and told me
"everyone makes mistakes, don't sweat it, just make sure you learn from it"
and that was that. I remember leaving his office that day thinking "if I ever
make it to the point where I have my own interns, I'm going to do everything I
can to support them and treat them as well as he treated me." A little
kindness really does go a long way!

~~~
doczoidberg
when a supervisor gives a freshman work which can mess up erverything it is
the supervisor's fault and not the fault of the freshman

~~~
HerraBRE
Why do you need to assign blame?

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.

------
ninjakeyboard
As software engineers:

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](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.

~~~
nostrademons
Overconfidence is a huge benefit in playing the political game - getting
people to take you seriously, managing up, interfacing with the outside world.
Like it or not, humans are primed to respond to confidence; for most people,
listing the dozen ways a system may fail signals that you shouldn't use the
system, while for engineers, it signals that these are a dozen things to be
fixed.

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.

~~~
haalcion3
This is why I don't really want to get back into management, even though
sometimes I think at some point it will be the only thing I'll have the
patience and mental capacity to do. I saw the best and worst of myself when I
was a manager- the worst is what scared me. But moreover, I learned after I
stopped being a manager that I didn't deserve the accolades I got. If you were
to take the best manager in the world, give him/her a shitty team, a hell of
shitty code, shitily designed application and infrastructure, a shitty
relationship with the customers/users, shitty support team, and shitty
project/product/upper management, and you don't let that manager work to fix
these things, they'll quit or fail, guaranteed. If you give them the best of
all of these things, they will succeed, guaranteed. Being a good manager-
knowing how to manage well and doing it, can be critical. However, it is
nothing on its own.

~~~
blacksmythe
One big difference is that a good manager can take an average team and build a
good team over time. If you can't do that, you aren't a good manager.

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.

------
crush_xc
This was literally the biggest issue for when I started at my first job. We
had a team member who was terribly condescending and talked down to everyone
but especially me. You could tell that he hated the fact that he was on a team
with a junior developer and took every chance he had to made sure I knew I
wasn't as good as him. It makes a terrifying environment to ask questions
because who knows what kind of response you're going to get.

~~~
cheez
Oh his behalf, I apologize. I literally started laughing at a junior's code
once but in my defense, he had spent 3 years at Amazon.

~~~
hluska
I'm sorry, but you have no defense. Laughing at a junior developer'a code is
completely inexcusable.

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.

~~~
savanaly
I think you're quite possibly judging the guy too much based on a simple
internet comment.

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.

~~~
icebraining
If it was a completely private laugh, seems weird that they would apologize
for the previously mentioned jerk.

~~~
sheepmullet
Due to open office layouts there is no such thing as a private laugh.

------
scraft
Nice little read. There is that little answer in the back of my head of:

"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.

~~~
overgard
Think of what you're saying on a meta-level here. You would basically be
telling this guy, _" I fucked up, but I'm blaming you for treating me like an
adult instead of a child. You screwed up by giving me enough autonomy that I
could make a mistake."_ That might not exactly be a smart career move..

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.

~~~
nathas
I disagree. If you have something that is of significant value to the company,
you need to hedge your risk. Automation is a particular hedge. People fail,
and while processes do too, they often fail less.

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.

~~~
slgeorge
I think you've hit the nail on the head at the end with "right tone at the
right time" \- the right time is almost certainly not when one has screwed up.

~~~
brazzledazzle
Or if you think it can and should be fixed at that institutional level tell
them what you've learned to do better on a personal level and then volunteer
to help lead the effort to create the automation/systems to prevent anyone
else from making the same mistake in the future.

------
_joel
One way to avoid Friday deployment issues is to go to the pub. Obviously you
need to spend all afternoon there and not be tempted to go back and deploy,
otherwise issues may be compounded! It seems to be a common mitigation
technique in some shops I've worked at ;)

~~~
NetStrikeForce
I can confirm it is an approach taken by different companies out there.

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...

------
mrits
I hope Kevin learned not to let a junior dev deploy to production on Friday.

~~~
phn
Well, he'd have to sooner or later. Better start learning as soon as possible
:)

~~~
sparrish
Nobody should be deploying to production on Friday... Nobody.

~~~
Shanea93
My company just had to do it today in response to a critical security issue we
identified in production.

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.

~~~
falcolas
IMO, if you deploy on Friday, you are promising to be available for fixing it
on Saturday... which makes it not really a Friday in the sense in which it's
meant.

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.

~~~
tomjen3
So I should just leave a security vulnerability rather than fix it on a
Friday, because I won't be available Saturday?

~~~
niij
Read to comprehend, not to argue.

~~~
danielweber
Great, _now_ what am I going to do with my life?

------
auganov
The reverse takeaway is perhaps even more valuable. Most are not going to be
as angry as you expect them to be. When you mess up don't hesitate to tell
people, it's going to be okay.

~~~
CWuestefeld
This is pretty much rule #1 for my team. If you make a mistake, I'm not going
to yell at you, but

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.

------
throwaway7767
Most of my career I've been the guy people come to when they get stuck and
need a second pair of eyes or just advice. I enjoy it, we all have to start
somewhere. For the most part this has been considered a positive by my bosses,
because they see the value this creates even if it's not technically my core
job.

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.

------
happyslobro
Mentoring is hard. It makes me question everything that I know, and worry
about what this guy's code will look like in a year if I criticise this, or
praise that. I wish there was some way we could all just work together, for
real, in real time.

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.

~~~
vlunkr
Ha, it's true. I grew up around lots of construction and farming. Those people
just aren't as sensitive as white collar workers. Probably why I'm not working
at a place like that.

------
sideproject
I run a number of side project sites and I do much of my work late at night.

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.

~~~
Cthulhu_
Generally a good idea, if you don't have a setup where everything is validated
end-to-end before you go to production - which is most software, and even if
you have end-to-end automated verifications there's still risks outside of
that scope / vision. (a server may run out of hard disk space from the new
code, to name something random).

------
euske
This reminds me of a similar story about being nice. It has nothing to do with
software development but I want to share this anyway.

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.

~~~
fcoury
I had a similar one. I was working in Rio de Janeiro, here in Brazil and money
was really really tight back then. I would fly from Rio back to my city where
my girlfriend is every other week.

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

------
LukeB_UK
I wish my first development job was like this place. Instead there was a blame
culture and I'd get told off when I made mistakes, eventually getting fired
for not progressing quick enough.

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.

------
jroseattle
This is underrated for managers and leaders trying to develop young talent.
The takeaways:

    
    
      - 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.
    

Some might believe that a serious ass-chewing is needed in this scenario; that
would be a decision that's simple, quick and stupid. An emotionally-charged
ass-chewing is almost always a sign of weakness in the ass-chewer. The only
thing anyone ever learned about a beating is how to avoid it in the future.

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.

------
makecheck
I have found that difficult people are a function of both themselves _and_ the
environment they’re in, and you can’t necessarily say “be kind” without fixing
the 2nd part.

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.

------
randartie
Seems like this story is being received pretty well here.

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?"

------
mijustin
This statement wraps it up:

 _“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.

~~~
taneq
As long as it's not overdone. If every review ends in "you can do better" it
just becomes the new "must apply themselves more in class".

~~~
falcolas
So long as you're not having to "you can do better" for the same issue every
time, I think it's fine. There's a lot of minutia to learn in software
development; a lot of opportunity to screw up.

------
bluetwo
I've worked with dozens of companies of various sizes over my career, and I've
always found that this type of attitude starts at the top of the company. If
managers are kind, curious, and tolerant of risks that might reap rewards, it
is an indication the person at the top is running it that way.

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.

------
slaunchwise
Also, never deploy and go camping. Not a knock on camping. You should also not
deploy and head immediately to the hospital for scheduled surgery. The point
is that if you deploy, on any day, you need to be available in case something
is amiss. The only advantage to deploying Mon - Thur is that you're probably
going to be available anyway.

------
herge
I have the similar problem with code reviews. It is really hard to not sound
harsh when giving a code review, especially in ones from junior developers
where a whole laundry list of fixes comes out.

~~~
matwood
Best way not to sound harsh is to ask questions. "What are your thoughts on
...?", "Is this really what you meant to do?", "Do you think there is a better
way to handle...?". It puts the power and learning opportunity back to the
other person and lets them feel the accomplishment of improving.

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.

~~~
gwbas1c
I find that tone works when the developer has clearly thought things through.

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.

~~~
icebraining
Does being stern actually produce better results?

~~~
gwbas1c
Yes, much better. It establishes that we are a "clean code" shop, and that
sloppiness isn't tolerated.

This is important when dealing with junior contractors.

------
deedubaya
Be kind, but don't be passive either. Talk about it, be kind, but don't glaze
over the learning experience.

------
davemel37
I heard a story about Pepsi (dont recall the names), where an executive made a
decisiom that lost them 10 Million dollars. The CEO called the executive into
his office... The executive shuffled into the office, head down, and meekly
said, I guess you called me in here to fire me." To which the CEO replied,
"FIRE YOU?! I just spent $10,000,000 educating you!

~~~
chiph
I recall that from Thomas Watson Jr's autobiography about his life working for
his father at IBM.

[https://www.amazon.com/Father-Son-Co-Life-Beyond-
ebook/dp/B0...](https://www.amazon.com/Father-Son-Co-Life-Beyond-
ebook/dp/B00DXKJ6KE/ref=tmm_kin_swatch_0?_encoding=UTF8&qid=1476456773&sr=8-1)

------
nodesocket
I was just thinking about this today. Why is it that software engineers have a
supreme mind set...

    
    
        "Oh you don't know that?"
        "Oh you don't know about that tool?"
        "Oh you use PHP?"
    

We categorize our peers into two buckets. One with whom you respect, and
unfortunately the other as newbies, rookies, not worthy of our time and
energy.

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.

~~~
gorbachev
That sort of dismissive, arrogant behavior is my number one red flag during
interviews whether I'm the one interviewing a candidate or I'm being
interviewed.

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.

------
bambax
> _One Friday afternoon (...) [Kevin:] what did you learn? / [OP:] I talked
> about the need for proper QA. About thoroughly testing my changes. About
> taking the time to make sure the job gets done right._

Kevin sure sounds like a great guy. But there was a simpler lesson to be
learned: never, ever push changes on a Friday.

~~~
grossvogel
_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...](http://product.hubspot.com/blog/how-we-deploy-300-times-a-day)

[https://github.com/blog/1241-deploying-at-
github](https://github.com/blog/1241-deploying-at-github)

[https://www.wired.com/2013/04/linkedin-software-
revolution/](https://www.wired.com/2013/04/linkedin-software-revolution/)

[https://www.facebook.com/notes/facebook-engineering/ship-
ear...](https://www.facebook.com/notes/facebook-engineering/ship-early-and-
ship-twice-as-often/10150985860363920)

~~~
rak00n
Pushing twice a day in that Facebook story gave me a shiver.

~~~
mrep
If they were deploying to their entire fleet all at the same time, I would
also shiver.

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.

------
chris_wot
Junior devs should also remember that whilst they might be trying to be kind,
sometimes the support person you are trying to instruct probably knows more
than you do.

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.

~~~
edc117
Juniors in particular are guilty of this, I've found - spending the last few
years solving problems, they often come into the real world looking at most
problems as 'simple' or 'a waste of time', and tend to be dismissive of non-
programmers or domain experts. Some young people can also be surprisingly
arrogant. College tends to be a very different experience from the working
world.

Good on you for being patient and not letting them drag you into a place that
would have humiliated them, though.

------
superjisan
Thanks a lot for sharing this. I've been in 3 different companies now where I
learned a lot but the biggest reason I left my first job was because I was
afraid to ask questions because my boss did not know how to respond to a
simple question without being snarky or rude. I learned a lot from that job
but I knew that I wanted to be in a better environment and I am thankful that
I made that decision. Working in an environment where everyone is encouraged
after making mistakes and learn from it is where I want to work for.

------
anateus
The virtues of being nice are often extolled, but it's kindness that's truly
valuable. You can do nothing and be "nice", but only actions can make you
kind. When you strive to be kind, you'll also start noticing who around also
tries to be kind and who is merely nice.

------
weaksauce
Also, don't ship on a Friday unless you expect to work on Saturday.

------
realkitkat
#FirstJobsMatter! Based on my subjective, statistically unsound observations,
when it comes to bad, obnoxious, and intimidating work place behavior there
are people who cannot be helped and are equal opportunity offenders, and then
the vast majority who appear to have picked up poor behavioral habits from
their old bosses, peers and companies that they were unlucky to be associated
with early on in their careers. I would assert that very few of us are
resilient enough to truly differentiate between good or bad workplace behavior
[in an early stages] of our careers - especially when you scored a job in one
of the many respected companies with a track record of success. No matter how
toxic the culture - it must be right since company is doing good, right? And
then as we move forward in our careers we take these ‘learnings’ with us. As a
recent observation, this seems to apply to all phases of peoples careers where
I witnessed an outstanding R&D manager / director turned into monstrous VP,
who in reflection is just putting into action same management practices that
were used by a pre-acquisition start up CEO he used to work for. And then of
course there are those golden people that really make it worthwhile to come to
the office and that you just love working with/for - sort of like the project
lead described in the story here.

------
binalpatel
Situations like this really let you know the true merit of your leadership.

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.

------
justin_oaks
Junior developers who make a mistake? Cut them some slack and teach them.

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?"

~~~
Bahamut
Talk to your manager. That is their job to make sure they are doing what
they're supposed to in a more formal setting if informal coaching does not
work.

~~~
justin_oaks
Yes, I suppose this is the "correct" way. If my manager doesn't have a problem
with my coworkers failures, then I'll just have to tolerate it too.

------
mysterpaul
This demonstrates two principles from "How to Win Friends and Influence
People":

\- 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.

------
karenho12
I have witnessed the same thing at my current startup and this is the reason
why I excel at my job and why my coworkers are some of my dearest friends. It
is this sense of camaraderie that brings people together. We've all been
through a lot, late nights of frantically pulling together an entire feature,
reading scores of hibernate exceptions, debugging through IE bugs and jumping
to help another developer with no questions asked. It is this through this
journey that I learned how to provide safety nets for my junior developers and
find ways to lead them to success just like my predecessors have done for me.

This is why I love being a developer.

------
gautamdivgi
Great anecdote. We've all done it. Another thing I learned really early on -
never deploy code on a Friday. Especially not Friday afternoon/evening. And
definitely not if you're leaving for the weekend :)

------
zavulon
I had a similar experience when I first started as a junior engineer at a
financial company. By accident, I dropped a database in production...
immediately, people found out and the head of production support came to me
and said "This is strike 1".

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.

------
lewisl9029
This reminds me of one of my favorite blog posts:
[https://circleci.com/blog/kindness-is-
underrated/](https://circleci.com/blog/kindness-is-underrated/)

> 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. :)

------
heisenbit
I think there are few professions where people screw up a little bit
(sometimes literally) and it gets logged, measured and escalated so frequently
than in SW.

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.

------
mikeleeorg
The best teams and organizations are the ones that are constantly learning,
and foster an environment that encourages and supports that.

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.

------
d--b
Is that so uncommon? I mean, maybe I've been particularly lucky in my career
but that sounds like standard behavior to me. I mean you already feel bad
enough for blewing it that it's no use to add some more to it. And as the
article says it happens literally to every one of us at some point. So unless
your boss is a genuine ______bag, that 's the expected way they should react

~~~
hueving
Unfortunately there are a non-negligible number of managers that take to the
'stick' approach and will yell at people, etc. Many people seem to be okay
working in that environment so there doesn't seem to be pressure to stop that
behavior.

~~~
bobic171
I have been a graduate dev for four months now and i already feel like im not
good enough on almost a daily bases. Though I do enjoy my code reviews because
i know it will improve me as i go along.

------
dbg31415
While it's nice that we know that the protagonist is agonizing over his
mistake, in reality, that's not often the case.

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.

------
GigabyteCoin
All this talk about being kind (or staying calm) in tense situations reminds
me of this video I caught on reddit last year. [0]

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.

[0] [https://www.youtube.com/watch?v=bvbS-
oHi9ro](https://www.youtube.com/watch?v=bvbS-oHi9ro)

~~~
Noseshine

      > "death spirals" or "flat spins".
    

Just an aside, for the record, obviously not important but since the topic
came up...

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.

------
JohannesH
Also as a senior developer you carry some of the responsibility for the
junior's ability to make that mistake. You probably set up and maintained the
development environment where such an error could slip through into
production.

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.

------
isuraed
This reminds of important lessons I've learned from the classic How to Win
Friends and Influence People - never ever criticize people and you will get
the best out of them. There are countless other great lessons in this book
about being a leader and dealing with people.

~~~
brlewis
I agree except for the word "never". In this story he was able to say “Great.
It sounds like you get it." If you can't honestly say that, then it's time for
some leading questions possibly followed by criticism.

------
muse900
When I started of as a junior developer it was in a team of 3. 2 Senior
developers and me.

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.

------
binarymax
I'm re-reading Peopleware this week, and this is one of the core points it
makes. You need to give the team the flexibility to make mistakes. I'm not
sure I've ever met a manager who has read that book and disagrees with that
principle.

------
dudul
While I fully appreciate the point of the post, the junior dev didn't screw
up. The team screwed up for not having a process and practices designed to
avoid these mistakes. Unless they do have those, and Brian decided to ignore
them.

------
ummahusla
101: Never deploy on Fridays.

------
pwenzel
> It’s okay,” he replied. “We’ve all done it.” He paused for a moment. “But
> what did you learn?”

Don't deploy to production on Friday! Queue it up in staging for Monday
morning. Make a team policy for it!

------
narrator
This is the Kaizen/Deming principle #8 of "Drive Out Fear". Here's a good in
depth blog article about this as it's a difficult to explain topic that,
especially for managers trained in the older methods of management, deserves a
long form treatment:

[http://michelbaudin.com/2012/10/27/deming_8_of_14_drive_out_...](http://michelbaudin.com/2012/10/27/deming_8_of_14_drive_out_fear/)

------
kinow
Had similar experiences in my first job with one of the smartest engineers I
ever worked with (Claudio Marcio da Silveira). He early-retired to work on his
family business (something related to flowers). But I can still remember all
the times he let me learn by doing small mistakes, covered my bigger mistakes,
and also educated me.

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.

------
SadWebDeveloper
> Jr Dev

> 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.

~~~
ceronman
I disagree. I work for a big company with a big product that shouldn't have a
single minute of downtime. We let new devs deploy to production from day 1. We
have ways of mitigating the risks, like a very sophisticated monitoring and
the ability to rollback changes in seconds. Yes we sometimes have outages, and
we lose money. But in our experience, empowering developers is much more
effective than handcuffing them. They learn to be careful and freedom allows
for creativity to flourish resulting in amazing solutions.

~~~
SadWebDeveloper
I think in your release model are forgetting about development and the staging
areas that most devs can run or well use freely before ever going to
production. Those are the places where the developers not only have access but
are also encouraged to disrupt, destroy and let their creativity run before
going to production. Giving access to production from day 1 its a disaster
waiting to happen and m pretty sure stoling ip or databases aren't part of
your monitoring software scope nor being able to detecting malice.

------
carlmungz
Good to know there are people looking out for junior devs :-)

------
GordonS
Wow, this really resonates with me.

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.

------
SloughFeg
The hardest thing for me when I was junior dev was simply being noticed. I'd
rather someone be hard on me than to pretend I don't exist.

------
vilius
This advice is obvious. How can you not be kind with a junior person that
makes a junior mistake? It's human. An angry phone call would not have made
any difference (except damaging the relationship). But what if Brian deployed
on Friday night without testing 4 times in two years? And 3 times it caused
trouble for the business. How do you stay kind then?

~~~
biesnecker
You can be kind while still being critical. Even if it's kindly letting the
person go with as soft of a landing as you can provide rather than the walk of
shame to the lobby with security.

------
partisan
A mistake is an education. If you fire someone after they make a mistake then
you are throwing away your investment in their growth.

------
johngalt
For actionable advice on how to be kind while still capturing the lesson. I
recommend this article by John Allspaw on blameless postmortems.

[https://codeascraft.com/2012/05/22/blameless-
postmortems/](https://codeascraft.com/2012/05/22/blameless-postmortems/)

------
drawkbox
The mistake was launching something on a Friday before vacation. Wed or
Thursday would solve this. Launching on Mondays or Fridays, not a good idea.

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.

------
throw2016
Cmon. An article about kindness as top post on HN. This is taking the piss.
This is a place that specializes in snark and dismissive discourse.

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.

------
hyperpallium
proggit has a better title: [Mentoring Junior Devs: Be
Kind]([https://www.reddit.com/r/programming/comments/57g3x7/mentori...](https://www.reddit.com/r/programming/comments/57g3x7/mentoring_junior_devs_be_kind))

------
jasonkostempski
Maybe im just lucky but this is generally how any manger I've ever had
normally would have handled the situation. Not every single time, of course,
since they were all humans and got frustrated sometimes, especially after a
few of these in a row, but for the most part, they weren't dicks.

------
odammit
My first job was at an aerospace company in Florida. My boss was so nice.

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.

~~~
ythl
For some reason I am imagining you working in a server room shaped like an
equilateral triangle (i.e. the walls of the room meet at a 60° angle)

~~~
mkagenius
And he came out of an aquarium (i.e. 90° walls + 100% humidity)

------
partycoder
I have seen people that react positively to feedback.

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".

------
johnwheeler
If someone asked, "what I'd learned" in the above context, I'd assume it was
more to satisfy their needs of feeling important and superior than genuinely
caring.

Much better is: "Shit happens." That's an empathetic attitude that reflects
experience in our field.

------
kornakiewicz
Well, this rule applies to basically every field of life. Most (if not all)
religions and moral systems have rules that say to respect the others and be
kind, even if they are not as we want them to be. But I'm not surprised that
it's rediscovered over and over.

------
exodust
I dont think "not getting angry" qualifies as "being kind" unless anger is the
default state.

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.

------
scelerat
"One Friday afternoon, [...] I deployed the changes"

Good god, this should be taught in high school.

------
orangepenguin
I thought this article was fantastic. We could use more kindness at home, at
work, and in general.

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.

------
SadWebDeveloper
Personally i prefer the type of mentor/boss that comes and says things
straight, surgarcoating everything isn't good once you realize that everyone
could think you are stupid or well starting to find your replacement.

------
laxentasken
Stuff like this always boggles my mind - anyone can mess up. Mistakes happen,
but if you didnt learn from it, history will repeat itself. I can't help to
feel that common sense is sometimes lacking.. Why is that?

------
arc_of_descent
Be kind, but also be honest.

------
jxramos
The key sentence: "Kevin gave me the space to screw up, as long as I learned
from it." I like that concept of space to screw up. I definitely recognize the
need for that.

------
Sire
"Blame is not for failure, it is for failing to help or ask for help." It
changes everything. Usually attributed to the CEO of The Lego Group, Jorgen
Vig Knudstorp.

------
oldtech
I only had to rad the first three words "One Friday afternoon". I learned
early that I was doing everyone a favour if no updates went out on Friday
afternoon.

------
mavsman
I have wept in the night For the shortness of sight That to somebody’s need
made me blind; But I never have yet Felt a tinge of regret For being a little
too kind.

------
esafwan
Being founder of a startup, I often get into position as this. I think there
is alot for founders too to learn form this small story. Thanks for sharing.

------
ronreiter
From my experience as a manager, being kind works very well. This is
especially important in the stressful start-up world where tensions are high
anyways.

------
mohsinr
I really liked that article was short and to the point!

------
kelvin0
> “It’s okay,” he replied. “We’ve all done it.” He paused for a moment. “But
> what did you learn?”

Never push changes on a Friday PM. Ever.

------
hobbitdeveloper
Can't believe you could get fired for something like that. Do you work for an
American company or something? Jeeze...

------
JulienRbrt
> I walked into the office certain I was about to be fired. Wait, can you be
> fired that easily ?

~~~
chiph
Many US states are "At Will" employment. You can be fired for almost any
reason, at any time. At the same time, you can quit at any time. Giving notice
is a professional courtesy, but not strictly required.

------
AlphaWeaver
Right now, this post is 4 votes away from being in the top 10 most popular HN
posts of all time.

------
mindfulgeek
Every child should be so lucky to have this experience as well. Empathy goes a
long way.

------
ing33k
Simple but highly effective writing . How can I learn to write like this ?

~~~
brlewis
Here's a list of online writing communities slanted toward young writers but
not exclusively:
[http://study.com/articles/40_of_the_Best_Websites_for_Young_...](http://study.com/articles/40_of_the_Best_Websites_for_Young_Writers.html)

------
alexmchale
Rewind.

~~~
hougaard
Came here for that :)

------
therealmarv
No. 1 rule for deployment: Don't deploy on Friday.

Let it be a deployment free day!

------
poletopole
That's why I never deploy on Fridays. For me, for everyone else.

------
dcwca
This goes for everyone on your team, not just junior devs.

------
shafiul
Very good advice. Your good deed rewards you over time.

------
AdmiralAsshat
Isn't there supposed to be a code review before devs are allowed to deploy
something to production?

Yeah, Brian screwed up. But the company has at least some fault for letting
him get that far unchecked.

~~~
etrain
This varies highly depending on the organization. I've worked at places that
do it both ways. Particularly in small places when resources are tight, teams
are distributed, or there is a non-code safety measure in place (e.g. Business
decisions are made ex-post of the code running dependent on the quality of its
output), code reviews pre-deployment may not be necessary and can even be
harmful (due to wasted resources).

------
finid
Refreshing...

~~~
bgilham
Thanks!

~~~
mkagenius
No problem..

------
joseph8th
Don't tell me what to do. ;)

------
arc_of_descent
Be kind. Rewind. :)

------
dsp0105
Amazing!

------
JustSomeNobody
We're an industry filled with people who have social disorders. Some people
are just angry little people. Misspell something in a config file and they
just ... go ... ballistic... It's not enough to just try and tell these people
to be nice. They don't know HOW to be nice. Their brain isn't wired to be
nice.

Edit: spelling.

~~~
karmajunkie
I hate to be this guy... but 'ballistic' has two l's.

~~~
JustSomeNobody
Correct, and thanks.

------
tofupup
interesting

------
cmoscoso
cool story bro.

------
fairpx
Life happens. Being kind shouldn't just be restricted to junior devs, or even
just devs for that matter. I've seen many folks be flatout mean and
unrealistic to adult freelance developers from low-income-countries. It's a
serious problem.

------
77pt77
Except in real life people sometimes make malicious "mistakes" deliberately
and when caught and called out on them either completely dismiss them or even
gloat.

This reads almost like a fairy tale.

~~~
bjelkeman-again
In my experience very few serious mistakes are deliberate and there is a huge
gain to find a way to not make the same mistake again. Which include avoiding
blame, but rather go looking for the root cause.

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.

~~~
heymijo
There's a story that I love about Pixar, a Black Swan event, and Toy Story 2
[0]. The gist was, the movie's files were accidentally deleted while still in
production, and the backup was corrupted.

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-...](http://thenextweb.com/media/2012/05/21/how-pixars-toy-story-2-was-
deleted-twice-once-by-technology-and-again-for-its-own-good/)

------
coldtea
> _That’s why I want to make sure that you’re the only one to refuel my plane
> tomorrow. I won’t let anyone else on the field touch it._

...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?)

~~~
openasocket
I don't know if you're being snarky or not, but Bob Hoover is still alive

~~~
jakub_h
This Bob Hoover?
[https://en.wikipedia.org/wiki/Bob_Hoover](https://en.wikipedia.org/wiki/Bob_Hoover)

------
sqldba
> I talked about the need for proper QA. About thoroughly testing my changes.
> About taking the time to make sure the job gets done right.

Oh good, a bunch of useless platitudes.

~~~
aws_ls
Honestly, I came to this page expecting some really intriguing story, from
which I could learn a lot. Its been voted to 2000+ points, so must be it hit a
nerve of a lot of people. But to me it seemed like a nice but very simple
story.

