This goes out to all the geeky spouses, partners and friends of brand new programmers:
Code review is a cultural practice.
When you sit down to read the work of another, you bring with you all the experience you’ve had up to that point, the code reviews you’ve received, the mistakes you see yourself making and the bits of hard-won knowledge embedded in your coding personality.
Basically, you bring your coding baggage into your review.
When a brand new programmer shares their code with you, they are fundamentally vulnerable. They’re sharing something creative, and like any new creative endeavor, the product is a newborn taking it’s first few, shaky steps.
They are asking for your help and very likely, they’re asking for an indication that they’ve accomplished something. That all the time they just invested in learning something new — paid off.
And, in the case of PyLadies, women are all stepping out on a limb. Some are taking a Coursera class or maybe a workshop, but mostly working alone. We have each other to learn with and we’re all learning something new. Many people are spending 2 nights a week with a group, and another 15-20 hours a week struggling through the very first programs they’ve ever written.
Here’s the very best thing you can say when a PyLady shares her code with you:
“Thanks for sharing this!”
And then, after you’ve had a look:
“I’ve had a look and you’re doing a great job. Tell me about what you’ve written.”
Seriously. That’s about it.
If the PyLady asks specific questions, give your answers. Keep it short and sweet, and encouraging.
I’m laying this out because lots of the women who are trying this stuff out for the first time have loving, geeky spouses and friends who are very excited that the women in their lives are learning to speak their languages. And some of that enthusiasm comes in the form of detailed critique of style, formatting and design.
I’m here to let you off the hook. Just be encouraging, and ask a few open ended questions. That is all you need to do.
Because the reality is: the PyLady is her own worst critic. And, when she comes to a meetup, she can get the detailed help she needs from the other women who are struggling right along with her.
The people in the group have earned the right to share and receive feedback by strugging together. That’s the value of a cohort and one reason why PyLadies, and groups like them, are so important.
If you’re lucky, you’ll get your chance to share some code back, and maybe even write something together. But you build that coding relationship one encouraging step at a time.
If you’re interested in joining PyLadies-PDX, we’re meeting weekly through December, and then starting Monthly meetings on January.
And, if you want to read more about code review in general, here are some additional blog posts I found useful:
- On Code Review – Dave describes code review culture, why people review and the benefits of consistently reviewing, even trival patches
- 5 tips to make good code reviews
- Things everyone should do: Code Review “The biggest advantage of code review is purely social.” — total agreement, great post
- Code Reviews: Good idea, bad idea? “the key factors to successful code reviews are trust and training” and “As with any development tool, just using it is not enough — you must be sure you are using it in the right way”
- Coding Horror — Code Review: Just do it Jeff Atwood links to some dead stuff here (from 2006), but also quotes Code Complete
which I found to be a good primer on big group programming projects.
I hear what you’re saying and understand that encouragement is needed most when people are taking their first steps.
I would also point out a simple truth to all learners discouraged by criticism: you should not be ashamed that you are not yet skilled in what you are pursuing. Whether the skilled can remember it and empathize with it or not, they were in the same position once. If someone calls you dumb, that is unconstructive and rude: they are being an asshole. If someone gives you honest but harsh feedback, take it in the best light: they are a sparring partner challenging you to be your best. You can beat this.
The most important thing is to not give up learning. You’ll get stronger, you start to move faster, and things will start to feel more natural. Just give it enough time to grow out of the awkward, afraid-to-raise-your-hand phase.
I’ve been a developer for nearly 20 years and I think it took me 5 or 10 to stop feeling dumb when I had to say “I don’t know” or “I don’t understand”. It gets better.
(written on phone, sorry for typos)
> I would also point out a simple truth to all learners discouraged by criticism
Completely agree.
Privately, a friend pointed out that she wants and asks for specific criticism of code when she needs it. This is a great thing to consider in code review — did the person asking me for a review ask for any particular kind of criticism? If not, asking questions in an open ended way is the best way to help.
Selena, this is great! I don’t think I’ve ever read about the etiquette of code review with newbies, even though I’m familiar with being a n00b reviewee, and it’s a great topic.
I remember my very first Python code review – in a work, corporate context, so there was no getting out of it. My code was reviewed by the author of an O’Reilly book about Python, and as a result the intimidation factor alone was through the roof. Dealing with the “Why did you do this x way instead of y way?” questions was pretty exhausting! It was a great learning experience, but I wish I hadn’t had to deal with so much emotional work to get through it intact (the sort of rationalizations that Jeremy mentions above – he’s correct that criticism plays an important role, but it does take a lot of energy to cope with it productively, even when it’s delivered free of asshole context!)
Code review is an incredible tool, but you’re so right that it weighs heavily on cultural factors and we need to remember why we are participating in it: not to indulge our inner critic, but to help our peers become better developers.
This! Also, code review is really difficult. It takes practice to get good at it. I encourage people to do as much code review as they can. It’s the secret sauce of excellent open source development groups, and it makes everyone’s code, and their thinking about the code, better.
I think ‘Tell me about what you’ve written’ is more than enough to get a new developer to really look at his/her own code and begin to think about it’s form, structure and efficiency. Nothing gets you thinking about those qualities more than explaining your own code, right?
That’s right.
It also gives the critic — assuming also that they’re actually, actively listening — a more informed framework for their criticism than solely their own assumptions about what the codewriter’s processes *might* be. Because as opposed to relying on their own presumptions about what the codewriter is thinking, they know what the codewriter is *actually* thinking.
Yes! Definitely. I can’t tell you how many times I find a bug by just having an engaged listener for a few minutes.
“…PyLady….”?? Any chance we could, you know, NOT start doing this??
Why should we differentiate between a mans and a womens code? Why would that affect your constructive criticism / approach to code review?
I replied on 4chan to this as well. This post was about how to approach code review with new programmers. I don’t think we should differentiate between code written by any kind of person. I am working with a group of women right now, so I addressed part of the post to that specific case.