> I talked about the need for proper QA. About thoroughly testing my changes. About taking the time to make sure the job gets done right.
Oh good, a bunch of useless platitudes.
Be Kind
101–110 of 458 posts
Re: Be Kind
#102Earlier quoted context omitted.
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 a…
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 pointle…
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.
Re: Be Kind
#103Earlier quoted context omitted.
Nobody should be deploying to production on Friday... Nobody.
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).
No, the best time to deploy is when everyone you need to fix the issue is in the (metaphorical) building already.
You should not be pulling people in from their time off to fix shit.
Re: Be Kind
#104Earlier quoted context omitted.
Nobody should be deploying to production on Friday... Nobody.
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).
+1. Some systems aren't used heavily on weekends so it acts like a beta test.
Re: Be Kind
#105Earlier quoted context omitted.
Nobody should be deploying to production on Friday... Nobody.
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!
And you don't get to that ideal state by breaking production on Fridays.
Re: Be Kind
#106Earlier quoted context omitted.
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.
Laughing at a junior's work when you are their mentor is a firable offense in my eyes.
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?
Re: Be Kind
#107Most of my career I've been the guy people come to when they get stuck and need a second pair of eyes or just advice. I enjoy it, we all have to start somewhere. For the most part this has been considered a positive by my bosses, because they see the value this creates even if it's not technically my core job.
I did however once work at a company that was very metric-focused. Turns out that the metric they used for our team was closed tickets, and they felt that given my salary I didn't close enough of them. No understanding whatsoever that others on the team were able to close more tickets because of my help (let alone that the tickets that made their way to me tended to be the complicated ones that others couldn't solve). After the first talking to, I stopped helping out my teammembers (I explained why) - and jumped on the first opportunity to get out of there.
Re: Be Kind
#108Earlier quoted context omitted.
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.
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.
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.)
Re: Be Kind
#109Nice little read. There is that little answer in the back of my head of:
"It is a good question why I caused this problem. It is weird to think there is a competent company that has been around for so many years, yet they have no procedures in place to stop this from happening. You would think that any changes that could cause downtime on a clients website would go through an automatic test suite and only after passing all tests would it be tested by human QA and finally made live. In this particular case I am the one who has made a mistake, and being a sensible person who is eager to constantly better myself, I will try and learn from this error, however I work alongside dozens of other people on my team who like me, have every chance of making a mistake at some point. It seems like a bad policy for us as a company to say that we should expect every person on the team to break a clients site and then rely on overtime from other people to fix it. So of course I will try and do better, but this is not fixing the root of the problem, the root of the problem is something that needs to be fixed at a much higher level. Have you, as my boss, not considered this problem already? What has the company learned from this? I would be happy to be part of the team that solves this problem by creating unit tests and creating policy to avoid this."
Of course I purposely make this slightly stand-off-ish, over the top, and written from a very specific perspective, to illustrate a point. But the reason I do this is I absolutely agree a single developer shouldn't feel bad about making a mistake (they should try not to, but these things happen), but the company should put measures in place to minimise the impact of mistakes. When the company fails to do this, the company has screwed up a lot more than the developer.
Re: Be Kind
#110Earlier quoted context omitted.
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?
And becoming passive implies the message that you're a pushover to whom anything can be done because there will never be nefarious consequences. To those people the mindset is: If I do X I might gain something (or feels good) and no mater what I'll never suffer any retaliation for it. Why shouldn't I do it?
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.