Upgrade to Pro — share decks privately, control downloads, hide ads and more …

How to become a better software engineer by breaking things

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.

Benjamin Kluck

February 05, 2020
Tweet

More Decks by Benjamin Kluck

Other Decks in Technology

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