Someone else's code. Even worse, thousands of lines, maybe hundreds of files of other peoples code. Is there a way to methodically read and understand other peoples work, build their mental models? In this talk I will go through techniques I have developed throughout 18 years of programming. Hopefully, you will walk away with a plan on how to approach a new code base. But even more, I hope you walk away with a feeling of curiosity, wanting to get to know your fellow programmers through their code.

1. T
S
@pati_gallardo

2. Reading
Other People's Code
Patricia Aas
NDC Copenhagen 2019
T
S
@pati_gallardo

3. Patricia Aas - Consultant
T
S
Programmer, Application Security
Currently : T S
Previously : Vivaldi, Cisco Systems, Knowit, Opera Software
Master in Computer Science - main language Java
Pronouns: she/her
@pati_gallardo

4. - So… You Got Someone
Else’s Code?
- Before You Start
- 10 Techniques
- Receiving a new
contributor
@pati_gallardo
4

5. So… You Got Someone Else's Code?
@pati_gallardo

6. This is not a code
review
@pati_gallardo
6

7. If you approach other people's
code wanting to learn
You will learn
If you approach to criticize
You will criticize
@pati_gallardo
7

8. “Instead of condemning people,
let’s try to understand them.
Let’s try to figure out why they do what they do.
That’s a lot more profitable and intriguing than criticism;
and it breeds sympathy, tolerance and kindness.”
Dale Carnegie, How to Win Friends & Influence People
@pati_gallardo
8

9. You want these
people to like
you!
@pati_gallardo
9

10. Code is the
serialized version
of a
Mental Machine
@pati_gallardo
10

11. With someone else's code we are lacking
The Mental Machine
Instead what we are faced with is
Possibly hundreds or thousands of files
@pati_gallardo
11

12. Running code is not linear,
reading code cannot be
linear either.
Also it doesn’t scale
@pati_gallardo
12

13. I’ve seen some big codebases
Example: Vivaldi has 600,000 files
@pati_gallardo
13

14. - So… You Got Someone
Else’s Code?
- Before You Start
- 10 Techniques
- Receiving a new
contributor
@pati_gallardo
14

15. Before You Start (or getting started?)@pati_gallardo

16. Get the Code!
Source ControlRun tests
Put in debugger
Run application
Smart IDE
Build
Before you
start
@pati_gallardo
16

17. Motivation
1. Learn something
2. Make documentation
3. Teach others
@pati_gallardo
17

18. Code is like Balls of Yarn on the FLoor
It’s a mess.
How do you know where to begin?
Find an interesting end
Pull on it
@pati_gallardo
18

19. The Process
- Establish a vague outline
- Flesh it out in an iterative
process
- Take notes
- Draw things out
@pati_gallardo
19

20. - So… You Got Someone
Else’s Code?
- Before You Start
- 10 Techniques
- Receiving a new
contributor
@pati_gallardo
20

21. 10 Techniques for
Reading Code
@pati_gallardo
21

22. 1. Grepping
2. Where is this button?
3. Following input events
4. What do the tests do?
5. Refactoring
6. Reading “main”
7. The graphical layout
8. Runtime Investigation
9. Reading a class
10. Retelling or Rubber Ducking@pati_gallardo

23. 1. “Grepping”@pati_gallardo

24. Grep for strings you
see
- in the GUI
- on the commandline
- in the logs
@pati_gallardo
24
1.“Grepping”

25. 1. Grepping
2. Where is this button?
3. Following input events
4. What do the tests do?
5. Refactoring
6. Reading “main”
7. The graphical layout
8. Runtime Investigation
9. Reading a class
10. Retelling or Rubber Ducking@pati_gallardo

26. 2. Where Is This Button?@pati_gallardo

27. - Grep for the button text
- Find the button
- Set a breakpoint on
onClick
- Click on the button
- Look at the stack
- Traverse up the widget
hierarchy@pati_gallardo
27
2. Where Is This Button?

28. 1. Grepping
2. Where is this button?
3. Following input events
4. What do the tests do?
5. Refactoring
6. Reading “main”
7. The graphical layout
8. Runtime Investigation
9. Reading a class
10. Retelling or Rubber Ducking@pati_gallardo

29. @pati_gallardo
3. Following Inputs Events@pati_gallardo

30. Investigating Your GUI
framework
- Trace platform events
- Look at graphics output
- Find the platform
integration architecture
@pati_gallardo
30
3. Following Inputs Events

31. 1. Grepping
2. Where is this button?
3. Following input events
4. What do the tests do?
5. Refactoring
6. Reading “main”
7. The graphical layout
8. Runtime Investigation
9. Reading a class
10. Retelling or Rubber Ducking@pati_gallardo

32. 4. What Do The Tests Do?@pati_gallardo

33. Integration / System Tests
- How to run it
- Use Cases
- Write tests to drive the code
you’re looking at
- Write tests to examine your
assumptions
@pati_gallardo
33
4. What Do The Tests Do?

34. 1. Grepping
2. Where is this button?
3. Following input events
4. What do the tests do?
5. Refactoring
6. Reading “main”
7. The graphical layout
8. Runtime Investigation
9. Reading a class
10. Retelling or Rubber Ducking@pati_gallardo

35. 5. Refactoring@pati_gallardo

36. Refactoring is Opinionated
Don’t get attached
This is throw-away code
@pati_gallardo
36
5. Refactoring

37. 1. Grepping
2. Where is this button?
3. Following input events
4. What do the tests do?
5. Refactoring
6. Reading “main”
7. The graphical layout
8. Runtime Investigation
9. Reading a class
10. Retelling or Rubber Ducking@pati_gallardo

38. 6. Reading “main”@pati_gallardo

39. What drives execution
in this code?
- Mainloop & event handling
- Read top to bottom
- Take notes & draw
- Important objects/functions
- Watch for common types
- Recurse@pati_gallardo
39
6. Reading “main”

40. 1. Grepping
2. Where is this button?
3. Following input events
4. What do the tests do?
5. Refactoring
6. Reading “main”
7. The graphical layout
8. Runtime Investigation
9. Reading a class
10. Retelling or Rubber Ducking@pati_gallardo

41. 7. The Graphical Layout@pati_gallardo

42. Window Layout
- Find the Main Layout
- This is what changes the
window contents
- Maps often to Use Cases
- Find the (implicit) State
Machine
@pati_gallardo
42
7. The Graphical Layout

43. 1. Grepping
2. Where is this button?
3. Following input events
4. What do the tests do?
5. Refactoring
6. Reading “main”
7. The graphical layout
8. Runtime Investigation
9. Reading a class
10. Retelling or Rubber Ducking@pati_gallardo

44. 8. Runtime Investigation@pati_gallardo

45. Runtime Investigation
● Synchronous: Debugger is great!
● Asynchronous: Use log to learn where to break
● “Printf debugging”
● (Profiler)
@pati_gallardo
45

46. Rough Outline of Architectures
- Event driven : main loop, async, event handlers
- Request handling : one thread per request - mostly
synchronous
- Command line tool : mostly synchronous, takes input,
produces output
@pati_gallardo
46

47. - Use the debugger to
examine state and stacks
- Read the logs to see flow
- Use the tests to drive flow
- Add logging
- Add tests and assertions
- Add a feature
@pati_gallardo
47
8. Runtime Investigation

48. 1. Grepping
2. Where is this button?
3. Following input events
4. What do the tests do?
5. Refactoring
6. Reading “main”
7. The graphical layout
8. Runtime Investigation
9. Reading a class
10. Retelling or Rubber Ducking@pati_gallardo

49. 9. Reading A “Class”@pati_gallardo

50. - Which interfaces does it
implement?
- Who uses it and how?
- Public functions are the
“mains” of a class
(Getters don’t count)
@pati_gallardo
50
9. Reading A “Class”

51. 1. Grepping
2. Where is this button?
3. Following input events
4. What do the tests do?
5. Refactoring
6. Reading “main”
7. The graphical layout
8. Runtime Investigation
9. Reading a class
10. Retelling or Rubber Ducking@pati_gallardo

52. 10. Retelling or Rubber Ducking@pati_gallardo

53. Explain It To Someone
Write a (fictional) blog post
Write some documentation
Make an internal presentation
(Ducks aren't very motivating)
@pati_gallardo
53
10. Retelling or Rubber Ducking

54. It’s an Iterative Process@pati_gallardo

55. The Process
- Establish a vague outline
- Flesh it out in an iterative
process
- Take notes
- Draw things out
@pati_gallardo
55

56. - So… You Got Someone
Else’s Code?
- Before You Start
- 10 Techniques
- Receiving a new
contributor
@pati_gallardo
56

57. Receiving a new contributor
@pati_gallardo
57

58. Excellence@pati_gallardo

59. What is the predictor of team excellence?
Google's Project Aristotle concluded
Psychological Safety
@pati_gallardo
59

60. “The term is meant to suggest neither a careless sense of
permissiveness, nor an unrelentingly positive affect but,
rather, a sense of confidence that the team will not
embarrass, reject, or punish someone for speaking up.
This confidence stems from mutual respect and trust
among team members.”
Psychological Safety and Learning Behavior in Work, Amy Edmondson
@pati_gallardo
60

61. Comfort Learning
Apathy Anxiety
high
low
low high
Psychological
Safety
Motivation &
Accountability
Amy Edmondson
@pati_gallardo
61

62. Get into a
learning mode
@pati_gallardo
62

63. Great code should be personal
We want people to take pride
in their work
Style is individual
Learn to appreciate other
people's code
@pati_gallardo
63

64. T
S
P f .
Patricia Aas, T S
@pati_gallardo

65. T
S
@pati_gallardo