Recommended
More Related Content
Similar to Clean code is like deodorant. If you don’t use it your coworkers will hate you
Similar to Clean code is like deodorant. If you don’t use it your coworkers will hate you (20)
Recently uploaded
Recently uploaded (20)
Clean code is like deodorant. If you don’t use it your coworkers will hate you
- 1. Finding Your Organization’s Code Deodorant How we, accidentally, found our way to promote clean code- a true story.
- 2. Ittai Zeidman Head of Backend Engineering @ Wix @ittaiz Clean code fanatic Proud spouse and father of 3
- 4. Over 70 million users From 50 to 1,000 employees ~350 developers Wix
- 6. RPC Monitoring Security Test Infrastructure Wix Server Infra > 15 libraries > 60 contributors
- 7. My manager and I A junior developer Legions of developers My aha moment
- 8. Two Truths
- 9. Clean code is NOT going to happen naturally
- 10. When everyone became abstract enough, no one was responsible.
- 11. Lack of Coverage Bad Naming Mixed Levels of Abstraction No TDD Over- Engineering Long Methods theblogofkevin.wordpress.com
- 13. You have to face it head-on
- 14. Section Slide 01 Clean your own code 01 edrianthomidis.blogspot.com
- 15. Others read your code Microsoft clip art
- 18. If it’s not clean before the push, it will never be clean.
- 19. You are the gatekeeper of good contributions.
- 20. Contributions have to be sustainable – for you
- 21. Contributions have to be sustainable – for you and for them.
- 22. Contributions have to be sustainable – for you and for them. So talk it out.
- 23. #1 Infra-Relevance The contribution should help several projects. A Good Contribution
- 24. A Good Contribution #2 YAGNI Contribute the least code possible, add features later.
- 25. A Good Contribution #3 The ‘Boy Scout’ Rule Contributions leave existing libraries’ code cleaner.
- 26. Every API has a purpose and was driven by a test. A Good Contribution #4 TDD
- 27. Less than 100% confidence is unacceptable. A Good Contribution #5 Regression Confidence
- 28. #1 Infra-Relevance The contribution should help several projects. Pay it forward #2 YAGNI Contribute the least code possible, add features later. #3 The ‘Boy Scout’ Rule Contributions leave existing libraries’ code cleaner. #4 TDD Every API has a purpose and was driven by a test. #5 Regression Confidence Less than 100% confidence is unacceptable. @ittaiz
- 30. Did we have to use the infra to promote clean code?
- 31. How YOU can take it from here • Face it head-on • Make it a priority • Find your own tools • Ours- 01 Clean your own code 02 Harness contributions 03 Mentorship
- 33. Clean code is like deodorant.
- 34. Clean code is like deodorant. If you don’t use it your coworkers will hate you.
Editor's Notes
- There are probably many ways to promote clean code, I’ll be talking about one that worked well for us. Clean code was actually a side effect resulting from trying to solve another issue, but it came to be such a powerful one that we thought it worth sharing, so you might benefit from our story and know what to expect if you are implementing it in your company.
- Server guild manager Wix has a very polyglot production topology but the vast majority of it runs on a shared jvm stack. This shared stack is comprised of OSS, an internal framework and internal shared libraries all of which is coined the infra. My previous position was the server software infrastructure team leader and This story happened when I first came to Wix, and was in charge of the shared libraries, which are: Shared by multiple projects Exposed to many developers Explain basic terms: ‘infra code’ About Wix – by a show of hands, how many do not know what Wix does? Wix is one of the biggest website building platforms and home to over 70 million users. We make building a stunning website easy. About Wix culture – embracing many methodologies that have recently emerged just because they work well for us: TDD, continuous integration, React etc. We also get support from management for it. ----- Meeting Notes (19/10/15 12:10) ----- slides to talk ratio needs to be higher wix slide (a bit biz but mainly tech numbers) then wix infra maybe delete the notes and practice "off-script" something about why this happened to be the infra- both concentration of good developers and since we took it apon ourselves to be the gatekeepers of clean code (see where it needs to be order wise) maybe reverse the me slide with the title slide
- Server guild manager Wix has a very polyglot production topology but the vast majority of it runs on a shared jvm stack. This shared stack is comprised of OSS, an internal framework and internal shared libraries all of which is coined the infra. My previous position was the server software infrastructure team leader and This story happened when I first came to Wix, and was in charge of the shared libraries, which are: Shared by multiple projects Exposed to many developers Explain basic terms: ‘infra code’ About Wix – by a show of hands, how many do not know what Wix does? Wix is one of the biggest website building platforms and home to over 70 million users. We make building a stunning website easy. About Wix culture – embracing many methodologies that have recently emerged just because they work well for us: TDD, continuous integration, React etc. We also get support from management for it. ----- Meeting Notes (19/10/15 12:10) ----- slides to talk ratio needs to be higher wix slide (a bit biz but mainly tech numbers) then wix infra maybe delete the notes and practice "off-script" something about why this happened to be the infra- both concentration of good developers and since we took it apon ourselves to be the gatekeepers of clean code (see where it needs to be order wise) maybe reverse the me slide with the title slide ----- Meeting Notes (24/10/15 21:22) ----- wix stats.
- Server guild manager Wix has a very polyglot production topology but the vast majority of it runs on a shared jvm stack. This shared stack is comprised of OSS, an internal framework and internal shared libraries all of which is coined the infra. My previous position was the server software infrastructure team leader and This story happened when I first came to Wix, and was in charge of the shared libraries, which are: Shared by multiple projects Exposed to many developers Explain basic terms: ‘infra code’ About Wix – by a show of hands, how many do not know what Wix does? Wix is one of the biggest website building platforms and home to over 70 million users. We make building a stunning website easy. About Wix culture – embracing many methodologies that have recently emerged just because they work well for us: TDD, continuous integration, React etc. We also get support from management for it. ----- Meeting Notes (19/10/15 12:10) ----- slides to talk ratio needs to be higher wix slide (a bit biz but mainly tech numbers) then wix infra maybe delete the notes and practice "off-script" something about why this happened to be the infra- both concentration of good developers and since we took it apon ourselves to be the gatekeepers of clean code (see where it needs to be order wise) maybe reverse the me slide with the title slide ----- Meeting Notes (24/10/15 21:22) ----- wix stats.
- Server guild manager Wix has a very polyglot production topology but the vast majority of it runs on a shared jvm stack. This shared stack is comprised of OSS, an internal framework and internal shared libraries all of which is coined the infra. My previous position was the server software infrastructure team leader and This story happened when I first came to Wix, and was in charge of the shared libraries, which are: Shared by multiple projects Exposed to many developers Explain basic terms: ‘infra code’ About Wix – by a show of hands, how many do not know what Wix does? Wix is one of the biggest website building platforms and home to over 70 million users. We make building a stunning website easy. About Wix culture – embracing many methodologies that have recently emerged just because they work well for us: TDD, continuous integration, React etc. We also get support from management for it. ----- Meeting Notes (19/10/15 12:10) ----- slides to talk ratio needs to be higher wix slide (a bit biz but mainly tech numbers) then wix infra maybe delete the notes and practice "off-script" something about why this happened to be the infra- both concentration of good developers and since we took it apon ourselves to be the gatekeepers of clean code (see where it needs to be order wise) maybe reverse the me slide with the title slide
- Server guild manager Wix has a very polyglot production topology but the vast majority of it runs on a shared jvm stack. This shared stack is comprised of OSS, an internal framework and internal shared libraries all of which is coined the infra. My previous position was the server software infrastructure team leader and This story happened when I first came to Wix, and was in charge of the shared libraries, which are: Shared by multiple projects Exposed to many developers Explain basic terms: ‘infra code’ About Wix – by a show of hands, how many do not know what Wix does? Wix is one of the biggest website building platforms and home to over 70 million users. We make building a stunning website easy. About Wix culture – embracing many methodologies that have recently emerged just because they work well for us: TDD, continuous integration, React etc. We also get support from management for it. ----- Meeting Notes (19/10/15 12:10) ----- slides to talk ratio needs to be higher wix slide (a bit biz but mainly tech numbers) then wix infra maybe delete the notes and practice "off-script" something about why this happened to be the infra- both concentration of good developers and since we took it apon ourselves to be the gatekeepers of clean code (see where it needs to be order wise) maybe reverse the me slide with the title slide
- Birth story. This small story is from the middle of the journey I was maintaining and developing ~15 libraries, riddled with technical debt, alone while being constantly hammered with new features and changes. My boss and I decided that the only sustainable way is to use contributions: “if it isn’t critical in time or severity or located in the core you should tell people that if they want it they need to contribute it or wait”. This was a big change and had its ups and downs. One incident shaped our path and led the way A junior developer needed a feature and just like everyone else he was requested to contribute it. The submitted contribution was very poor in all counts of design, coverage and cleanliness. We did a couple of cycles of online and offline code-reviews which fixed some minor issues but didn’t drive the message home. I went to my boss and told him I’m not sure it’s worth the effort and maybe I should do the feature, either now if he thinks it’s critical or have it enter the backlog. He insisted and said it’s important for him that all developers will be able to contribute to the shared libraries. After a few more cycles I had to go to my boss again and explain that other features will be delayed… He still insisted. It took us about 7 cycles on the feature which was a big investment on my part. The contributed code was very clean and future PRs from that developer were of much higher quality. The most important aspect was a week later that developer started experimenting with TDD on his own home projects to the point he practices TDD thoroughly and teaches others which was the real a-ha moment for me. These actions made us realize there is a path here to spreading clean code. ---------------------------------------------- There are 2 truths I have learned throughout this process…
- Clean Code is NOT going to happen naturally Wix is a fast growing company, both in terms of its business and number of engineers. Shared libraries were everyone’s responsibility and when “everyone” became an abstract enough notion it meant no-one was responsible. ----------------------------------- In fact, what’s going to happen naturally is dirty code…. ----- Meeting Notes (19/10/15 12:10) ----- emphasize the everyone and no-one
- Clean Code is NOT going to happen naturally Wix is a fast growing company, both in terms of its business and number of engineers. Shared libraries were everyone’s responsibility and when “everyone” became an abstract enough notion it meant no-one was responsible. ----------------------------------- In fact, what’s going to happen naturally is dirty code…. ----- Meeting Notes (19/10/15 12:10) ----- emphasize the everyone and no-one
- Clean Code is NOT going to happen naturally Wix is a fast growing company, both in terms of its business and number of engineers. Shared libraries were everyone’s responsibility and when “everyone” became an abstract enough notion it meant no-one was responsible. ----------------------------------- In fact, what’s going to happen naturally is dirty code…. ----- Meeting Notes (19/10/15 12:10) ----- emphasize the everyone and no-one
- And indeed more often than not people pushed dirty code. We had a myriad of Code smells (coined by Kent Beck) indicate possibly a deeper problem in design. 2-3 examples of what this smell might lead to (laying the ground for technical debt). Explain each by a very painful example. Why it is not in anyone’s interest to invest (my small change) : Code duplication (mainly because the change is “small” and refactoring to a common place is too much work for my small change) High coupling between modules (since I just need my small change in, I can’t bother to think about the entire scope) Lack of TDD in the design sense which created hard to use APIs and tests which don’t say why a feature is needed but only how it was implemented --------------------------- So if it’s not going to happen naturally… ----- Meeting Notes (19/10/15 12:10) ----- see if i should only concentrate on those related to the infra lack of TDD => something more binary
- And indeed more often than not people pushed dirty code. We had a myriad of Code smells (coined by Kent Beck) indicate possibly a deeper problem in design. 2-3 examples of what this smell might lead to (laying the ground for technical debt). Explain each by a very painful example. Why it is not in anyone’s interest to invest (my small change) : Code duplication (mainly because the change is “small” and refactoring to a common place is too much work for my small change) High coupling between modules (since I just need my small change in, I can’t bother to think about the entire scope) Lack of TDD in the design sense which created hard to use APIs and tests which don’t say why a feature is needed but only how it was implemented --------------------------- So if it’s not going to happen naturally… ----- Meeting Notes (19/10/15 12:10) ----- see if i should only concentrate on those related to the infra lack of TDD => something more binary
- You have to face it head-on Even if every push contained a small amount of code smells their cost on the TECHNICAL DEBT is often exponential – You now have land-mines riddled in every intersection of the code and they tend to blow up when you least have the time to handle them. ----------------------------------- So here’s how we tackled it. Step number one….
- I first decided that the most important manner of raising the bar is by doing it myself This helped me spread clean code since the infra code is read by many developers wanting to use it The ability to help people with similar pains since we face the same dilemmas ----- Meeting Notes (19/10/15 12:10) ----- "do as i do, not as i say"
- I started off by adding email notifications post push and reviewed all code that was pushed I tried talking with people about post push cleanups Had little success since they were always busy with the next thing You gotta draw the line somewhere (and it has to be before the push) Thought: add email graphic here?
- I started off by adding email notifications post push and reviewed all code that was pushed I tried talking with people about post push cleanups Had little success since they were always busy with the next thing You gotta draw the line somewhere (and it has to be before the push) Thought: add email graphic here?
- Given dirty code contributions still kept coming I realized they also had to be addressed. Remember the birth story? ------------------------------------------ Here are 3 things we learned the hard way…
- I started off by adding email notifications post push and reviewed all code that was pushed I tried talking with people about post push cleanups Had little success since they were always busy with the next thing You gotta draw the line somewhere (and it has to be before the push) Thought: add email graphic here?
- I decided to close off pushes to master and move to Forks and PRs on GitHub This got some backlash at the beginning – EXAMPLES but over time people learned that a well formed contribution gets handled fast and that the need to manage contributions is real and not a control issue -------------------------------------------- A backlog began forming up and we had to do something about it… Thought: add backlog graphic?
- For us - minimize the amount of work we need to do for each PR For them - minimize the frustration of contributors of having back-and-forths on their code Take code reviews to the next level: building a conversation where we – explain our motivation for every change to contributor, give feedback about tdd and design and not only about end contribution, spend several iterations of review per PR until the contributor and the reviewer both feel content and in general educating people about what we demand from code contributed to us. Thought: should this be split up to several slides?
- For us - minimize the amount of work we need to do for each PR For them - minimize the frustration of contributors of having back-and-forths on their code Take code reviews to the next level: building a conversation where we – explain our motivation for every change to contributor, give feedback about tdd and design and not only about end contribution, spend several iterations of review per PR until the contributor and the reviewer both feel content and in general educating people about what we demand from code contributed to us. Thought: should this be split up to several slides?
- For us - minimize the amount of work we need to do for each PR For them - minimize the frustration of contributors of having back-and-forths on their code Take code reviews to the next level: building a conversation where we – explain our motivation for every change to contributor, give feedback about tdd and design and not only about end contribution, spend several iterations of review per PR until the contributor and the reviewer both feel content and in general educating people about what we demand from code contributed to us. Thought: should this be split up to several slides?
- These points talk about the end conclusion (the do’s), you can explain using the don’ts. For instance TDD: people usually document how the code tests, its purpose is more important. Must have specific examples for each. Yagni for instance – very simple idea but hard to do… ------------------------------------------ The feedback, both positive and negative, from these efforts opened our appetite to spreading clean code in our group. ----- Meeting Notes (19/10/15 12:10) ----- TDD- why it's important for me (it's important to me that the APIs) split to 6 slides (1 for every bullet and this slide at the end) YAGNI- say you aint gonna need it
- These points talk about the end conclusion (the do’s), you can explain using the don’ts. For instance TDD: people usually document how the code tests, its purpose is more important. Must have specific examples for each. Yagni for instance – very simple idea but hard to do… ------------------------------------------ The feedback, both positive and negative, from these efforts opened our appetite to spreading clean code in our group. ----- Meeting Notes (19/10/15 12:10) ----- TDD- why it's important for me (it's important to me that the APIs) split to 6 slides (1 for every bullet and this slide at the end) YAGNI- say you aint gonna need it
- These points talk about the end conclusion (the do’s), you can explain using the don’ts. For instance TDD: people usually document how the code tests, its purpose is more important. Must have specific examples for each. Yagni for instance – very simple idea but hard to do… ------------------------------------------ The feedback, both positive and negative, from these efforts opened our appetite to spreading clean code in our group. ----- Meeting Notes (19/10/15 12:10) ----- TDD- why it's important for me (it's important to me that the APIs) split to 6 slides (1 for every bullet and this slide at the end) YAGNI- say you aint gonna need it
- These points talk about the end conclusion (the do’s), you can explain using the don’ts. For instance TDD: people usually document how the code tests, its purpose is more important. Must have specific examples for each. Yagni for instance – very simple idea but hard to do… ------------------------------------------ The feedback, both positive and negative, from these efforts opened our appetite to spreading clean code in our group. ----- Meeting Notes (19/10/15 12:10) ----- TDD- why it's important for me (it's important to me that the APIs) split to 6 slides (1 for every bullet and this slide at the end) YAGNI- say you aint gonna need it
- These points talk about the end conclusion (the do’s), you can explain using the don’ts. For instance TDD: people usually document how the code tests, its purpose is more important. Must have specific examples for each. Yagni for instance – very simple idea but hard to do… ------------------------------------------ The feedback, both positive and negative, from these efforts opened our appetite to spreading clean code in our group. ----- Meeting Notes (19/10/15 12:10) ----- TDD- why it's important for me (it's important to me that the APIs) split to 6 slides (1 for every bullet and this slide at the end) YAGNI- say you aint gonna need it
- These points talk about the end conclusion (the do’s), you can explain using the don’ts. For instance TDD: people usually document how the code tests, its purpose is more important. Must have specific examples for each. Yagni for instance – very simple idea but hard to do… ------------------------------------------ The feedback, both positive and negative, from these efforts opened our appetite to spreading clean code in our group. ----- Meeting Notes (19/10/15 12:10) ----- TDD- why it's important for me (it's important to me that the APIs) split to 6 slides (1 for every bullet and this slide at the end) YAGNI- say you aint gonna need it
- The last distribution form we use is one we identified only after the fact and it was mentorship. Ongoing mentorship every new team-member gets brain washed with these principles at code review time even the smallest detail will be discussed so that this line of thought will become a second nature and part of their culture One-time off mentorships usually surface when developers come to discuss a dilemma (how to use a certain piece from the infra, how to test it or whether it even exists) We try to use these encounters to ask questions rooting from the same sources and when we go over code together to point out code-smells we see to people be them infra related or not
- These points talk about the end conclusion (the do’s), you can explain using the don’ts. For instance TDD: people usually document how the code tests, its purpose is more important. Must have specific examples for each. Yagni for instance – very simple idea but hard to do… ------------------------------------------ The feedback, both positive and negative, from these efforts opened our appetite to spreading clean code in our group. ----- Meeting Notes (19/10/15 12:10) ----- TDD- why it's important for me (it's important to me that the APIs) split to 6 slides (1 for every bullet and this slide at the end) YAGNI- say you aint gonna need it
- Server guild manager Wix has a very polyglot production topology but the vast majority of it runs on a shared jvm stack. This shared stack is comprised of OSS, an internal framework and internal shared libraries all of which is coined the infra. My previous position was the server software infrastructure team leader and This story happened when I first came to Wix, and was in charge of the shared libraries, which are: Shared by multiple projects Exposed to many developers Explain basic terms: ‘infra code’ About Wix – by a show of hands, how many do not know what Wix does? Wix is one of the biggest website building platforms and home to over 70 million users. We make building a stunning website easy. About Wix culture – embracing many methodologies that have recently emerged just because they work well for us: TDD, continuous integration, React etc. We also get support from management for it. ----- Meeting Notes (19/10/15 12:10) ----- slides to talk ratio needs to be higher wix slide (a bit biz but mainly tech numbers) then wix infra maybe delete the notes and practice "off-script" something about why this happened to be the infra- both concentration of good developers and since we took it apon ourselves to be the gatekeepers of clean code (see where it needs to be order wise) maybe reverse the me slide with the title slide
- These points talk about the end conclusion (the do’s), you can explain using the don’ts. For instance TDD: people usually document how the code tests, its purpose is more important. Must have specific examples for each. Yagni for instance – very simple idea but hard to do… ------------------------------------------ The feedback, both positive and negative, from these efforts opened our appetite to spreading clean code in our group. ----- Meeting Notes (19/10/15 12:10) ----- TDD- why it's important for me (it's important to me that the APIs) split to 6 slides (1 for every bullet and this slide at the end) YAGNI- say you aint gonna need it
- how do you do code contributions without hurting people but not giving up on standards Clean code practices expectations Feedback loop- how much time it took us Startups and teams
- To summarize… If you’re here you’re probably passionate about clean code. What I want you to take away is that opportunities for promoting clean code are all around us We just need to face them head-on! Your fellow developers probably also want clean code. They are sometimes stressed, usually by themselves. and often aren’t educated enough. That’s on us. ----- Meeting Notes (19/10/15 12:10) ----- maybe explain why books aren't enough clean code is like deodearnt if you promote it people will use it and then you don't have code smells if bacteria, maybe use "culture"
- To summarize… If you’re here you’re probably passionate about clean code. What I want you to take away is that opportunities for promoting clean code are all around us We just need to face them head-on! Your fellow developers probably also want clean code. They are sometimes stressed, usually by themselves. and often aren’t educated enough. That’s on us. ----- Meeting Notes (19/10/15 12:10) ----- maybe explain why books aren't enough clean code is like deodearnt if you promote it people will use it and then you don't have code smells if bacteria, maybe use "culture"
- To summarize… If you’re here you’re probably passionate about clean code. What I want you to take away is that opportunities for promoting clean code are all around us We just need to face them head-on! Your fellow developers probably also want clean code. They are sometimes stressed, usually by themselves. and often aren’t educated enough. That’s on us. ----- Meeting Notes (19/10/15 12:10) ----- maybe explain why books aren't enough clean code is like deodearnt if you promote it people will use it and then you don't have code smells if bacteria, maybe use "culture"