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

2. Reading Other People's
Code
@pati_gallardo Patricia Aas
Web Rebels 2018

3. Patricia Aas - Vivaldi Browser
Programmer - mainly in C++
Currently : Vivaldi Technologies
Previously : Cisco Systems, Knowit, Opera Software
Master in Computer Science - main language Java
Twitter : @pati_gallardo

4. - So… You Got Someone
Else’s Code?
- Before You Start
- 10 Techniques
- Different is Good
@pati_gallardo

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

6. This is not a code
review
@pati_gallardo

7. Code is the
serialized version
of a mental
machine
@pati_gallardo

8. What We Are Lacking Is:
The Mental Model
What we are faced with is: pages and pages of code.
This is fine
@pati_gallardo

9. @pati_gallardo
Before You Start

10. #preperation
- Get the code
- Put it in source control
- Put it in a “smart” IDE
- Try to build it
- Try to run it
- Preferably in a debugger
@pati_gallardo

11. Browsers are MASSIVE
Vivaldi: 600,000 files
@pati_gallardo

12. @pati_gallardo
10 Techniques That Will
Help You Understand
Other People’s Code

13. 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

14. @pati_gallardo
1. Grepping

15. Strings you see
as ends to pull on
- in the GUI
- on the commandline
- in the logs
@pati_gallardo

16. 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

17. @pati_gallardo
2. Where Is This Button?

18. - 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

19. 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

20. @pati_gallardo
3. Following Inputs Events

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

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

24. 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

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

27. Refactoring is Opinionated:
Don’t get attached
This is throw-away code
@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
6. Reading “main”

30. The How
Execution Architecture
- Mainloop & event handling
- Read top to bottom
- Take notes & draw
- Important objects/functions
- Watch for common types
- Recurse@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 7. The Graphical Layout

33. - Find the Main Layout
- Find the (implicit) State
Machine
- This is what changes the
window contents
- Maps often to Use Cases
@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
8. Runtime Investigation

36. 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

37. - Use the debugger to
examine runtime state and
stacks
- Read the logs to see flow
- Run the tests
- Add logging
- Add tests and assertions
- Add a feature@pati_gallardo

38. 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

39. @pati_gallardo
9. Reading A “Class”

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

41. 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

42. @pati_gallardo
10. Retelling or Rubber Ducking

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

44. @pati_gallardo
Conclusion : Different Is Good

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

46. Make Everyone Feel Safe To Be Themselves
@pati_gallardo

47. @pati_gallardo

48. Vivaldi Swag
Patricia Aas, Vivaldi Technologies
@pati_gallardo
Photos from pixabay.com

49. Don’t be tempted to
criticize
If only… it were
different...
No. Breathe and
accept
@pati_gallardo

50. #philosophy
Running code is not linear,
reading code cannot be linear
either.
@pati_gallardo

51. #goals
- Establishing a vague
outline and fleshing it out
in an iterative process
- Taking notes and drawing
- Make documentation
- Teach others
@pati_gallardo

52. 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

53. Refactoring is opinionated
Use it to understand,
throw it away and go back to the original code
Do not judge
@pati_gallardo

54. You Need a Full Toolset
For synchronous execution the debugger is useful
For async the log will yield interesting places
@pati_gallardo

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

56. “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