Clean Code Academy
At MYOB, Continuous Improvement is one of our key values. This year, we have run an experiment to support the improvement of our code. Twice a week, a group of junior developers has been meeting for an hour to study Robert Martin's "Clean Code". Each week, there has been a theory lesson and a practical lesson. The theory lessons have been focused on the discussion of Uncle Bob's book, while the practical lessons have been focused on reviewing the students' solutions to a coding exercise, which has been chosen because of its relevance to the studied theory.
Anton was a regular participant in these sessions. Here are his thoughts on the experience:
I'd never understood the idea of reading a book to learn how to code. To me, programming is something that's easier to learn by just doing. Looking at existing code or documentation, or even a quick tutorial, and then trying to do it myself made a lot more sense than reading through a book.
So given this mindset, I was skeptical of the benefits of Clean Code Academy. Not to mention, I'm currently on placement from Monash, so the idea of finally escaping the world of academic theory and entering the real world of practical work, only to immediately sign up to do a theory class wasn't the most enticing idea.
Reading through Clean Code at first, a lot of things seemed obvious to the point of being mundane. Of course you name your variable something that describes what they actually are, and your methods should do just one thing. These things are just common sense!
But after reading more and reflecting on code that I've written, I realised that although it seems like common sense, actually doing it was another matter entirely. My own personal code was littered with variable names and syntax that only made sense to me. There were things like
backgroundswhich when I wrote it, made sense to me, but if anybody else looked at it, they'd be thrown for a loop and have to ask me how it works. This obviously isn't good in the real world where multiple people are working on the same codebase at the same time. If every time someone worked on code like that, they'd have to spend time understanding it, then probably even more time refactoring to make it more understandable for the next person.
After having this lightbulb moment, I realised the importance of Clean Code Academy. It gave me a reason to read the Clean Code book weekly to make sure I actually could contribute to class, and being able to discuss and debate ideas in the book with other people gave me an even better understanding.
Of course, it's not just reading a book for an hour and talking about it. The practical sessions - where we did coding katas - were just as important because they gave us a chance to put what we had just learned from the book into practice. These tasks really helped reinforce what we learned, and being able to look at how each other solved the problem in different ways was also really enlightening. I feel like sometimes, as programmers, we have our way of doing things, and if it works once, we'll always try doing it the same way.
Seeing a variety of both techniques and languages being used for the same problem was insightful, and despite not being too familiar with some of the languages, I was able to understand how the code worked.
Why? Because it followed the rules of clean code we'd just been studying.
By the time Clean Code Academy had ended, I was recommending the book to my friends. Admittedly, I don't know how helpful it will be to just read the book. Part of what made the classes so good was the discussion and applied learning, and if I'm being honest the times where we just read through the book verbatim was a little dry – to say the least. But I'm hopeful the lessons are vital enough that any developer can learn something from it.
Looking at my code before and after Clean Code Academy, I do think it's a lot more readable because it's cleaner – so that's a positive. I'm going to try and read more books to expand my learning horizons. Hopefully, they'll be as helpful as Clean Code was.