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
@pati_gallardo Patricia Aas
NDC London 2019
T
S

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

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

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

6. This is not a code
review
@pati_gallardo

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

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

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

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

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

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

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

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

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

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

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

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

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

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

21. @pati_gallardo
10 Techniques
(finding an interesting
end to pull on)

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. @pati_gallardo
1. “Grepping”

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

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. @pati_gallardo
2. Where Is This Button?

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

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

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

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. @pati_gallardo
4. What Do The Tests Do?

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

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. @pati_gallardo
5. Refactoring

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

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. @pati_gallardo
6. Reading “main”

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

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. @pati_gallardo 7. The Graphical Layout

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

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. @pati_gallardo
8. Runtime Investigation

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

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

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

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. @pati_gallardo
9. Reading A “Class”

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

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. @pati_gallardo
10. Retelling or Rubber Ducking

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

54. @pati_gallardo
It’s an Iterative Process

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

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

57. Receiving a new contributor

58. @pati_gallardo
Excellence

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

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

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

62. Get into a
learning mode
@pati_gallardo

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

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

65. T
S
@pati_gallardo