In December 2020 I (virtually) attended the Yow! Conference and was inspired to write this blog post based on a presentation given by Felienne Hermans. She gave a marvellous talk which relieved one of my lingering insecurities almost immediately. Felienne told me that it was OK to spend time reading code, and that it was in fact a necessary precursor to being able to write code effectively.
In this post I wanted to highlight some of the key points that Felienne raised and then discuss specifically how certain workplace settings would benefit from embracing alternative approaches to the “get your hands dirty” style of learning and understanding code.
When magic isn’t enough
Felienne is an Associate Professor at the Leiden Institute of Advanced Computer Science, where she does research into programming education. In her talk she discussed her experiences with teaching programming to young children, and how this caused her to reflect on they way she learnt to code. Her experience coding as a child involved picking up a text book and copying lines of code from the book into an editor and then running the program.
This was also how I remember learning to program when I was young. It all seemed like magic – you type some words into a machine and it does something – draws, speaks, calculates. This magic was enchanting, and something about it made me feel powerful and smart.
It all seemed like magic – you type some words into a machine and it does something – draws, speaks, calculates. This magic was enchanting, and something about it made me feel powerful and smart.
The one major problem with this approach, which Felienne covers in detail, is that there is no fundamental understanding that is established by the student. She found that although children can get a program to work, they cannot describe what it actually does. As she states, “just building something doesn’t mean you can understand it”. Many of these limitations she discusses with respect to children, are certainly also transferable to adults.
The ‘get your hands dirty’ approach
I was always under the impression (and I found this reinforced in practical settings) that in order to learn code you had to ‘jump right in’ and ‘get your hands dirty’. Learning to code is definitely viewed as a type of apprenticeship, and this implies learning by getting on the tools, as opposed to spending time dissecting problems and understanding their root cause. Felienne’s advice is somewhat contrary to this established approach. She discusses three key limitations that currently exist when learning to code. I will summarise each of these briefly.
- “We don’t teach reading code”
As already discussed, we often equate learning to write code with doing – getting on the keys. Felienne rightly mentions that although this is the approach frequently taken to write coding languages, it is certainly not the approach adopted when learning to write regular languages. When I learnt English, or even Chinese or French, the focus on reading before writing was paramount, otherwise one cannot place the symbols (letters) into any cohesible context. We cannot comprehend what we are writing, even though it may be correct syntactically.
2. “We don’t practice reading”
After listening to Felienne, I realised that this is probably something that I should make part of my learning routine. She likened practising reading code to practising reading books. The more books you read, the more likely you are to become a proficient writer, because you have a larger pool of knowledge to draw from.
According to Bob Martin, we already spend a lot of time reading code, so it is certainly something we need to acknowledge and value, and also get better at doing! The more we practise reading code, the better we get at recognising ‘good’ code, and as Bob says, when we come to write it ourselves, we appreciate the importance of making it readable for others.
3. “We don’t have theories for reading code”
Felienne suggests that even if we are interested in learning to read code, we don’t have many strategies to call upon to make this task easier. Where do we start? There are no ‘best practices’ to follow – no guidelines. She mentioned that these strategies can be developed once we have a good understanding of where our confusion or barriers lie. What makes reading code hard – is it due to a limitation in our short-term memory, working memory, or long-term memory? For example, if someone is learning a coding language they’ve never seen before, then flashcards etc. can be used to improve long term memory. If the code being read is complex, ie. has many variables and states to keep track of, then we can assist our working memory by using pen and paper to document the complexities in state table, diagrams etc. She also mentioned that summarizing code can be a great way to increase comprehension – what is the goal of the code, what decisions are being made, even what is the most important line.
Surely a developer doesn’t get paid to read?
I loved all the advice that Felienne offered, but then I paused and thought about how I could practically apply this day to day in my job. I work as a consultant, and in the back of my mind I am always conscious of the ‘time’ I am spending on tasks. It’s not like the clients I work for are strict timekeepers, or even deadline/milestone focused, it’s just that I feel like my time is what they’re paying for, and therefore I want to provide the best value within that time. So if I spend time reading, rather than writing code, is this as valuable? One the face of it, allowing myself time to read code and learn seems incredibly indulgent – and slow. Getting back to what I mentioned earlier, aren’t I being paid to ‘jump right in’ and ‘get on the tools’?
The more I thought about it, the more I realised that the basis for this attitude of mine was insecurity – as is usually the case when I’m faced with similar dilemmas. Value doesn’t equate to lines of code – I know that – but my brain was resisting this truth and invariably comparing myself with other more experienced developers, who are able to code with their eyes closed! These developers seem to be able to jump right into a code base and start writing, in fact this way of working energizes them. In general, they have more experience than me, and therefore a more established long term memory when it comes to recognising the patterns and structure of code. For them, slowing down and taking time to read code may be laborious and boring.
Why learning to read code is valuable in consulting
I believe taking the time to read code can have unexpected practical and long-term benefits for developers at all levels – particularly for those working in consulting. Here are some of my thoughts:
- Reading code proficiently can prove a valuable tool in the problem solving process, particularly when adding features to already established code bases. Reading existing code and understanding what it does allows one to add new code with more confidence, because a more holistic understanding underpins the additions being made.
- Valuable artefacts can be produced whilst one is reading through code, I have often found that clients appreciate these artefacts as they are often a concise form of documentation for complex systems.
- Reading code and refactoring it in order to understand it better can have long term benefits. This refactoring may persist and contribute to maintaining the hygiene of a code base.
- If code is complex to read, this may encourage the writing of tests to describe the behaviour of the code. Once again, these tests may persist and add valuable coverage to the code base.
- Reading through code and being able to summarise what it does allows for better communication between developers on a team, and also with the client. When changes need to be made, one is able to clearly communicate what is changing and why.
In summary, Felienne’s talk certainly made me realise the importance of dedicating more time to practising reading code, and that by growing this skill I would inevitably become better at writing it too. Although it may not be everyone’s cup of tea, it should definitely be considered as a valuable alternative approach to the traditional forms of learning to write code.