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
   

   View Slide

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
   

   View Slide

3. How to make espresso ☕
   

   View Slide

4. Dose
   

   View Slide

5. Distribute
   

   View Slide

6. Tamp
   

   View Slide

7. Extract
   

   View Slide

8. Enjoy
   the coffee
   🙈
   

   View Slide

9. • Software engineering is writing code that changes with TIME, PEOPLE
   and SCALE
   Software Engineering
   

   View Slide

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
    

    View Slide

11. Product
    

    View Slide

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
    

    View Slide

13. Pre-PMF
    Product
    User
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

17. • CHANGE - product, code and team
    • Nothing’s gonna change is a risky bet
    • Unstoppable change inducers:
    • Passage of time
    • Entropy
    Common factor
    

    View Slide

18. Organization
    

    View Slide

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?
    

    View Slide

20. Breakpoints
    

    View Slide

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
    

    View Slide

22. Handling Change
    

    View Slide

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
    

    View Slide

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
    

    View Slide

25. • Ways to handle change
    • Find the change ASAP
    • Undo previous change
    • Find change by reducing the feedback loop
    Detect and Undo
    

    View Slide

26. Always shift left
    

    View Slide

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
    

    View Slide

28. Healthy Engineering
    

    View Slide

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
    

    View Slide

30. • Constantly encourage to communicate
    • Silent team is a dangerous team
    • Encourage proactive learning
    • Eliminates parroting
    Proactiveness
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

34. Keep It Simple and Stupid
    GREAT ADVICE… HURTS MY FEELINGS
    EVERY TIME.
    MICHAEL ALWAYS SAYS,
    K.I.S.S - KEEP IT SIMPLE, STUPID!
    

    View Slide

35. Engineer
    

    View Slide

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
    

    View Slide

37. • Few of my talks and writings for reference:
    • Becoming pragmatic
    • What’s next
    • Software craftmanship
    How to show excellence
    

    View Slide

38. You Dev who’s gonna maintain your code
    

    View Slide

39. Conclusion
    

    View Slide

40. Variables in coffee
    

    View Slide

41. Variables in engineering
    

    View Slide

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
    

    View Slide

43. Thank you
    Naren, Software Consultant
    Twitter: @DudeWhoCode
    

    View Slide