http://qs321.pair.com?node_id=133204


in reply to How do you critique another person's code?

I made a comment about the code to my manager, and have now been called into a meeting with my manager, and the programmer's manager where I am expected to provide feedback on the script and what I think the problems are. If I were the programmer's supervisor, I would have no problem providing him direction (and rejecting the entire script.) However, how can I politely provide factual feedback without "attacking" the style of programming?
Your company isn't paying you to be polite. If the "style" of the code makes future maintenance and upgrades difficult, that's something the company needs to know.

But you should make it clear what the purpose of your feedback is, ahead of the actual feedback. Remember that "purpose", "trust", and "respect" all go hand-in-hand: if one is missing or unclear, the rest will erode rapidly. So, make it clear that the purpose of your feedback is to reduce the risk to the company, and then remain true to that purpose. Within that purpose, the means by which the content is spoken matters little, as long as the purpose is clear and respected. Hidden agendas will undermine the process, so you must ensure that the cards are all face up on the table.

-- Randal L. Schwartz, Perl hacker

  • Comment on Re: How do you critique another person's code?

Replies are listed 'Best First'.
Re: Re: How do you critique another person's code?
by VSarkiss (Monsignor) on Dec 19, 2001 at 22:49 UTC

    This is excellent advice. I can't emphasize this point strongly enough:

    ensure that the cards are all face up on the table
    This includes your own. Make sure you're clear about your motivations and what you want to achieve. If you're only after improving the code, then your style will not matter. If you have a personal beef with the programmer, it will.

Re: Re: How do you critique another person's code?
by Gyro (Monk) on Dec 20, 2001 at 22:20 UTC
    I agree. Remember this is not a personal attack, only a critiquing of his code. Calmly let him know that the comments are unprofessional and reflect badly on him and the company. Let his manager reprimand him for the poor choice in comments that's his job, concentrate on the code. Remind him that well used comments and understandable variables help bring real understanding as to what the code is doing. If you feel that the code needs to be rewritten show them why.
    From the looks of it he needs mentoring. I am one who likes to give people a chance, but I am not suggesting that you take that job. Does he have potential? Yes, we all do. If they don't already have it suggest a code review process. bmcatt has an excellent out line. This is an excellent site for code review as well.

    Ideas for designing and conducting code reviews at TechRepublic has links to articles and tips from readers. These have some good info, you may have to sign up at the site, it's free. If you have problems let me know and I'll get you the articles.

    Good luck,
    Brad

      Does he have potential? Yes, we all do.
      If by that you mean "Does he have potential to be an expert programmer?", I'm going to disagree with you.

      Over the years, I've had lots of opportunity to watch various people attempt and master programming.

      Some people "get it". Others... just don't.

      Now there's nothing lesser about those that don't. Let's take the inverse as an example. Most people consider me to be an expert programmer. But I can't draw worth beans. It mystifies me. I can't figure out how people know where to put the lines or the colors, or how to transform the 3-D world they are viewing into the 2-D projection of it for the paper.

      So, I don't draw. I'm not braindead. I just don't think that way. Similarly, I've seen that most people don't think in the way that it takes to be an expert programmer. Nothing wrong with them. They just don't have that particular aptitude.

      And I may get flamed on this. Lemme also say that I think as children, we probably can and do pick a path, and maybe only then were all possibilities equally probable. But at some point, we start specializing, and after that, there's a commitment to the wiring of a particular brain. My theory, anyway.

      Now if you meant "has potential to get a bit better", certainly, I can support that. But maybe he oughta take up another line of work. Seriously.

      -- Randal L. Schwartz, Perl hacker

        Once upon a time I took a drawing class in college. The teacher had been teaching art classes for about 20 years. One day early in the class, the subject of 'people who can't draw' came up -- of which there were, as I recall, about five in this particular class of ~20. His opinion was that, yes, some people can't draw. And in his twenty years of teaching people from the age of 5 to 95 he's encountered precisely two such poor souls.

        Our class didn't provide him with a third example. Now consider, say he teaches four classes per year (he doesn't teach only at the university). Take an average class size of twenty. That's 1600 people. So the odds of a random person picked off the street really not being able to draw is about 0.125% (with rounding).

        You may argue that people who 'can't draw' don't sign up for art class. But he doesn't teach just people who volunteer. He teaches at lower level schools and at nursing homes. Further, some people who think they can't draw take classes anyway as an attempt to 'better themselves'.

        To be more specific, by 'draw' I mean the ability to produce, say, a drawing of a person's face that the average viewer would call 'good art' and have no trouble matching with the actual person it was an image of, even if they'd never met them before.

        I wonder, have you taken an art class? If so did the teacher actually teach you things -- like blind contour drawing, foreground/background, hot/cold coloring, etc. -- or did they just say 'watch me do this and then you do it'? Did they run you through drills and make you keep all your drawings so you could compare results? Did they explain how to suggest shape by varying the thickness of a line? And then make you practice for a half an hour? And then make you practise again the next day? Did you work at it for four hours a day, five days a week for six weeks?

        If you haven't done these things than you can't legitimately say you can't draw, IM(NSH)O, you can only say that, unlike people who could play Mozart after merely being shown what the keys of a piano do, it's not an innate ability.

        And now, after much ado, my personal opinion:

        I don't see how programming is any different.

        Speaking as someone who can draw pretty well, and who can do mathematics and physics even better, and therefore, presumably, knows something about what it takes to do each, I can say that I quite definitely don't experience any 'different mode of thought' when I'm doing these three rather different things. The main difference between drawing a person's hand and showing that a given set of sets defines a topology is the degree of hand-eye coordination required to ensure success.

        </down with the art-science dichotomy rant>

        scott

        I agree completely with you, merlyn.

        ------
        We are the carpenters and bricklayers of the Information Age.

        Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

        Again I agree with you. This is definitely someone who needs more training. Did not mean he would be an expert.