Back to School

What do you love most about being a programmer? For me it's knowing that everyday there's going to be something different to do and find out - a new bug to track down and fix; some design work that needs thinking about; a meeting to discuss what the product requirements are; investigating the latest and greatest technology; reading books and newsgroups for new ideas; and sitting down and writing code to solve these problems.

What I dislike is when things get samey and repetitive - especially when the root cause of this repetition is known about but somehow never gets improved.

This struck me recently as I was reading Allan Kelly's book Changing Software Development: Learning to become Agile [ Kelly ] , and the first few chapters are all about learning and building up knowledge. Not just how people learn, but also how the organisations we are in learn, and how the software we produce reflects this.

Indeed, a program can be considered as encoded knowledge. The understanding of the requirements by people such as the customer, product manager, and marketing, are used by developers to come up with a solution that addresses those requirements and teaches the computer makes life better for the final end user. This information is channeled through processes and eventually produce a product. That product reflects not only the information about the requirements, but also the processes used to create the final code.

This applies very much over time, which can result in what I only half-jokingly call 'Software Archeology' - when you try to understand some odd piece of code you can gain useful insights if you think of it as accumulated layers of historical code changes made by past actors each with their own motives. Sometimes an appreciation of why something was done in an initially unexpected way becomes much clearer if you can work out what problem they were trying to solve - perhaps what you are seeing is a perfectly valid work round for an awkward problem in a tight deadline situation, both of which are long gone. A classic example would be a kludgy expression to avoid a compiler bug in a long-gone version. So instead of seeing some odd looking code and thinking 'Which idiot wrote this?' it's better to think 'What odd constraints forced them to do it like that?', which is not only a more realistic way of looking at code, but also avoids a blame culture.

But the knowledge is not just in the code - it's also written in the obvious documents that are generated - this knowledge is explicit - but less well appreciated is in the minds of people and the processes that have grown around such knowledge. This knowledge is known as tacit - implied and not consciously thought about (or if you will excuse the Rumsfeldian term, it's an 'Unknown Known'). This is one reason that Documentation and Code Handovers work so badly, whether it's for something that has been outsourced, handing over from one team to another, or during the final few weeks before leaving a job. Writing documents just captures the Known Knowns, or at least the ones you remember to write down (and it might not even be read), and a huge amount of vital knowledge can be lost.

Tacit knowledge is a remarkably useful resource. For example some programmers will get to know an area of code in great detail - not so much the technical aspects, but at a deep 'gut feel' level. It might show itself in the form of a rapid evaluation of a bug symptom into a likely area of code to investigate ('Oh, the Foobaz handling has always been a bit fragile - I'd start looking there'), or a deep understanding of why some code is tricky ('Even though this area is complex, it's because it's having to deal with complex and contradictory requirements - a big rewrite won't improve things much as it will still have to reflect that complexity'). Sadly such tacit knowledge can be easily overlooked, partly because people don't realise it's there, partly because it's harder to justify hard decisions based on 'gut instincts', and partly because the people who have most first-hand experience of a system (and thus have most tacit knowledge of it) are often the people least likely to be making major decisions about it's future. (The pattern Architect Always Codes is a way of avoiding this - keeping them in touch with their own designs helps them keep their knowledge of how it really works up to date.)

It is not hard to learn more. What is hard is to unlearn when you discover yourself wrong.
- Martin H. Fischer

If we only learnt from our immediate work environment then we'd be in danger of staying in a rut, falling into groupthink problems ('We do it this way because we've always done it this way'), or just failing to take on board new ideas and new observations. One way is to keep in touch with people in similar situations (and a few wildly different ones), and exchange anecdotes, experiences, and techniques. For example, I read quite a few software and management books, programming newsgroups and mailing lists, a few blogs, and of course Overload and CVu.

Plus of course there are conferences and smaller get-togethers, where on top of the obvious value of the presentations and sessions, the informal chats in the bar can be amazing learning experiences and huge eye openers - they might not tell you a solution, but it might just make you think and realise you have a problem in the first place.

And learning opportunities don't have to be from software specific sources. There was an interesting thread on accu-general recently asking what non-fiction books would you recommend, things that were 'Influential classics, non-fiction, books about people's original ideas. Ideas that changed the world. Great thinkers, who influenced the way we think, with what they wrote. Politics, philosophy, science, and to a lesser extent, economics, history, psychology.' (Thanks to Thaddaeus Frogley for starting the thread)

Here I reproduce some of the ones I thought were of most interest (apologies to those I left out):

• How to Read a Book , by Doren and Adler (a cheat as it has a reading list itself)
• The Republic , by Plato
• On the Origin of Species , by Darwin
• Lateral Thinking by Edward de Bono
• The Prince , by Machiavelli
• Predictably Irrational , by Dan Ariely
• Godel, Escher, Bach: An Eternal Golden Braid , by Douglas Hofstadter
• Relativity: The Special and General Theory , by Einstein
• The Design of Everyday Things , by Donald Norman
• The Timeless Way of Building , by Christopher Alexander
• How Buildings Learn , by Stewart Brand
• The Earth: an intimate history , by Richard Fortey
• The Great Crash, 1929 , by Galbraith
• The Making of the Atomic Bomb , by Richard Rhodes
• The Soul of a New Machine , Tracy Kidder
• Seven Habits of Highly Effective People , by Stephen Covey
• The Science of Cooking , by Peter Barham

and, intriguingly:

• Principles of Helicopter Flight , by Jean-Pierre Harrison

Interestingly enough, while none of the above are directly about software, several have strongly influenced relevant ideas, in particular Alexander's works led to the patterns movement (and in turn their need to collaborate on pattern writing led to the invention of the Wiki); Brand's ideas are about system design and ongoing maintenance; and Norman's ideas apply to UI design. We can learn from many sources.

Some people will never learn anything, for this reason, because they understand everything too soon.
- Alexander Pope

Sometimes though, people just doesn't want to learn. A depressing story was related to my by a friend who I've been trying to persuade to come to the ACCU Conference. He was very keen, but apparently his management turned him down with the excuse that he was 'senior enough to just need books', which I thought missed the point of conferences rather spectacularly. Plus, if there's one thing I've learnt over the years, is that the 'experts' who write the books are the first ones to admit the gaps in their knowledge, but want to find out - and will write a book about it.

I wonder how many other organisations and people have such an attitude to learning? Many of the developers and companies I know are self-selecting in that regard - I know them via communities of people who do want to learn, so all I see are the 'good' ones. But I don't know of all the other communities, and ultimately if people don't want to learn and join such groups then I won't hear about them at all.

This is why there's a common interview question along the lines of 'what was the last technical book you read?', or 'how do you keep up to date with new innovations?' The answers can give some insight into how much that person approaches their work (caveat: as with all such open interview questions there are no right or wrong answers, just extra information that can be put together to form a fuller picture of that candidate, so an informed judgement of their suitability for the role can be made.)

And the questions work the other way too - if interviewing how would you answer 'How do you help developers improve?'

References

[Kelly] http://eu.wiley.com/WileyCDA/WileyTitle/productCd-047051504X.html