Conversation

Notices

1. nixCraft 🐧 (nixcraft@mastodon.social)'s status on Monday, 04-Dec-2023 03:06:32 JST nixCraft 🐧

   Sometimes, the feedback you get on your code can feel like a personal attack, and it can mess up your peace. How do you deal with that? 🤔

   • Sean Payne (seantpayne@mastodon.social)'s status on Monday, 04-Dec-2023 03:41:59 JST Sean Payne

     in reply to

     @nixCraft

     I'll tell you what I do!

     git checkout master
     git merge my-branch
     git push origin --force

     j/k I tend to try to take the feedback as an opportunity to learn why I received the feedback I got and see how things could be better going forward. I feel using feedback as a way to learn to improve my craft is just as much a skill as coding and should be practiced as well.

     But, yeah, it's not easy separating from what I create, especially if I feel proud to have solved a difficult problem.

   • val = int(1) (val_int1@mastodon.social)'s status on Monday, 04-Dec-2023 03:46:46 JST val = int(1)

     in reply to

     @nixCraft

   • SiliconFarmer (siliconfarmer@mastodon.social)'s status on Monday, 04-Dec-2023 03:46:57 JST SiliconFarmer

     in reply to

     @nixCraft I have such a low opinion of my coding skills, that I can take whatever reviewers say as a compliment.

   • Alex (a_lex_ander@mastodon.social)'s status on Monday, 04-Dec-2023 04:01:01 JST Alex

     in reply to

     @nixCraft Don't answer immediately. Take a step back, let a day pass, then look at the review in detail. Technical reviews are very direct, very blunt, there are no frills like with other discussions. Be direct as well and explain your rationale behind your decisions. Sometimes you're right, sometimes the reviewers are. There's much I leaned from reviews, other times it was just stupid nitpicking for no apparent reason, so in the end at least I learned not to take it personally and move on.

   • Luca Archidiacono (archi_luc@mastodon.social)'s status on Monday, 04-Dec-2023 04:16:25 JST Luca Archidiacono

     in reply to

     @nixCraft based on my personal experience and opinion, thats something which wears off with time and seniority. I also think, that learning to not take it personal, is a step to being a senior developer.

   • Peter Hanecak (phanecak@mastodon.social)'s status on Monday, 04-Dec-2023 04:44:15 JST Peter Hanecak

     in reply to

     @nixCraft 1) Everybody makes mistakes from time time to time.
     2) Even when "I'm doing this professionally for years" there still might be a better way for doing a particular thing.

     1/2

   • Freevolt (freevolt24@mastodon.social)'s status on Monday, 04-Dec-2023 04:48:32 JST Freevolt

     in reply to

     @nixCraft The same thing can happen when you get feedback for your academic paper. For that, I just came to terms with that by disarming my defense mechanism for personal attacks.

   • Gilles Bonnet (gillesbonnet@mastodon.social)'s status on Monday, 04-Dec-2023 07:39:17 JST Gilles Bonnet

     in reply to

     @nixCraft depend upon the way I've feedback is.. if polite, I have no problem if not I just put it at the lowest priority

   • Daniel Quinn (danielquinn@mastodon.social)'s status on Monday, 04-Dec-2023 09:57:53 JST Daniel Quinn

     in reply to

     @nixCraft determine whether the criticism is valid, or just someone being a dick.

     If it's the former, you learn how to do it better, if it's the latter, tell them to fuck off.

   • The Green Knight (greenknight23@mastodon.social)'s status on Monday, 04-Dec-2023 10:01:43 JST The Green Knight

     in reply to

     @nixCraft I review my own code first before sending it to anyone. I treat those reviews like a confessional.

     Instead of "forgive me father,I have sinned" it's, "look at that dumb shit you made me redo"

     Instead of "hail Mary", it's "you fucking idiot".

     By the time I'm done with the whole ritual, nobody could hurt me more than I have already hurt myself.

   • Daniel (helmet91@mastodon.social)'s status on Monday, 04-Dec-2023 17:04:08 JST Daniel

     in reply to

     @nixCraft First I analyze if their feedback really is an improvement or a garbage. If it's an improvement, I'm happy for it and I'll follow it. If it's garbage, then it depends on what I'm working on. Personal project? Then ignore it. Company project? Then check if it aligns with the company's coding standards. If so, then follow it, otherwise ignore it. This is, of course, a simplified walkthrough. In real life it may be a bit more complex.