There’s an old saying, “Practice makes perfect”. And, as you’re probably aware if you read this blog and you understand the InnerWorkings’ philosophy, the mantra we repeat over and over is “Practice, practice, practice”. So you’d probably think that we would automatically endorse that old saying.

But does practice always make perfect?

Not necessarily! Obviously, the more you practice something, the easier it will be for you to do. With constant practice, some skills become almost reflexive. But imagine that you learned the skill incorrectly in the first place. Or that, during your practice, bad habits crept in and then became ingrained through repetition. When this happens, practice certainly doesn’t make perfect.

Let’s say you’re learning how to play golf, and you find it difficult to drive the ball the required distance. You modify your swing, and then you practice and practice. Eventually you start to consistently achieve the required distance. But somewhere along the way you acquired some bad habits and now you find it difficult to consistently get the direction right. You’ve solved one problem but you’re stuck with another. Not so good!

Ideally you’d have had a golf pro on hand to periodically review your practice, give you feedback, and correct any faults creeping into your swing and grip. This would have prevented you from developing bad habits which are so hard to get rid of later.

One of the great things about programming is its flexibility. You can achieve a desired solution by writing code in many different ways. A competent programmer will write code in a certain way, while a really excellent programmer will write the code differently. Conversely, a poor programmer can still achieve the desired solution but may do so by writing inefficient, bug-ridden code that’s difficult to understand and maintain.

Not everyone can be a brilliant programmer. But one of the most important ways you can maximize your potential as a programmer is by adhering to good programming practices and avoiding bad ones.

The InnerWorkings developers are always careful to use good programming practices. For example, they make heavy use of refactoring, which improves and simplifies the code design without changing its functionality. This makes it easier for the learner to understand the code in the challenge, and encourages the writing of clean, straightforward code to meet the challenge’s requirements. Another example of good practice is the use of naming conventions that adhere closely to industry standards and Microsoft guidelines.

These are just two simple examples of good programming practices. We use many others to ensure that the code in InnerWorkings challenges is – as far as is practicable - readable, maintainable, reusable, modular, testable, and so on.

What’s more, hints are given in some challenges – when used, they often point to the better programming practice among several possible solutions.

This exposure to good programming practices means that when a learner successfully completes an InnerWorkings challenge, they won’t just have grasped the key learning objective of that challenge. They’ll also be more likely to use good programming habits when putting what they’ve learned into practice.

Yet another benefit of the InnerWorkings system!

Add this post to: