33 Days of Education

IT is a fast moving industry. Heinz Kabutz says that "we are in an industry with a knowledge half-life of at most 18 months. [...] Half of what you knew 18 months ago is worthless today, so you need to keep learning new things." We need to learn a lot, fast and continuously. Today even traditional companies recognise the need for professional development, also - or especially - for senior and expert level employees. (I could argue that senior tech people need more training than junior ones, because their time of dedicated learning in school or university has been longer ago, but I am digressing.) All companies I have seen, offered five days of professional training by year. (Unfortunately, not all employees take the opportunity to use this training budget, but that is another story.) A few companies have a stronger focus on self-development. For example the Swiss Zühlke Engineering offers ten days of professional training. (At least they did in the past, as confirmed by several Zühlke employees I met.)

Obviously ten days are twice as much as five, but I believe we need more. A few companies allow Research or Lab Fridays from time to time, following the idea of 20% time, made famous by Google Friday. While slack at work is focusing on innovation, the time is also available to learn. In the end, exploring new ideas is related to both. One of my clients runs a "Basteldonnerstag" once a month, which adds another ten days. sipgate runs Open Fridays every second week. So we are up to 20 or even 30 days for your professional development each year, I like that.

My Personal Development
As Code Cop I am working with my clients on different things. Some clients use technologies I have never seen before. Still my goal is to help them to improve. It could be as simple as writing unit tests with a xUnit styled testing framework - or as alien as modularising a legacy application written in an old, purely procedural language.

I learn a lot and need to learn more. I am conscious of the time I spend on learning. I think about learning methods and try different approaches, e.g. flash cards. I am still performing code katas, on my own and together with others.

2016
When reflecting about last year, I think that I could have done better. I had interesting work and got a lot of new experience, but I did not attend all training that seemed necessary and I did not visit as many conferences as I needed to visit. I worked full time and had to squeeze in the occasional learning. Out of curiosity I counted the days spent on learning last year. I was very surprised when I found 33 full days spent on professional training:

• 9 days of conference presentations. Last year I attended 5 traditional conferences, e.g. GeeCON, full of great talks and coding demos.
• 6 days of classic training like training courses or workshop days before conferences.
• 2 days of unconference sessions. Unconferences like SoCraTes are less structured than traditional conferences and enable discussion and deliberate discovery of new ideas. Usually I am hooked up with a new topic after attending.
• 9 days of personal workshops. These include Journeyman Visits, Code Camps and meeting with other people to work on a research topic for a whole day.
• 2 Coderetreats. While some unconferences include Saturdays, Coderetreat happens on Saturday by design. I am attending them rarely because usually I am facilitating them.
• approximately 5 days of pair programming practise. I remember 18 sessions either remote pair programming or attending Coding Dojos. Usual sessions last 2 to 2.5 hours.

This list does not include books I read, user group meetups, side projects or writing blog posts - all these activities are an essential part of learning, too.

After seeing these numbers, I am impressed with myself. ;-) 33 days are a lot, and one third of them was spent on evenings and weekends.

Previous Years
So 2016 was a good year for my personal learning. How about the previous years?


2015, shown in the orange bars, is pretty similar to last year (blue bars). Surprisingly I spent 33 days on professional development, too: one workshop less and no Coderetreats, instead more remote pairing sessions. In 2014, shown in yellow bars, I fell a little short. I did not attend any training or unconferences and did fewer workshops. Becoming independent enabled me to visit (paid) training and I just discovered the opportunity of unconferences and workshops back then. Still I had more than twice as many pairing sessions, summing up to 27 days of professional development.

Conclusion
While I felt bad about my personal learning earlier, these numbers satisfy me. 33 days sounds much and I am starting to pride myself on them. I have no way to compare, I know people who attend at least one conference each month, which already sums up to 24 days at least. So maybe 33 days are not that many after all. So I might/ should/ could do more (MOAR PROFESSIONAL DEVELOPMENT!!1!), but I am pretty sure that I will not. I did not aim for 33 days in the past and I will not do so now. I am very busy, both with my work and my major ongoing side project. On the other hand, this year was full of opportunities and I already spent 12 days professional training in the first quarter.

Followup Global Day of Coderetreat 2016

This is an email I sent to all the participants of the recent Global Day of Coderetreat, Vienna. Because it applies to all participants worldwide, I repost it here.

Looking back at the Global Day of Coderetreat 2016
It is a month since you participated in the Global Day of Coderetreat. Let us look back for a moment. At the end of the day, during the final retrospective, you answered the questions

• What you learned at that day?
• What surprised you during that day?
• What you planned to do differently?

Some of you learned "new programming concepts" and that "it can be done in a simpler way". (These quotes were things you wrote on the Post-its on the picture on the right.) Others found new ways "how to split the problem". Several people discovered that pair programming was productive. You were surprised that there were so "many different ways to do the same functionality". But most important you decided to do things differently in the future. Here are some things that you wanted to do:

• "Try TDD at work!"
• "Learn more shortcuts!"
• "Aim for simpler code!"
• "Code more!"

These were just a few examples for the 21 things you wanted to do differently. Try to remember your personal plan. What did you write on your Post-it? In the last month, did you apply the things you learned? Did you do the thing you wanted to do differently? Did it work for you? We fall back into old patterns easily - changing habits is hard. If your first attempt failed, I encourage you to try again. Do not give up!

A box of things to take from the Coderetreat
At the end of the Coderetreat the facilitators, Houssam and I, talked about things you might want to try after the event. Houssam called it the "Box of things to take home".

• Code Katas. Code Katas are exercises like the Game of Life. You can find many suitable exercises at codingdojo.org or codekata.com. If you like to crack some math problems I recommend Project Euler. It is a lot of fun!
  
• Coding Dojo. A Coding Dojo is an event like a Coderetreat, just shorter. In Vienna there is the Coding Dojo Vienna. If you need for more practise this is the place to go. The dojo happens once a month. To get notified about upcoming events register at Softwerkskammer Gruppe Wien or follow #CodingDojoVie on Twitter. More information about Coding Dojo can be found in Emily Bache's excellent book.
  
• Pair Programming. You can run your own practise session in a coffee shop or McDonalds. Talk to people in your company or at local meetups and find some like minded individuals.
  
• Screencasts. Recordings of Code Katas, sometimes called Katacasts, are a great source for learning. This way you can (kind of) pair program with famous people like Robert C. Martin, J.B. Rainsberger, Sandro Mancuso and others.
  
• For more details on how to improve your skills further, I recommend Houssam's (and Boris Gonnot's) article How to Boost Your Skills to Become a Better Developer.

Craftsmanship Community
Finally I want to point you to the Software Craftsmanship community in general. In Germany, Austria and Switzerland the local Craftsmanship communities are hosted by the Softwerkskammer. There is a group for Vienna and Linz. These communities run yearly conferences, the SoCraTes (Software Craftsmanship and Testing) unconferences. Currently we have SoCraTes conferences in many countries. In Austria the next SoCraTes will be autumn 2017 in Linz.

I wish you all the best for your future. You can do it!

How to divide learning time

As software delivery professionals we constantly need to learn and practice to keep our skills sharp. Last year I even spent three months pair programming to do exactly that. Possible activities required for learning and related to the sharing of knowledge are:

• (a) studying, e.g. reading technical books or blog posts, watching (recorded) presentations as well as any form of consuming knowledge.
• (b) practising, e.g. doing code katas, attending Coding Dojos or working on fun (but otherwise useless) projects.
• (c) experimenting, which includes creating prototypes or trying out new frameworks or ideas.
• (d) creating something real, e.g. hobby projects or maybe contributing to Open Source.
• (e) documenting and sharing, e.g. creating how-to documents or writing blog posts.
• (f) teaching, e.g. preparing presentations and talking at user group meetings.

Why are documenting, sharing and teaching considered learning activities?
Obviously sharing is no learning activity by itself but the process of analysing and describing things improves our understanding similar to Rubber Ducking. For example writing an article about some topic is a great way to bring one's thoughts into order and learn more about it. Documenting and sorting knowledge is also part of PIM (Personal Information Management) which is related to learning as well. Teaching is considered a learning activity by most people. Teaching is a great way to perfect the understanding of an idea. This is sharing on steroids as you are forced to dig deep into the topic to be able to explain it to others.

How should I divide my learning time into activities (a) to (f)?
With the start of 2014 I came back to (sort of) regular work and obviously my personal time for learning became limited again. I was not sure if I spent the available time in the most efficient way and looked for guidelines how to divide my learning time into these activities. All activities (a) to (f) seem vital, but likely do not have the same priorities. For example there are so many important books to read, I could spend all my time on reading alone, which does not feel right to me. Sören Kewenig pointed out that items (a) to (f) might be seen as the phases of a project: a -> [c,d,b] -> e -> f, which also indicates that all these activities are important and related.

This question is subjective ;-)
As usual when I have a question I ask StackOverflow. In this case I asked on Programmers. Unfortunately the question was closed in less than 19 minutes as being off-topic. (Many of my questions I ask on StackOverflow get closed but 19 minutes is my personal record so far ;-) While it is true that learning is a subjective process, there might be some research that gives clear advice how to optimise learning activities.

Comments suggest that practice is the key.
Nevertheless I was able to harvest at least some comments from my StackOverflow question. Robert Harvey wrote "if you're not writing code that illustrates the principles being taught, they won't stick. [...] I am saying that, without practice, the other stuff won't matter." I conclude that there needs to be a strong focus on (b) or (d) until the newly acquired material is incorporated into the daily work and applied every day. Then I asked my fellow craftsmen of the Softwerkskammer, the Software Craftsmanship Communities in Germany, Austria and Switzerland. Sören answered me that he used 50% of his free time for Coding Dojos (b) and 50% for working on Open Source (d). Jan Sauerwein spends his time on code katas (b) and preparing a lecture (f). Franziska said that she liked learning with others and therefore favoured (b), (c) and (f). Ulrich Merkel said that developing skills needs as much practice as possible - (b), (c) or (d), but probably he was talking about real work - together with discussion and feedback as corrective. So all answers agree that practice, either by real work or (b), (c) or (d) is important.

How I divided my learning time till now
Franziska asked me how I divided my learning time till now. Yes I should have checked my own time before asking ;-) So I started tracking my learning time. For several weeks I spent an average of 10 hours on learning activities.

• (a) studying: 20%. I spent some time reading. I am participating in an online book club which forces me to keep up reading and allows for discussions afterwards. I read the book while commuting. Further I browse my feeds of blogs and news to get an overview about what's going on and to stay aware of new trends.
• (a) studying: 30%. I watched presentations. This includes user group presentations as well as recorded ones.
• (b) practising: 20%. Once a week I meet online with a friend to do remote pair programming. We schedule the appointment up to one month in advance, to make sure it even happens when workload is high - and it usually works.
• (d) creating stuff is still part of my job, although recently I am not doing as much development as I used to do.
• (e) documenting: 10%. I used some time to look up slides of seen presentations and to take notes about what I have learned.
• (e) sharing: 20%. An average of two hours went into writing blog posts, which was not enough to publish a full article but I worked on fragments of posts which eventually will be published.
• (f) teaching is part of my new profession and I prepare a presentation now and then. Sometimes I also present something at user group meetings.

This looks pretty balanced, there are no huge gaps. I am surprised how much I do read because I always feel like I should read more but then I am too tired most evenings. Maybe I should watch more demonstrations though. Also 20% practice might not be enough compared to the previous comments by Robert and Sören.

The Learning Pyramid
Not all learning activities are equally effective. For example I remember a vivid discussion about something much better than just reading about it. Edgar Dale summarises these findings as Learning Retention Rate which ultimately leads us to the Learning Pyramid. In the Learning Pyramid, the learning activities are ordered by how much they pay off.


When looking at these rates I see that I need to add another activity to my list: discussion, which might happen during user group meetings, practice with others or teaching. So let me revisit my tracked learning time and distribute it according to the pyramid.

• Lecture, 5% retention. Next to real lectures that I sometimes attend, I consider some user group meetings to be in this category. Sometimes presentations are of mixed quality and there is not much discussion. 15% of my learning time (a) goes here.
• Reading, 10% retention. I spend 20% of my time reading (a).
• Audio-Visual, 20% retention. To be fair, not all presentations I see are boring, so I consider some of them to be of this category. Here I spend another 20% of my time from (a).
• Demonstration, 30% retention. It is difficult to assign one of these categories to a typical user group talk or conference presentation. Some presenters give high quality demonstration, but I see this rarely, maybe 5%.
• Discussion Group, 50% retention. Especially in the reading group (a) there is much discussion. Maybe 10% of my time is of this category.
• Practice by doing, 75% retention. With two hours of pair programming code katas (b) each week I score 20% here.
• Teaching others, 90% retention. As I teach as part of my day job (f), I did not track the time. Also I am left with two hours documenting and blogging (e) which do not fit into the pyramid. To make things easier I will just award myself honorary 10% here.

When multiplying my learning time by the retention rate I end up with a weighted learning time, let's call it my "effective" learning time:

• Lecture 2%,
• Reading 5%,
• Audio-Visual 10%,
• Demonstration 4%,
• Discussion 14%,
• Practice 40%,
• Teaching 24%.

How I (maybe) should divide my learning time
It is time for a conclusion. I have spent some time analysing the topic - and this made some things clear to me - call it meta-learning. I do not know if the final distribution of my effective learning time is well balanced or not. On one hand the activities with smaller retention rate obviously do not pay off, so there is no point in doing more of them. On the other hand - maybe - there would be some benefit in spreading the learning across all activities. As the retention rates (5, 10, 20,...) look (sort of) exponential, the effective learning would also look exponential for equally distributed learning times.

Now I see that my feeling about not reading enough comes from the fact that I do not learn enough while reading, which is obvious when looking at my effective learning time for reading. Even if I would add another hour of reading each week, it would not make much difference. But I still believe that it is important to read technical books, because it is a good way to cover a topic in depth. So I will stick to my reading routine of one to two hours each week. I will continue watching presentations, because I usually watch them during cardio-workout. I will add demonstrations, but I am not sure where I could find these. Maybe I will look for user group meetings with live coding. I am doing a lot of practice already, and it is dominating my learning. I will have to think about this. Just half an hour moved from practice to teaching each week might improve my effective learning. So even if I give presentations as part of my day job, I will look for user groups willing to listen to me ;-)

As others already pointed out, different people have different learning styles. Learning styles might even change for the same person over time. I am very interested in your take on dividing learning time and how you think the few hours of personal learning could be spent best.

Required Reading: Clean Code

Here is an email that I wrote to my team earlier this year. The team members are able to deliver new features on time but do not care for code quality (at least not as much as I do ;-). This is going to change.

Raising the bar. ⁽¹⁾

Dear team,
as mentioned in the kick-off, we need to get into the right attitude for the upcoming refactoring effort. Many items on our code clean-up list are ongoing changes, e.g.

• use proper names for fields and methods
• clean up magic numbers
• split large classes
• add JavaDoc to core classes
• fix compiler warnings
• remove duplicated code
• remove dead code
• add JUnit tests

All of these changes are in fact rules how to produce code that is easy to read and maintain. All these rules are part of a coding style sometimes called "clean code".

The Pragmatic Programmers once wrote that you should read at least four technical books a year to stay sharp and relevant in our fast paced industry. Remember that the half-life of our technical knowledge in only 18 months. (Heinz Kabutz) So as first technical book to read in 2012 I highly recommend Clean Code by Bob Martin. It's a great book and has raised a new wave of code-consciousness. Read one of its reviews if you do not believe me.

Sooner or later you will have to read it, so why not start now? Go ahead, buy it, read it! Or at least browse it and see what is inside. We cannot afford to have any more cryptic variable names or huge classes.

Regards,
Code Cop

Lowering the bar.

Of course I did not attach the PDF of the book. That would have been illegal but it might lower the bar to get my colleagues into reading it. I know that not many of the team will read it. I would consider my email successful if one of two read the table of contents or browse a chapter.

⁽¹⁾ "Raising the bar" is the subtitle of the Software Craftsmanship Manifesto.

Literature for Java Developers

Jonny Andersson asked for a list of good books that one needs to read to learn how to create proper and useful Java code. He knew a few reasonable books, like the SCJP (Sun Certified Programmer) Study Guide, and I immediately came up with some recommendations. Still he encouraged me to share more literature tips in a discussion thread because as he said, there are so many books on Java development and software engineering available that it is impossible to know them all. We cannot afford to waste time on other books than the best ones and have to relay on recommendations. My last reading list is a bit outdated so I decided to repost my recommendations here.

First I would like to differentiate the topic of Java into three phases: First learn how to program, second learn how to program in an object oriented way and only then learn whatever framework you like. Unfortunately I see that most junior developers have serious deficiencies in the first two areas, whereas frameworks are well known. I met developers who knew the Spring Framework pretty well, but had never heard of Test Driven Development and had no idea what the Java keywords volatile or transient are supposed to do.

For the first phase I refer to the most influential book every programmer should read. There you see that the most important book (as seen by the StackOverflow community) is Code Complete. The second important book is The Pragmatic Programmer. I think it's even more important than Code Complete. This book is the base of all development work. I'm sure you will like it. It has around 350 pages and for an experienced developer only a few chapters will be new. But on the other hand, I still meet people that do not use version control or build automation. That's one reason that everybody has to read it. Now go, read it! Even if you are an expert, just go and read it! ;-)

The SCJP Study Guide is a good start for Java. There is no way around knowing operator precedence and other low level details of the language. Another book on Java basics like TIJ (Thinking in Java) is necessary to deepen the knowledge after the SCJP guide, which is just focusing on the very basics. Then I highly recommend Java Generics and Collections to comprehend Java Generics. Of course no list of Java books is complete without Effective Java which is also very important. To round up the basic Java knowledge I recommend the Java Language Specification. It's a specification but it's not that bad to read.

After the basics I would definitely add Kent's Beck Test Driven Development by Example, which is a short and excellent introduction to JUnit and TDD. And of course you must read Design Patterns, Refactoring, Clean Code - argh, more and more books get piling up. Think about it, you will not become a professional (Java) developer by reading three books, you probably need more than that, maybe 30 ;-) So if you feel like more books, just check out my Goodreads reading list. All books I've read are rated and tagged accordingly. I encourage to have a look. I'm looking forward to see your recommendations.

backwater, in-house development

Maybe I am too strict, or my expectations are far too high for the average company (which is likely the case). However, while staying with Herold I reached the conclusion that "backwater, in-house development" does not provide footing for IT innovation. Obviously this is true but the ironic part is, that management pretends that it's there. Listen to this:

Two years ago they came up with the idea of science Fridays. Every Friday the development department would be locked, so no one would disturb us and all developers would try out new stuff or study books. Well, it never happened. Last year the idea was still around, we would just start after this particular next release. And there is always some pressing next release to work on. The WTF of this paragraph is that two months ago I was asked by the boss of my boss if I used the science Friday time for some project. I had to laugh out loud.

Another idea was born at the beginning of last year: every month a member of the team would prepare some topic, e.g. new features in .NET 3, and present an overview. There was not a single one of these presentations, the monthly meetings were always full with lists of features to be put into the next release. The proposed topics, already outdated, are still in my boss' drawer, waiting for their time.

How about professional training? "Sorry, there is no budget for that. Sales revenue just increased by 5 percent last year. The company is in critical condition. We all have to work harder."

So I experiment with new technologies at home and try to bring in something new from time to time. But I was told that we do not need it, because we are no IT company and there is no point in spending time to stay up to date because it is not our main business. And anyway I am not supposed to spend "so" much work time on education and research. But I have to, because as Heinz Kabutz once said, we're in an industry with a knowledge half-life of at most 18 months. Keep in mind that half of what you knew 18 months ago is worthless today, so you need to keep learning new things.

Do you work under similar conditions? Tell me how you overcome them to stay a top notch developer.

Java Bookshelf

On this page you will find what I think are the most valuable resources for Java developers available. First a list of books every Java software developer should know (no excuses). It's amazing how old some of these are and still there are people around not knowing them. Next are my favourite newsletters (electronic journals), which I read regularly. Last I give you a (probably subjective) list of some of the best development tools available, which are all free.

Books

• The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt, David Thomas (1999): This is no Java book, but about how being one of the best developers, called pragmatic programmers.
• UML Distilled: A Brief Guide to the Standard Object Modelling Language by Martin Fowler (3rd Ed. 2003): A short and nicely written introduction to OOA/OOD and the UML.
• Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (1994): The bible of patterns, also called the Gang of Four (GOF) book.
• Refactoring: Improving the Design of Existing Code by Martin Fowler, Kent Beck (1999): Refactoring to clean up bad code. And your code will be bad, given some time of evolution...
  
• Test Driven Development: By Example by Kent Beck (2002): A really easy introduction into test driven development, nicely written - you will become test-infected...
• Mastering Regular Expressions by Jeffrey E. F. Friedl (3rd Ed. 2006): The only book available on the topic, really giving a deep understanding of Regular Expressions.

Books on the Java Language

• Thinking in Java by Bruce Eckel (4th Ed. 2006): The best book to start with the Java language. Basics are covered in detail to build a robust fundamental base. Available for free download from Bruce Eckel's website.
• Effective Java Programming Language Guide by Joshua Bloch (2001): The best book on the Java language. It features 57 items any good Java developer has to know.
  
• Java 2 Performance and Idiom Guide by Craig Larman, Rhett Guthrie (1999): Although this book is outdated and pure Java 1.1/1.2, it documents useful techniques and best practices.
• Java Performance Tuning by Jack Shirazi (2nd Ed. 2003): A wonderful book about something most worried about in Java - performance.
• Java Puzzlers: Traps, Pitfalls, and Corner Cases by Joshua Bloch and Neal Gafter (2005): Although I was only able to answer 49 out of the 95 questions correctly, I love this book :-)
  

Newsletters and Sites

• IBM developerWorks newsletter: technology edition by IBM developerWorks
• Java Performance Tuning News by Jack Shirazi
• The Java Specialists' Newsletter by Dr. Heinz M. Kabutz
• Java Examples from The Java Developers Almanac: Code examples to copy and paste into your programs.

Tools

• Eclipse IDE: free integrated development environment (IDE) to create your Java code.
• JUnit: Then test your code.
• PMD: Source Code Analysis - Analyse your code for potential problems.
• Apache Ant: Build and package your code.
• Anthill Build Server: to daily build your code because Daily Builds Are Your Friend.
• Apache Tomcat: Reliable servlet container for your web components code.