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.
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.
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.
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.
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.
Or... bring the team in to review some old code that no one has touched in a while and give everyone the opportunity to critique it. Set those critiques as the bar for everyone's code review. Then, when you review the JD, if he has made those mistakes, you don't have to be stern, you just have to remind him (or her).
Stern really is the last resort mainly because the things that people really argue about are often just opinions. No one is going to argue that test1, test2, etc... are good test names. It is certainly better to let someone realize that on their own with a question than sternly tell them they are bad.
The very rare times when I have to be stern is with consistency issues. Usually though, that's even softened with a "Yes this might be a better way to do it, but it is not consistent with how it has been done so far. We'll make some time in the future to change it everywhere, but for now stay consistent." Often times the biggest issue with juniors or even mid level people is they are only looking at their immediate piece, and not thinking about the larger application or system level picture.
I was subjected to this "Socratic" type of code review when I was younger and I didn'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.
Yeah I feel like a lot of advice is describing what constructive critics do, rather than the attitudes that lead to it.
If someone is humble, they'll naturally tend to ask questions as described. What you've written isn't what they expect, but they assume you're not an idiot and there's a reason for it, so they ask why.
But if someone assumes they know better, the socratic method is likely to be just as condescending as just saying you're wrong.
> What you've written isn't what they expect, but they assume you're not an idiot and there's a reason for it, so they ask why.
This is exactly why I ask questions. It's important in a code review to understand the frame of mind of the code writer. I presume the person is not an idiot and did things for a reason or will respond with a doh! it was late/that was careless/thanks I'll fix it.
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'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'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't cooperate in the code review process.
When it comes to code reviews; judge the code, not the developer. It'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's important to give your engineers the understanding that code reviews can be harsh, but it's meant to help improve everyone on the team, and to learn from anything someone says.
I'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's a very subjective thing.
There'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've just shredded my code apart and now I'm going to have to do all that work again.
Conversely, I've come out of reviews from other people, where they've been fundamentally happy with my code, feeling depressed and miserable.
Communication skills are vitally important. I've been trying to learn from the first reviewer; next time they visit I should actually grab them for coffee and talk about it...
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.
I work with a couple of particularly arrogant junior devs. In code reviews I will tell them things like "the way you're doing this works, but it's better practice to do ..." and they just shrug it off, saying they don'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 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.
It is hard, particularly when management has put someone in a position they don't have the training for. In a junior developer that'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't lie to save feelings. You need to tell the truth or they will feel a whole lot worse later. Loosen yourself up. Don't go into that ridged pose. Talk evenly, and if you can manage it act in a jovial mood as you walk in. For the love of all you hold holy, know what they did code-wise, and take some damn notes before hand. Winging it will be the death of their trust. Teachers you don't trust aren't going to teach you anything.
I had a job where I was the C code reviewer, but was not allowed to program in C[2]. One developer, a fairly senior one, wrote some of the worst code I've ever seen. My code review was basically C 101 and it really was a tough chore to keep myself following good body language and words while still indicating the code needed a lot of changes to be acceptable. I really do blame the employer for setting the developer up to fail (no C training, just read a book and wing it). I did it ok, but I really wish I had a mentor of some sort in the room to give me a critique of my critique.
1) I really don't mean design patterns, more like the general pattern of code with that project / workplace.
2) Well, obviously I couldn't write C code since there would be no one to code review mine. Not obvious? Wasn't to me either to tell the truth. I got to spend my days programming in a reporting language and AWK. I only lasted 9 months (my 3 seasons in heck).
This is one of the main reasons I prefer pairing w/junior developers over code reviews. Giving lots of small pieces of feedback feels a lot less harsh than a monolithic dump of everything that's wrong.
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.
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.
If it has the potential to take down your site? Unless you have someone who can fill in for you, absolutely.
Really, it will come down to a cost/benefit analysis. Are your chances of the site going down due to being hacked over the weekend higher than the chances of a last minute update taking down the site?
The answer is almost always no (much to a sysadmin's chagrin). If the answer is yes (i.e. another heartbleed), then you are probably going to be working through the weekend anyways.
It's a good rule to live by, and like all rules it can be overridden when the circumstances require.
It's good to instill in your team that Friday deployments should be done only in special circumstances, or they become a habit (and people inevitably end up working Saturday). But yes, sometimes it's necessary.
Because missing three days of velocity will definitely cause your growth hacking to fall off the hockey stick and reduce the tempo of your disruption of unique hackathons for people with a left little toe deficiency?
Surely you can envision some scenario where it makes sense?
* It's the holiday weekend and your new website with its curated comparison feature needs to go live
* It's the end of the quarter and having this is the only way you can sign a deal now (enough of your partners will be bound to quarters that this is possible)
* You're in the business of live sentiment analysis from TV video and a critical bug needs to be fixed before this weekend's Presidential Debate or your news channel partner will be pissed
Nothing of that. The reason has nothing to do with "startup culture", head in the clouds buzzword crap, quite the opposite.
The changes are pushed and working in staging, the tests are passing, Q&A is done. Why hold off? So that you get your Good Practices™ badge? I'd say it's better that you don't have to deal with last week's work on a Monday if at all possible.
I think being down to earth, and keeping your good judgement is key. I don't recommend making world-shattering changes on a Friday, but even then, well, it really depends on the circumstances.
Well, when do you do if you have a submission of your project on Saturday morning, and someone finds a bug on Friday afternoon? You fix it and hope it doesn't break anything else, that's what :P
I'd rather have a robust infrastructure and enough confidence that deploys won't break anything that we simple stop paying attention to the day or time!
Friday is the best day to deploy to production. If something screws up, you still have the weekend to solve the issue before the big bosses are there.
On weekdays you have the added pressure of other work.
(Of course depends if your business is mostly or evenly loaded on weekends as on weekdays. In most businesses I've know it's usually the lower load/customer visits period).
In my experience this strategy has not worked out very well. When we tried to deploy risky changes during low traffic times, we would end up creating time bombs, scale issues being masked until a high traffic time rolled around.
This also creates like a kind "brain latency" for developers I think. I'm coming at this from the operations side of things, so maybe my observations are a little biased here. I have observed that if people deploy changes and it breaks something immediately, it's a very clear correlation and they can fix the bug generally pretty quick. If they deploy and then it breaks 72 hours later, any number of things could be the culprit, especially in a fast moving environment (times 1 billion percent if it's a microservices architecture without a strong devops culture, which most of 'em are). Debugging then takes much much longer. This is made worse if the person who deployed the change is not quickly available when their thing breaks, and it makes being on call for someone else's unproven feature very stressful.
So instead I think it's better to make sure deployment and build systems are rock solid, and deploys are as accessible and as idempotent as possible. Chatops type systems are good here. Then you can roll out big changes during peak traffic and be confident that you can quickly revert if it goes bad, and that the changes were reliable under load if it goes good. I also think it's critically important that big changes are behind rollout flags, such that you can dial up or dial down traffic at will. This is also useful when introducing new cache systems or something like CDN if you need to warm up slowly.
This is a better approach I think than trying to use the time of day to modulate user traffic. I would rather developers can control traffic to their feature themselves and have the person deploying the change with their hands on the wheel until they are confident they can take them off. That way people can do stuff independently, and everyone can trust everyone to deploy and yet still feel safe.
[Client, Friday 4PM]"Hello, client here. I know it's Friday 4pm but we messed up and did X. Could you deploy Y fix, thanks!"
[Client, Friday 4PM] "We are having a big sale this weekend we told nobody about. Could you quickly deploy a fix where all the product's prices are red and bold? That shouldn't take you long, right?"
[Project manager, Friday 4:45PM] "Hey team, X just released an important security fix for Y platform. I need you to deploy it right now or the client could get hacked."
And my own darn fault for using platform Y from team X that would release a security update on a Friday. Yes, fix it. But if this isn't a one-off, get off of platform Y.
If platform Y regularly releases security updates on Friday, that's poor management by X and I would reconsider using platform Y. 0-day issues of high severity should be the exception.
Reminds me when my boss got pissed at me because we were discussing moving all deployments to production after 5pm and I replied something along the line "I'm not going to be on the hook after hours to fix problems other people caused".
At one place I worked I put in a 4pm deadline on deploys, because I was tired of the devs seeing the end of the day as their deadline, tossing it over the fence to me, and then sodding off at 5. Invariably, it led to me trying to hunt someone down at a time when everyone was commuting home or similar. 4pm was enough time to do the deploy determine if something went wrong, and get the relevant dev started on the fix.
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.
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.
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.
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.
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).
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 :-)
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
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.
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.
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.
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.
If someone's work is poor enough that a reasonable person might laugh at it, then there's nothing wrong with that. Hence the phrase "laugh at our mistakes". It doesn't mean you are a bad coder/painter, it just means you made mistakes that were a little funny and can learn from them like anyone else.
There's a difference between laughing at your own mistakes and laughing at someone else's. People who are ridiculed for making mistakes are incentivized to hide their mistakes rather than learning from them.
My team playfully makes fun of each other's code all the time. Every once in a while, someone does something stupid in code and we playfully make fun of that person, everyone on the team takes it in stride and our code is better for it.
Hell, every now and then I stumble across some idiocy in the code base and think "LOL, whoever did it this way is an idiot". git blame. "OH, hahaha, it was me, what an idiot past me was, amirite guys?" Everyone on the team takes levity about mistakes very seriously ;) It's healthy.
Mocking condescension on the other hand is a different thing entirely.
Is it? Or is it more like laughing at someone who built a table with 3 legs and wonder why it fell over? Or someone who fixed a car but forgot to put the engine back and wonders why they can't go anywhere?
Amen. I don't know about firing, but I'd definitely be having a conversation about proper mentorship. We hire juniors because they show promise, but need to learn. Being snarky and shutting them down doesn't just hurt the individual dev – it hurts the entire company.
I think you're quite possibly judging the guy too much based on a simple internet comment.
His statement could mean anything from cruelly laughing in the face of the junior dev during a face to face code review to having a quick heh under his breath from the privacy of his office at the developer's use of "if (foo === true)". Or anything in between.
> I think you're quite possibly judging the guy too much based on a simple internet comment.
There are such judgements in every thread.
It's even better when it is paired with the famous "I would not hire you" (or its variation "I would fire you") although the conversation does relate to this at all, the OP has shown no intent no be hired in any company, let alone the answerer's company, and, icing on the cake, the answerer is not in a position to hire anyone.
While I admire the sentiment, I've NEVER seen an asshole fired for belittling juniors/co-workers.
Harsh, withering treatment is quite common not just with developers but in all technical fields. I wish things were different, but that's the reality as I've seen it.
I've seen it once, but the guy cursed and laughed at the team architect when we had a meeting instructing us to start writing tests and adhering to a certain level of code coverage. Seeing the guy literally begging for his job after witnessing him demean and belittle people for months was kind of eye opening to me.
At more than one place where I've worked with at least semi-functional management, people with attitudes like that tend to get moved to special "one person" teams and then are given a long stream of crap work (or at least work they feel is beneath them) until they get bored and quit.
Senior devs make mistakes too. I think your tone is rather inappropriate given that the poster seems aware of the inappropriateness of his response and is apologizing for making that sort of mistake.
Firing for laughing? Did you forget the point of the article? Be kind. Don't hand out harsh punishments for mistakes. Teach instead. (Only fire if the person is immune to teaching.)
Let me relay a story about people who laugh at and mock other people's work.
My wife used to work as a copy editor at a major newspaper and worked with one of those "laugh at and make rude comments about other people's work" kind of people. The copy editing checks had to be checked by another copy editor before it was allowed to be forwarded to the layout team for placement in the news paper. How the story checkin and checkout system worked was that your submitted checks were anonymous to other team members. So, there was this one guy on copy editing team who openly mocked and call other people's work "stupid" and "idiotic". He could never say the person's name that he was talking about, but since every copy editor was in the same room, you knew he might be talking about your work. Everyone hated the guy and everyone complained about the guy. My wife would say how much everyone just hated working with the guy and he was just one of those people that made the job unpleasant.
Then layoffs came around (Newspaper in the Internet Age). When this guy was laid off, champagne bottle were opened up and people celebrated. You know when someone is bad when there is a "sorry to see you go" bar get together and they are not invited. A strange thing happened though, productivity went up because people felt better about submitting their work for final approval. Less copy editor mistakes, less stress, more learning, more openness and more engaging with other team members happend. Barriers between teams fell and even with layoffs, people felt better.
It turns out that the person who mocks other people's work, make for a crappy work environment. You can be tolerant of failures on technical levels, but failure in personal level should not be tolerated. Be pleasant to work with, or should you should be fired.
hmm, seems a bit harsh. For instance if your guy had done that once and been taken to the side and told "stop, shut up, never do that again, next time you're fired" then (a) the work environment would have improved much faster and (b) he might have never done it again. Firing instantly for one harsh comment/action seems like foolishness, just like keeping a known problem person around forever (as in your story) seems like foolishness.
Fireable offense? Software Development is a profession, it's not coding school. Junior Devs are expected to have have an education, written code before, and know the basics. If they write something so crazy that it induces a chuckle, it's probably pretty bad. By all means tell them how to fix it, but don't mask the fact that the job they are getting paid to do expects them to know how to do this.
Maybe an analogy would do better. In the Army, Soldiers go through basic training and are taught just that - the basics. Once they show up at a unit, they will have lots of questions and lots to learn. But if they show up with their name patch velcroed upside-down on their uniform, I guarantee their Sergeant is going to chuckle before they tell the Soldier to turn it right-side up.
Your comparison is apple and orange if you think a person's education in software is comparable to an army. in army, the training is real hands on. rigid. while learning how to code is never a real hands on, always partly figuring out on your own, thus each person having more various understanding/competency on how to do the job.
Yeah, there's an obvious lack of details in the story that should preclude judgement of the poster.
I've seen people write things like: if (true == true)
I won't be mean to you about it, but I can't promise I won't chuckle a little before explaining why that's unnecessary. If you've been working in a professional setting for 3 years and are writing code like that, then yeah, I might struggle to be empathetic.
I've never waded into JavaScript, so I'll take your word for it. I've heard some...surprising...things about JavaScript, so I'm not really taken aback that this might exist.
I'm referencing a time when I was in school, and most everything was taught in Java, where that doesn't make sense. This was written by someone who was almost finished their degree and had already started at their professional job. Definitely junior, but I still feel like that's stretching the acceptable level of noobishness. That said, I have an EE degree, so maybe had to solve / reduce a lot more boolean algebra expressions than a straight CS major?
Again, the guy spent 3 years at Amazon and was talking himself up big. I looked at the code and started laughing. He wasn't a junior in title, in fact, he was on his way to being senior and had his eyes on an architect position.
That is my defense and the only time I've laughed at someone's code. I guess the combination of him talking himself up big about all the amazing things he did at Amazon and the code vomit that he actually produced was too much for me.
I regret it, but he shouldn't really have been that junior after 3 years?
Though I guess I still write pretty shitty code now too on occasion.
No, it means he expected that particular person's code quality to be better than that, because he lasted at a 'Big Four' company for three years and thus should have decent coding chops, but apparently didn't, thus the incongruence made him laugh. It doesn't mean all Amazon coders are shit.
I like figuring out how to look at a sentence how others do (like those images that can be viewed two ways). But I'm having trouble with this one. Amazon devs being generally bad would not be suitable for use as a defense ("in my defense") for his behavior. I think it would require the assumption that he thinks that Amazon devs are generally bad as well as the assumption that he thinks that laughing at them is something that's generally permissible.
I too originally read it as saying that it was expected to be bad coming from Amazon. And the "in my defense" part is that, if you know the coder is from Amazon, then you understand why the code might actually be truly bad enough to elicit a chuckle (as opposed to just chuckling at normal bad code). In other words, it's like saying "in my defense, it was super bad code".
That said, I think the interpretation that "he had 3 years experience at a big company, he should have been better" is probably the correct one.
> I think it would require the assumption that he thinks that Amazon devs are generally bad as well as the assumption that he thinks that laughing at them is something that's generally permissible.
They are so bad that laughing is permissible.
Maybe you just don't spend enough time around arrogant people to interpret this sentence this way :)
People ready to fire someone for laughing should not be allowed to work with other human beings at all, in my opinion.
What's going on with this ready to be offended for wind blowing the wrong way culture and the fragile egos?
It's not just about laughing. It's about laughing at someone's work in a derogatory manner. I hope you can tell the difference and understand the extremely negative impact the latter can have on culture.
I disagree. Firing assholes is never bad for culture. On the contrary, it increases morale and makes the workplace better.
Keep in mind that I don't categorize laughing at someone's work as a "simple mistake." Bugs can be simple mistakes. Offensive jokes can be simple mistakes. Laughing at someone's work however is deeply troubling behavior that actively undermines trust and discourages cooperation in the workplace. That's why you have to kill it with fire.
Everyone seems to be taking this too far--parent just mentioned a laugh. It could be anything from a well meaning jab to a mean put-down, and I'm reading it as just something funny for the junior to learn.
Firing somebody based on your own subjective opinions is toxic for culture.
I've worked on amazing teams with plenty of good natured ribbing and I've worked on great high performing teams where you could say "this code is rubbish, you can do better". I've also worked on teams where saying that would really hurt people's feelings and impact moral.
Put aside your own pre-conceptions and look at how your team responds to an event/situation. That's the only way to build a high performing team.
Sometimes that will mean laughing at someone's code is toxic and needs to be addressed, other times it will be a non-issue and addressing it creates an issue, and other times it can even be a good bonding exercise.
I already specified that this isn't just about laughing, but about laughing at someone's work in a derogatory manner. You seem to be saying "but a laugh can mean other things!" and it's kind of besides the point.
No. I'm not. I'm saying people, cultures, and teams operate differently and assuming that laughing at someone's work is toxic rather than looking at the actual impact to the team is unprofessional and a sign of poor leadership.
I worked in a team where if you broke the build you had to put on a clown nose for the rest of the day. It worked well and was a bit of fun. We still catch up a couple of times a year even though I left that team more than 5 years ago.
I've worked in other teams where pressuring a team member to wear a clown nose would be harassment and deeply unsettling.
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.
Then you're as bad as he is. Especially given that he's already acknowledged he shouldn't have done it. Indignation doesn't make you right, it just makes you stubborn.
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'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't matter if the person is Jr. or Sr. I'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
> 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'll get the same experience. It's extremely frustrating, especially seeing it happen as an outsider to communities you like.
I feel like, in the same way that power generally corrupts people, "feeling smart" can corrupt the same way, coming down to the same attitude of feeling like you have an advantage over other people. Regardless of whether you actually are smart or not.
On one hand, I get it. Especially the popular channels on Freenode or places like the Arch Linux forums can get swamped with people who could not care less for rtfm'ing. Ungrateful, entitled, obnoxious folk, robbing people of resources and time who're putting in work for free, at least in a lot of cases. Sucks. I usually get splendid answers from these sources because I don't even bother unless I have a specific question or error, logs to back it up maybe. Yesterday I had somebody on #Openvpn help me with an issue in three lines. Nice.
But if the snark is heavy without being warranted at all, it more than pisses me off. It reflects poorly on whatever you're representing and it's just bad communication. If all you have to offer is a lmgtfy.com Link, don't bother. Those immune to that train of thought won't, the others already have.
I think it comes down to trust. In a lot of teams where the trust is poor, one can'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'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).
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 "10X" developers might write great code themselves, but if they're pushing the quality of everyone else'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're not really interested in the project as a whole. It takes a group of people to build something complicated, and someone who is antagonistic towards other people holds back the effort of the group. You're better off without them.
I 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't well tolerated. I'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't understand the thinking behind it.
I'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'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.
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.”
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
I know you're probably not implying regression to the mean is causational, but that was my initial reading so I want to clarify for those who may not be familiar with the concept.
Regression to the mean is simply that any given datapoint is most likely to be the mean, or close to it. This means that any exceptional data point,up or down, can be expected to be followed up by the mean.
The example of this being misinterpreted that I am familiar with is that of a flight instructor's belief on training. When a pilot performed well, they wouldnt comment. If a pilot performed poorly, they would be punished. They believed this was better because when they praised a pilot, they would usually do worse the following run, and when they punish them they do better. This isn't technically wrong, they are just ascribing causation where there is none. I think I saw this example in Signal vs. Noise, but I'm not sure.
Basically, regression to the mean isn't a reason to pick someone who did poorly, it's a reason that that person will do no worse or better than they do normally.
Yeah, I always make an example with coin flips to show how this is true.... lets say heads is success and tails is failure.
Flip 100 coins. Take the ones that 'failed' (landed tails) and scold them. Flip them again. Half improved! Praise the ones that got heads the first time. Flip them again. Half got worse :(
Clearly, scolding is more effective than praising.
Except, coins are not humans with emotions, and neither can they dupe probability to improve their outcome. The 50 heads(success) that you left are not going to do any better than the 50 tails you scolded. You are just changing the sample space in a biased fashion to prove your point.
I think you are totally missing my point. The whole point I am trying to make centers on the fact that the coins are all actually equal. The observed difference in performance is entirely due to chance.
While, of course, human performance is not always equal in the same way our coins are, the fact that performance (or whatever it is you are measuring) will still regress towards the mean still holds true. The coin example just gives an extremely obvious demonstration about what is happening when things regress towards the mean.
There's also differences in management and industry style.
If labour is so abundant that there's little problem in replacing any given worker, people can and will be fired for trivial offences. If there's a shortage, or there's a considerable on-boarding process, less so.
The threat of a firing-at-any-moment also makes for a more tractable workforce, at least from a management perspective.
Correct. I think reversion to the mean is a non-sequitur here.
Neither the GP's quote, nor the OP, are making the statement "I understand that this mistake was an outlier, you'll probably never make this mistake again if you remain unchanged".
The claim being made is that acknowledging the mistake and learning from it can dramatically reduce the base probability of such mistakes happening again.
Regression to the mean applies any time a process has high variance. If I have an unusually productive week, odds are the next week will be worse, simply because the previous one was an outlier. But people often make the mistake of noticing week X+1 was much worse than week X, and attributing it to some variable that changed between X and X+1.
In my model, humans have an average performance, that increases over time (unless something terrible happens) and a random component, that makes performance fluctuate around the average.
The question is: is the day-to-day random variation much bigger than the day-to-day average increase? If so, regression towards the mean makes total sense.
3) Out of remorse, pride, being shocked out of complacency or some combination of these, the man would do his absolute best the next day, especially for the very same pilot.
There is tradeoff between exploration and exploitation that has to be made.
The goal in this case corresponds to a particular type of bandit. It is to postpone death for as long as possible by pulling the right arm. I actually didn't find this type yet (a mortal multi-armed bandit has a birth-death process of the arms themselves).
Edit: This is only about the learning process on the non-pilot side, as one of the other commentators already articulated.
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.
Right. I've been in a situation where I attained a huge amount of responsibility and authority in a short amount of time. I was learning a dozen new tasks simultaneously and getting something like 4 hours of sleep a night (military). I made some pretty big mistakes, and I think it's fair to assume that anyone would under those circumstances.
This doesn't jibe with my experience. As long as the person doesn'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'd say it depends on your environment combined with the individual. Someone who is apathetic and/or lacks critical thinking skills will probably learn very little beyond avoiding that specific mistake again.
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'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's just inevitable.
Well that's not the experience I've had at all. I bet you if you ask any senior engineer they'd tell you the numerous different ways they have really messed over their careers.
I think it's especially true in tech jobs where there is a lot learned on the job. I would be deeply skeptical of any tech company that takes a fire first attitude. That just tells me they 1) treat devs as disposable and 2) they get rid of everyone that has a chance to learn from their mistakes
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's substantial investment in teaching them to act with due deliberation.
I've seen several versions of that story, often with the quote "Why would we fire you? We just spent $X million educating you." Probably some combination of truth and exaggeration, but it makes for a memorable story regardless.
This is a good point--I remember even the online game "Runescape" had a warning that would pop up if you tried to sell an item worth X for a very low price.
It would seem to me (somebody who knows squat about stock trading) that a warning screen would be much more beneficial for stock trading software than it is for an online video game.
You'd think that, but then what happens is users get used to the warnings coming up and consciously/unconsciously adjust to click by it without reading.
I'd imagine in the case of the stock trader, where quick reaction is valued, he'd have quickly entered whatever key combo is necessary to dismiss it the warning and made the same mistake.
Only if the warnings come up too often. I imagine it should be quite possible to define criteria that discriminate selling shares at a price of 0.0000016 yen from normal prices, by comparing with the market price, or the range of prices ever seen by the software, for example.
Alarm fatigue is an important design consideration, but not a reason to not put warnings at all (given that this isn't amenable to an "Undo" button, which is preferable when possible).
Alarm fatigue is indeed an issue -- but if the trader is repeatedly trying to sell for way below market price that often, then perhaps there is a much bigger problem...with the trader.
It ended up with order sanity checks being implemented for all manual trading systems at Mizuho. Things like blocking an order if it's more than 10% away from the market mid, etc.
You shouldn't fix an issue like this with UI validation alone - it needs to go between the component that creates orders and the stock exchange, so that it also protects against software bugs. For instance, a possible bug is a developer multiplying the order size by the lot size in the backend, when it has already been multiplied in the frontend, causing huge orders to be sent. Sanity checks can catch this.
Automated trading systems have traditionally been under a lot of scrutiny, and nobody in their right mind would run one without sanity checks and a kill switch. That incident taught Mizuho that manual trading can, in fact, also be quite dangerous :)
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:
"A perhaps-undesired recognition is the Hoover Nozzle used on jet fuel pumps. The Hoover Nozzle is designed with a flattened bell shape. The Hoover Nozzle cannot be inserted in the filler neck of a plane with the Hoover Ring installed, thus preventing the tank from accidentally being filled with jet fuel.
This system was given this name following an accident in which Hoover was seriously injured, when both engines on his Shrike Commander failed during takeoff. Investigators found that the plane had just been fueled by line personnel who mistook the piston-engine Shrike for a similar turboprop model, filling the tanks with jet fuel instead of avgas (aviation gasoline). There was enough avgas in the fuel system to taxi to the runway and take off, but then the jet fuel was drawn into the engines, causing them to stop.
Once Hoover recovered, he widely promoted the use of the new type of nozzle with the support and funding of the National Air Transportation Association, General Aviation Manufacturers Association and various other aviation groups (the nozzle is now required by Federal regulation on jet fuel pumps)." [1]
In terms of physical connectors, I've always referred to this as polarisation. The connector is polarised so that it can only be inserted in one orientation, generally by use of a slot and key.
It's probably not unrelated that American air travel is very safe because there'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.
I'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.
"Listen! Take a look around this table. Everyone here has a massive failure in their past. Big, epic failures. In the US, we think thats a good thing. In the UK you think it's a bad thing. Thats it."
Or soemthing like that, you get the idea.
Anyway, i've always liked that outlook regardless of wether it's true or not.
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'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.
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.
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.
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 ;)
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...
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.
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.
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.
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.
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.
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."
Except those people are disproportionately represented in positions of authority and you really can't cut them off without effectively becoming a pariah.
In my experience, most of the time those people in positions of authority aren't actually malicious. They're either misinformed (the higher you get, the less you're able to have both depth and breadth of knowledge), or they have competing priorities.
What you describe certainly happens and is probably the most common scenario. Many times there is no malice, just some very worldly constraints that result in undesired consequences.
However, rising through the ranks of social structures is facilitated by machiavellianism and this results in an over representation of the kind of people I was talking about the higher up you go. It's a numbers game.
This isn't even very controversial and academics studying psychopathy will even acknowledge 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?
You're talking about sociopaths. Who are estimated to make up 4% of the population. So you should be prepared to deal with them and cut them off as needed, but you shouldn't base your average strategy on assuming everyone you deal with is one.
I think perhaps your mindset, and possibly your situation, might be improved if you assumed less about other people's thought process and motivation, or at least if you didn't assume you were correct. It's very easy to come up with ideas about what someone is thinking and why, it's much, much harder to be correct about that.
By assuming you know why people are doing things, you've already biased yourself against future information that may contradict that. Maybe sometimes they aren't doing it to be a dick to you, and maybe sometimes what you view as gloating isn't directed at you, or isn't actually gloating.
How many, out of all the people you interact with? It's safe to make your assumption the people who revealed their workings to you, but not with everyone else.
You sound like the one who'd have called BG back from his camping trip to fix up his code - a 3 hours drive and a ruined weekend for him, instead of maybe a 5 minute rollback to the latest stable version for you.
So with your mindset, it's no wonder people react to you the way you describe it. But believe it or not - most probably you are the problem, not them.
Practical action can be taken without having to angrily scold the person.
Giving into anger is the easy thing to do, but in doing so we become emotionally blinded to more practical courses of action which we may have realized if we had kept our cool.
I understand that this thread might seem off-topic, but if that is the case it'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.
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.
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).
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.
456 comments
[ 2.6 ms ] story [ 314 ms ] threadTo the junior devs, when you screw up (and you will) own it and learn from it. Like public scandals, the cover up is almost always worse than original issue.
Other times, though, some developers need a very stern review. Things like: "Don't name your tests test1, test2, test3. Give them descriptive names," "Follow style," and "this does not belong in the dependency injector," and "don't screw with event publishing logic, filter this out in the event handler in the UI" are warranted when a developer isn't taking the time to think through his/her changes.
This is important when dealing with junior contractors.
The very rare times when I have to be stern is with consistency issues. Usually though, that's even softened with a "Yes this might be a better way to do it, but it is not consistent with how it has been done so far. We'll make some time in the future to change it everywhere, but for now stay consistent." Often times the biggest issue with juniors or even mid level people is they are only looking at their immediate piece, and not thinking about the larger application or system level picture.
"Can you think of names for these tests that would be more helpful when we need to debug why they're failing?"
"Check out the styleguide for indentation like this; consistent code is easier to maintain"
"Here's a place where we did something similar. See how this logic goes over here instead? That helps us keep x, y, modular"
Phrasing things a little differently can make feedback feel like a learning opportunity instead of a criticism.
I think just saying what you think but with a bit of humility and the attitude that you need to justify yourself is best. Especially since even the best seniors often get hung up on pointless crap during code reviews.
If someone is humble, they'll naturally tend to ask questions as described. What you've written isn't what they expect, but they assume you're not an idiot and there's a reason for it, so they ask why.
But if someone assumes they know better, the socratic method is likely to be just as condescending as just saying you're wrong.
This is exactly why I ask questions. It's important in a code review to understand the frame of mind of the code writer. I presume the person is not an idiot and did things for a reason or will respond with a doh! it was late/that was careless/thanks I'll fix it.
IMHO, code reviews should be clear and concise. They aren't a place to go out of your way to soften blows. I expect the same when my code is reviewed.
Edit:
It occurs to me the parent may have been referring to an informal review or one with the intent of mentoring. Asking questions, like the sibling mentioned is a great way. My comment is geared more towards a formal review.
A far worse situation though is when a mid-level or senior developer is defensive about code reviews and won't cooperate in the code review process.
Conversely, I've come out of reviews from other people, where they've been fundamentally happy with my code, feeling depressed and miserable.
Communication skills are vitally important. I've been trying to learn from the first reviewer; next time they visit I should actually grab them for coffee and talk about it...
To me, the biggest thing is don't lie to save feelings. You need to tell the truth or they will feel a whole lot worse later. Loosen yourself up. Don't go into that ridged pose. Talk evenly, and if you can manage it act in a jovial mood as you walk in. For the love of all you hold holy, know what they did code-wise, and take some damn notes before hand. Winging it will be the death of their trust. Teachers you don't trust aren't going to teach you anything.
I had a job where I was the C code reviewer, but was not allowed to program in C[2]. One developer, a fairly senior one, wrote some of the worst code I've ever seen. My code review was basically C 101 and it really was a tough chore to keep myself following good body language and words while still indicating the code needed a lot of changes to be acceptable. I really do blame the employer for setting the developer up to fail (no C training, just read a book and wing it). I did it ok, but I really wish I had a mentor of some sort in the room to give me a critique of my critique.
1) I really don't mean design patterns, more like the general pattern of code with that project / workplace.
2) Well, obviously I couldn't write C code since there would be no one to code review mine. Not obvious? Wasn't to me either to tell the truth. I got to spend my days programming in a reporting language and AWK. I only lasted 9 months (my 3 seasons in heck).
Saying that nobody should ever do it isn't realistic, sometimes things go wrong on a Friday, sometimes you can't afford to wait 3 days to watch them become even worse.
Don't deploy when you won't be around to support it is a better description; but it doesn't roll off the tongue as easily.
Really, it will come down to a cost/benefit analysis. Are your chances of the site going down due to being hacked over the weekend higher than the chances of a last minute update taking down the site?
The answer is almost always no (much to a sysadmin's chagrin). If the answer is yes (i.e. another heartbleed), then you are probably going to be working through the weekend anyways.
It's good to instill in your team that Friday deployments should be done only in special circumstances, or they become a habit (and people inevitably end up working Saturday). But yes, sometimes it's necessary.
"Only deploy on Friday if you like working weekends"
* It's the holiday weekend and your new website with its curated comparison feature needs to go live
* It's the end of the quarter and having this is the only way you can sign a deal now (enough of your partners will be bound to quarters that this is possible)
* You're in the business of live sentiment analysis from TV video and a critical bug needs to be fixed before this weekend's Presidential Debate or your news channel partner will be pissed
Reduce the tempo? Some of these can kill.
The changes are pushed and working in staging, the tests are passing, Q&A is done. Why hold off? So that you get your Good Practices™ badge? I'd say it's better that you don't have to deal with last week's work on a Monday if at all possible.
I think being down to earth, and keeping your good judgement is key. I don't recommend making world-shattering changes on a Friday, but even then, well, it really depends on the circumstances.
On weekdays you have the added pressure of other work.
(Of course depends if your business is mostly or evenly loaded on weekends as on weekdays. In most businesses I've know it's usually the lower load/customer visits period).
You should not be pulling people in from their time off to fix shit.
This also creates like a kind "brain latency" for developers I think. I'm coming at this from the operations side of things, so maybe my observations are a little biased here. I have observed that if people deploy changes and it breaks something immediately, it's a very clear correlation and they can fix the bug generally pretty quick. If they deploy and then it breaks 72 hours later, any number of things could be the culprit, especially in a fast moving environment (times 1 billion percent if it's a microservices architecture without a strong devops culture, which most of 'em are). Debugging then takes much much longer. This is made worse if the person who deployed the change is not quickly available when their thing breaks, and it makes being on call for someone else's unproven feature very stressful.
So instead I think it's better to make sure deployment and build systems are rock solid, and deploys are as accessible and as idempotent as possible. Chatops type systems are good here. Then you can roll out big changes during peak traffic and be confident that you can quickly revert if it goes bad, and that the changes were reliable under load if it goes good. I also think it's critically important that big changes are behind rollout flags, such that you can dial up or dial down traffic at will. This is also useful when introducing new cache systems or something like CDN if you need to warm up slowly.
This is a better approach I think than trying to use the time of day to modulate user traffic. I would rather developers can control traffic to their feature themselves and have the person deploying the change with their hands on the wheel until they are confident they can take them off. That way people can do stuff independently, and everyone can trust everyone to deploy and yet still feel safe.
[Client, Friday 4PM] "We are having a big sale this weekend we told nobody about. Could you quickly deploy a fix where all the product's prices are red and bold? That shouldn't take you long, right?"
[Project manager, Friday 4:45PM] "Hey team, X just released an important security fix for Y platform. I need you to deploy it right now or the client could get hacked."
“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.
I was a bit bemused when a young guy who had just gone into devops and sysadmin gave me a mini lecture on the importance of open source and contributing to it if you have the skills, and that I really should give it a go one day, because open content is amazing.
I didn't have the heart to tell him I'd gotten into a few of the LibreOffice release notes for work I'd done on the project. Nor did I feel like telling him I'd made significant contributions to Wikipedia. I think I sort of weakly smiled and tried to change the subject.
Good on you for being patient and not letting them drag you into a place that would have humiliated them, though.
Yeah, Brian screwed up. But the company has at least some fault for letting him get that far unchecked.
Simple fact is, if you worked for me, I would have fired you for that. Junior devs are supposed to do bad things - that's why they aren't senior devs.
Well, no. It is the product of someone's work. Someone who is trying to learn and should be supported and taught how to make it better and why it is not as good as it should be.
Hell, every now and then I stumble across some idiocy in the code base and think "LOL, whoever did it this way is an idiot". git blame. "OH, hahaha, it was me, what an idiot past me was, amirite guys?" Everyone on the team takes levity about mistakes very seriously ;) It's healthy.
Mocking condescension on the other hand is a different thing entirely.
Amen. I don't know about firing, but I'd definitely be having a conversation about proper mentorship. We hire juniors because they show promise, but need to learn. Being snarky and shutting them down doesn't just hurt the individual dev – it hurts the entire company.
His statement could mean anything from cruelly laughing in the face of the junior dev during a face to face code review to having a quick heh under his breath from the privacy of his office at the developer's use of "if (foo === true)". Or anything in between.
There are such judgements in every thread.
It's even better when it is paired with the famous "I would not hire you" (or its variation "I would fire you") although the conversation does relate to this at all, the OP has shown no intent no be hired in any company, let alone the answerer's company, and, icing on the cake, the answerer is not in a position to hire anyone.
Harsh, withering treatment is quite common not just with developers but in all technical fields. I wish things were different, but that's the reality as I've seen it.
My wife used to work as a copy editor at a major newspaper and worked with one of those "laugh at and make rude comments about other people's work" kind of people. The copy editing checks had to be checked by another copy editor before it was allowed to be forwarded to the layout team for placement in the news paper. How the story checkin and checkout system worked was that your submitted checks were anonymous to other team members. So, there was this one guy on copy editing team who openly mocked and call other people's work "stupid" and "idiotic". He could never say the person's name that he was talking about, but since every copy editor was in the same room, you knew he might be talking about your work. Everyone hated the guy and everyone complained about the guy. My wife would say how much everyone just hated working with the guy and he was just one of those people that made the job unpleasant.
Then layoffs came around (Newspaper in the Internet Age). When this guy was laid off, champagne bottle were opened up and people celebrated. You know when someone is bad when there is a "sorry to see you go" bar get together and they are not invited. A strange thing happened though, productivity went up because people felt better about submitting their work for final approval. Less copy editor mistakes, less stress, more learning, more openness and more engaging with other team members happend. Barriers between teams fell and even with layoffs, people felt better.
It turns out that the person who mocks other people's work, make for a crappy work environment. You can be tolerant of failures on technical levels, but failure in personal level should not be tolerated. Be pleasant to work with, or should you should be fired.
Maybe an analogy would do better. In the Army, Soldiers go through basic training and are taught just that - the basics. Once they show up at a unit, they will have lots of questions and lots to learn. But if they show up with their name patch velcroed upside-down on their uniform, I guarantee their Sergeant is going to chuckle before they tell the Soldier to turn it right-side up.
I've seen people write things like: if (true == true)
I won't be mean to you about it, but I can't promise I won't chuckle a little before explaining why that's unnecessary. If you've been working in a professional setting for 3 years and are writing code like that, then yeah, I might struggle to be empathetic.
Which, if you make that an === in JavaScript, can actually make sense in some situations :)
I'm referencing a time when I was in school, and most everything was taught in Java, where that doesn't make sense. This was written by someone who was almost finished their degree and had already started at their professional job. Definitely junior, but I still feel like that's stretching the acceptable level of noobishness. That said, I have an EE degree, so maybe had to solve / reduce a lot more boolean algebra expressions than a straight CS major?
That is my defense and the only time I've laughed at someone's code. I guess the combination of him talking himself up big about all the amazing things he did at Amazon and the code vomit that he actually produced was too much for me.
I regret it, but he shouldn't really have been that junior after 3 years?
Though I guess I still write pretty shitty code now too on occasion.
Alright, I'll take the karma L in this case.
(I had a collegue at my last company who worked at Amazon before. His code was just fine.)
That said, I think the interpretation that "he had 3 years experience at a big company, he should have been better" is probably the correct one.
They are so bad that laughing is permissible.
Maybe you just don't spend enough time around arrogant people to interpret this sentence this way :)
Laughing in this situation is merely inappropriate. Firing someone for being inappropriate once or twice is incredibly toxic behaviour.
Keep in mind that I don't categorize laughing at someone's work as a "simple mistake." Bugs can be simple mistakes. Offensive jokes can be simple mistakes. Laughing at someone's work however is deeply troubling behavior that actively undermines trust and discourages cooperation in the workplace. That's why you have to kill it with fire.
Firing somebody based on your own subjective opinions is toxic for culture.
I've worked on amazing teams with plenty of good natured ribbing and I've worked on great high performing teams where you could say "this code is rubbish, you can do better". I've also worked on teams where saying that would really hurt people's feelings and impact moral.
Put aside your own pre-conceptions and look at how your team responds to an event/situation. That's the only way to build a high performing team.
Sometimes that will mean laughing at someone's code is toxic and needs to be addressed, other times it will be a non-issue and addressing it creates an issue, and other times it can even be a good bonding exercise.
I worked in a team where if you broke the build you had to put on a clown nose for the rest of the day. It worked well and was a bit of fun. We still catch up a couple of times a year even though I left that team more than 5 years ago.
I've worked in other teams where pressuring a team member to wear a clown nose would be harassment and deeply unsettling.
Extends far further than the workplace. A few minutes in some of the more popular IRC channels on Freenode, you'll get the same experience. It's extremely frustrating, especially seeing it happen as an outsider to communities you like.
I feel like, in the same way that power generally corrupts people, "feeling smart" can corrupt the same way, coming down to the same attitude of feeling like you have an advantage over other people. Regardless of whether you actually are smart or not.
But if the snark is heavy without being warranted at all, it more than pisses me off. It reflects poorly on whatever you're representing and it's just bad communication. If all you have to offer is a lmgtfy.com Link, don't bother. Those immune to that train of thought won't, the others already have.
A good way to detect these environments is when you observe those who have been there longer not asking obvious questions. That usually means the trust issue is there. When you start asking those obvious questions, at first you get that feedback loop of slight condescension. But then others start asking questions and you often get a fruitful conversation.
Having worked outside of the startup world and in the startup world, I think this is a little more prevalent in the startup world because there is another axis besides experience involved in these conversations: how long the person has been with the startup. It's common to have an official or unofficial hierarchy based on experience but in the startup world, there is another hierarchy based on how long you have been at the startup. That additional axis means it comes up a little more in the startup world (in my experience so far).
Anyone who treats someone else on the team in that way, regardless of seniority, is demonstrating that they're not really interested in the project as a whole. It takes a group of people to build something complicated, and someone who is antagonistic towards other people holds back the effort of the group. You're better off without them.
I will die on this hill.
What I don't find ok is to blame a person for an error going to production. Specially when the error is caused by the lack of supervision to the new hire code (code reviews) and probably QA.
i am a huge fan of the turn of the century dancer isadora duncan and her lover who she first had a child with, the theatre set design theorist, edward gordon craig who she affectionately called endymion
a complete aside, but if you have, or anyone reading this has, yet to read duncan's autobiography 'my life' i highly recommend it to anyone and everyone
she is a brilliant writer, lived an eccentric life, and she was and her writing is imbued with a mad passion for expression and both life's hardships and joys
1) Reversion to the mean. This is what the above person believes and that this likely won't happen again.
2) Indication of a trend. The pilot is actually incompetent, and this will happen more frequently with this pilot than an average pilot.
Regression to the mean is simply that any given datapoint is most likely to be the mean, or close to it. This means that any exceptional data point,up or down, can be expected to be followed up by the mean.
The example of this being misinterpreted that I am familiar with is that of a flight instructor's belief on training. When a pilot performed well, they wouldnt comment. If a pilot performed poorly, they would be punished. They believed this was better because when they praised a pilot, they would usually do worse the following run, and when they punish them they do better. This isn't technically wrong, they are just ascribing causation where there is none. I think I saw this example in Signal vs. Noise, but I'm not sure.
Basically, regression to the mean isn't a reason to pick someone who did poorly, it's a reason that that person will do no worse or better than they do normally.
https://www.google.com/#&q=%22how+to+win+friends+and+influen...
Flip 100 coins. Take the ones that 'failed' (landed tails) and scold them. Flip them again. Half improved! Praise the ones that got heads the first time. Flip them again. Half got worse :(
Clearly, scolding is more effective than praising.
While, of course, human performance is not always equal in the same way our coins are, the fact that performance (or whatever it is you are measuring) will still regress towards the mean still holds true. The coin example just gives an extremely obvious demonstration about what is happening when things regress towards the mean.
https://en.wikipedia.org/wiki/Regression_toward_the_mean
If labour is so abundant that there's little problem in replacing any given worker, people can and will be fired for trivial offences. If there's a shortage, or there's a considerable on-boarding process, less so.
The threat of a firing-at-any-moment also makes for a more tractable workforce, at least from a management perspective.
Humans aren't perfect improvement machines, but they surely beat a random variable?!
Neither the GP's quote, nor the OP, are making the statement "I understand that this mistake was an outlier, you'll probably never make this mistake again if you remain unchanged".
The claim being made is that acknowledging the mistake and learning from it can dramatically reduce the base probability of such mistakes happening again.
The question is: is the day-to-day random variation much bigger than the day-to-day average increase? If so, regression towards the mean makes total sense.
3) Out of remorse, pride, being shocked out of complacency or some combination of these, the man would do his absolute best the next day, especially for the very same pilot.
Not everything is a financial metaphor.
This is psychological insight, not statistical insight.
I think more appropriate in this context is learning though. And I would suggest here multi-armed bandits (with every arm representing a pilot).
https://en.wikipedia.org/wiki/Multi-armed_bandit
There is tradeoff between exploration and exploitation that has to be made.
The goal in this case corresponds to a particular type of bandit. It is to postpone death for as long as possible by pulling the right arm. I actually didn't find this type yet (a mortal multi-armed bandit has a birth-death process of the arms themselves).
Edit: This is only about the learning process on the non-pilot side, as one of the other commentators already articulated.
Or under external pressures they have no control over.
So I'd say it depends on your environment combined with the individual. Someone who is apathetic and/or lacks critical thinking skills will probably learn very little beyond avoiding that specific mistake again.
Shows the other meanings of the homophones - English huh!
A pattern of making mistakes can tell you somebody is careless, or sloppy, or in over their head. But a single mistake? That's just inevitable.
Or that you need to fix the process.
When that happens, I hope the people around you are more forgiving than you are.
I think it's especially true in tech jobs where there is a lot learned on the job. I would be deeply skeptical of any tech company that takes a fire first attitude. That just tells me they 1) treat devs as disposable and 2) they get rid of everyone that has a chance to learn from their mistakes
It would seem to me (somebody who knows squat about stock trading) that a warning screen would be much more beneficial for stock trading software than it is for an online video game.
I'd imagine in the case of the stock trader, where quick reaction is valued, he'd have quickly entered whatever key combo is necessary to dismiss it the warning and made the same mistake.
Alarm fatigue is an important design consideration, but not a reason to not put warnings at all (given that this isn't amenable to an "Undo" button, which is preferable when possible).
You shouldn't fix an issue like this with UI validation alone - it needs to go between the component that creates orders and the stock exchange, so that it also protects against software bugs. For instance, a possible bug is a developer multiplying the order size by the lot size in the backend, when it has already been multiplied in the frontend, causing huge orders to be sent. Sanity checks can catch this.
Automated trading systems have traditionally been under a lot of scrutiny, and nobody in their right mind would run one without sanity checks and a kill switch. That incident taught Mizuho that manual trading can, in fact, also be quite dangerous :)
"A perhaps-undesired recognition is the Hoover Nozzle used on jet fuel pumps. The Hoover Nozzle is designed with a flattened bell shape. The Hoover Nozzle cannot be inserted in the filler neck of a plane with the Hoover Ring installed, thus preventing the tank from accidentally being filled with jet fuel.
This system was given this name following an accident in which Hoover was seriously injured, when both engines on his Shrike Commander failed during takeoff. Investigators found that the plane had just been fueled by line personnel who mistook the piston-engine Shrike for a similar turboprop model, filling the tanks with jet fuel instead of avgas (aviation gasoline). There was enough avgas in the fuel system to taxi to the runway and take off, but then the jet fuel was drawn into the engines, causing them to stop.
Once Hoover recovered, he widely promoted the use of the new type of nozzle with the support and funding of the National Air Transportation Association, General Aviation Manufacturers Association and various other aviation groups (the nozzle is now required by Federal regulation on jet fuel pumps)." [1]
[1] https://en.wikipedia.org/wiki/Bob_Hoover#Hoover_Nozzle_and_H...
https://en.wikipedia.org/wiki/Poka-yoke
More generally it is very difficult to build highly reliable systems of any kind without having a very open culture where you focus on exposing problems and fixing them rather than blaming the message.
Everyone was chipping in with their theories about why the U.S and Silicon Valley were so good at what they do when Jobs lost his patience and butted in in true Jobsian fashion.
"Listen! Take a look around this table. Everyone here has a massive failure in their past. Big, epic failures. In the US, we think thats a good thing. In the UK you think it's a bad thing. Thats it."
Or soemthing like that, you get the idea.
Anyway, i've always liked that outlook regardless of wether it's true or not.
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.
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.
I miss construction. Back then, I could just tell someone "Hey! You! Don't fuck that up, I'm pouring concrete around it tomorrow!" And we would still be cool at lunch break.
I 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...
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.
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.
This reads almost like a fairy tale.
People who can handle serious mistakes in others are some of the best partners you can have in your efforts. IMHO they aren't fairy tales.
Instead of blasting people for mistakes they set about fixing the immediate problem, and then instead of demanding "accountability" from those responsible, they set about fixing the root cause.
A few excerpts from the linked article:
"Aside from the fact that there was immediate chatter about who might have made such a dumb move, the discussion quickly moved right on to how to fix the problem."
"Instead of dwelling on pinning the blame or lamenting the loss of time and effort, the team made sure to alter the backup strategy so that something like that didn’t happen again, and it went about making up for lost time."
[0] http://thenextweb.com/media/2012/05/21/how-pixars-toy-story-...
A minority of people are toxic, you start by cutting them slack as you'd do anyone else, then you cut them off. It's not really a problem.
You should try Reddit.
However, rising through the ranks of social structures is facilitated by machiavellianism and this results in an over representation of the kind of people I was talking about the higher up you go. It's a numbers game.
This isn't even very controversial and academics studying psychopathy will even acknowledge it.
To those people the mindset is:
If I do X I might gain something (or feels good) and no mater what I'll never suffer any retaliation for it. Why shouldn't I do it?
Those figures of 4% are fairytales, not unlike what most psychologists said before knowing the outcomes of the Milgram experiment.
Almost no one believed that the vast majority of subjects would take the experiment to its end.
By assuming you know why people are doing things, you've already biased yourself against future information that may contradict that. Maybe sometimes they aren't doing it to be a dick to you, and maybe sometimes what you view as gloating isn't directed at you, or isn't actually gloating.
They'll do it in private so that their social standing doesn't suffer but they are very explicit about it.
Not a lot of room left for assumptions after this.
Downvote away.
How many, out of all the people you interact with? It's safe to make your assumption the people who revealed their workings to you, but not with everyone else.
So with your mindset, it's no wonder people react to you the way you describe it. But believe it or not - most probably you are the problem, not them.
I can play that game too!
Maybe the most likely explanation is that you are a sociopath and resent having your nature so clearly exposed.
Of course I have no way of knowing this and it's totally unsupported by fact, kind of like your comment.
Giving into anger is the easy thing to do, but in doing so we become emotionally blinded to more practical courses of action which we may have realized if we had kept our cool.
You are obviously free to decide to detach the threads that you see fit, but not detaching at the parent level strikes me as incomprehensible and discretionary.
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.