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

31–40 of 458 posts

Re: Be Kind

#31

Post by LukeB_UK »

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.

Re: Be Kind

#32

Post by taneq »

mijustin wrote: 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".

Re: Be Kind

#33

Post by [deleted] »

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

[deleted]

Re: Be Kind

#34

Post by Manishearth »

matwood wrote: post #12
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.

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…

Also, "why not X?". It puts the assumption up front that the programmer has already thought it through, which is often the case.

Re: Be Kind

#35

Post by sparrish »

phn wrote: post #22
mrits wrote: post #6

I hope Kevin learned not to let a junior dev deploy to production on Friday.

Well, he'd have to sooner or later. Better start learning as soon as possible :)

Nobody should be deploying to production on Friday... Nobody.

Re: Be Kind

#36

Post by bryanlarsen »

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…

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.

Re: Be Kind

#37

Post by crdoconnor »

matwood wrote: post #12
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.

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 pointless crap during code reviews.

Re: Be Kind

#38

Post by happyslobro »

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.

Re: Be Kind

#39

Post by southphillyman »

crush_xc wrote: post #17

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…

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