PatternsAndPractices

For a while now I have been advocating that junior engineers review every code submission, I mean all of them (of course they should not necessarily have the ability to approve a code review). More specifically though, I am adopting the position that for every line of code you write, you should ensure that you read about 50, the more senior you get the less that ratio may actually need to be, although I would suggest if you value your craft you will ensure that number is still relatively high.

My reasoning is that great writers, of any kind, prose for example, are not honing their skills by writing more, it is usually by absorbing and internalizing brilliant examples of written work created by others. I want to encourage developers to spend more time reading code, and the most obvious and linear place to do that are with code reviews in your own organization or schools. Today we have a plethora of amazing locations that encourage us to read code in a broader sense, sites like Stack Overflow, CodePlex, MSDN, and Google Code.

James Baldwin, an American novelist, essayist, and social critic once wrote, "You think your pain and your heartbreak are unprecedented in the history of the world, but then you read". It is a little more dramatic than my point requires, but appropriate non the less, we assume we are the first to tackle difficult problems because we have not taken the time to really look at our work from a historical perspective. How have your progenitors tackled these problems? How is that appropriate to your current problem? We are standing on the shoulders of giants and the shame for our industry is that we do not adequately value that rich history in the way that other scientific and engineering disciplines tend to.

To be clear I am not advocating blindly copying code from whatever Google search you just conducted, we need to push to understand our code beyond the convenient layers of abstraction by finding great examples to learn from and build upon. Our industry has overused the excuse that it is relatively new and so historical context means less, because even given our adolescence we have somehow reinvented our solutions too many times for it to be considered the natural progression and evolution of our discipline.

Do some reading, learn about patterns and practices, you may find that a better way to solve your problem already exists.