Live data from Hacker News

Be Kind

briangilham.com

51–60 of 458 posts

Re: Be Kind

#51
post #30

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…

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.

Maybe I don't get the joke, but why is this a defense?

(I had a collegue at my last company who worked at Amazon before. His code was just fine.)

Re: Be Kind

#52
post #30

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…

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.

Re: Be Kind

#53
post #32
post #9

This statement wraps it up: “Great. It sounds like you get it. I know that you can do better.” Giving folks a chance to communicate what they learned, and then encouraging them to "do better," is the best way to lead.

As long as it's not overdone. If every review ends in "you can do better" it just becomes the new "must apply themselves more in class".

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.

Re: Be Kind

#54

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

Nice!

Re: Be Kind

#56

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…

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.

Re: Be Kind

#57

Earlier quoted context omitted.

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.

[deleted]

Re: Be Kind

#58
post #14

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

I think you've been lucky. I've seen some really awful senior devs/team leads in my time.

Re: Be Kind

#59
post #4

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.

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.

Re: Be Kind

#60

Isn't there supposed to be a code review before devs are allowed to deploy something to production? Yeah, Brian screwed up. But the company has at least some fault for letting him get that far unchecked.

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 :-)
Post reply on HN