Jens Schauder is software developer since 1997. He loves software development for the constant challenges and constantly changing environment. A great chance to learn and teach. He is also blogger, author of various articles and speaker at conferences. Jens is a DZone MVB and is not an employee of DZone and has posted 90 posts at DZone. You can read more from them at their website. View Full User Profile

Three Types of Learning

  • submit to reddit

My kids are playing chess. And they really eager to play it even better. Therefore I’m reading books about how to teach chess. Much of the advice in the book are really not that specialized on chess but are applicable for any kind of learning and training. One of those advices is: There are three kinds of training:

Theory: Here kids learn about different patterns (yes there are patterns in chess just as there are in software development). They learn when and how to apply them. Mostly by looking at examples and analyzing them. They also learn rules, like how to properly convert a pawn into a queen if no queen is available (Hint: turning a rook upside down doesn’t work)

Practice: In this kind of training the kids get isolated problems to solve. Puzzles basically. Like Mate in one. They also do games based on chess rules, but not actually chess. Like collecting gummy bear from the chess board with knights.

Play: Starting from a friendly game against family or other club members to tournament.

I think it maps 1:1 to what you should do if you want to improve your software development skills:

Theory: Read books, read blogs, go to conferences. Learn as much as you can about design, algorithms, network protocols and so on. 90% of all developers neglect this. But since you are already reading this blog, you are probably among the other 10%

Practice: Do Katas, Dojos, spikes, tracer bullets, prototypes. Write code. But not in order to have working code in the hand but in order to learn and explore. I’m afraid 90% of those doing the theory part completely neglect this part. You should not. The first couple of times you try to use something which you have read or heard about, you probably will do it wrong. To bad if this is in a real project with time pressure and lots of money at risk.

Work: If you take care of the first two parts work will still bring some surprises. Your agile approach runs into problems because the customer doesn’t like it. Your nicely normalized schema doesn’t happen because you have to use an old existing database, used by lots of other applications, what worked nicely in the kata fails flat on its face when applied to 1 million records … So there is still a lot of stuff you can learn at work, but for this you have to think about what you are doing at work. Chess players eager to improve their skills analyze games they played in order to understand which move was good and which wasn’t. Do you do that? Do you do a personal retrospective in the evening? Thinking what you did well? What you could have done better?

I think you should.



Published at DZone with permission of Jens Schauder, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Afandi Merathi replied on Sat, 2012/03/24 - 8:26am

Interestingly, after spending much time trying to improve my chess (and just barely missing achieve a US Master rating), after I left chess earlier this year, I replaced that “hobby” with serious work on improving (1) my musical skills and (2) my software development skills. Definitely a multi-pronged approach to practice, feedback, and understanding is the way to go.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.