Most developers already know Bob Martin’s writing, ie “Clean Code”, but can I assure you it’s a worthwhile experience to hear him talk about software. He is a very engaging speaker, and this, together with his passion for building quality code, can get you back sitting proud at the keyboard.
At the beginning of November I got my passion for coding fired up again by going to the SCNA conference. The conference first started in 2009 and it’s a place where you can meet a wider community of people deeply passionate about the craft of writing software. It was my first time there and it seemed like a place where topics were less on the side of “what” particular technologies people use and more focused on “how” people do things, what’s their attitude when building software and how can we support each other as a community.
Cory started his talk reflecting on what quality code feels like. I know we have code metrics, and tools like Sonar to inform us of the health of the codebase, but stating that “Quality code makes me say, “hmm,” not “ick.”” rings very true as well. During the talk I was reminded about Christopher Alexander’s work “The Timeless Way of Building” and similarities between well architected building and the code, because quality code is “Code that actually gets used”. It creates a space that is alive and “sets free”. This fits well for me with the sense of being free when modifying well written, well modularized code. When you are able to understand it, introduce new functionality in a way that is not invasive and when it doesn’t feel like there are many constraints restricting what you can do. Opposite to that, when code is bad it doesn’t make much for a living space.
As developers we have our programming languages, but it’s sometimes easy to forget that our job’s main purpose is communication. It’s always great when I hear a new metaphor that puts a new spin on concepts I have arranged in my head. I already knew that code can smell, Cory made a point that code sometimes cries – it happens when no one understands it. I find it to be a neat metaphor that will make me think twice when naming my methods so that it easy to understand for other people and myself in the future. Cory also drew analogies from the ways we learn languages and showed how we can take a similar approach when learning to listen to code better. Using the BICS/CALP model of language proficiency, he suggested the way to move on a path toward being a better “code listener”. Starting from code kata moving to koans we first need to get familiar with the language operating in a well defined context. Only when we get comfortable with that we then we can move on to working with bigger code bases and adding new features and “listening to code”. I wouldn’t see myself following this path too strictly though. I guess, and I don’t think I’m alone here, I like figuring out how pieces work together as part of a bigger system and it would be too tempting not to jump ahead from time to time. This model reminds me though of the importance of coming back to simpler exercises, like katas, to get more focused training. Actually, the last day of the conference, which was full day code retreat, was a good chance to pair with new people, and try a Game of Life kata in different languages.
Following Cory, understanding the rules of good code together with principles of good listening can make me a better coder. Deciding to listen, being curious and letting go of my personal agenda all make for a better listener, at the same time I can definitely see how they can get me better equipped when I’m about to read unfamiliar code. Also “Testing for understanding” when I’m a listener translates surprisingly well into testing the code and making sure I expressed my intention correctly. Here you can find the slides and video for Cory’s “When Code Cries..”.
Uncle Bob talked about what he as a CTO would expects of his developers. I think it’s important to be reminded about professionalism and ethical responsibility of building software in a professional way. This is what I saw him emphasize the most and it’s what he is promoting with his Clean Coder’s Green Band. It’s what we do under the pressure of time and deadlines that makes for what we really believe. That statement made me think that I need to strengthen my habit of TDD, to make it more natural and be able to stick with it when the going gets tough. Only quality code and practices that we can sustain for longer time is what provides stable productivity. Rushing and cutting corners, even though it sometimes feels like moving fast, gives only the illusion of progressing fast. Nothing to add here.
Another message Uncle Bob directed attention to was a need to be able to say “No”. Say “No” to unrealistic demands and time pressures that may tempt us to compromise on quality. This made me think of the time-cost-scope triangle and that being professional means saying what is realistic to achieve within a given timeframe, and not treating quality as a variable.
These were just a few from the list of expectations from the “new CTO”. Delivery of most of them was accompanied by audience’s sighs and chuckles of understanding. Even if it wasn’t the first time for me to hear from Uncle Bob I find it always refreshing and motivating to be reminded of his message to developers.
Summarizing, I appreciate that the software craftmanship movement lets me look at my job as a developer from a different perspective. It’s not that much a software engineering discipline but more a craft, a set of skills that I develop walking along the path from apprentice to journeyman and toward becoming a master. It was definitely a worthwhile experience meeting and hearing from other craftsmen.
You soon should be able to find these and other talks from the SCNA conference uploaded to the 8th Light’s vimeo channel.