How to Criticize like a Senior Programmer

As I spend most of my socials online time on Github and PHP-related discussion, I've noticed many people do so many wrong things while giving critics.

I want to correct this once and for all, so I've prepared a guide for you.

1. Find an Error

This is very easy step that many people can handle. Just pick something wrong in a project, or content and point it out. Rush to create that issue! Also, comment only thing, where is no request for critics or feedback. The worst think you can do is actually help the person who want some feedback.

2. Strong Intro

No "hello" or "hi", never use a surname and NEVER use a name. Just write right away what is wrong, that's the only thing that matters. Some example:

Minitip: Judge Others 

    <br>

    <p>
        As a senior programmer you have right to say what is right and wrong. You should be clear and right to the point. Only that way the other person knows what is this about and can do something about that.
    </p>

    <p><em>"this is definitely wrong"</em></p>
</div>

Minitip: Point out the Other person is Below You 

    <br>

    <p>
        If that would be another way, he or she would not need a correction, right?
    </p>
    <ul>
        <li>missing education: <em>"read the docs first"</em></li>
        <li>more stupid: <em>"lol, you really think this is the way to use it?"</em></li>
    </ul>
</div>

3. Never Back up - You're not Weak

When you get a response like this, it is usually very rude like for no reason:

  • "What do you mean by that?"

You only are trying to help the second person to stop being to stupid. The author is only pretending he doesn't know. But luckily you are smarter than him to recognize it!

4. Repeat the Same to Make Them Hear You

If the other doesn't want to listen, he or she probably didn't read our comments clearly. Who can blame them, it's today's world full of social media distractions (and alcohol and drugs!). There is no better solution than point that out.

  • "I wrote that already."

In case you have mood for long essays:

  • "I wrote that already, see comment up"

If you have bless mood, you can write it explicitly for those with attention disorder:

  • "I wrote that already: this is wrong way to use this"

5. Point out Places to Learn From

As our mission is to educate others about their mistakes, thus we should always provide a source of knowledge.

  • "Read the docs first"
  • "it's in the manual, doh"
  • "read php manual"

Today, we have Google, so there is no need to use actual link. Everybody can google now. And if they don't, they're stupid and they should learn that first.

Minitip: Use Shortcuts To Save Time 

    <br>

    <p>
       All people in the field know all the shortuts you do - they're programmers after all - so why not use them so save time in conversation and your elbows.
    </p>
    <ul>
        <li><em>"why don't you use IDE"?</em></li>
        <li><em>"use Docker AWS setup with DTOs lol"</em></li>
    </ul>

    <p>Again, do not add any links, Google can handle it for you.</p>
</div>

6. Believe in Yourself

You know the best (as your mama and papa told you) - never forget that. And if other try to change your mind, they probably don't know a thing.Stick to your believes and don't let anyone to question it.

  • "no, you don't understand this"

You're the most objective person there could be, so use it. That's what intelligent means!

7. Always Tell, Never Ask

Because many people are missing parenting, you're here for them to help them with raising to proper senior programmer. Always, tell the other person what to do or how the world works. It's objective true. How can you be subjective if you're human. Asking is sign of not-knowing and weakness.

8. Keep it Short, Never Provide a Reason

To make conversion faster, always talks about your final ideas. There is not time to provide motivation reason, how you conclude it and all that life story of yours. It's obvious already and he should know it. Or just google it.

And so on... you get the gist.



Disclaimer: Start with Misconceptions First

As you probably guessed, this post is written in sarcasm language.

I got inspired by Derek Muller, known as author of Verritasium, with "start with misconceptions first". This list describes just few of misconceptions on feedback topic I found on Github during my open-source career. If you know any more, just tell me in the comments ("you forgot some").

If you know Czech, you can check my talk Jako Vinnetou a Old Shatterhand – refaktoruj nenávist v přátelství from PHPLive 2016, where I address similar topic between 2 PHP frameworks.

So...

How to Give Feedback that Helps You Both

After misconceptions we can move to really what matters - emphatic feedback. Once I read a post about people with of 30+ years long and happy marriages:

We have a strong feeling, that when we point out mistakes we see at other people, they will change that.

It nails it! So what I'm trying to do apart inversion of all the 8 points above to make my online/offline feedback communication better?

1. Is Feedback Desired?

Do you enjoy parenting and patronizing? Neither do I. So when I give feedback, I try to find out first if the other person is even open to some.

There is small trick to do that:

  • "Well, I have some feedback for you, but I'm not sure if you'd like to hear it."
  • "Yes, of course."
  • "Ok, I saw your presentation and I think the letters are so small, that no one will see it."

vs.

  • "Hey John, I saw your presentation and I think the letters are so small, that no one will see it."

2. What is My Motivation?

Giving advices is just talking to your younger self.

I know this is not easy to hear, but giving feedback is partially just projection of the one who gives the feedback. Even now, when I'm writing this post, I frustrated with something else. I'm frustrated by educational systems and misconceptions it teaches people.

If you know your real motivation, you can work it much better and be able to give the other person not the information that you're frustrated with but information that he or she really wants.

3. Make a Rapport instead of an Enemy

No, this is not a dinosaur nor air fighter.

If you want to persuade someone, start in a friendly way.

You can find this quote in all books on persuasion. I didn't know about this for a long time, so I started with rationalization arguments:

  • "Hey, you have to use IDE, because it will help you with productivity a lot."
  • "You should use Symfony, because it's more matured than any other frameworks!"

This only forces the other for defense, even if you don't want him to:

  • "Sublime Text is just fine. It can compare to PHPStorm and is even faster!"
  • "I use Nette for many years and Symfony seems too complicated and is very slow."

Sorry brain! Instead, you can make a rapport - a short term friendship if you like.

  • Be curious: "What do you mean by "this is too complicated"? What part exactly is too complicated?"

  • Relate to the his or her point of view: "I agree you might have problems reading this, since it's your first time and I use this for over 3 years and know it by heart."

4. Replace "You" and the Future" with "I" and the Present

"I'm objective", a human said.

When one person claims something, it's usually his own personal experience wrapped into cognitive heuristics.

  • "You'll definitely find IDE useful."

vs.

  • "I personally find IDE useful, because it it helps me with class autocomplete. That saves me lot of time, since I use other dependencies than my code."

As people tend to mirror each other's communication, being personal might unlock personal approach of the other person as well.

6. Provide a Reason

I'll just reuse the example above (because it shows it already and will keep you more attentive to the detail):

  • "I personally find IDE useful"

vs.

  • "I personally find IDE useful, because it it helps me with class autocomplete. That saves me lot of time, since I use other dependencies than my code."



Your feedback and tips are most welcomed as I want to get better in this, so add your comment. Even with sarcastic examples from this post ;).



Happy feedbacking!



Do you learn from my contents or use open-souce packages like Rector every day?
Consider supporting it on GitHub Sponsors. I'd really appreciate it!