Hate The Code

A brief commentary on how to change your engineering team's attitude about the code it writes.

Transcript

1. Hate the Code Making code suck less Ian Asaff 9/28/2012
2. • Awkward teenage phase of engineering team growth • Modest technical debt • Coding decisions based on legacy issues • Staying the course doesn't scale Where we are
3. We all own the code
4. Everyone writes janky code.
5. EVERYONE.
6. You are NOT the code you write. (your ego may not be aware of this)
7. • Encourages individual ownership • Discourages collective ownership • No feedback means easier to go off the "rails" (heh) Silo coding is bad
8. No feedback means slower growth as a developer...
9. Which means you are short-changing yourself every day.
10. • It's ok. • Really. • Code needs to get beaten up. • Tough love. Let's talk trash about our code
11. Need to bang out a feature?
12. First, get the bare essentials working (MVP)
13. Then... throw it to the wolves
14. • Every developer has something to contribute • "Hey, junior dev. Does this make sense to you?" • "Hey, senior dev. Would you have done it this way?" The takeaway is...
15. The next step...
16. Seek out criticism and feedback • “I know this isn’t great. What can I improve about it?” • "Am I better today than I was yesterday?"
17. A little secret...
18. You aren’t coding for yourself.
19. You are coding for the poor bastard coming in after you.
20. My last job: WTF is this shit?
21. Oh. I wrote this six months ago…
22. Our codebase is our startup
23. Iterate (refactor) quickly based on feedback (from other devs)
24. Don’t ignore pain. Dive into it. Setting up dev environment sucks. Ruby script for installation? Test data is irreplaceable. DB dump after migrations are run? Let's make things suck less
25. “This code is fragile and mission critical. Don’t touch it.” VS “This code is fragile and mission critical. Let’s refactor so it’s easy to understand and debug.” What's better?
26. What annoys you every day? How can you make it suck a little less?
27. What about our bottom line?
28. There's business value here!
29. • “That’s X’s code. Ask X how it works.” “X is out until Monday…” • Low bus factor • “Just this one time…” • “We need to ship this…” Technical debt is expensive
30. • “I think it basically works this way… Let’s dig in a bit.” • Higher bus factor • Frequent discussion about the code Let's move toward...
31. Easier to understand code means...
32. Faster ramp-up time for new devs (more productivity → $$$)
33. Extending and refactoring are less this
34. and more this
35. which ultimately leads to more
36. ABC -- Always Be Communicating The takeaway
37. So where do we start?
38. Everyone reviews code
39. Be merciless with feedback but...
40. Don't be an ass.
41. Remember you are not your code.
42. Enjoy leveling up as a developer while increasing your value to the business
43. Thanks.