I stumbled (thanks John!) on this post about the right way to review code. This is a key skill for working in a team and one that is underappreciated. A solid code review makes sure the code changes can be understood.
If code can’t be understood, it can’t be changed. If code can’t be changed, business processes can’t be changed (code is, after all, just business process made digital). If business processes can’t be changed, the organization can’t adapt to new opportunities or threats. Have you ever seen a tree grow around a fence? The fence constrains the tree, but the tree keeps trying its best to work around the fence. Neither end up serving their inner purposes. That’s what I think of when I see code that can’t be changed.
Here is a brief excerpt to give you a flavor of the post.
Your goal, then, is clear: question, probe, analyze, poke, and prod to make sure that you, the reviewer, could support the code presented to you for review. From an overall perspective, there are several questions to keep in mind as you begin your task…
It seems like this is a series, where the author discusses code reviews from a variety of different perspectives. Recommended.
I was talking to a friend the other day about startup vs big company life and he used an analogy so good I’m going to steal it (and expand upon it).
Based on this
This article on
Sometimes you have a list of locations in a Google spreadsheet and want to visualize where the locations using a map. Google Fusion tables lets you do just that, for free, with no technical expertise needed.
I have written before about
If you aren’t an avid follower of
A friend recently shared a letter from Hunter S. Thompson on 