YOW! September 2021 Recap
Felienne Hermans
Do you remember the BASIC programming books of the 80s? Felienne does.
In the 1980s, there weren’t that many computing teachers at schools. But there were a lot of books that came equipped with BASIC programs, fully typed out, that you typed into your BBC Micro, Amiga, Commodore, etc and “learned” programming. Except, you didn’t really learn anything - you just typed the thing out fully, cursing when you made mistakes, and if you were lucky you had a game to play at the end of it.
For Hermans, her own experiences trying to teach kids to program in an after-school class made her recognise just how poorly we equip ourselves to learn programming.
“The fact that we celebrate how hard programming is makes it a barrier to entry… We don’t even teach you how to read code. If you can write code, we assume you know how to read it.”
Likewise, there is a general pattern in senior-junior programming relationships where a senior will deliberately withhold information from the junior partner, albeit in a well-intentioned way to make them think about what the answer might be. The problem is, this isn’t always the best way to approach such questions. As Hermans herself puts it;
“Consider a very young child who doesn’t yet know how to read. If they point at a word and ask you what it says, telling them “What do you think?” is somewhat pointless. They don’t know - this is why they asked!”
Programmers spend vastly more time reading code than they do writing it over the course of their careers, so it makes sense to say that we should have some way of sharpening these skills. We assume that writing it will help us read it better, but this falls apart as soon as we encounter vastly different syntax or even just different styles of writing or structuring code to what we’re used to. While we don’t have readymade theories and research about what happens in your brain when you read code, we do actually have pretty good research into what happens when you read, period.
George Miller’s work in the 1950s into cognitive function talks about short term memory, which can only hold 5-9 things at a time, and long term memory, where the vast majority of our knowledge is stored. Working memory is then like the processor which can link elements in short term memory with those stored in long term memory; “Do I recall something like this?”. Hermans demonstrated this by showing a series of code snippets for a split second to the audience, ranging from obscure languages to the very common - and it was amazing to see how the brain worked in action, where you were completely puzzled by foreign symbols in the rarest language, yet totally comfortable with the Python statement showed later on, despite being showed both of them for the briefest of moments.
So, how can we aid our working memory and practice reading code? Hermans has some suggestions:
- First of all, don’t attempt to read code where you don’t understand 25-50% of the syntax. You’ll just waste your time. Take the time to learn the syntax first, then return to the code afterwards.
- Flash cards are a well-used mechanism for teaching children to read, or adults to learn foreign languages. Programming languages are no different; stick the syntax on one side, stick the meaning on the other, and test yourself.
- If you almost understand some code, but are not quite grokking that final part - do a cognitive refactor. Reshape the code into a way that you understand for your own use. You can always revert that commit before you push it out to others if it’s not the right “style” - but you should also consider if you’re the only one who can’t understand it; there could be a good reason it’s hard to read!
- Support your working memory by filling out state tables as you step through the code (many IDEs will do this for you in debug mode)
- Read code together at work. Why not? We pair program, why shouldn’t we pair read?
More information is available in her book, The Programmer’s Brain which covers not just reading code, but making codebases welcoming to newcomers, onboarding new devs into a team, and that most wicked of all Computer Science problems… naming!
I’ll finish on a quote from Felienne that I thought summarised her talk quite well;
“By understanding your own misunderstandings, you become a better programmer.”