How to become a better software engineer by breaking things

Menschen machen Fehler und wo viele Menschen zusammenkommen (Spoiler: in Unternehmen), kommt es auch zu vielen Fehlern. Aber anstatt sie zu verurteilen, sollten wir Fehler nutzen und als Chance verstehen, etwas zu lernen. Dazu gehören nicht nur Software-Lösungen und Tools, sondern vor allem der Rückhalt der gesamten Firma bzw. der Kollegen. Der Talk wird dir Einblicke geben, was wir bei sipgate schon kaputt gemacht haben und wie wir daraus lernen konnten.

Transcript

1. Benjamin Kluck & Peter Mösenthin:
   Creating a safe to
   environment
   How to become a better software engineer by breaking things
   #HBABSE
   Part 2
   .fail..
   

   View Slide

2. Ben
   Peter
   

   View Slide

3. 180
   Employees
   600 kg
   Coffee 2019
   Deployments
   / Day
   Ø 100
   300
   Server
   »hubot party bis 02:00«
   Chatbot command #1
   1300
   Post-Its / Tag
   445
   VMs
   6.600.000
   API requests / Day
   Düsseldorf
   120
   Services
   

   View Slide

4. ♀ ♂
   First: People
   ‍‍
   Second: Code
   /
   

   View Slide

5. Disclaimer
   

   View Slide

6. Type 1 vs. Type 2
   

   View Slide

7. Type 1 != Type 2 l
   

   View Slide

8. safe-to-fail
   vs.
   fail-safe
   

   View Slide

9. safe-to-fail
   

   View Slide

10. Culture
    “… social behavior and norms
    found in human societies.”
    – Wikipedia
    

    View Slide

11. Failure Culture
    ➡ “Failing is OK”
    ➡ “I trust that you do your best!”
    ➡ “Do or do not, there is no try”
    

    View Slide

12. Blame Culture
    ➡ “Don’t fail!”
    ➡ “It’s better to keep doing things the same way!”
    ➡ “Never change a running system!”
    ➡ “It wasn’t me!”
    

    View Slide

13. View Slide

14. Time
    

    View Slide

15. Bias for Action
    “Speed matters in business. Many
    decisions and actions are reversible
    and do not need extensive study. We
    value calculated risk taking.”
    https://www.amazon.jobs/en/principles
    

    View Slide

16. Fail fast, fail often
    “By failing early, you can create
    something useful and deliver it to
    the consumer as soon as possible.”
    Many people (including Martin Fowler)
    

    View Slide

17. Move fast,
    break things
    Facebook (bis 2014)
    

    View Slide

18. Move fast with
    stable infrastructure
    Facebook (seit 2014)
    

    View Slide

19. Feedback loops
    (but basically scrum)
    

    View Slide

20. © agile42
    

    View Slide

21. Extended waterfall
    

    View Slide

22. .Feedback talks.
    

    View Slide

23. .Feedback talks.
    

    View Slide

24. .Feedback talks.
    .Non violent!.
    .Descriptive!.
    .Non judging!.
    .Stay positive!.
    .Highlights.
    .Ideas.
    .Keeps.
    .Bad stuff.
    .No defensiveness!.
    .Ask questions!.
    .What’s done is done..
    

    View Slide

25. Dunning-Kruger Effect
    

    View Slide

26. Learning
    

    View Slide

27. Learning methods
    Conferences
    YouTube etc. (also conferences)
    Books! (The paper thingies)
    Microdegrees
    Knowledge exchange
    Meetups
    ...
    

    View Slide

28. .Value learning.
    

    View Slide

29. .Pair- / Mobprogramming.
    #HBABSE
    Part 1
    

    View Slide

30. .Personal growth.
    

    View Slide

31. .openfriday.org.
    

    View Slide

32. ‍‍
    Second: Code
    

    View Slide

33. Continuous Integration
    Continuous Delivery
    Continuous Deployment
    

    View Slide

34. View Slide

35. Invest in Rollback
    

    View Slide

36. View Slide

37. View Slide

38. Canary Deployment
    

    View Slide

39. “Canary deployments are a
    pattern for rolling out releases
    to a subset of users or servers”
    – Ben & Peter, 2 seconds ago
    

    View Slide

40. View Slide

41. Feature Toggles
    

    View Slide

42. if (hasFeature(“canary”))
    

    View Slide

43. Feature Toggles
    – martinfowler.com
    

    View Slide

44. Release Toggles
    

    View Slide

45. View Slide

46. Release Toggles
    

    View Slide

47. Release Toggles
    

    View Slide

48. But there is more
    

    View Slide

49. Pre-Commit-Hooks
    

    View Slide

50. npx mrm lint-staged
    

    View Slide

51. Idempotency
    

    View Slide

52. Idempotency
    “… the system state remains the
    same after one or several calls.”
    – Wikipedia
    

    View Slide

53. POST /users/{userId}/contracts
    PUT /users/{userId}/premium
    

    View Slide

54. Sane Defaults & Circuit Breaker
    

    View Slide

55. View Slide

56. try {
    return getSuggestions();
    } catch {
    return ["The Big Lebowski"];
    }
    

    View Slide

57. Recap
    

    View Slide

58. Chaos Engineering
    

    View Slide

59. Have you really tested what
    happens when ...?
    

    View Slide

60. View Slide

61. Gameday!
    

    View Slide

62. “Let’s kill Service X”
    

    View Slide

63. “Today we close the port
    to the database”
    

    View Slide

64. Team Evil vs. Team Good
    

    View Slide

65. View Slide

66. Machen!
    

    View Slide

67. Danke fürs Zuhören
    Quatscht uns am Stand an,
    wir machen bestimmt was kaputt.
    

    View Slide

68. Benjamin Kluck & Peter Mösenthin:
    Creating a safe to
    environment
    How to become a better software engineer by breaking things
    #HBABSE
    Part 2
    .fail..
    

    View Slide