Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Be Kind

briangilham.com

Post reply on HN
Print view View original

141–150 of 458 posts

Re: Be Kind

#141

Post by tomjen3 »

falcolas wrote: post #46
Shanea93 wrote: post #41

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.

So I should just leave a security vulnerability rather than fix it on a Friday, because I won't be available Saturday?

Re: Be Kind

#142

Post by JustSomeNobody »

We're an industry filled with people who have social disorders. Some people are just angry little people. Misspell something in a config file and they just ... go ... ballistic... It's not enough to just try and tell these people to be nice. They don't know HOW to be nice. Their brain isn't wired to be nice.

Edit: spelling.

Re: Be Kind

#143

Post by vlunkr »

happyslobro wrote: post #38

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.

Re: Be Kind

#144

Post by cheez »

sgift wrote: post #51
cheez wrote: post #30

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

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

I had expected better code to result. It was borderline comical.

Re: Be Kind

#145

Post by cheez »

enraged_camel wrote: post #52
cheez wrote: post #30

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

Wasn't his mentor. Just a guy reviewing code.

Re: Be Kind

#146

Post by davemel37 »

auganov wrote: post #70

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.

This should be upvoted to the top! Definitely more than some story about turn of the century dancers :)

Re: Be Kind

#147

Post by vlunkr »

herge wrote: 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.

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.

Re: Be Kind

#148

Post by makecheck »

I have found that difficult people are a function of both themselves and the environment they’re in, and you can’t necessarily say “be kind” without fixing the 2nd part.

The level of stress matters a lot. If a team is being run in a standard “everyday crisis” mode, they quickly reach the point where there is very little they can take. Every tiny mistake wears people down, reminding them of how much more there is to do, and turning them sour. Managers seem to panic and cut into their team’s time even more by starting to have long, daily meetings to “fix” things.

If you want “nice” people, you have to set them up for success. Reward completing the whole chain, not just hacking away (e.g. for software, not just coding but also testing, documentation, and seeking peer review). Keep meetings to a minimum. No overtime. When short-cuts were taken to meet hard deadlines, open up your schedule and scribble in the exact window after the deadline where you will stop everything and clean up the mess that the short-cut created. Give your people the best equipment that money can buy. And so on.

Re: Be Kind

#149

Post by icebraining »

gwbas1c wrote: post #24
matwood wrote: post #12

Earlier 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 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 develo…

Does being stern actually produce better results?

Re: Be Kind

#150

Post by cableshaft »

7Z7 wrote: post #111
maket wrote: post #83

Earlier quoted context omitted.

He said "In my defense", justifying laughing at the junior dev because he (the junior dev), had 3 years of experience at Amazon.

Right, which suggests that coders from Amazon generally have rubbish code, excusing the laughter.

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