We used to think that the secret to getting better at anything was directly linked to the timed dedicated to practice (we’ve all heard about the 10, 000 hours that stand between us and achieving mastery in any field) but, as in turns out, it’s not how much we practice but also how we do it. According to psychologist Andres Ericsson, “deliberate practice” is what matters and makes a huge difference in achieving expert performance.
In his research paper “The Role of Deliberate Practice in the Acquisition of Expert Performance,” published in the journal Psychological Review, Ericsson looked at the habits of top performers in fields like sports, music, mathematics, and chess, and noticed an interesting pattern: they engage in focused, intense practice sessions, usually only for an hour or two at a time. Along with an intense focus, what defines deliberate practice is also a constant thirst for improvement through actively and consistently asking for feedback and incorporating it.
If the mere mention of the word “feedback” gives you the chills, you might want to read Karl E. Wiegers’ essay on why feedback (or peer reviews as he call it) is not a dirty word but a practice that signals maturity and a sincere and strong commitment towards becoming a better software engineer.
According to Wiegers, feedback mechanisms are a clear indicator of a healthy software engineering culture that creates the premises for higher productivity and better product quality.
One obvious feedback mechanism is code review, the process by which someone other than the code’s author checks a program by looking at parts of its source code. This usually happens after implementations or before, as an interruption.
Here are a few (common sense) reasons why code reviews are a good idea:
You get to brag about what an awesome job you are doing. All humans take pride on the things they do well, and programmers are no different.
To Ericsson’s point, we learn from others through feedback and some of the best software engineers got there after years of refining their skills and outputs with the support of their peers.It ensures consistency and are a great way of preventing bugs. Is a great way of increasing legibility of code fragments (fewer bugs, reusable code)? The more security requirements you have to navigate, the more useful code reviews are with spotting weaknesses and preventing pitfalls.
When deciding what to review, practices vary – you might want to review every change merged into the main branch or set a limit under which a review isn’t necessary.
For best results, put a bit of effort into preparing your code for reviews:
Make sure to complete, test and review the code yourself before submitting for review. Changes can differ in scope and size (you might be looking to get rid of a bug or add/remove a feature) and it’s up to you to decide how to split reviewable fragments – shorter ones are always easier to work with and yield better results.
Be mindful with refactoring – remember that the focus in on improving internal structure without altering external behavior. It’s common sense to clean up after oneself and even more so when coding – keep it clean and elegantly simple.
While there are many places to go to for code reviews (from colleagues or team members or companies that provide software audit services to freelancers, agencies and even programming subreddits for smaller code fragments), you decide at what stage of the project to ask for code reviews – we recommend doing it before merging the code to the mainline branch.
Another example of good practices when looking for helpful code reviews is caring about your commit message – a note that signal changes made to a code repository. Make sure it’s concise and easy to understand by anyone reviewing your code: keep it clear and short; use bullet points, asterixis, or hyphens, use hanging indents. More details on structure and examples here.
The article was published first on Waydev Git Analytics Blog