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

More Decks by Benjamin Kluck

Other Decks in Technology


  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..
  2. Ben Peter

  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
  4. ♀ ♂ First: People ‍‍ Second: Code /

  5. Disclaimer

  6. Type 1 vs. Type 2

  7. Type 1 != Type 2 l

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

  9. safe-to-fail

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

    – Wikipedia
  11. Failure Culture ➡ “Failing is OK” ➡ “I trust that

    you do your best!” ➡ “Do or do not, there is no try”
  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!”
  13. None
  14. Time

  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
  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)
  17. Move fast, break things Facebook (bis 2014)

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

  19. Feedback loops (but basically scrum)

  20. © agile42

  21. Extended waterfall

  22. .Feedback talks.

  23. .Feedback talks.

  24. .Feedback talks. .Non violent!. .Descriptive!. .Non judging!. .Stay positive!. .Highlights.

    .Ideas. .Keeps. .Bad stuff. .No defensiveness!. .Ask questions!. .What’s done is done..
  25. Dunning-Kruger Effect

  26. Learning

  27. Learning methods Conferences YouTube etc. (also conferences) Books! (The paper

    thingies) Microdegrees Knowledge exchange Meetups ...
  28. .Value learning.

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

  30. .Personal growth.

  31. .openfriday.org.

  32. ‍‍ Second: Code

  33. Continuous Integration Continuous Delivery Continuous Deployment

  34. None
  35. Invest in Rollback

  36. None
  37. None
  38. Canary Deployment

  39. “Canary deployments are a pattern for rolling out releases to

    a subset of users or servers” – Ben & Peter, 2 seconds ago
  40. None
  41. Feature Toggles

  42. if (hasFeature(“canary”))

  43. Feature Toggles – martinfowler.com

  44. Release Toggles

  45. None
  46. Release Toggles

  47. Release Toggles

  48. But there is more

  49. Pre-Commit-Hooks

  50. npx mrm lint-staged

  51. Idempotency

  52. Idempotency “… the system state remains the same after one

    or several calls.” – Wikipedia
  53. POST /users/{userId}/contracts PUT /users/{userId}/premium

  54. Sane Defaults & Circuit Breaker

  55. None
  56. try { return getSuggestions(); } catch { return ["The Big

    Lebowski"]; }
  57. Recap

  58. Chaos Engineering

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

  60. None
  61. Gameday!

  62. “Let’s kill Service X”

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

  64. Team Evil vs. Team Good

  65. None
  66. Machen!

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

    bestimmt was kaputt.
  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..