Engineering Excellence

A good engineering team writes code that lives through time, people & scale. At most companies engineering excellence takes a back seat because of various reasons. This talk will show how to maintain engineering standards at all phases of the project to build great teams and deliver great software.

Transcript

1. Naren 🐦@DudeWhoCode Engineering Excellence RubyConf 2022
2. 🐺 Full time adventurer with Tensoon 👨💻 Software Consultant 🛠 Engineering Lead @ Arcana.Network ☕ Chief Co ff ee O ff i cer @ La Vita Cafe 🐦 @DudeWhoCode About
3. How to make espresso ☕
4. Dose
5. Distribute
6. Tamp
7. Extract
8. Enjoy the coffee 🙈
9. • Software engineering is writing code that changes with TIME, PEOPLE and SCALE Software Engineering
10. • E ffi ciently delivering to customers and taking pride and satisfaction from the work • Non functional requirements that keep the system running • Improves the daily work and productivity of the engineers • It’s a journey, not the end goal Engineering Excellence
11. Product
12. • Ship prototypes and prove your product to gain early adopters • No early users? • Get back to the whiteboard • Pivot • Repeat until you fi nd your PMF or shut down • Until you get your early adopters, engineering excellence doesn’t matter Pre-PMF
13. Pre-PMF Product User
14. • Go from early adopters to early majority - more users in short time • Add new features from early adopters’ feedback • Fix screw ups from prototypes - product and engineering • Refactor the prototype or rewrite the prototype in rare cases • All these while catering the existing users and expanding the team PMF
15. • Gain late stage adaptors • Expand the business by building di ff erent product verticals • By this time if there is no engineering excellence, then either product will be miserable or team will be miserable Post-PMF
16. • Engineering excellence will take back seat sometimes • A long living cash cow product - a.k.a Legacy Code • Fight for survival - Product or business is at risk because of runway, funding or competitors Exceptions
17. • CHANGE - product, code and team • Nothing’s gonna change is a risky bet • Unstoppable change inducers: • Passage of time • Entropy Common factor
18. Organization
19. • “Move fast and break things” happens if you are able to undo the broken things • Change is the only option for any product • Faster the change is undoable, more con fi dent the team is to make mistakes Why engineering excellence?
20. Breakpoints
21. • Real world is messy and chaotic • 80% of the engineering problems you (will) face would be solved by fi xing 20% of the problems Minimum Viable Process
22. Handling Change
23. • You take decisions and tradeo ff s on daily basis • Should we have cake cutting for everyone’s birthday? • 10 people • 30 people • 300 people CD - Continuous Decisions
24. • Measurable • Quanti fi able inputs • Ex. CPU cycles • Measurable outputs • Direct costs • Immeasurable • Unquanti fi able inputs • Ex. Lack of tests, docs or API contracts • Immeasurable outcomes and impacts • Indirect costs Decision I/O
25. • Ways to handle change • Find the change ASAP • Undo previous change • Find change by reducing the feedback loop Detect and Undo
26. Always shift left
27. • Policy is easy, changing minds are di ff i cult • Policy = Extrinsic. Mindset = Intrinsic • Examples • Documentation - needs writing habit • Remote team - needs e ff ective communication • Change brings resistance and people develop immunity to change • Retrospect how team embraces the change Mindset over policies
28. Healthy Engineering
29. • Form writing habit. One pagers and meeting notes are good start • Deliberately refer the written docs • Helps mitigating all or nothing expertise • Internal talks helps to avoid information islands Knowledge sharing
30. • Constantly encourage to communicate • Silent team is a dangerous team • Encourage proactive learning • Eliminates parroting Proactiveness
31. • Individual productivity, prioritization, time and energy management are unlisted part of • Prioritize heavily to reduce the streams of work. So that anyone can have a mental model of the work • Create psychological safety for the team • Don’t measure lines of code or number of issues closed, evaluate the impact of the team on the product or release Productivity
32. • Let the team believe in expertise • If there is no ability to take continuous tradeo ff s, then team copies patterns without understanding them • Incentivize for long term e ff orts • A stretched team will put engineering to back seat Dynamics
33. • Time and entropy makes sure the process you put degrades • Slip ups which aren’t addressed will be propagated and it will become a norm • Leave no broken windows • Stay vigilant about slip ups Process decay
34. Keep It Simple and Stupid GREAT ADVICE… HURTS MY FEELINGS EVERY TIME. MICHAEL ALWAYS SAYS, K.I.S.S - KEEP IT SIMPLE, STUPID!
35. Engineer
36. • Helps to grow in your career. Either to get promoted inside the company or get more opportunities outside • Product mindset and collaboration > Churning code • In fl uence without authority • Natural leadership Why it’s important for engineer
37. • Few of my talks and writings for reference: • Becoming pragmatic • What’s next • Software craftmanship How to show excellence
38. You Dev who’s gonna maintain your code
39. Conclusion
40. Variables in coffee
41. Variables in engineering
42. • Catchy terms and analogies are inspired from books • “Pragmatic Engineer” Newsletter by Gergely Orosz • “Build” book by Tony Fadell • “Software Engineering at Google” book by Winters, Manshreck & Wright • “Leaders Eat Last” by Simon Sinek • “Cute pictures” from Tensoon 🐺 Reference & Credits
43. Thank you Naren, Software Consultant Twitter: @DudeWhoCode