On code reviews and being a programmer
Dec. 7th, 2015 01:51 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
deborahI have finally started identifying as "I have all these huge posts in draft, but I really want to boil them down into something smarter before I post them. But I have one very simple thought just occurred to me.
I have finally started identifying myself as "a programmer" and not just "a person who writes a lot of code" or "an archivist who hacks a lot." I don't think it's actually because I now have a job title of "programmer." It's because I've been doing code reviews.
My code reviews are still very junior. In many ways, I'm too trusting of the code that I read; I sometimes read it as pseudocode and so don't see errors. But I forced myself to start doing it, and I started with just asking for more comments any place where the code wasn't self-explanatory -- which is really valuable, and I should not understate that with "just."
The obvious next step from there was to ask people to clarify their coding style to make it more self-documenting. If it took me too long to figure out what was going on, then either it's a complex bit of algorithm and needs better comments, or there's a fair chance the code is not as clearly written as it could be. I will admit this is an easier task than it could be because I am almost always code reviewing Python programmers, not Perl programmers. Python programmers don't have so much of the cultural machismo attached to writing WORN (write once, read never) code. (For what it's worth, I don't think that has anything to do with structures inherent in the languages. You can write unreadable Python just fine, and Perl Best Practices-compliant code is plenty readable. It's a cultural problem.)
From asking people to clarify their coding style it was actually a surprisingly short jump to pointing out ways code could be more efficient. Once you start looking at ways the code is not written very clearly, you start noticing inefficiencies. Before you post a comment you say to yourself, "that generator is kind of hard to read, I wonder why they used it? Before I critique it maybe I should check to see if that's the best way to do this thing." And then you find it's not; it's too slow, or too memory intensive, or the like.
Of course, I need to remember to comment on the elements of the code where I do have strengths, and I need to remember that those strengths, while they are not the same as those of senior engineers, are relevant skill sets which actually need to be addressed in the product by more people. In my case, that's accessibility along with usability and user experience.
Everyone doing a code review needs to check for security and accessibility issues, and don't worry if you don't know the details. All you have to do is say things like "I see you are taking user input here; did you verify all of the security issues were resolved?" Or "I see you have added a new interaction mode to the front page; did you do an accessibility review?"
Just make sure the person for whom your code reviewing those your limitations. If you are not particularly skilled with knowing performance tuning, then you probably shouldn't be the only person code reviewing a rewrite the database ORM. If you aren't sure, talk to the developer.
You can code review for developers who are far more experienced than you! You can code review even if you aren't doing a lot of programming yourself.
So give it a try.
I have finally started identifying myself as "a programmer" and not just "a person who writes a lot of code" or "an archivist who hacks a lot." I don't think it's actually because I now have a job title of "programmer." It's because I've been doing code reviews.
My code reviews are still very junior. In many ways, I'm too trusting of the code that I read; I sometimes read it as pseudocode and so don't see errors. But I forced myself to start doing it, and I started with just asking for more comments any place where the code wasn't self-explanatory -- which is really valuable, and I should not understate that with "just."
The obvious next step from there was to ask people to clarify their coding style to make it more self-documenting. If it took me too long to figure out what was going on, then either it's a complex bit of algorithm and needs better comments, or there's a fair chance the code is not as clearly written as it could be. I will admit this is an easier task than it could be because I am almost always code reviewing Python programmers, not Perl programmers. Python programmers don't have so much of the cultural machismo attached to writing WORN (write once, read never) code. (For what it's worth, I don't think that has anything to do with structures inherent in the languages. You can write unreadable Python just fine, and Perl Best Practices-compliant code is plenty readable. It's a cultural problem.)
From asking people to clarify their coding style it was actually a surprisingly short jump to pointing out ways code could be more efficient. Once you start looking at ways the code is not written very clearly, you start noticing inefficiencies. Before you post a comment you say to yourself, "that generator is kind of hard to read, I wonder why they used it? Before I critique it maybe I should check to see if that's the best way to do this thing." And then you find it's not; it's too slow, or too memory intensive, or the like.
Of course, I need to remember to comment on the elements of the code where I do have strengths, and I need to remember that those strengths, while they are not the same as those of senior engineers, are relevant skill sets which actually need to be addressed in the product by more people. In my case, that's accessibility along with usability and user experience.
Everyone doing a code review needs to check for security and accessibility issues, and don't worry if you don't know the details. All you have to do is say things like "I see you are taking user input here; did you verify all of the security issues were resolved?" Or "I see you have added a new interaction mode to the front page; did you do an accessibility review?"
Just make sure the person for whom your code reviewing those your limitations. If you are not particularly skilled with knowing performance tuning, then you probably shouldn't be the only person code reviewing a rewrite the database ORM. If you aren't sure, talk to the developer.
You can code review for developers who are far more experienced than you! You can code review even if you aren't doing a lot of programming yourself.
So give it a try.
no subject
Date: 2015-12-08 04:33 pm (UTC)no subject
Date: 2015-12-09 12:06 pm (UTC)Let's coin a term for Official Reminder About [Thing That's Critical to You But No One Else Ever Thinks of]!
*Not because they have sustainability in the bag, to be clear, but because I'm already doing 3 jobs and don't have the mental capacity to add Sustainability Harridan. :P
no subject
Date: 2015-12-09 08:45 pm (UTC)no subject
Date: 2015-12-10 02:14 am (UTC)no subject
Date: 2016-02-28 10:49 pm (UTC)"WORN" is horrifying, but not surprising, sadly.