undefined | Better HN

0 pointsmacksd3y ago0 comments

I had a job where they gave training on how to constructively engage with the open source community, and one of the big points was, "you don't suck, the patch sucks".

Oh you have a bug in the patch? No, there's a bug in the patch. Oh you missed an edge case? No, there's an edge case nobody had documented yet.

The point was mostly about how to give feedback on the patch, and to never phrase it about the person personally, but perhaps it would help to try and catch yourself thinking of the feedback this way and have your internal dialog look at the patch as being separate from you.

Yes, it's your work, but it's always a work in progress, and it's everybody's work to try and make incremental improvements to the code, to the process, etc.

I used to think I didn't like working with inexperienced engineers, but I noticed that what I actually didn't like was people who were unwilling to candidly discuss ways to improve, whether they were junior or senior - it's just a little easier to spot in people more junior than one's self. So kudos to you for recognizing this, because if you can learn to absorb constructive feedback it's a real game changer for you and for everyone around you too.

0 comments

3 comments · 2 top-level

taeric3y ago· 1 in thread

I was hoping someone would have something about learning to give criticism. I was legit scared when the top posts are, "learning to take criticism is how you become a senior programmer."

Not that that is worthless, mind; but becoming aware of that in the process is what makes you senior. By definition of it being part of growth. With time, you will have been no both ends of more and more reviews. Hopefully you start to see how both sides of the conversation that is a pull request go.

And note that you can't "policy away" bad snarky comments. If someone is giving a ton of those, or is generally tone deaf, work with them. If it is someone you don't want to work with, pull in peers to help work through that. If you don't have a support network, start there above anything. Even if things seem to be going well, having peers to lean on is important for the times that it doesn't. Learning to be a good peer is equally vital, and is a part of what makes the reviews more relatable and part of a group project.

macksdOP3y ago

Agreed. One reason you can't "policy away" snark is another reason it's best to separate your sense of self from your work: what you hear as snark when you're feeling down, maybe wasn't even snark, it might have been lightheartedness. I can think of a review I gave recently where I saw someone having to work around something confusing that my team is ALWAYS having to work around, and I just commented on what a mess it was. In hindsight, it could have sounded like snarky criticism of the patch, when in reality it was meant as supportive, empathic, camaraderie. If I was giving the code review face to face verbally, probably would have come across. At least we have emojis.

topaz03y ago

This is a great and underappreciated point: the person giving the criticism has a lot of power in determining whether or not you take it personally. I would add that having good mentors who give criticism in this way also helps you to internalize the separation between yourself and your work, so that it's easier to take harsh criticism later in life.

j / k navigate · click thread line to collapse