At my current place of employment we are nearing a release. Personally, I don't feel like I'm as far along as I'd like to be, but I've still grown as a developer. There is one aspect that I wanted to talk about that I've found very interesting. It's a process known as code review.

I would highly recommend reading the link referenced above (as well as other posts on peer review, etc. from coding horror). This process can go by different names: code review, peer review, programmer quality assurance (PQA), and probably a few others. I also think it's one of the best tools in the whole toolkit for developers. Being new to the process, I find it relatively difficult to do.

Code review is a skill that takes a lot of time and practice to become proficient, and it takes even longer to master it. There are many things you can do to improve though. Just doing it is one way, but you can also find books that discuss styles and other conventions.

At first you're more likely going to be the one having your code reviewed. It's a great way to learn and cement style and convention into your head. More experienced developers may have better ideas for algorithms or ideas for performance boosts. 

If you are a student or a lone wolf, you may never have had this experience. Working with production code is very different than stuff learned in a classroom. Code reviewers will quickly tell you if your code is hard/impossible to follow. 

Things you may never have thought as hard about before are put front-and-center. How much thought do you put into naming conventions? Do you use nondescript variable names like a, b, c? That won't fly with code review. It may pass in college or high school, but not with production code. Even if you are a loner, naming conventions are critical. 

They can also find things like edge cases you may have missed. You'd be surprised how things like this can lead to crashes. Oftentimes they will try to crash your program. This is good because you want it found before it reaches your audience. 

You also cannot let your ego get in the way. We get it, you're god's gift to coding. Hate to break it to you, but you're not. If that's the attitude you take towards this, give up now because your growth as a developer is done. They aren't trying to be mean. In a way, if they pass your code, that's a mark of their work as well. It's just making sure your code is the best it can be at that time. 

This won't get rid of mistakes, but it will catch a lot. It should be a key part of your development. Even 10 year experts make mistakes. I've seen and caught them myself. It's all part of shipping the best product possible. It's a point of pride, and  developers, reviewers, and testers should all take pride in the final product. 

If you don't have someone to review your code, find someone. It can be a friend or another developer far away. It should be someone that isn't afraid to be blunt/confrontational since you may have to butt horns a little.  It's generally worth it when you see the final product as well as your growth as a developer/reviewer. 

Here's a funny but true comic to end this on (may have been in coding horror post):

These are thought and said out loud