Speaker Marit van Dijk

For more see the table of contents

---

Notes

• We spend more time reading code than writing code
• Read code when adding features, fixing bugs, understand new codebase, when doing code review, when learning new technologies, etc
• Up to 58% of time comprehending existing source code – Felienne Hermans, Programmer’s Brain
• We spend time learning by writing code. We rarely deliberately practicing reading code
• 1992 research – three groups. One learned by writing and reading code. One write and read but also explanations about code such as why made decisions. Last group only read code with those explanations. Second and third groups did better.

Code reading club

• http://codereading.club
• Marit participated in a monthly club – https://maritvandijk.com/code-reading-club/
• Printed code sample that is 1-2 pages, structured exercises (ex: annotate code with markers)
• Practice reading a variety of exercises
• Focus on reading to understand rather than to judge

Example exercises

• First glance – 1 minute.. Note the first and second thing that catches your eye. Think about why noticed first. Examples was in Groovy
• Identify components and relationships – ex: methods
• Identify the five most important lines. If don’t discuss up front what “most important” means, answers vary. The group then converged on what was most important
• Identify concepts. Someone in the group is likely to know
• Summarize what think code does

Lack of info

• Could be short or long term, details, names, too many things
• Chunking – 3-5 things

Lack of knowledge

• language, constructs, business domain
• Create a list of what don’t know, research and memorize if relevant

Lack of processing power

• Too much to keep track of
• Dependency graph – on paper, draw arrows to show where variable used
• State table – keep track of variable values

Dimensions of code reading

• Structure – we don’t read linearly. More experienced programmers scan code a lot before focusing on a piece
  • Domain – data
• Concepts – programming and domain
• Context – why app written, who uses it

Getting started

• Checkout the code. Proves found project and have access
• Look at package structure. How many? Names? If see name unfamiliar with, add to list so look up what means later
• Build project to ensure can
• Read readme.md. Tip: Check readme to ensure clear how to build and test application
• See if can run locally and explore in UI if possible
• Find starting point – main method, export
• Docs 0 exL swagger

IntelliJ Features

• AI assistant – Prompt to ask what’s wrong and how to fix
• Generate diagram to show relationships between classes. Tip: draw own to focus on part interested in and remember it better
• Generate matrix showing relationship between modules. SHows number of dependencies as well.
• Can trace code outside in and see where leads
• Endpoints view – to go a part of the code.
• Be able to search/navigate without thinking

Outside IDE

• Identify use case
• Draw own diagrams

Understanding code

• structured exercises can help
• start with the thing you noticed in the 1 minute example to get past being stuck
• IDE can help you
• syntax highlighting
• pull up documentation in pop up
• pull up code in pop up
• collapse sections of code
• find references
• view tests – hopefully their names express the indended behavior
• debugger
• AI assistant can give summary of a commit or set of commits

My take

The code was way too small on the 1 minute example. It was fine on everything else.. Marit invited us to move. Two people (I was one) sat on the floor in the font. I liked the demo. My brain was full before the session started though.