Nobody should be deploying to production on Friday... Nobody.
[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 pla…
The appropriate response to Client is "Great, but it will cost $Z in Friday fees"
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 wish that story ended with the developer of the trading software learning a lesson about user interfaces
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.
I'm sorry, but you have no defense. Laughing at a junior developer'a code is completely inexcusable. Simple fact is, if you worked for me, I would have fired you for that. Junior devs are supposed to do bad things - that's why they aren't senior devs.
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 wou…
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.
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…
As a junior, I've found a similar experience as well. Programming environments seem to have a really unprofessional attitude when it comes to this.
Oh his behalf, I apologize. I literally started laughing at a junior's code once but in my defense, he had spent 3 years at Amazon.
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.
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.”
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 fil…
In general, this design principle is known as poka yoke:
This reminds of important lessons I've learned from the classic How to Win Friends and Influence People - never ever criticize people and you will get the best out of them. There are countless other great lessons in this book about being a leader and dealing with people.
No, definitely criticize people, but do it in a constructive and positive manner so it doesn't seem like it is criticism or coming from a negative place.
You cannot run a team without some measure of criticism or feedback.
From my experience as a manager, being kind works very well. This is especially important in the stressful start-up world where tensions are high anyways.
Nice little read. There is that little answer in the back of my head of: "It is a good question why I caused this problem. It is weird to think there is a competent company that has been around for so many years, yet they have no procedures in place to stop this from happening. You would think that any changes that could cause downtime on a clients website would go through an automatic test suite and only after passi…
Think of what you're saying on a meta-level here. You would basically be telling this guy, "I fucked up, but I'm blaming you for treating me like an adult instead of a child. You screwed up by giving me enough autonomy that I could make a mistake." That might not exactly be a smart career move.. On a more personal level, if someone shows you kindness in the face of a mistake, the last thing you want to do is throw it…
I read what he was saying differently. When errors like this occur it's very much worth evaluating what could be done to avoid it in the future beside me just learning my lesson. There are many general team behaviors (e.g. Automated functional testing, automated load testing, static analysis, code reviews, non-production environments, etc.) and things specific for the problem at hand (what test is missing that would have caught this?) that must be considered after a major issue. If these aren't evaluated then there it is likely they will happen again. I don't believe these are being treated like a child. Instead these are the team deciding to be adults by avoiding emergencies and being more confident when releasing.
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.
The original wording is ambiguous. I too read it as if OP had some issues with people coming from there.
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.