Dispelling The 'Genius Programmer' Myth Through Code Review by Ashwini Oruganti

Speaker 1: Come on, yo.

Speaker 2: Okay. Um good morning everyone. Good morning. I'm a software engineer living in San Francisco. Um you may know me from one or more of these other uh places. This is my first Django Gone ever, and also my first time in Philadelphia. So I'm really excited to be here. The campus is like amazing. So, um Ever since I was a kid, I had always wanted to be good at things without trying. The first time I came across a piano, I tried to play my favorite song on it and I somehow expected to get it alright without like any training whatsoever.

Speaker 2: I failed. Um the first time I tried to ride a bike, I wanted to get it right once again and like not fall at all. I did fall And I I say these things as if the older me is any wiser, but that's not really true. So every time, even today, when I try to do something new, I still hope to get excellent results on my first attempt. Many said faults and failures later, now I know that this is not how things work. I had hoped the same when I started programming. It was like uh

Speaker 2: you can say I was lazy or that popular culture makes success stories sound like talent is all it takes that a successful person has an intellectual gift that is far greater than what most people have in a given area. And not just programming that's like mathematics, music, dancing. running any athletic sport. And by that natural ability, they're going to far excel the rest of us. And almost as if by destiny, right? You can you cannot question destiny So in 2009, uh Fitz and Ben, um two engineers from Google deeply analyzed this. They've crafted a myth behind

Speaker 2: this the ideal programmer. They say, hey, here's a genius. The genius goes off in a cave. writes this brilliant thing, reveals it to the world, and becomes famous forever. I mean, I hear it so often. I'm sure those of you who are software engineers in pur uh like as a in a professional capacity, uh also hear it too often. But X writes excellent code. X is really smart. So I started investigating what what these genius programmers are like. Where do they get their ideas from? How can they look at a piece of code and say, hey, that won't work or hey, that won't scale?

Speaker 2: It is true that while being skilled and talented helps, I realize that a large part of this is because these experts have put in a lot of deliberate practice behind their work. They've iterated through so many failure modes so much that now when they work it all appears to be instantaneous And when you get to that level of specifics, you realize that there's no reason why these things cannot be taught, practiced, or learned. A great way, perhaps the best way

Speaker 2: to become an expert programmer is to have one teach you. Unfortunately, just simply walking up to one and being like, hey, teach me like make me like you. That won't work. That doesn't always work at least. Um I know this because I've tried. So uh a good strategy here is to ask them to review something that you've done and gather feedback. And it's even better if that something is a project they care about. And often the projects that programmers care deeply about are their own open source libraries.

Speaker 2: So go contribute to their projects. If you haven't already made any open source contributions yet, think about how you would want that experience to be. If you have already, think about your experiences so far. Do you feel happy, accomplished, or rewarded if your patch is accepted and merged? Do you feel valued if someone thanks you for your time? I know I definitely do, and most people agree. Successful contributions make us feel happy and productive. And I don't just mean a successful merge by a contribution.

Speaker 2: When I say contribution I mean right from the point where one starts working on an issue to when the maintainers or other community members start reviewing their code to finally when the said contribution gets merged. So let's assume we all buy into that, that we all want to see more successful contributions. And we want our patches to get accepted. Also, as maintainers, we want more quality patches for our software This leads us to the next part. How do we make this process painless for contributors and efficient for maintainers? And more selfishly, how do I become an expert contributor?

Speaker 2: And how do I get more people to work on improving the library I maintain and care about? Before we address those issues, we have a problem. This whole part about a non-expert seeking feedback from the expert This part is a little scary. It means that you have to sometimes show people code that you wrote that isn't already in a great shape. And people want to be seen as clever. And clever people don't make mistakes, right? Wrong. This uh well let's take an example from Python.

Speaker 2: There is this library called there is a part of Python called asyncio. Which a lot of people have been really excited about recently. It looks quite good now, but taking a look into its history. shows that a lot of discussions took place during its inception. Some were in person, some were online, some were on mailing lists And there were many iterations of design reviews and quite some rewrites. And that is how we got to the current state of async. io. A lot of people were involved in it. One person alone did not write it.

Speaker 2: Collaboration is not just essential. It's a prerequisite. It's a must-have. It is not a nice to have. And no one thinks no one builds things alone. Like not Guido, not Jessica, not Cliff, not Kenneth. And the experienced programmers just lead their projects. They encourage collaboration and build a community around the things they care about. That's it, it is sometimes frustrating to contribute when the maintainers won't just merge your badge in. and throw nitpicks at you and suggest an improved implementation

Speaker 2: and request a rewrite. But they have good reason to do it. Once your patch is merged in, they are the ones who will need to maintain it from there. Their goal is to make that process, that that process of maintaining it as painless as possible. Because all this is happening on volunteer time, especially for open source uh libraries that have been here for a while. At ByGon this year um there was an amazing doc by Augie and Nathaniel where they showed a slide with never ending lines of poorly organized colours. The slide was animated and pretty and like really well written, but every maintainer in the room winced at the sight of that slide.

Speaker 2: They recognized the pain of maintaining such a project. They all secretly hoped that their work doesn't now and doesn't ever look like that So every time someone mentions Pepe, Linters, code coverage, continuous integration tools, or just more tests or more documentation for tests. They are not trying to block your progress by being nitpicky. They are trying to maintain code quality. And there are always things you can do to get around those nitpicks Look, for example, look for coding standard guidelines. Every large open source project welcoming contributions should have one.

Speaker 2: By making sure your code follows these basic guidelines before you submit it for review, you're making the reviewer 's job a lot easier. You like before you actually go on to contribute, knowing the process is useful at the same time It's also important to respect the process. Many open source libraries have these well established steps or processes that they like following Sometimes it can be hard to understand why this process was chosen or why it is so important in me. The process may be wrong, it may look wrong, or

Speaker 2: you may be missing some context. I would recommend saving that fight for later. Never forget that the reason you started doing this in the first place was to learn. You can always go and change the process or modify it or ask questions Well, you can ask questions even initially. I don't think anyone would mind that. But uh as as about the fight to change it, you can save it for later Idou every potential code reviewer in this room would thank you for this It makes their lives very, very difficult if you submit like a huge pull request

Speaker 2: with lots of changes. And uh this is not just for new contributors. Uh I will pick an example from Trusted where someone, a longtime contributor, made some really amazing changes to the logging system of Trusted. The only problem was that that diff was extremely large. And so despite having an active development community , The diff sta sat in the review queue for ages. We finally had to like dedicate one whole sprint day at PyCon to review it and get it merged So gather feedback early. Even if things don't feel complete, show your code.

Speaker 2: That's the right thing to do. Also, respect the maintenance time. It's okay to ask them questions and ask them to elaborate on their comments and suggestions, but respectfully, not in an argumentative manner. And who knows, maybe you were right all along. Maybe the expert programmer made a mistake, right? That happens. It happens a lot. I say all this, but I know criticism is hard to take, even when it is presented objectively without judgment or prejudice in the nicest possible manner. And that's really just human nature. Let me show you an example from one of my first contributions to Twisted.

Speaker 2: Where I was working on implementating in in on implementing some endpoint APIs and there was just one thing that kept showing up on my code review repeatedly white space because I was getting the same feedback over and over I realized that maybe I'm making a systematic mistake Maybe the answer to this is not me going and fixing white space. Maybe I need a systematic solution for this. So I dug around, I asked the experts, and figured that it is possible to configure your text generator to take care of the white spaces so you don't have to bother And this review shaped the way for my future system setups as well. Now every time I set up a new system, the first thing I do is to configure my text editor to automate as much code cleanup as possible.

Speaker 2: And I rarely saw a review comment about white space again for that project or any other. So embrace failures. It is easier said than done. I know I am Still pleasantly surprised that everyone in the Twisted and Python community associates me with all of the things that I've built and not with my white white space mistakes But what's more important is that you learn from the mistakes and don't fail on the same thing repeatedly. Rather than being embarrassed by them, consider them to be context around your thought process and document them intensively. When you look back, I know documenting like mistakes is

Speaker 2: It it is not easy. When you look back, surely there'll be cases where you'll go, hey, that was some complete nonsense I wrote. What was wrong with me? There might also be cases of, well, that approach led me nowhere, or it makes the system fail. Let's not repeat it. Or you might say, oh, that's why I did it. It makes sense. That context might help in fixing broken bytes later. So that's a lot of things for contributors. Uh my doc is not not just for them. I also have some things to say to potential Goldra viewers and my maintenance friends here. So hello. When you communicate, are you clear and effective to understand?

Speaker 2: Are your reviews non-personal and educational? The uh well, when I say non-personal, that is for the review on the code itself, the only personal part of the review should be the part where you thank people for their time and effort, and that part should definitely exist. People have their quirks. I, for example, like desktop strings, to the extent where I tend to not look at the accompanying code itself until the batch has unit test. with doc strings that tells me exactly what's happening. This may or may not always be important for all projects, but it matters to me. So when I build and develop a library When I maintain a library, I will know that doc strings are important to me and I will look likely look for them in any pull request.

Speaker 2: That sounds fair if I just document that in the contributing guidelines Because I'm the maintainer and I have clearly communicated a prerequisite for making changes to my project. It is not enough to just document it though, you have to also make it visible. Twisted, for example, had like five contributing document documents that uh were developed over the years. And we tried for a long time to m make build one single document out of them. I think I wrote the sixth one that was aimed at collaborating all five and that still hasn't been completed. So we have six Contributing documentation. That's not really visible. And

Speaker 2: that's also not the right way to go about uh telling your contributors what you care about. And still, even if you do that, even if you document it visibly, people might miss things. People might overlook some seemingly obvious points. That does not make them blind. Please don't be unkind about it. They do not deserve unkindness for this I was going around and asking my friends about their worst code review experiences. Ian, uh who maintains a bunch of open source libraries, including requests said that one of the reviews he regrets the most is from the requests library. In a pull request there was one point where instead of describing why something was a bad idea, he just wrote this

Speaker 2: Below the code. And the contributor politely asked for more context behind all the notes, and he explained. The sa the this line was fixed and the pull request was merged eventually, but Ian said that things could have gone so much better and smoother had he objectively described the point the first time itself. It might it might not feel like it's important while you're doing a code review if you've seen the same thing being done over and over again, but it's still worth the effort This reminded me of uh the time when I was making a logical error in my code.

Speaker 2: Which was not so obvious to me. I think it was about how I was organizing my if I'll statements and my reviewer marked the change provided a self-contained example to help me understand the error that I was doing and described in detailed why this was important. And I never made the same mistake again It is important to treat people as reasonable human beings with whom you can have a logical discussion. Make your case, described by the change you're suggesting, is necessary. On the site, there's a review that I once got for a super complicated complicated implement

Speaker 2: implementation that I was doing for Twisted. I'd been working on this for weeks and when I submitted it for review again after a lot of attempts, um this is what I got. It started with a thank you That's nice. It says that things looked good. That's nicer. It then mentions that my my branch needs a lot of changes. Well that's okay, because I'm already happy from the first two sentences now to actually care about what the next line says really And it like even ends with a smiley like who knew expert programmers use smileys. It also reassures me that I'm going in the right direction.

Speaker 2: So I I think this was a great code review. I think that even though the changes took me days to complete and it was a while before this thing was merged I feel like the kind of happiness this uh review gave me was was really nice and rarely seen So work with your contributors, be encouraging, thank them for their time, and tell them early if they're taking the right or wrong approach so they know when to abandon a particular track I have said a lot of things in the last 20 or so minutes to both contributors and maintainers. And I know these things because I was a contributor for a long time before putting on my maintener hat. And that new hat taught me a lot of things and brought with it a massive change in perspective.

Speaker 2: The most important one being that you you you're always qualified. For many years I did not review a lot of twisted code. I I contributed a lot. I built a lot of things. I responded and participated in discussions, but I rarely reviewed actual code from other people. The reason being that the people that I was working with were excellent expert programmers and their reviews were thorough, educational, and just so awesome. I thought that that was a prerequisite for reviewing code. And I did not feel I was knowledgeable enough to do that. What I didn't know was that good code reviews also come with practice. Being an expert isn't a prerequisite, it is a result of continuous practice.

Speaker 2: And that's why there is a community to work with, right? So once again, contributors, you will need to work with the maintainers and meet them halfway. And my maintener friends here You will have to be the contributors halfway, be nice, kind and respectful. Thank you

Speaker 3: Thank you so much, Ashwini. That was amazing. Uh we have time for one question.

Speaker 4: Hey, fantastic talk. Um I'm interested in getting from the perspective of project maintainers and I suppose also from contributors, uh what's your opinion about automated tools for doing some of these review processes? You know, things like the white space trailing and even some of the style guide stuff that Trey was talking about in the previous talk can be picked up automated and you can write little programs that'll just jump in automatically and say, oh by the way, you've got traveling one space. Oh by the way, this thing is small than 80 characters, or whatever the problem happens to be Um that's incredibly impersonal. It's completely robotic. It's a robot. Do you think that's a good approach or a bad approach for Project to Adult?

Speaker 2: I thank you for your question. I definitely think that's a really good approach. Uh this whole like all through this talk, the point that I've been trying to convey for reviewers was that your review needs to be non-personal. No one takes what a robot says personally. So I think If the more robots in your GoDrive you process, the better it is, because the more non-firstal your GoDrive is. So

Speaker 3: All right, thanks so much.