A printed copy of this article has appeared in SDN Magazine #102, in Dutch.

The Kick Ass Development Series

As a software developer you’re constantly familiarizing yourself with tools and techniques. The skill to learn quickly and effectively is perhaps the most important one to own as a developer. The most important tool that you use is your brain. But do you use this to optimal effect? In the Kick Ass Development Series we will provide you tips and insights, using models and practice-based examples, to ‘refactor’ your brain for optimal result. In the first part we will mostly discuss learning methods and learning aids. Further on in the series we will focus on fields of knowledge specifically of interest to software developers. In addition we will advise you how to utilize your brain to the full in the solving of problems.

Kick Ass development – part 1 : developing a developer

The half-life time of (mostly technological) knowledge reduces faster than ever. Technological developments and globalization ensure you need to do a lot just ‘to keep up’.
As a novice developer you may have produced a few hundred lines of code during your degree. As a beginner you are put to work in a software development project where the complexity is often a multitude of what you were exposed to during your studies. Along the way you find out just how complex software development really is. Your knowledge and expertise often fall short when choosing a sound solution for a problem. You might think: “Wisdom comes with age, and when I gain more experience my skills will automatically improve.” This is true, but only to a certain extend.
Experience is useful, but it does not have the straight correlation with quality that people often expect. Someone can have years of experience in VB without caring for the basic principles of Object Orientation. When someone has 5 years of experience handling a certain technique does that make him or her an expert? Or does that only indicate 5 times one year the same experience on different projects?
Maybe you have worked with someone who performs the most complex tasks with great ease, whistling along while doing them, so to speak. When you watch him or her work it all seems so easy. In no time these sorts of people add new languages and frameworks to their already impressive toolkits. Perhaps you believe these characters have more talent than you do and that you will never be able to reach their standard. In most cases you are wrong.

A total lack of talent might make it hard to become truly good in a certain field. However, in general not talent but focus, practice and commitment are the ruling factors in the development of expertise. Mozart at the age of 4 was already a musical child prodigy, but not until 13 years later did he conduct music of world class.
In his book ‘Talent is overrated’ Geoff Colvin argues that to become a true expert, in any field, will take 10 years. Talent is not a condition for being among the best. Hard work is. Perseverance is. And patience is, too.

The right combination of hard and effective labour can yield huge improvements. Researchers claim the most productive developers to be many times more productive than the least productive ones. Cautious estimations mention factor 5, while there is also a factor 28 indicated (see e.g. ‘Code complete’ by McConnel and ‘Facts and Fallacies of Software Engineering’ by Glass). Picture this: a developer producing 28 web applications in the same timeframe another software developer will deliver one! For your employer enough reason to cherish these thoroughbreds – though they probably will not pay them 28 times as much.

Learning styles and personalities

Most learning theories acknowledge people use different learning styles. You can for example distinguish visual and auditory learning styles. Some people prefer to learn by listening to podcasts, while others really need a visual component.
In the book ‘Experiential Learning: Experience As The Source Of Learning And Development’ (1984) Kolb describes a cyclical model of learning.

When you go through something (concrete experience) it is important to think through the experience and to reflect on what that experience signifies (reflective observation). Subsequently you need to integrate these loose thoughts into a theory (abstract conceptualism). You can then contemplate how at a next occurrence with similar events you can implement this theory. The implementation of these new insights (active experimentation) will lead to new experiences.
Unconsciously in this way you will already be learning and automatically proceed through the 4 stages. It helps to be actively aware of this cycle so you can optimize the process as it is strongly dependant on the person on which of the stages of the cycle emphasis is put. Kolb discerns the following 4 learning styles.

In the software industry you are often dependent on self study. It helps to know what your default learning style is. For example if you are a thinker you might read a book on design patterns from A to Z. You have not yet experienced the real problems these patterns can solve, and if you don’t experiment actively you will find it hard to memorise what you learned in theory. In that case you could do with a hands-on workshop to gain concrete experience.

Or imagine you need to learn a new framework. You could read books on the matter, or work through the complete API. Another option is to apply the framework straight away in a project and to learn along the way what the advantages and disadvantages are (with all the possible refactoring as a result). An alltogether different option is to write automated tests against the framework. Write tests until all desired functionality is tested and you grasp the essence. What you end up with is executable documentation, more compact and reliable than any manual. When a new version of the framework is released you can see by the failing tests immediately which functionality needs refactoring. And while you write and perform tests you effectively gain experience with using the framework but without contaminating the project code. And you go through each of the stages of Kolb’s model.

Know your own learning style and make sure you pay sufficient attention to the stages of the style that get less of a chance.

Switch your brain to turbo mode.

When the X286 PC came out it was a lot faster than all previous IBM machines. This new computer type came with a turbo switch that sped up the computer. Many people wondered why the switch was there –why not always just set the switch to ‘on’? (Certain software was only suitable for slow PC’s and therefore only functioned when the switch was set to ‘off’.) Many users didn’t know the purpose of the switch and for that reason the switch was often set to ‘off’, making the machine slower and not performing to an optimal level.
Our brain has different levels of activity, and different situations or approaches switch it into a comparable turbo mode.In illustration of the above we give you this true story.

“Some years ago an acquaintance adapted software for a manufactoring system, loaded the code to the PLC (programmable logic controller), activated the new program and discovered to his alarm that almost instantly the whole factory hall around him became quiet as a mouse. All factory noises of pumps, motors en spinners were suddenly extinguished. The silence did not last long. In no time all operators came running into the control room and asked what he had done. What had happened: in one of the codes he had made a reference to a label that did not exist. A ‘goto’ to an unidentifiable place. The instruction had crashed the whole PLC and all the outputs connected to the PLC fell back to their safety mode. The cleansing of all tubes and machines and the loss of productivity that were caused by this error cost a lot of time and money.”

You can imagine an event like this will switch your brain to turbo mode: you’ll not make the same mistake ever again.

This is an extreme example but all learning moments have more of an impact when they contain an emotional component. You remember better when something is surprising or challenging. You don’t remember for very long how you walked in the street and nothing happened. You perceive many things when being outside walking but you don’t store all these things. The storage capacity of your brain is limited and because of that you are very well equipped to ignore things that don’t matter. Something has to happen, something that goes against what your brain is expecting, to make sure that what happened gets stored and remembered.
Suppose you want to master a new programming language, but you don’t work with it (yet) on a daily basis. In the evening hours at your garret once again you bend over the newly acquired book. Often the matter is dry, and that makes it hard to keep your attention focused. How can you can convince your brain, that is so good at ignoring futile information, that the subject matter in the book is significant?

First of all you can make some changes to the environment you are learning in: instead of withering away at your garret you can also try to form a study group with friends or colleagues. As a member of a developer community you can choose from many events such as Special Interest Group (SIG) meetings, code camps and coding dojos. These events offer you the possibility to experiment with new techniques, together with others. This often means you have to get out of your comfort zone a bit more, and sometimes that can be a bit tough. When you take this step though you will discover how you learn much more in this kind of setting than on your own. The situation will trigger all kind of emotions. Maybe you need to overcome your shyness, but often it is fun, sometimes challenging, but in all cases more emotion is involved. And – with your brain in turbo mode – you will remember things better.

Not all learning will be shared with others, so what can you do to shift brain to the turbo mode when you’re on your own?

Traditional Study

Traditional study such as academic- or certifying courses will deliver mostly declarative knowledge (‘codified knowledge’): knowing that something is what it is, also known as factual knowledge. To transpose this to procedural knowledge (‘tacit knowledge’) requires experience. To speak in programming terms: the experience functions as the compiler that transposes declarative knowledge into procedural. As shown in Kolb’s method only abstract conceptualism is usually not very effective. There are however some designated features effective learning material will comply to.

• Good books are compressed learning experiences. They show you the prime areas of attention and place knowledge in a relevant context.
• Good books will also demonstrate how knowledge can be applied in practical situations. Key is to transfer procedural knowledge into basic principles.
• Good books will show patterns you are already acquainted with through experience but have not consciously recognised or worded.
Someone can read tens of books on design patterns without ever having applied them in practice. All pattern knowledge of such a person is then declarative. It is plausible to believe that this person with all his declarative knowledge will be a teacher for someone who wants to improve his/her design pattern knowledge. Practice problems usually go way beyond a ‘student registration system’ or an ‘ATM’, making it quite probable such a teacher will fail.
With traditional study methods the procedural knowledge of the expert will be transposed to declarative knowledge (books/learning courses). Subsequently the pupil needs to transpose this declarative knowledge into procedural knowledge. In the figure below this is being indicated by the red arrows.

Michael Polanyi says about procedural knowledge: “We know more than we can tell” – for an expert it is often hard to transpose the procedural knowledge they have into a declarative form.
A characteristic example is the development of a bread baking machine for domestic use by Matsushita. At the initial design of this machine a satisfactory result failed. At the end of their wits they had one of their engineers working alongside a master baker to find out the secrets of the preparation process. The engineer cribbed the art of the kneading (the doe was being turned and pulled) and along the way he wrote down his findings. The bread baker could not word his skill very well and someone was needed to crib so the findings could be transposed into a declarative form.

The process of the transposing of declarative knowledge into procedural knowledge is laborious: first experience needs to be gained (and mistakes to be made) before knowledge can be applied appropriately. For these kinds of study tracks the direct interaction between pupil and student (author) often is minimal, the student not using one of the key talents of his brain: the capability to learn by mimicry.

Monkey see, monkey do!

Man has evolved evolutionary many centuries by learning by mimicry and because of this our brain is quite capable to learn this way. Only since we use script (and mostly since the invention of the art of printing) have we largely transferred to the study of abstract, declarative knowledge. The method we are best equipped for is often being neglected with these sorts of learning tracks; the 1 to 1 learning moments where the expert can be observed in action are usually very scarce.

In situations where it does happen direct transfer of procedural knowledge can take place. In fig. 2 the path is being indicated by the green arrow. The figure clarifies parts of the knowledge through the red arrows is much more elaborate, lengthy and labour-intensive than sharing knowledge offhand by socialising. Mathieu Weggeman especially pleads for sharing quickly outdated information, socializing in a ‘master-pupil’ relationship in his book ‘Leidinggeven aan professionals? Niet doen!’. For basic knowledge, that as a rule has lower turnover rate, the long way can be valuable.

Techniques such as pair programming and the carrying out of code reviews can increase the number of these kinds of transfer moments. Also the movement that looks at software engineering as a craft (‘Software Craftsmanship’), promotes this approach by forming the master-pupil working relation. The knowledge gap can’t be too wide, avoiding the pupil not knowing what the master is doing. ‘Learn to walk before you can run.’

For every sort of learning experience counts that it only leads to true mastership when gained knowledge can be put into practise. Ideally as a software developer you will find work in your field of interest. If this is not the case consider gaining experience by participating in a hobby project and/or an open source project to compile your declarative knowledge into procedural knowledge. You will learn fastest by working together with fellow developers who are just ahead of you. Or as Robert Fripp, a well known jazz-guitarist, words his learning advice: ‘Make sure you’re the worst player in the band.’ So, when possible, make sure you work together with people who are better than you are.

When for example you drive a new route in your car and you are not familiar with the area you will trust your navigation system or road map blindly. But when you know the area and the traffic flow rate you will deviate from the suggested route at certain junctions. The get the optimal result (not the shortest but fastest route) you look at the context.

When you already prevail several programming languages the overview of the syntax and the most important features of a new language are sufficient to learn a new language. The experience with other programming languages provides you enough context to quickly gain understanding in the new language. At learning your first programming language you will have to learn more low-level to eventually – by experience and experimentation – reach to a high-level understanding

Finally

For developers it is of key importance to keep on learning. Techniques come and go, and the C# of today is the COBOL of tomorrow. It pays therefore to learn how to learn. Metacognition and the Kolb learning styles provide tools for optimizing the learning process. Learning by mimicry is relatively easy for people, so see to it you work with people with more expertise than you have. Take in account the ten year principle: often you have to practise a profession many years before you are an expert. Talent is of minor significance – practice, dedication and pleasure are much more important.

About the authors

Freek Leemhuis works since 1996 with the Microsoft development platform. Since 2006 he works as a consultant for Logica, performing the roles of Developer and Software Architect. He has a keen interest in subjects such as OO, Domain Driven Design, Agile techniques and quality of software. In his free time he looks for like minded people through Devnology http://Devnology.nl to exchange knowledge and experience. Follow him on http://freekleemhuis.com Freek is also a husband, father, dog walker and guitar player.

Maarten Metz works as a software developer for the Java Competence at Logica. He has 10 years of experience in bit-, byte-, procedural- and object orientated environments. His interests are software design, construction, quality, testing and the psychology of software engineering. He reads many books and articles on the above and one day hopes to create the software equivalent of Pink Floyd’s Dark side of the moon, Monet’s Cathedral of Rouen and Tolstoy’s Anna Karenina.

English translation by Helen Potters Text and Translation – www.helenpotters.com