Does Your Codebase Spark Joy?

A presentation at NDC Oslo in June 2020 in by Jenna Pederson

Slide 1

Slide 1

Does Your Codebase Spark Joy? @jennapederson | #NDCOslo

Slide 2

Slide 2

Agenda The backstory What is joy? Why do we want tidy? How do we find the magic? @jennapederson | #NDCOslo

Slide 3

Slide 3

What is the KonMari Method™? “The KonMari Method™ encourages tidying by category – not by location – beginning with clothes, then moving on to books, papers, komono (miscellaneous items), and, finally, sentimental items. Keep only those things that speak to the heart, and discard items that no longer spark joy. Thank them for their service – then let them go.” - konmari.com @jennapederson | #NDCOslo

Slide 4

Slide 4

What is joy? Different for each person and each team. Small teams - Being productive and confident across the stack Larger teams - Being productive and confident across the team and between teams; Being able to act on the risk of a particular change @jennapederson | #NDCOslo

Slide 5

Slide 5

Define what joy looks like This is what is looks like for me Productivity Confidence Quality built in Feedback Experimentation Effective decision making Consistency Collaboration Observe and monitor @jennapederson | #NDCOslo

Slide 6

Slide 6

1 We write code for humans 2 We’re more confident 3 We’re more productive 4 We build quality in early 5 Developer onboarding 6 Developer happiness 7 Cost savings @jennapederson | #NDCOslo Why do we want tidy? More importantly, how do we sell it to management?

Slide 7

Slide 7

We write code for humans “Programming is the art of telling another human what one wants the computer to do.” - Donald Knuth @jennapederson | #NDCOslo

Slide 8

Slide 8

We’re more confident “One of the magical effects of tidying is confidence in your decision-making capacity.” - Marie Kondo @jennapederson | #NDCOslo

Slide 9

Slide 9

We’re more productive We can find what we need. We can understand it more quickly. We get quicker feedback. We can automate some of our decisions. @jennapederson | #NDCOslo

Slide 10

Slide 10

We build quality in early Because we better understand the code, we’re more likely to write higher-quality code Bugs are not obscured by complex code It becomes easier to test @jennapederson | #NDCOslo

Slide 11

Slide 11

Developer onboarding What if your new teammate could on-board to your codebase in one day instead of one month or six months? @jennapederson | #NDCOslo

Slide 12

Slide 12

Developer happiness Do your codebase or your development processes make you want to throw things? @jennapederson | #NDCOslo

Slide 13

Slide 13

Cost savings All of these lead to cost savings. In the end, this is what the business cares about. @jennapederson | #NDCOslo

Slide 14

Slide 14

How to find the magic 1 Commit to tidying up 2 Visualize your destination 3 Discard what doesn’t spark joy 4 Tidy by category, not by location 5 Tidy a little everyday @jennapederson | #NDCOslo

Slide 15

Slide 15

Commit to tidying up Get management on board and get dedicated time on the calendar. @jennapederson | #NDCOslo

Slide 16

Slide 16

Visualize your destination Tidying is not our goal, but it’s the tool to get there. We need to define our end state and plan how we’ll get there. @jennapederson | #NDCOslo

Slide 17

Slide 17

Your destination Improved developer confidence when making changes and committing code BASELINE No test coverage No test suite at all No continuous integration HOW YOU’LL GET THERE Dedicate one person for entire sprint Add test framework to codebase Add one passing test Set test coverage thresholds to fail the test suite when coverage goes down Add CI hook to run test suite on code push Set expectations with team Task it out and put it on your kanban/sprint board @jennapederson | #NDCOslo

Slide 18

Slide 18

Your destination Save time spent on minor nits and common bugs during code reviews BASELINE No code style guide (defined or automated) No linters in use Comments in code reviews are for formatting style and small or minor errors Comments are more critical of the human than the code New devs get stuck on syntax and style (with criticism) More experienced devs get stuck debating style HOW YOU’LL GET THERE Dedicate one person for entire sprint Use a standard style guide for your stack Implement a linter on save Implement a code formatter on save Run each one time on the entire codebase Set expectations with team Task it out and put it on your kanban/sprint board @jennapederson | #NDCOslo

Slide 19

Slide 19

Discard what doesn’t spark joy Don’t skip this step. Dead code. Dead features. Unhelpful teammate. Unmaintained tests. Data. Heavy process. @jennapederson | #NDCOslo

Slide 20

Slide 20

Tidy by category, not by location Tidy in the right order. @jennapederson | #NDCOslo

Slide 21

Slide 21

Areas to tidy 1 Code formatting & style 2 Common errors 3 Testing 4 Names & comments 5 Refactoring 6 Beyond your codebase @jennapederson | #NDCOslo

Slide 22

Slide 22

Code formatting & style Using an automated formatter eliminates nits in code review comments and helps newcomers Example: Prettier @jennapederson | #NDCOslo

Slide 23

Slide 23

Common errors Using a linter helps find and fix common programming mistakes like deprecated APIs, unused variables or functions, undefined variable assignments, and security vulnerabilities Example: ESLint @jennapederson | #NDCOslo

Slide 24

Slide 24

Testing Having a well-maintained, passing test suite allows you to confidently change your code Examples: Unit tests, end-to-end tests @jennapederson | #NDCOslo

Slide 25

Slide 25

Names & comments Both names and comments communicate your intent to your reader @jennapederson | #NDCOslo

Slide 26

Slide 26

Don’t do this @jennapederson | #NDCOslo

Slide 27

Slide 27

Do this instead @jennapederson | #NDCOslo

Slide 28

Slide 28

Don’t do this @jennapederson | #NDCOslo

Slide 29

Slide 29

Do this instead @jennapederson | #NDCOslo

Slide 30

Slide 30

Refactoring Take a series of small structural changes, supported by tests to make your code easier to change @jennapederson | #NDCOslo

Slide 31

Slide 31

Feathers’ Algorithm For refactoring legacy code 1 Identify Change Points 2 Find test points 3 Break dependencies 4 Write tests 5 Make changes and refactor @jennapederson | #NDCOslo

Slide 32

Slide 32

Beyond your codebase Monitoring & observability UX & design Security Tools & processes @jennapederson | #NDCOslo

Slide 33

Slide 33

Tidy a little everyday Change your mindset. Make it a habit. @jennapederson | #NDCOslo

Slide 34

Slide 34

1 Train people 2 Set expectations 3 Have a plan 4 Reserve time for tidying @jennapederson | #NDCOslo Make it a habit

Slide 35

Slide 35

Train people Learn the tools Learn software design principles Learn the refactoring techniques Start a book club PRACTICE @jennapederson | #NDCOslo

Slide 36

Slide 36

Set expectations Style guides Test coverage Broken builds Always leave the codebase cleaner than you found it @jennapederson | #NDCOslo

Slide 37

Slide 37

Have a plan Plan it out like you would a new feature or project Task it out Put it on your kanban/sprint board Set goals and track to them Make progress visible @jennapederson | #NDCOslo

Slide 38

Slide 38

Reserve time for tidying Build time into your sprints, whether it’s 25% of one person or 100% of the team Do this every sprint @jennapederson | #NDCOslo

Slide 39

Slide 39

“If you tidy up in one shot, rather than little by little, you can dramatically change your mind-set.” - Marie Kondo @jennapederson | #NDCOslo

Slide 40

Slide 40

Define your joy. Find your magic. Clearing the physical digital clutter will help you clear the mental clutter. @jennapederson | #NDCOslo

Slide 41

Slide 41

Thank you! Q&A @jennapederson | #NDCOslo