25 ms·

Some anecdata: I tried to submit a patch once (https://patchwork.ozlabs.org/patch/660921/ https://patchwork.ozlabs.org/patch/660921/) - which to me felt exactl

• bayindirh 8y ago
  > I can see the other side of the coin as well - the need to maintain the code quality, and probably the burnout of multiple “stupid” questions/patches. I can imagine how it gets tiring especially if one does it in their spare time. It gets tiring only if you despise answering these "basic" and/or seemingly "stupid" questions. In my day job I'm a system administrator of an HPC cluster, and we also do technical support ourselves. Users ask questions "wrong" all the time. Not enough information, seemingly simple details, etc. I personally never get mad at them, because they don't know how to do it better. We generally try to guide them, point to the correct places, test the problem ourselves, and see what happens, but never intentionally harass them. You can maintain the code quality with a polite "Why this patch didn't pass the inspection" letter. There's a similar effort called "I downvoted because" [0], but even giving links from that page requires some niceness. Just pasting the relevant URL also looks and feels rude. If a user is intentionally volatile, we defuse them. If they're intentionally malicious, we block/prevent them. If they're intentionally smarmy or snarky, they get polite but firm answers. At the end they cool down, because they cannot fuel their anger with our reactions. > Do I have the right to say “they need to be more patient/welcoming”? Probably I don’t - but equally I don’t fancy being someone’s emotional grounding. They don't need to be patient, if one is intentionally testing their patience. They don't need to be (overly) welcoming, but they need to be polite enough to tell that, or point the person to right way. Saying "no" is not a problem, but not pointing the next step is problematic, especially if the asking person doesn't know the better. At the end, these behaviors are not because of the person asking the question, or sending in that "stupid" patch. It's about the person who's reacting to the patch/question/whatever. They don't like something, or see something and get triggered, then unload all the rage upon the asking person regardless of relevance of the rage. For one, knowing oneself better is as essential knowing the stuff that you're working on. Having a baseline niceness is a win for everyone, because it makes life much simpler without softening boundaries. In fact, it strengthens them without making them intimidating. [0] http://idownvotedbecau.se http://idownvotedbecau.se
  • marcus_holmes 8y ago
    I am responsible for my emotions, and my reaction to something is my problem. I get this. Programming is creative. Just like artists, writers, any other creative process. We get emotionally involved with our work and we become emotionally vulnerable when we show our work to others. So submitting code to the scrutiny of others is a vulnerable space for me. If the reaction of others is "this sucks" then I have a negative emotional reaction to that. I understand that this reaction is my problem, I'm not blaming the other person for their response, but I still have a negative emotional reaction. I do not want to emotionally disassociate myself from my creative work so that I no longer have this reaction. I enjoy being this emotionally connected to my work. I'd rather not show my work to others, or to only selected people who I can trust not to respond with something that will hurt me. I know this about myself.
    • bayindirh 8y ago
      Disclaimer: I'll intentionally use "you" to address you, since you expressed some emotions, and I'll directly address them, but I won't hurt you. > I do not want to emotionally disassociate myself from my creative work so that I no longer have this reaction. I enjoy being this emotionally connected to my work. I also see programming as a form of art, and I'm also attached to my code emotionally, however you need to understand that, when someone says that your code "sucks" it's their point of view. Neither you nor your code sucks. It may not be doing something in a certain way the critical person likes or prefers. Even if your patch is plain wrong, this doesn't change the real value of you or your code. You've put the effort and tried something. You're the man in the arena [0]. If the person is agreeable, you can talk and improve the code and the persons involved in this. If not, do not take the critics' criticisms and move on. Even if your patch or code is wrong, it doesn't give the person the right to hurt you. So don't allow him/her to do so. The critic might be right in its words, but wrong in its attitude. You can learn to separate the two, and thank for the advice while giving back the thorny part. Yes it's a very hard thing to learn, but when you learn it, you can keep the ability without much maintenance. When you learn this skill, you do not emotionally disconnect from your work. On the contrary, your connection is stronger and the elements cannot affect this connection between you and your work. Also, you have a much pure and powerful kind of empathy as a result of this learning process. Because you can look from the eyes of the critic, with the disconnection of the critic from your life and work, and process this criticism with the emotional connection to your code. This transforms the whole situation into something hard to describe, but it's very powerful indeed. Last but not the least, it's free from the emotional damage that critic deals (knowingly or unknowingly). Code on, keep creating and at least put it somewhere visible. You don't need to shout about it. [0] http://www.theodore-roosevelt.com/trsorbonnespeech.html http://www.theodore-roosevelt.com/trsorbonnespeech.html