How to Read Complex Code without Getting a Headache
Please log in to watch this conference skillscast.
Research shows that on average developers spend about 58 percent of their time on reading code! However, we are not explicitly taught reading code in school or in boot camps, and we rarely practice code reading too.
Maybe you have never thought about it, but reading code can be confusing in many ways. Code in which you do not understand the variable names causes a different type of confusion from code that is very coupled to other code. In this talk, Felienne Hermans, associate professor at Leiden University, will firstly dive into the cognitive processes that play a role when reading code. She will then show you theories for reading code, and close the talk with some hands-on techniques that can be used to read to any piece of code with more ease and fewer headaches!
Q&A
Question: My Thesis was on Intelligent Tutoring Systems.
It was a real eye opener that no one teaching method suits everybody
- some like starting with examples
- some like syntax first
- some like a verbose explanation
Have you found the same applies to reading code?
- do some people prefer to start with the tests
- do some prefer to start with the main
Answer: Yes I think this is true for code reading too, while it might not be so related to personality style but more to prior knowledge. We know from research that more experienced programmers read following the call stack and beginners tend to read top to bottom.
Question: Do you think we’d naturally write better (more readable) code if education focused more on teaching reading code vs just writing it?
Answer: That is a great question, I do think it would lead to better code and indeed there might also be people like managers or product owners that could just read but not write code which can be helpful. Great additions to the talk!
Question: Is this why REPL's are good, they help with that working memory? Are REPLs a good or bad thing for learning how to read and understand code?
Answer: Wow I do not have a simple answer there! It is a deep question. I think they could be great tools for learning when used deliberately, for example, you get code, first you predict what it does (also a very good way of practicing reading!) and then you verify. But they also encourage “just try it out” which as a culture might harm learning as I said in the talk.
Question: So if used correctly they could support learning? But can also be a crutch. Like an IDE too I guess, using one without understanding is not great for improving your skill in a language.
Answer: That indeed!
Question: Should we be refactoring code so that it contains a summary?
Answer: Yes that’s what I say in the book as well that if you make summaries for cognitive purposes you can commit them back to the code as docs
Question: The only risk with a summary that is not directly linked to code is that they tend to get outdated. Any suggestions on how to ensure the summary is always relevant?
Answer: You can link it in the code of course, place it there or link it. But yeah that is a risk! I’d like to add that even if it is executable it might still decay over time
Question: Are there any natural language preprocessors that could be used to record the summary and it would be compiled into the actual calls to the real code?
This way you have your summary but it has to be kept up to date in order for the code to still work.
Answer: Interesting idea! But I think the most important thing about the summaries in my talk is that they help people understand the code. Using them as docs is extra/additional. So it can be done many times. You might even imagine that new people coming into the code base make their own summaries, compare them with what is there and update what is needed. (which is helpful for the code base and for the new programmer)
Question: Does your book also give ways to write code so that it reads easier from a cognitive perspective? We already have clean code practices which should help a great deal, but with this framework in mind, there could be more to be done
Answer: Yes, it has a whole chapter on Code Smells and their relation to cognitive processing of code!
Question: Have you incorporated any research around the styles that people can also learn? Such as visual, audio, feel, doing. it would be interesting to see the breakdown of longterm, short term etc and what affect different styles also play into how people absorb and learn. Great talk btw.
Answer: I am not an expert in learning styles, but what I know the research into them seems to say they do not really work -> https://www.psychologicalscience.org/news/releases/learning-styles-debunked-there-is-no-evidence-supporting-auditory-and-visual-learning-psychologists-say.html
It seems people might be bad at choosing their own style also, shying away from needed practice (e.g. bad readers will choose visual style, leading them to read even less)
Question: I may have missed it but was it posted where we would be able to order the "The Programmer’s Brain"?
Answer: When it comes out (which should be this week!) the link will be on felienne.com/book
Just got the news the book is online!!! See: ttps://www.manning.com/books/the-programmers-brain
YOU MAY ALSO LIKE:
How to Read Complex Code without Getting a Headache
Felienne Hermans
Associate professor in software engineering
Delft University of Technology