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..
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!”
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
35. Invest in Rollback
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
41. Feature Toggles
42. if (hasFeature(“canary”))
43. Feature Toggles – martinfowler.com
44. Release Toggles
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
56. try { return getSuggestions(); } catch { return ["The Big Lebowski"]; }
57. Recap
58. Chaos Engineering
59. Have you really tested what happens when ...?
61. Gameday!
62. “Let’s kill Service X”
63. “Today we close the port to the database”
64. Team Evil vs. Team Good
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..