When we think about coding – especially early in our journeys as code learners – we typically think about writing code. Code is something that we write, and common ways of measuring productivity using software metrics often reflect our tendency to conceptualize the outputs of coding as something that is written.
The further along we get in our coding journeys, though – once we have moved past learning primarily via tutorials and prepared curriculums – we realize that code is something that we must also read. The importance of code literacy becomes especially apparent once we start coding collaboratively on teams with other code writers. As a prerequisite to writing code against an existing codebase, you must be able to read and make sense of the code that was written by those who – proverbially speaking – click clacked on the keyboard before you.
Something that I’m increasingly learning through mentoring bootcamp graduates and software engineering interns, though, is that code is something to which we must also be able to apply the skills of speaking and listening.
Speaking and listening are skills that – in the realm of second and foreign language learning – sit alongside reading and writing as key facets of overall language proficiency. With human languages, certainly, it’s not necessary to be equally fluent in each of these facets (and in fact some have led successful careers through command of a single of the four primary skills. There are, for example, academics who read French quite fluently because the bulk of their source texts are written in French, but can not write, speak, or comprehend spoken French).
I would argue, though, that in the realm of learning and using computer languages – and especially in the context of a career as a software engineer – speaking and listening skills are just as important as reading and writing skills.
How do “speaking” and comprehending “spoken code” manifest for a software engineer?
Consider the new programmer applying for her first, entry-level job. She must complete a technical interview, where she is asked to pair program with someone to solve a series of coding challenges. For some of this time, she is the navigator – she must tell her interviewer – the driver – what code to write to solve the problem.
She may be perfectly capable of fluently writing code to solve the problem, but without having the precise language to describe the code she wants the driver to write, this new programmer will struggle, and without fluency in intelligibly “speaking” that precise language, the experience is likely to be inefficient at best, and at worst, frustrating for both navigator and driver.
Consider, too, the junior software developer who is struggling to solve a problem and reaches out to a senior colleague for help. The more experienced developer prefers communicating live via video conferencing, rather than asynchronously via messaging systems, and so they jump onto a video call to work through the problem.
The junior developer’s lack of speaking fluency prevents him from lucidly describing the problem he is trying to solve and the errors that he has continuously encountered in the console, however. This impedes the senior developer’s ability to understand the problem, the context around the problem, and what the junior developer has already tried in order to solve the problem.
Similarly, the junior developer may not have the listening comprehension to understand the solutions his colleague suggests. Time, energy, and – in the worst cases – goodwill are squandered as both parties move inefficiently through this troubleshooting process.
Again, this is a recipe for inefficient and mutually frustrating pair programming.
Activities to deepen code speaking and listening comprehension
As developing code writers, then, how can we increase our fluency in “speaking” and comprehending “spoken code”?
I believe that we can extend the principles of efficient language learning found via empirical inquiry in the field of second language acquisition to the code-learning realm. Based on findings in this domain, here are a few activities that I suggest code-learners try:
Practice speaking your code
Speaking fluency is gained through speaking. Not through writing, not through reading, and not through listening. So in preparation for having to talk through and about your code with others, practice “speaking” that code.
Take any piece of code that you’ve written – something small, like a class or even a method within a class – and simply describe what the code is, what pieces comprise it, and what it’s doing. Note the places where you get tripped up or are unable to articulate something. Do you find yourself struggling to distinguish between arguments and parameters when describing a function? Do you fumble over explanations of why an async function was necessary? These places of inarticulateness likely highlight those concepts that you need to gain better understanding of and speaking fluency around.
Practice listening to code
Just as speaking fluency is gained through speaking, listening comprehension is deepened through listening.
Something you can try to improve your listening comprehension is to recruit a senior or a principal engineer to record themselves “speaking” a piece of code that they’ve written, then use that recording to try and recreate that piece of code. Compare what you transcribed to the code that your colleague described. Notice the discrepancies, and reason about why that distance between what they said and what you wrote exists.
You might even try combining this activity with the former. Look at a piece of code you’ve written, and record yourself “speaking” it. Schedule some time with your senior or principal teammate to play the recording, and see if they are able to recreate what you’ve described.
You might also try listening to coding tutorials without watching the visual, and try coding along with whatever the instructor is creating. At the end of the clip, you can compare what you have written with that produced by the instructor.
Conclusion
When we study and practice human languages, we practice each of the four skills – reading, writing, listening and speaking – and neglecting to practice any one of these results in decreased fluency in that particular skill and – thus – overall proficiency in that language.
The same applies to programming. We must not neglect to talk about and listen to others talking about code. These are essential skills when coding collaboratively with others, and developing them is well worth the time investment!