22 ms·

Be Kind

• orangepenguin 10y ago
  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.
• AdmiralAsshat 10y ago
  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.
  • chris_wot 10y ago
    Sure, and I don't see them blaming Brian in any way.
  • etrain 10y ago
    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).
  • deleted 10y ago
    [deleted]
  • bgilham 10y ago
    This was far enough in the past that code reviews and "Don't deploy on Friday" weren't necessarily taken as standard practice at a lot of companies yet. But yes, we all learned :-)
• johngalt 10y ago
  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/
• d--b 10y ago
  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 10y ago
    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 10y ago
      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.
  • bgilham 10y ago
    I think you've been lucky. I've seen some really awful senior devs/team leads in my time.
  • pyb 10y ago
    I've worked at a few different places now and have never seen junior team members treated badly either.
• finid 10y ago
  Refreshing...
  • bgilham 10y ago
    Thanks!
    • mkagenius 10y ago
      No problem..
• deedubaya 10y ago
  Be kind, but don't be passive either. Talk about it, be kind, but don't glaze over the learning experience.
• herge 10y ago
  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.
  • deleted 10y ago
    [deleted]
  • matwood 10y ago
    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 10y ago
      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.
      • bryanlarsen 10y ago
        A lot of that can be softened with "This is the project's style. I don't agree with everything in the style guide, but consistency is important." You can say that, even if you agree wholeheartedly with the part you're calling out.
      • phkahler 10y ago
        Never say "do it this way". Try to explain why "this way" is better so they learn. If you don't they'll just think you're saying "my way is better" and resent you for it.
• weaksauce 10y ago
  Also, don't ship on a Friday unless you expect to work on Saturday.
• mrits 10y ago
  I hope Kevin learned not to let a junior dev deploy to production on Friday.
  • phn 10y ago
    Well, he'd have to sooner or later. Better start learning as soon as possible :)
    • happyslobro 10y ago
      Trial by fire. Unavoidable in battle, untenable in surgery.
    • sparrish 10y ago
      Nobody should be deploying to production on Friday... Nobody.
      • Shanea93 10y ago
        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 10y ago
          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.
          • deleted 10y ago
            [deleted]
          • tomjen3 10y ago
• carlmungz 10y ago
  Good to know there are people looking out for junior devs :-)
• fairpx 10y ago
  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.
• mijustin 10y ago
  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 10y ago
    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 10y ago
      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.
    • hilop 10y ago
      I don't want to ever work at a job where to can't get better.
  • deleted 10y ago
    [deleted]
• chris_wot 10y ago
  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 10y ago
    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.
• ummahusla 10y ago
  101: Never deploy on Fridays.
• crush_xc 10y ago
  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 10y ago
    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 10y ago
      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.
      • rimantas 10y ago
        You are an asshole if all it takes to fire someone is some laugh. Everyone shoukd be able to laugh at everyone's code. It's just a code.
        • goshx 10y ago
          > It's just a code. Well, no. It is the product of someone's work. Someone who is trying to learn and should be supported and taught how to make it better and why it is not as good as it should be.
        • kenrikm 10y ago
          Laughing at someone's code is like laughing at someone's painting or their novel or really any other creative endeavor. It's not ok period.
• endymi0n 10y ago
  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.”
  • bgilham 10y ago
    Nice!
  • justifier 10y ago
    this is a great anectdote, but the reason i am replying to your comment is because of your user name i am a huge fan of the turn of the century dancer isadora duncan and her lover who she first had a child with, the theatre set design theorist, edward gordon craig who she affectionately called endymion a complete aside, but if you have, or anyone reading this has, yet to read duncan's autobiography 'my life' i highly recommend it to anyone and everyone she is a brilliant writer, lived an eccentric life, and she was and her writing is imbued with a mad passion for expression and both life's hardships and joys
    • ryanmarsh 10y ago
      Seems like something my wife would like to read. Just bought her a copy. Thanks for the tip.
      • sjcsjc 10y ago
        Good idea. I've just done the same. Thanks both
    • edraferi 10y ago
      That is some really quality nerd stuff right there. Thanks!
    • tominous 10y ago
• SloughFeg 10y ago
  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.
• odammit 10y ago
  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 10y ago
    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 10y ago
      And he came out of an aquarium (i.e. 90° walls + 100% humidity)
  • JustSomeNobody 10y ago
    Florida native here. You're not really doing yourself a favor by sitting in the A/C all day. You aren't allowing your body to accommodate to the heat.
• LukeB_UK 10y ago
  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.
• happyslobro 10y ago
  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 10y ago
    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.
  • driverdan 10y ago
    If you have the culture you can make similar jokes with people who write code.
• dcwca 10y ago
  This goes for everyone on your team, not just junior devs.
• _joel 10y ago
  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 ;)
  • new_hackers 10y ago
    I like the way you drink ... wooops I mean 'think', I like the way you think.
  • NetStrikeForce 10y ago
    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...
• muse900 10y ago
  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.
• kornakiewicz 10y ago
  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.
• auganov 10y ago
  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.
  • davemel37 10y ago
    This should be upvoted to the top! Definitely more than some story about turn of the century dancers :)
  • CWuestefeld 10y ago
    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.
• 77pt77 10y ago
  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 10y ago
    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.
    • deleted 10y ago
      [deleted]
    • new_hackers 10y ago
      Never attribute to malice that which can be adequately explained by stupidity.
    • heymijo 10y ago
      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-2-was-deleted-twice-once-by-technology-and-again-for-its-own-good/ http://thenextweb.com/media/2012/05/21/how-pixars-toy-story-...
  • openasocket 10y ago
• sideproject 10y ago
  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_ 10y ago
    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).
  • danenania 10y ago
    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.
• binarymax 10y ago
  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.
• laxentasken 10y ago
  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?
• gavman 10y ago
  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!
  • Normal_gaussian 10y ago
    Mistakes happen. I can deal with that. People lying about their progress however, that is hard to deal with.
    • secstate 10y ago
      Having been in this situation and been supervisor to people in this situation, it's possible to not be lying but also to not have complete understood the task or have it mis-spec'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.
      • Normal_gaussian 10y ago
        Oh no, absolutely. There is no doubt this happens in the majority of cases, so when two things don't pair up when you look at them you don't accuse people of lying. Of course this does land you in an incredibly tricky situation when you do find out there is a habit of systematic lying. Thankfully that situation is resolved now, though it lasted for too long, and miraculously didn't fall off the cliff it teetered on.
• arc_of_descent 10y ago
  Be kind, but also be honest.
• coldtea 10y ago
  >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 10y ago
    I don't know if you're being snarky or not, but Bob Hoover is still alive
    • deleted 10y ago
      [deleted]
    • jakub_h 10y ago
      This Bob Hoover? https://en.wikipedia.org/wiki/Bob_Hoover https://en.wikipedia.org/wiki/Bob_Hoover
  • spenczar5 10y ago
    Just to avert anyone else's confusion: Bob Hoover didn't die. Not sure what coldtea is referring to.
    • coldtea 10y ago
      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 ("oh, you did a mistake once == you'll never make it again"). That's why in the except I kept, I didn't keep any reference to Bob Hoover. It's about the idea in the story, not some particular pilot.
      • schintan 10y ago
        that's a twisted way to twist a story.
• dudul 10y ago
  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.
• sqldba 10y ago
  > 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 10y ago
    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.
  • deleted 10y ago
    [deleted]
• throwaway7767 10y ago
  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.
• scraft 10y ago
  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.
  • d0mine 10y ago
    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't lead unconditionally to a mandatory multi-step process that involves multiple people and may take several months to finish. The examples of the "cover your ass" decision making overpowering the common sense engineering are abundant.
    • pwillia7 10y ago
      It depends on the project. Is it a web application for keeping track of daily tasks? You probably don't need that much rigor. Are you building something that if it fails will harm/kill/cost people a lot of money? More rigor is needed.
• JulienRbrt 10y ago
  > I walked into the office certain I was about to be fired. Wait, can you be fired that easily ?
  • chiph 10y ago
    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.
• slaunchwise 10y ago
  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.
• justin_oaks 10y ago
  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?"
  • DanBC 10y ago
    Aren't you interested to find out why they're making those mistakes?
    • justin_oaks 10y ago
      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 "That's how I've always done it and I don't want to change. I'll just add that missing else". Another developer constantly forgets to terminate servers that he started in our cloud hosting provider. This costs the company money and thus should be avoided. When its noticed that they're still running, he gets asked to terminate them but he doesn't do it right away and forgets again. Someone else ends up doing it. He's been asked repeatedly to make sure to terminate the servers. Suggestions to help include setting a timer, writing a script that will check for unused servers, etc. Those suggestions aren't heeded or I guess he forgets to remember to set the timer. Another developer says in a meeting that he'll perform a task, but forgets before he gets out of the meeting. When he's asked to write it down, he does so, but never looks at the paper later. There are more cases, but it seems to boil down to people not learning. You need to learn how to structure your code, you need to learn how to manage your time, you need to learn how to remember to do something. But maybe I'm the slow learner and I'm missing something. Thus I'm open to suggestions. So far my strategy is to accept that these other developers behave this way, and setup ways to protect myself from their failures.
      • 10y ago
• zavulon 10y ago
  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.
• binalpatel 10y ago
  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.
• dbg31415 10y ago
  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.
• therealmarv 10y ago
  No. 1 rule for deployment: Don't deploy on Friday. Let it be a deployment free day!
• davemel37 10y ago
  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 10y ago
    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/B00DXKJ6KE/ref=tmm_kin_swatch_0?_encoding=UTF8&qid=1476456773&sr=8-1 https://www.amazon.com/Father-Son-Co-Life-Beyond-ebook/dp/B0...
• JustSomeNobody 10y ago
  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 10y ago
    I hate to be this guy... but 'ballistic' has two l's.
    • JustSomeNobody 10y ago
      Correct, and thanks.
    • MrMullen 10y ago
      You're fired.
• makecheck 10y ago
  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.
• mohsinr 10y ago
  I really liked that article was short and to the point!
• partisan 10y ago
  A mistake is an education. If you fire someone after they make a mistake then you are throwing away your investment in their growth.
• gautamdivgi 10y ago
  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 :)
• deleted 10y ago
  [deleted]
• vilius 10y ago
  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 10y ago
    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.
• bambax 10y ago
  > 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 10y ago
    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-day http://product.hubspot.com/blog/how-we-deploy-300-times-a-da... 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-early-and-ship-twice-as-often/10150985860363920 https://www.facebook.com/notes/facebook-engineering/ship-ear...
    • rak00n 10y ago
      Pushing twice a day in that Facebook story gave me a shiver.
      • prodigal_erik 10y ago
        Facebook legitimized the "move fast and break things" attitude by demonstrating that users don't care about reliability, at least nowhere near as much as some of us wish they did.
      • mrep 10y ago
        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.
• deleted 10y ago
  [deleted]
• superjisan 10y ago
  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.
• jroseattle 10y ago
  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.
• bluetwo 10y ago
  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.
• johnwheeler 10y ago
  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.
• poletopole 10y ago
  That's why I never deploy on Fridays. For me, for everyone else.
• heartofaneagle 10y ago
  >He was fired from Home Depot for building a fort once. It's a fun story. dude... you're not a 16 year old girl man... this is not cute at all.
• heartofaneagle 10y ago
  >He was fired from Home Depot for building a fort once. It's a fun story. dude... you're not a 16 year old girl... don't try to be cute.
• pwenzel 10y ago
  > 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!
• mysterpaul 10y ago
  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.
• SadWebDeveloper 10y ago
  > 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 10y ago
    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 10y ago
      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.
• drawkbox 10y ago
  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.
• SadWebDeveloper 10y ago
  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.
• JohannesH 10y ago
  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.
• ing33k 10y ago
  Simple but highly effective writing . How can I learn to write like this ?
  • brlewis 10y ago
    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_Writers.html http://study.com/articles/40_of_the_Best_Websites_for_Young_...
• partycoder 10y ago
  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".
• isuraed 10y ago
  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.
  • jorblumesea 10y ago
    No, definitely criticize people, but do it in a constructive and positive manner so it doesn't seem like it is criticism or coming from a negative place. You cannot run a team without some measure of criticism or feedback.
  • brlewis 10y ago
    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.
• ronreiter 10y ago
  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.
• alexmchale 10y ago
  Rewind.
  • hougaard 10y ago
    Came here for that :)
• realkitkat 10y ago
  #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.
• anateus 10y ago
  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.
• mikeleeorg 10y ago
  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.
• joseph8th 10y ago
  Don't tell me what to do. ;)
• ninjakeyboard 10y ago
  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.
  • StanislavPetrov 10y ago
    >It seems paranoia is a great indicator of experience, and over-confidence/arrogance is an excellent indicator of a lack of learning. This is certainly true, and it isn't limited to the field of engineering.
  • dancek 10y ago
    Yes, and that makes "being kind" a lot harder. Many people reading the article think of a nice person that humbly tries their best but makes a bad mistake. But what if they're a hugely over-confident asshole? I mean, not everyone likes everyone, so when someone you don't like to begin with is arrogant, you might easily label them as an asshole. I think the deeper lesson of the article is not to consider other people assholes, and to be kind to them even if you don't like them at all.
    • GigabyteCoin 10y ago
      >But what if they're a hugely over-confident asshole? Then they have absolutely no business working on a team effort. They never should have been hired in the first place.
      • omginternets 10y ago
• nodesocket 10y ago
  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.
  • yunruse 10y ago
    If anything, acting arrogant helps maintain any habitual problems you have. If you teach someone something, you have to reword it - which teaches it back you you most of the time, and offers a good third-person view of your work habits.
  • gorbachev 10y ago
    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.
• karenho12 10y ago
  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.
• oldtech 10y ago
  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.
• mindfulgeek 10y ago
  Every child should be so lucky to have this experience as well. Empathy goes a long way.
• tofupup 10y ago
  interesting
• GigabyteCoin 10y ago
  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 10y ago
    > "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.
  • yunruse 10y ago
    Approaching problems with a calm (and positive!) mental attitude is a tough life skill, even more so when it's become a life-or-death skill. This is why I really dislike road rage - people take dangerous situations and make them worse, usually saved by instincts alone.
• jxramos 10y ago
  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.
• tofupup 10y ago
  neat
• narrator 10y ago
  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_fear/ http://michelbaudin.com/2012/10/27/deming_8_of_14_drive_out_...
• GordonS 10y ago
  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.
• kinow 10y ago
  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.
• euske 10y ago
  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 10y ago
    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
  • hilop 10y ago
    You are allowed to overpay. The drivers don't like it because they are Seattle nice and would prefer you just not pay at all.
• randartie 10y ago
  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?"
• jasonkostempski 10y ago
  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.
• lewisl9029 10y ago
  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. :)
• hyperpallium 10y ago
  proggit has a better title: [Mentoring Junior Devs: Be Kind](https://www.reddit.com/r/programming/comments/57g3x7/mentoring_junior_devs_be_kind https://www.reddit.com/r/programming/comments/57g3x7/mentori...)
• dsp0105 10y ago
  Amazing!
• heisenbit 10y ago
  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.
• esafwan 10y ago
  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.
• throw2016 10y ago
  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.
• cmoscoso 10y ago
  cool story bro.
• shafiul 10y ago
  Very good advice. Your good deed rewards you over time.
• arc_of_descent 10y ago
  Be kind. Rewind. :)
• scelerat 10y ago
  "One Friday afternoon, [...] I deployed the changes" Good god, this should be taught in high school.
• exodust 10y ago
  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.
• hobbitdeveloper 10y ago
  Can't believe you could get fired for something like that. Do you work for an American company or something? Jeeze...
• kelvin0 10y ago
  > “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.
• AlphaWeaver 10y ago
  Right now, this post is 4 votes away from being in the top 10 most popular HN posts of all time.
• mavsman 10y ago
  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.
• Sire 10y ago
  "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.