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:
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:
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.
If you want to find out more about how Waydev can help you, schedule a demo.
Ready to improve your teams' performance?