Be kind, but don&#x27;t be passive either. Talk about it, be kind, but don&#x27;t glaze over the learning experience.

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: &quot;Don&#x27;t name your tests test1, test2, test3. Give them descriptive names,&quot; &quot;Follow style,&quot; and &quot;this does not belong in the dependency injector,&quot; and &quot;don&#x27;t screw with event publishing logic, filter this out in the event handler in the UI&quot; are warranted when a developer isn&#x27;t taking the time to think through his&#x2F;her changes.

Also, &quot;why not X?&quot;. It puts the assumption up front that the programmer has already thought it through, which is often the case.

I was subjected to this &quot;Socratic&quot; type of code review when I was younger and I didn&#x27;t like it. I felt like I had to worry about what I thought the reviewer might be thinking as well as what was actually going wrong with the code.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.

Best way not to sound harsh is to ask questions. &quot;What are your thoughts on ...?&quot;, &quot;Is this really what you meant to do?&quot;, &quot;Do you think there is a better way to handle...?&quot;. 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.

My only advice is to not worry too much about it. One of the first things a new dev needs to learn is how to separate critique of the wok from critique of them as an individual.IMHO, code reviews should be clear and concise. They aren&#x27;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.

I find it&#x27;s a good idea to throw in some positive comments as well along with indicating the severity of different comments (e.g. must fix, nice to have).A far worse situation though is when a mid-level or senior developer is defensive about code reviews and won&#x27;t cooperate in the code review process.

When it comes to code reviews; judge the code, not the developer. It&#x27;s ok to be harsh to the code, but always make it a learning experience that people can take something away from -- and as a lead or manager, it&#x27;s important to give your engineers the understanding that code reviews can be harsh, but it&#x27;s meant to help improve everyone on the team, and to learn from anything someone says.

I&#x27;m currently working as a junior dev. Not by title, but by experience. Honestly, I appreciate getting a laundry list of fixes over none. I know either way I can be doing better. As for sounding harsh, I feel it&#x27;s a very subjective thing.

There&#x27;s a developer where I work who has an amazing ability to make you feel good about code reviews --- I come out of one feeling pumped and enthusiastic even though they&#x27;ve just shredded my code apart and now I&#x27;m going to have to do all that work again.Conversely, I&#x27;ve come out of reviews from other people, where they&#x27;ve been fundamentally happy with my code, feeling depressed and miserable.Communication skills are vitally important. I&#x27;ve been trying to learn from the first reviewer; next time they visit I should actually grab them for coffee and talk about it...

This is a matter of being friendly with the team on a daily basis. If you are, then you can change a sentence that could sound harsh without the context into friendly conversation which may teach both of you something new. If you have found anything bigger then one line, sit together, have a laugh or joke (friendly one), chat about the issue, think (both) about improvement. Not so difficult, really.

It sounds like your org is lacking in some basic leadership. If issues are brought up in the code it either needs to be corrected or justified with the team.

I work with a couple of particularly arrogant junior devs. In code reviews I will tell them things like &quot;the way you&#x27;re doing this works, but it&#x27;s better practice to do ...&quot; and they just shrug it off, saying they don&#x27;t really want to change it, they just want their code merged. Drives me crazy. So junior devs, and really ALL devs, please be humble about your abilities or you will be terrible to work with.

It is hard, particularly when management has put someone in a position they don&#x27;t have the training for. In a junior developer that&#x27;s understandable, but still painful when you have deadlines. Luckily, most developers are willing to learn and pretty good at seeing the patterns[1] of things done by the team.To me, the biggest thing is don&#x27;t lie to save feelings. You need to tell the truth or they will feel a whole lot worse later. Loosen yourself up. Don&#x27;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&#x27;t trust aren&#x27;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&#x27;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&#x27;t mean design patterns, more like the general pattern of code with that project &#x2F; workplace.2) Well, obviously I couldn&#x27;t write C code since there would be no one to code review mine. Not obvious? Wasn&#x27;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).

This is one of the main reasons I prefer pairing w&#x2F;junior developers over code reviews. Giving lots of small pieces of feedback feels a lot less harsh than a monolithic dump of everything that&#x27;s wrong.

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.

Also, don&#x27;t ship on a Friday unless you expect to work on Saturday.

Trial by fire. Unavoidable in battle, untenable in surgery.

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

Well, he&#x27;d have to sooner or later. Better start learning as soon as possible :)

Definitely a lesson that was re-learned that day  Some lessons only come from pain.

He did :-) It&#x27;s a lesson I also learned that day.

Kevin might have learned more than Brian that day. It goes both ways :)

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

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

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

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

I don&#x27;t want to ever work at a job where to can&#x27;t get better.

As long as it&#x27;s not overdone. If every review ends in &quot;you can do better&quot; it just becomes the new &quot;must apply themselves more in class&quot;.

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 &quot;do better,&quot; is the best way to lead.

Juniors in particular are guilty of this, I&#x27;ve found - spending the last few years solving problems, they often come into the real world looking at most problems as &#x27;simple&#x27; or &#x27;a waste of time&#x27;, 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.

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&#x27;t have the heart to tell him I&#x27;d gotten into a few of the LibreOffice release notes for work I&#x27;d done on the project. Nor did I feel like telling him I&#x27;d made significant contributions to Wikipedia. I think I sort of weakly smiled and tried to change the subject.

Sure, and I don&#x27;t see them blaming Brian in any way.

This varies highly depending on the organization. I&#x27;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).

This was far enough in the past that code reviews and &quot;Don&#x27;t deploy on Friday&quot; weren&#x27;t necessarily taken as standard practice at a lot of companies yet. But yes, we all learned :-)

Isn&#x27;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.

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.

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

I think you&#x27;ve been lucky. I&#x27;ve seen some really awful senior devs&#x2F;team leads in my time.

I&#x27;ve worked at a few different places now and have never seen junior team members treated badly either.

Is that so uncommon? I mean, maybe I&#x27;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&#x27;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&#x27;s the expected way they should react

I&#x27;m sorry, but you have no defense. Laughing at a junior developer&#x27;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&#x27;s why they aren&#x27;t senior devs.

Maybe I don&#x27;t get the joke, but why is this a defense?(I had a collegue at my last company who worked at Amazon before. His code was just fine.)

Laughing at a junior&#x27;s work when you are their mentor is a firable offense in my eyes.

That is completely unacceptable behavior. If you were in my company I would petition to have you fired. I hold a strict no asshole rule, life is too short to work with people who would do something like that.

Wheaton&#x27;s Law violator here. Don&#x27;t be a dick.

Oh his behalf, I apologize. I literally started laughing at a junior&#x27;s code once but in my defense, he had spent 3 years at Amazon.

&gt; Maybe I have just had bad experiences but a lot of developers do this thing where they answer a question with a snarky question.Extends far further than the workplace. A few minutes in some of the more popular IRC channels on Freenode, you&#x27;ll get the same experience. It&#x27;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, &quot;feeling smart&quot; 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.

I think it comes down to trust. In a lot of teams where the trust is poor, one can&#x27;t ask a question without your competency coming into question in a subtle way: many developers will latch onto it and try to exhibit their business-specific or technical knowledge in a form of one-upmanship. So they have turned it into a competition instead of a conversation.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&#x27;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).

Maybe I have just had bad experiences but a lot of developers do this thing where they answer a question with a snarky question. Sometimes it&#x27;s annoying to be asked basic questions but behaving in a condescending way lends to people not asking questions at all and not communicating issues. It doesn&#x27;t matter if the person is Jr. or Sr. I&#x27;ve seen good capable Sr. developers miss stories because they would rather be silent and struggle trying to research and figure something out instead of asking questions due to the snarky competitive nature of the team. 
At my last company I became the default mentor of a non Jr. team member because his real mentor, who was also my mentor, was so condescending the guy was terrified to approach him. Having been in his shoes I had no issue repeatedly helping him get his build working or helping him understand the undocumented proprietary framework etc. A little empathy goes a long way

<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Prima_donna" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Prima_donna</a>I will die on this hill.

And that means the developers will all try to fix their own mistakes without bringing issues to the wider team, leading to a worse solution to problems in general. Premadonna &quot;10X&quot; developers might write great code themselves, but if they&#x27;re pushing the quality of everyone else&#x27;s code down then the overall effect of having them on the team is a negative.Anyone who treats someone else on the team in that way, regardless of seniority, is demonstrating that they&#x27;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&#x27;re better off without them.

I&#x27;ve always felt this attitude towards giving trust to the new hire is a good thing. It remembers me to something I read not so long ago where a Perl core contributor makes the same thing with collaborators.What I don&#x27;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.

I had a similar experience at my first job. I was given a lot of access to important, core functionality like server configurations (e.g. using staging vs. production API servers and DB config), but mistakes weren&#x27;t well tolerated. I&#x27;ve always been rather frustrated that I was given this unsupervised leeway yet judged when something inevitably went wrong - what did you expect would happen with a junior developer given master keys to all of your stuff? I still don&#x27;t understand the thinking behind it.

As a junior, I&#x27;ve found a similar experience as well. Programming environments seem to have a really unprofessional attitude when it comes to this.

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&#x27;t as good as him. It makes a terrifying environment to ask questions because who knows what kind of response you&#x27;re going to get.

Seems like something my wife would like to read. Just bought her a copy. Thanks for the tip.

That is some really quality nerd stuff right there. Thanks!

I can&#x27;t resist chiming in with another Endymion reference: the Hyperion Cantos by Dan Simmons. Fantastic series.

I&#x27;m now reading My Life because of this comment. I&#x27;m greatly enjoying it so far -- thanks!

this is a great anectdote, but the reason i am replying to your comment is because of your user namei 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 endymiona complete aside, but if you have, or anyone reading this has, yet to read duncan&#x27;s autobiography &#x27;my life&#x27; i highly recommend it to anyone and everyoneshe 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&#x27;s hardships and joys

I know you&#x27;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&#x27;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&#x27;t technically wrong, they are just ascribing causation where there is none. I think I saw this example in Signal vs. Noise, but I&#x27;m not sure.Basically, regression to the mean isn&#x27;t a reason to pick someone who did poorly, it&#x27;s a reason that that person will do no worse or better than they do normally.

There&#x27;s also differences in management and industry style.If labour is so abundant that there&#x27;s little problem in replacing any given worker, people can and will be fired for trivial offences. If there&#x27;s a shortage, or there&#x27;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.

Isn&#x27;t regression to the mean a phenomenon of random variables?Humans aren&#x27;t perfect improvement machines, but they surely beat a random variable?!

Wow, you totally missed the point of the story: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.

3) Experience is a series of non-fatal mistakes.Not everything is a financial metaphor.

I disagree with your interpretation. I think this is a case of understanding that the pilot is now motivated to save face, and will be extra careful.This is psychological insight, not statistical insight.

Totally ruined that warm feeling I got from the anecdote with your damn logic.

3) You might argue for versions of Bayesian thought as well (full Bayesian, MAP, ML).I think more appropriate in this context is learning though. And I would suggest here multi-armed bandits (with every arm representing a pilot).<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Multi-armed_bandit" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Multi-armed_bandit</a>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&#x27;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.

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&#x27;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.

&gt; making a serious mistake is often a sign that someone is careless, and more likely to make other, different mistakes in the future.Or under external pressures they have no control over.

This doesn&#x27;t jibe with my experience. As long as the person doesn&#x27;t evaluate their mistakes in a vacuum they become more careful in general because they learn that things can bite you in the ass in totally unexpected ways.So I&#x27;d say it depends on your environment combined with the individual. Someone who is apathetic and&#x2F;or lacks critical thinking skills will probably learn very little beyond avoiding that specific mistake again.

One mistake, even one very serious mistake, means nothing. People are human, even the best of them are going to make mistakes occasionally. Be as careful as you want, it doesn&#x27;t matter, literally nobody is perfect.A pattern of making mistakes can tell you somebody is careless, or sloppy, or in over their head. But a single mistake? That&#x27;s just inevitable.

We all make serious mistakes from time to time. Yes, you too. If you haven&#x27;t yet, you will - don&#x27;t worry. Nobody gets an exemption from that.When that happens, I hope the people around you are more forgiving than you are.

Well that&#x27;s not the experience I&#x27;ve had at all. I bet you if you ask any senior engineer they&#x27;d tell you the numerous different ways they have really messed over their careers.I think it&#x27;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

In my experience, while someone might be extra careful not to repeat a mistake that has burned them in the past, making a serious mistake is often a sign that someone is careless, and more likely to make other, different mistakes in the future.

Link to the Bob Hoover story: <a href="http:&#x2F;&#x2F;www.squawkpoint.com&#x2F;2014&#x2F;01&#x2F;criticism&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.squawkpoint.com&#x2F;2014&#x2F;01&#x2F;criticism&#x2F;</a>

I&#x27;ve seen several versions of that story, often with the quote &quot;Why would we fire you?  We just spent $X million educating you.&quot;  Probably some combination of truth and exaggeration, but it makes for a memorable story regardless.

I wish that story ended with the developer of the trading software learning a lesson about user interfaces

There is a perhaps apocryphal story about the time when Mizuho Securities lost ~$225 million by attempting to sell 610k shares at 1 yen instead of 1 share at 610k yen.  When asked whether he intended to fire the person who physically keyed in the order, the relevant department head stated that he did not intend to waste the firm&#x27;s substantial investment in teaching them to act with due deliberation.

In general, this design principle is known as poka yoke:<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Poka-yoke" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Poka-yoke</a>

I was not familiar with this story; that prompted me to research it. I found it interesting that this aviation incident had a positive outcome, in the form of safety innovations: the Hoover Nozzle and the Hoover Ring. Wikipedia states:&quot;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).&quot; [1][1] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Bob_Hoover#Hoover_Nozzle_and_Hoover_Ring" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Bob_Hoover#Hoover_Nozzle_and_H...</a>

I&#x27;m reminded of the time Tony Blair visited Silicon Valley to figure out how to replicate it back home. He was at a round table with tech royalty (Gates, The Sun guy, Schmidt etc etc). Steve Jobs was there too.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.&quot;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&#x27;s a bad thing. Thats it.&quot;Or soemthing like that, you get the idea.Anyway, i&#x27;ve always liked that outlook regardless of wether it&#x27;s true or not.

It&#x27;s probably not unrelated that American air travel is very safe because there&#x27;s a no-blame, learn-from-the-issue attitude to problems.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.

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

The hardest thing for me when I was junior dev was simply being noticed.  I&#x27;d rather someone be hard on me than to pretend I don&#x27;t exist.

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

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)

Florida native here. You&#x27;re not really doing yourself a favor by sitting in the A&#x2F;C all day.  You aren&#x27;t allowing your body to accommodate to the heat.

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.

I wish my first development job was like this place. Instead there was a blame culture and I&#x27;d get told off when I made mistakes, eventually getting fired for not progressing quick enough.It&#x27;s now 4 years since I was fired from that job and I&#x27;m still in development, despite that incident nearly causing me to decide it wasn&#x27;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.

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

If you have the culture you can make similar jokes with people who write code.

Mentoring is hard. It makes me question everything that I know, and worry about what this guy&#x27;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 &quot;Hey! You! Don&#x27;t fuck that up, I&#x27;m pouring concrete around it tomorrow!&quot; And we would still be cool at lunch break.

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

I like the way you drink ... wooops I mean &#x27;think&#x27;, I like the way you think.

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 &quot;fire extinguisher mode&quot; which meant &quot;only move if there&#x27;s a fire&quot; and watch silly videos in Youtube, have some coffee with Baileys because why not...

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&#x27;ve worked at ;)

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&#x27;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 &quot;we&quot; 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&#x27;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&#x27;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&#x27;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&#x27;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&#x27;t need to brag or try to showoff because you might end up making them not trusting you.

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&#x27;m not surprised that it&#x27;s rediscovered over and over.

This should be upvoted to the top! Definitely more than some story about turn of the century dancers :)

This is pretty much rule #1 for my team. If you make a mistake, I&#x27;m not going to yell at you, but1) If you try to hide the mistake I&#x27;ll be mad. As soon as you know there&#x27;s a problem, we can mitigate the damage by addressing it immediately.2) I want to see that you&#x27;re learning from it. A pattern of repeated mistakes may take some explaining.

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&#x27;t hesitate to tell people, it&#x27;s going to be okay.

Never attribute to malice that which can be adequately explained by stupidity.

There&#x27;s a story that I love about Pixar, a Black Swan event, and Toy Story 2 [0]. The gist was, the movie&#x27;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 &quot;accountability&quot; from those responsible, they set about fixing the root cause.A few excerpts from the linked article:&quot;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.&quot;&quot;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.&quot;[0] <a href="http:&#x2F;&#x2F;thenextweb.com&#x2F;media&#x2F;2012&#x2F;05&#x2F;21&#x2F;how-pixars-toy-story-2-was-deleted-twice-once-by-technology-and-again-for-its-own-good&#x2F;" rel="nofollow">http:&#x2F;&#x2F;thenextweb.com&#x2F;media&#x2F;2012&#x2F;05&#x2F;21&#x2F;how-pixars-toy-story-...</a>

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&#x27;t fairy tales.

Are you suggesting that man purposely tried to kill Bob Hoover?

&gt; Except in real life people sometimesA minority of people are toxic, you start by cutting them slack as you&#x27;d do anyone else, then you cut them off. It&#x27;s not really a problem.

And becoming passive implies the message that you&#x27;re a pushover to whom anything can be done because there will never be nefarious consequences.To those people the mindset is:If I do X I might gain something (or feels good) and no mater what I&#x27;ll never suffer any retaliation for it. Why shouldn&#x27;t I do it?

In which case angrily confronting that person would further justify their ill will towards you and strengthen their resolve to sabotage you. How is that productive or tactful?

I understand that this thread might seem off-topic, but if that is the case it&#x27;s due to the fact that the parent thread (regarding a Bob Hoover anecdote) was already off-topic.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.

We detached this subthread from <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=12707881" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=12707881</a> and marked it off-topic.

Except in real life people sometimes make malicious &quot;mistakes&quot; deliberately and when caught and called out on them either completely dismiss them or even gloat.This reads almost like a fairy tale.

Generally a good idea, if you don&#x27;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&#x27;s still risks outside of that scope &#x2F; vision. (a server may run out of hard disk space from the new code, to name something random).

Definitely. I have a similar policy about deploying late in the day on a Friday. Rushing to get something deployed before an arbitrary deadline is generally a bad idea. By all means, push hard to finish the feature and qa it thoroughly, etc., by whatever cutoff, but wait to hit that launch button until the next morning. Saves so much stress.

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&#x27;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&#x27;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&#x27;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&#x27;m not sure I&#x27;ve ever met a manager who has read that book and disagrees with that principle.

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&#x27;t help to feel that common sense is sometimes lacking.. Why is that?

Having been in this situation and been supervisor to people in this situation, it&#x27;s possible to not be lying but also to not have complete understood the task or have it mis-spec&#x27;d.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.

Mistakes happen. I can deal with that.People lying about their progress however, that is hard to deal with.

I had an intern for the first time last summer! I tried my best to focus on being as encouraging as I could and helping him whenever he ran into trouble. He clearly was working very hard and doing his best, so I focused on being as supportive as possible and praising the work he did (which was very good!). If I&#x27;m being honest though, we was a really terrific intern and we never ran into a situation like I did, so I wouldn&#x27;t say it was much of a test :)

To follow up, have you had interns yet and how did you treat them?

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&#x27;s a calculated risk which may well be worth it.

Exactly! A sane supervisor should have put a rule that disallows deploying on Fridays. End of story.

when a supervisor gives a freshman work which can mess up erverything it is the supervisor&#x27;s fault and not the fault of the freshman

Maybe he made the same promise you did back in the day?

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 &quot;everyone makes mistakes, don&#x27;t sweat it, just make sure you learn from it&quot; and that was that. I remember leaving his office that day thinking &quot;if I ever make it to the point where I have my own interns, I&#x27;m going to do everything I can to support them and treat them as well as he treated me.&quot; A little kindness really does go a long way!

This Bob Hoover? <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Bob_Hoover" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Bob_Hoover</a>

I don&#x27;t know if you&#x27;re being snarky or not, but Bob Hoover is still alive

I was giving a different twist to the story to point that things can (and do) go differently to the rosy picture painted in it (&quot;oh, you did a mistake once == you&#x27;ll never make it again&quot;).That&#x27;s why in the except I kept, I didn&#x27;t keep any reference to Bob Hoover. It&#x27;s about the idea in the story, not some particular pilot.

Just to avert anyone else&#x27;s confusion: Bob Hoover didn&#x27;t die. Not sure what coldtea is referring to.

Sure it could.<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Allegory" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Allegory</a>

&gt;Maybe tell a true story that helps your point, rather than a blatantly fictitious one.The point wasn&#x27;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.&gt;I could tell a story about purple moon dragons, but it wouldn&#x27;t &quot;show&quot; anything.Why not? That&#x27;s what allegories, parables, zen koans, fables and 200 other forms of fictional stories used in making a point do.

Maybe tell a true story that helps your point, rather than a blatantly fictitious one.I could tell a story about purple moon dragons, but it wouldn&#x27;t &quot;show&quot; anything.

&gt;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&#x27;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&#x27;s not saying Hoover actually died or anything... I mean, isn&#x27;t it obvious?)

While I fully appreciate the point of the post, the junior dev didn&#x27;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.

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.

&gt; 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.

Most of my career I&#x27;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&#x27;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&#x27;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&#x27;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.

It depends on the project. Is it a web application for keeping track of daily tasks? You probably don&#x27;t need that much rigor. Are you building something that if it fails will harm&#x2F;kill&#x2F;cost people a lot of money? More rigor is needed.

That&#x27;s true, you can definitely over-correct. I guess if I was the supervisor in this case, I&#x27;d be doing some analysis with the developer after the fact. Were procedures correctly followed? If not, use this event as an example of why the procedures are in place. If they were followed, was it a brain-dead simple error? If so, then obviously there is something wrong with our test plans. If it was one of those errors that turned out to be a perfect storm of environment differences, unexpected inputs, code side-effects or what-have-you, then there probably is no quick solution and the imposition of some overbearing system to try to limit something that will probably not happen again would be overkill.It&#x27;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&#x27;s not the &quot;get my permission before ever putting a Y in that field again&quot; kind of enhancement.

There is a cost in not having certain procedures in place. On the other hand the red tape has a cost too.A single mistake shouldn&#x27;t lead unconditionally to a mandatory multi-step process that involves multiple people and may take several months to finish. The examples of the &quot;cover your ass&quot; decision making overpowering the common sense engineering are abundant.

Good point. It&#x27;s important to take responsibility even if you think there should have been guardrails.

Reminds me of an old VP of mine who came thundering out of his office, absolutely livid, shouting, &quot;What idiot gave me permissions to delete the source backups???&quot;

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.&quot;I&#x27;m really sorry I caused that car accident.&quot;
&quot;That&#x27;s okay, next time take Driver&#x27;s Ed and don&#x27;t drive on sidewalks.&quot;
&quot;Thanks, I&#x27;ll make sure to do that... by the way, why can I even drive on the sidewalk in the first place? Why wasn&#x27;t it required to take Driver&#x27;s Ed?&quot;I&#x27;m very obviously using hyperbole here, but questioning a process, to me, often shows a level of maturity in engineering. It&#x27;s not blame-shifting - you clearly still made the mistake - but it&#x27;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 read what he was saying differently. When errors like this occur it&#x27;s very much worth evaluating what could be done to avoid it in the future beside me just learning my lesson. There are many general team behaviors (e.g. Automated functional testing, automated load testing, static analysis, code reviews, non-production environments, etc.) and things specific for the problem at hand (what test is missing that would have caught this?) that must be considered after a major issue. If these aren&#x27;t evaluated then there it is likely they will happen again. I don&#x27;t believe these are being treated like a child. Instead these are the team deciding to be adults by avoiding emergencies and being more confident when releasing.

Why not both? Of course you can accept responsibility for this mistake but then suggest creating a testing suite to run commits through before making them live?

Think of what you&#x27;re saying on a meta-level here. You would basically be telling this guy, &quot;I fucked up, but I&#x27;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.&quot; 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&#x27;s a very quick way to make sure nobody ever wants to work with you again.

&gt; His reasoning (later revealed) was that you can&#x27;t give people fish and expect them to become expert fishermen.I think you can, it&#x27;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&#x27;s best and how to accomplish something. This works well because it&#x27;s both more palatable to a wider audience of people, and it accounts for people&#x27;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 worked for a boss once who essentially engineered this kind of problem to exist: he knew not having automated testing etc. was a problem, and instead of asking his (too junior) programmers to build up a test suite, he decided to let them fail and discover for themselves why writing up test suites is a good idea.His reasoning (later revealed) was that you can&#x27;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&#x27;t have the soul-crushing experience that teaches them why something is really important, they never really internalize why it&#x27;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&#x27;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&#x27;s something to that, but at the same time, it&#x27;s basically a defense of institutional hazing on the investor&#x27;s dime. So take it for what it is.

It&#x27;s not about being a good cowboy developer, it&#x27;s about beijg a professional engineer who builds systems that work.I don&#x27;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.

I feel where you&#x27;re coming from, but in reality it&#x27;s not like any test suite can guarantee to prevent downtime caused by bad deploys. All it takes is a little networking related bug, something that differs ever so slightly between environments, whatever, and your site could be down.I agree with the other replies that while you may be the &#x27;technically right dev&#x27; 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&#x27;s the company&#x27;s responsibility to protect you from fucking up the site instead of you just being a good developer, and not fucking up the site?

Exactly. If you&#x27;re one mistake away from a disaster, you already lost.Ideally you would have either test gates, or a staged rollout with automated rollback.

Nice little read. There is that little answer in the back of my head of:&quot;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.&quot;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&#x27;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.

Many US states are &quot;At Will&quot; 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.

&gt; I walked into the office certain I was about to be fired.
Wait, can you be fired that easily ?

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&#x27;re probably going to be available anyway.

Of course. I guess I can give some examples.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 &quot;That&#x27;s how I&#x27;ve always done it and I don&#x27;t want to change. I&#x27;ll just add that missing else&quot;.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&#x27;re still running, he gets asked to terminate them but he doesn&#x27;t do it right away and forgets again. Someone else ends up doing it. He&#x27;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&#x27;t heeded or I guess he forgets to remember to set the timer.Another developer says in a meeting that he&#x27;ll perform a task, but forgets before he gets out of the meeting. When he&#x27;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&#x27;m the slow learner and I&#x27;m missing something. Thus I&#x27;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.

Aren&#x27;t you interested to find out why they&#x27;re making those mistakes?

Yes, I suppose this is the &quot;correct&quot; way. If my manager doesn&#x27;t have a problem with my coworkers failures, then I&#x27;ll just have to tolerate it too.

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

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&#x27;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&#x27;t learn from either kindness or harshness. I&#x27;m not in a position to fire them. Does anyone have an idea better than &quot;Just suck it up?&quot;

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 &quot;This is strike 1&quot;.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 &quot;happens to everyone, don&#x27;t worry about it, just be more careful next time.&quot;I was extremely thankful and a LOT more careful next time, and each time after that.

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.

While it&#x27;s nice that we know that the protagonist is agonizing over his mistake, in reality, that&#x27;s not often the case.Since I don&#x27;t have insight into their heads, and I can&#x27;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&#x27;s bad to deploy on Fridays, why it&#x27;s bad to have single-person deployments, why it&#x27;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, &quot;I don&#x27;t give a shit, Senior will catch it and I just want to be on a beach now. Fuck it, I&#x27;m &#x27;done&#x27; -- now to just sneak out and put my phone in the glove compartment for the next 3 hours while this blows over...&quot;The answer is he wouldn&#x27;t.So here&#x27;s the other issue. Let&#x27;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&#x27;s say there&#x27;s even the slightest difference in hair length or eye color between A and B... and presto that&#x27;s an HR discrimination complaint I now have to deal with. As it turns out, Juniors don&#x27;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&#x27;t deploy on Fridays), and do what you can to treat everyone fairly and equally based on perceived actions and offenses.We can&#x27;t know what goes on in someone&#x27;s head.

No. 1 rule for deployment: Don&#x27;t deploy on Friday.Let it be a deployment free day!

I recall that from Thomas Watson Jr&#x27;s autobiography about his life working for his father at IBM.<a href="https:&#x2F;&#x2F;www.amazon.com&#x2F;Father-Son-Co-Life-Beyond-ebook&#x2F;dp&#x2F;B00DXKJ6KE&#x2F;ref=tmm_kin_swatch_0?_encoding=UTF8&amp;qid=1476456773&amp;sr=8-1" rel="nofollow">https:&#x2F;&#x2F;www.amazon.com&#x2F;Father-Son-Co-Life-Beyond-ebook&#x2F;dp&#x2F;B0...</a>

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.&quot; To which the CEO replied, &quot;FIRE YOU?! I just spent $10,000,000 educating you!

I hate to be this guy... but &#x27;ballistic&#x27; has two l&#x27;s.

We&#x27;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&#x27;s not enough to just try and tell these people to be nice. They don&#x27;t know HOW to be nice. Their brain isn&#x27;t wired to be nice.Edit: spelling.

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.

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

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

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

You can be kind while still being critical. Even if it&#x27;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.

This advice is obvious. How can you not be kind with a junior person that makes a junior mistake? It&#x27;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?

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

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&#x27;t believe they suspend all of that every Friday.<a href="http:&#x2F;&#x2F;product.hubspot.com&#x2F;blog&#x2F;how-we-deploy-300-times-a-day" rel="nofollow">http:&#x2F;&#x2F;product.hubspot.com&#x2F;blog&#x2F;how-we-deploy-300-times-a-da...</a><a href="https:&#x2F;&#x2F;github.com&#x2F;blog&#x2F;1241-deploying-at-github" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;blog&#x2F;1241-deploying-at-github</a><a href="https:&#x2F;&#x2F;www.wired.com&#x2F;2013&#x2F;04&#x2F;linkedin-software-revolution&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.wired.com&#x2F;2013&#x2F;04&#x2F;linkedin-software-revolution&#x2F;</a><a href="https:&#x2F;&#x2F;www.facebook.com&#x2F;notes&#x2F;facebook-engineering&#x2F;ship-early-and-ship-twice-as-often&#x2F;10150985860363920" rel="nofollow">https:&#x2F;&#x2F;www.facebook.com&#x2F;notes&#x2F;facebook-engineering&#x2F;ship-ear...</a>

&gt; One Friday afternoon (...) [Kevin:] what did you learn? &#x2F; [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.

Thanks a lot for sharing this. I&#x27;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.

This is underrated for managers and leaders trying to develop young talent. The takeaways:<pre><code> - With a system outage, don&#x27;t lose your cool. Rationality is what&#x27;s needed at the time.
 - Elevating &quot;perfection&quot; at the expense of potential breakage will ensure nothing ever moves forward and your team doesn&#x27;t grow.
</code></pre>
Some might believe that a serious ass-chewing is needed in this scenario; that would be a decision that&#x27;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.

I&#x27;ve worked with dozens of companies of various sizes over my career, and I&#x27;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 &quot;blame-first, ask questions later&quot; 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&#x27;t think you can change these organizations. If their temperament doesn&#x27;t match your own, you have to live with it or craft an escape plan.

If someone asked, &quot;what I&#x27;d learned&quot; in the above context, I&#x27;d assume it was more to satisfy their needs of feeling important and superior than genuinely caring.Much better is: &quot;Shit happens.&quot; That&#x27;s an empathetic attitude that reflects experience in our field.

That&#x27;s why I never deploy on Fridays. For me, for everyone else.

&gt; It’s okay,” he replied. “We’ve all done it.” He paused for a moment. “But what did you learn?”Don&#x27;t deploy to production on Friday! Queue it up in staging for Monday morning. Make a team policy for it!

This demonstrates two principles from &quot;How to Win Friends and Influence People&quot;:- Don&#x27;t criticize, condemn, or complain.
- If you&#x27;re wrong, admit it quickly and emphatically.There are many good anecdotes like this in the book, including 	
endymi0n&#x27;s example.

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&#x27;t part of your monitoring software scope nor being able to detecting malice.

I disagree. I work for a big company with a big product that shouldn&#x27;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.

&gt; Jr Dev&gt; Access to production&gt; With clients that need the service running 24&#x2F;7Oh boy... is he used to work on facebook? when i was a jr dev, i didn&#x27;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&#x27;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 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.

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

Also as a senior developer you carry some of the responsibility for the junior&#x27;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&#x2F;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&#x2F;improve it as needed.

Here&#x27;s a list of online writing communities slanted toward young writers but not exclusively: <a href="http:&#x2F;&#x2F;study.com&#x2F;articles&#x2F;40_of_the_Best_Websites_for_Young_Writers.html" rel="nofollow">http:&#x2F;&#x2F;study.com&#x2F;articles&#x2F;40_of_the_Best_Websites_for_Young_...</a>

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

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 &quot;lower rank&quot;.

No, definitely criticize people, but do it in a constructive and positive manner so it doesn&#x27;t seem like it is criticism or coming from a negative place.You cannot run a team without some measure of criticism or feedback.

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

This reminds of important lessons I&#x27;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.

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.

#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&amp;D manager &#x2F; 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&#x2F;for - sort of like the project lead described in the story here.

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

Be Kind