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!

However, I decided that rather than continuing with the course, I’d take a break and try to consolidate what I’d learned. I figured that the best way to do this was to meet up with some Spanish people and try to have real conversations with them. Talk. Practice.

And it’s worked out well. I started meeting and talking to Spanish people on a regular basis. And now, while I’m by no means fluent, my Spanish has improved greatly since I started this new, more active and practice-based approach.

What’s this got to do with InnerWorkings, you may ask? A lot, in fact!

Learning a language like Spanish or German has a lot in common with learning how to program. Both are complex activities. Both require a lot of dedication and hard work to achieve a reasonable degree of proficiency.

There are many aspects to learning a new language. You start off with simple phrases, like how to introduce yourself and how to describe other people and situations. Then you learn basic grammar, which involves a lot of verbs (including those tricky irregular ones). Next, it’s important to build up your vocabulary. The more words you know, the more you’ll be able to understand and express yourself.

Even with all this done, it’s still a big step to actually talk with someone in a foreign language. It’s always easier to read and write the language than it is to hold a meaningful conversation in it. And for most people, being able to hold a real conversation is the main motivation to learn a new language.

There are many resources for language learning. Grammar books teach the rules of the language, dictionaries provide vocabulary, books and movies also help. But take it from me, you will not be able to speak a language properly unless you practice regularly with a fluent speaker. It’s the difference between simply knowing about something and actually doing it.

The same situation applies to programming. You can have all the resources to hand—the latest version of Visual Studio, access to MSDN, online tutorials, great textbooks. But unless you’re getting relevant and regular on-the-job experience, it’s very difficult to ‘practice’ with a programming language or technology in a meaningful way.

This is where InnerWorkings’ unique challenge-based approach helps. The key to our approach is structured practice. We assume that you know the basics, can program competently, and can look up relevant reference sources. Where the InnerWorkings challenge makes the crucial difference is that it provides the opportunity to really practice – to put theory into practice in a realistic and supportive environment. To apply the techniques used in real-world problem solving. To write code. And to learn .NET.

If you want to learn Spanish, get talking to a fluent Spanish speaker.

And if you want to learn .NET, get coding with an InnerWorkings challenge!

There are many definitions of knowledge. One straightforward definition is “the facts and information acquired by a person through experience or education”. Another definition is “the theoretical or practical understanding of a subject”.

So knowledge is evidently a good and necessary thing in today’s world.

Skill is also regarded as a good thing. A person who’s regarded as a “skilled” operative or a “skillful” player is obviously the kind of person you’d like to have on your team.

There are many kinds of skills – academic and technical skills, communication abilities, sports prowess. The common denominator among those who possess these skills is their ability to influence and change the world around them. The politician who is a skillful communicator can win people’s votes. The inspirational football coach can motivate a team to win time after time. The skillful software developer can analyze a problem and quickly develop a solution.

But what’s the relationship between knowledge and skill?

Knowledge is like a description of the world - it’s somewhat intangible. Skill is more directly connected to the world - it enables you to change the world in a real and meaningful way.

If knowledge is a map that shows the landscape around you, then skill enables you to read the map and your surroundings, and then navigate to where you want to go.

Another difference between knowledge and skill is that while you can simply study to acquire knowledge, the only way to acquire a skill is to practice, practice, practice.

Of course the two things are not incompatible - in fact, they’re closely related. Knowledge is what you’re aware of, your understanding of how things work. In contrast, skill is your ability to use what you know to effect a real change in the outside world. Being skillful does imply a certain amount of knowledge. But the converse is not true. You can be knowledgeable about something without being skillful in that area.

I can give a personal example of this seeming paradox. I have a good knowledge of C# - I’ve read a couple of Jesse Liberty’s C# books, and sampled numerous articles and web sites devoted to C#.

But what about my C# programming skills? Well, let’s just say that I won’t be joining the InnerWorkings developer team anytime soon! My skills are those of a technical writer, and are quite different from the skills needed to program in C# or VB. I need a certain knowledge of these languages to do my job properly, but I don’t actually need the skill to program - I leave that to our very competent developers.

This confusion between knowledge and skill brings us to a basic problem in much of the technically oriented learning that’s available today - instructor-led training (ILT), e-learning, self-learning through books and videos, and so on.

In many cases, it is knowledge that’s being imparted, not skill. Much of this knowledge is good stuff – highly technical, accurate, well structured and presented. But the end result of engaging in this type of learning is simply a transfer of knowledge to the learner, without a corresponding increase in the learner’s skill level.

And it is skills that are vitally needed in today’s workplace, not simply knowledge.

Right from the beginning, InnerWorkings determined that the best way to develop real programming skills is to get people to write real code, in a realistic working environment.

Our practical coding challenges point you to relevant knowledge sources that are available on the web.

But they then provide you with an opportunity to turn that knowledge into skill by writing the code needed to solve the programming challenge.

It’s a pretty unique approach.