My Reading List @KanDDDinsky

Accelerate - Building and Scaling High Performing Technology Organizations

Accelerate by Nicole Forsgren, Gene Kim, Jez Humble

This book was referenced to in a lot of talks, mostly with the same phrase “hey folks, you have to read this!”


Domain Modeling Made Functional by Scott Wlaschin

The book was called as the only real currently published reference work for DDD for functional programming.

More books and videos to find on fsharpforfunandprofit


Functional Core, Imperative Shell by Gary Bernhard – a talk

The comments on this tweet are telling me, watching this video is long overdue …


37 Things One Architect Knows About IT Transformation by Gregor Hohpe

The name @ghohpe was also mentioned a few times at @KanDDDinsky


Domain Storytelling

A Collaborative Modeling Method

by Stefan Hofer and Henning Schwentner


Drive: The surprising truth about what motivates us by Daniel H Pink

There is also a TLDR-Version: a talk on vimeo


Sapiens – A Brief History of Humankind by Yuval Noah Harari

This book was recommended by @weltraumpirat after our short discussion about how broken or industry is. Thank you Tobias! I’m afraid, the book will give me no happy ending.

UPDATE:

It is not a take-away from KanDDDinsky but still a must have book (thank you Thomas): The Phoenix Project

10 Jahre Open Space – meine Retrospektive

Workshop-Tag:

Seit ein paar Jahren gibt es die Möglichkeit, den Open Space um ein Tag Workshop zu erweitern – wenn einem die zwei Tage Nerdtalk nicht reichen  😉

Ich habe mich diesmal für Tensorflow: Programming Neural Networks mit Sören Stelzer entschieden – und es war großartig. Obwohl ein sehr schwieriges Thema (das Wort Voodoo ist öfter gefallen), ich weiß jetzt genug über Machine Learning und Neuronale Netze, um mit dem Thema gut starten zu können. Ich formuliere es mal so: ich weiß jetzt, was ich weiß und vor allem, was ich nicht weiß und wie wir weiter machen müssen. Und mehr kann man von einem Workshop nicht erwarten. Zusätzlich finde ich, dass Sören eine sehr große Bereicherung für unsere Community ist, die sich genauso weiterentwickeln muss, wie die IT-Welt da draußen. Vielen Dank für dein Engagement!

Eigentlich ein fetten Dank an alle Trainer, die sich bei Community-Events engagieren!!

Erkenntnisse der nächsten 48 Stunden – geclustert:

Agile datengetriebene Entwicklung – war meine eigene Session (das heißt, ich habe das Thema vorgeschlagen, war Themen-Owner aber das war’s dann auch mit den Pflichten).

Ich wollte Tipps und Ideen dazu hören, wie man seine Arbeit nach scrum organisieren kann wenn man Themen beackert, wie Reporting, wo die Features auf große Menge Daten basieren. Es ist eine Sache, ein Testsetup für 2 möglichen Situationen zu schreiben und es ist eine ganz andere, die vielfalt der Situationen in Reporting zu beschreiben.

Take-aways:

  • wir werden damit leben müssen, dass unsere Features, Tests, Erwartungen eventual consistent sind  😀 Wichtig ist, dass wir Annahmen treffen, die wir für den Anfang als “die Wahrheit” betrachten.
  • User labs beauftragen.
  • Measurements weit vor ihre Auswertung einzubauen ist ok, bricht nicht mit dem Konzept “Jedes Feature muss Business Value haben” – auch wenn der echte Business Value erst in 2 Jahren auswertbar ist.
  • Aha-Effekt: In der Welt von Business Teams gibt es keine Fachabteilung. Ich bin in dem Reporting-Team ergo ich bin die Fachabteilung. (finde ich gut, häßliches Wort  😎 )

Stolperfallen mit React

  • unser Internationalisierungskonzept ist richtig (Texte aufteilen nach Modulen/Bereiche/o.ä., ein common Bereich, alles via API in den State laden)
  • Package-Empfehlung: react-intl
  • das Thema so früh, wie möglich berücksichtigen, später kann es richtig weh tun.
  • DevTool-Empfehlung: https://github.com/crysislinux/chrome-react-perf um die Performance der einzelnen React-Componenten zu sehen.
  • (es)Linting Empfehlung um zirkuläre Referenzen zu vermeiden:  “import/no-internal-modules” (Danke @kjiellski)

Wann kann Scrum funktionieren

  • wenn die Möglichkeit besteht, auf Feedback zu reagieren, sprich die Entwickler sind keine Resourcen sondern kreative Menschen.
  • das Team, in dem ich die Ehre habe, unser Produkt mitzugestallten, und @cleverbridge ist führend was agiles Arbeiten betrifft.

Menschen

  • man kann bei Trinkspielen mitmachen, ohne zu trinken
  • nachts träumen, dass der Partner einen enttäuscht hat und danach den ganzen Tag sauer auf ihn sein, ist eine Frauen-Sache (bestätigt von @AHirschmueller und @timur_zanagar) 😀

Nachtrag: fast vergessen, dass

  • wir dank @agross eine super wertvolle Session über dotfiles hatten
  • DDD wird gerade durch Zertifizierung kaputt gemacht, Serverless durch Hype
  • mit der Session von @a_mirmohammadi über/zu den Anonymen Abnehmer ist der @devopenspace eindeutig in die Kategorie “es gibt nichts, was nicht geht” angekommen

Der Open Space muss eine UNkonferenz bleiben

sonst ist es kein Open Space mehr…

 

Am Wochenende gab es den letzten Pflichttermin des Jahres, der 8. Developer Open Space im Leipzig. Es wurden schon wieder alle Rekorde gebrochen – so viele Workshops (20), so viele Teilnehmer (um die 240) und – zu meiner besonderen Freude – so viele Frauen (kenne die genaue Zahlen nicht, aber im zweistelligen Bereich), wie noch nie. Danke nochmal an @TorstenWeber für die großartige Arbeit.

Für “Kenner” – alte Open Space-Hasen – war er lehrreich und spannend, wie immer. Wie sollte es sonst sein, wenn über 200 Nerds aufeinander treffen und ihre Erfahrungen austauschen. Diesmal haben sogar die üblichen 14 Stunden Session-Zeit + gemeinsames Frühstück + gemeinsame Abendveranstaltung nicht gereicht

Es war großartig, wie immer, aber wie gesagt: für Kenner. Ich habe nicht mal den Flughafen erreicht, als eine Diskussion über das immer zahlreicheren “Folien-Sessions” – Präsentationen – entbrannt ist.

 


Die Wahrheit ist, mir ist das früher auch nicht aufgefallen, aber das lag an meiner Erfahrung, wie man richtig priorisiert. Nach so vielen Jahren Community-“Mitgliedschaft” weiß ich genau, welche Sessions wert sind, in der begrenzten Zeit, die man bei einem Open Space hat, besucht zu werden. Deshalb ignoriere ich grundsätzlich Sessions die “Ich zeige euch meine Präsentation über das geilste, hippste, usw. Framework und wie ihr alle damit das geilste, hippste, usw. Webseiten bauen könnt”.

Und da ist das Problem: nur die erfahrenen Leute wissen das, die schon immer dabei waren, auch in den Zeiten, wo das die Ausnahme war. Die Beschreibung “Unkonferenz” ist nicht von ungefähr, ein Open Space ist keine Konferenz, wo man sich hinsetzt und konsumiert! Es lebt von den Teilnehmern, nicht von den Sponsoren oder von den Speakern.

Es gab schon immer One-Man-Shows und ich persönlich habe unglaublich viel davon profitiert, ich kann und will es nicht leugnen. Aber die waren NIEMALS Verkaufsgespräche sondern einfach nur Beweise dafür, wie großartig es ist, zu einer Community zu gehören. Ich habe manche von diesen Freunden – ich glaube, ich kann euch inzwischen Freunde nennen – mal gefragt, warum sie das tun, warum sie ihre wertvolle Zeit in uns noobes investieren und die Antwort war “darum, dass ihr das dann genau so weiter macht”. Und das ist genau das, was ich tue: ich möchte was der Community zurückgeben und meine Zeit in die Zukunft, in unseren Nachfolgern investieren: anderen zeigen, wie genial ein Community Event ist, wie großartig die Leute sind, die die Community bilden.

Ergo tue ich mich sehr schwer mit Versuchen, diese Events als “Projektmarkt” zu misbrauchen. (Ein hartes Wort, ich weiß, aber ihr wisst, ich sage, was ich denke 😉 )

Also hier mein Aufruf: Besucht weiterhin die Open Spaces, meidet aber Sessions, die “ich zeige euch, wie es geht” lauten, es sei denn, ihr habt selber darum gebeten. Lasst euch nicht die Zeit klauen, um euch von einer einziger Person berieseln zu lassen, wenn ihr in dieser Zeit einen echten Erfahrungsaustausch mit ehrlichen Berichten, ohne Powerpoint-Folien, erleben könntet. Alle haben was zu bieten, das beweist schon die Tatsache, dass ihr den Weg zum Open Space gefunden habt! Und noch was: stellt ruhig alle Fragen, die ihr habt, weil eins ist sicher: Hier gibt es keine Rollenaufteilung in Sprecher / Zuhörer, Entwickler / Administrator, Softwareentwickler / Projektmanager usw. und die Themen finden sich vor Ort ganz von selbst. ( http://nossued.de/ ).

Der nächste Open Space ist die Spartakiade und danach – wahrscheinlich 😉 – der Shorty Open Space (zu finden und anmelden via Twitter) oder doch der OPEN SPACE SÜD (im Juni oder Juli in Karlsruhe) – und danach natürlich der 9. Open Space Leipzig. Lass uns also eine neue Regel etablieren: Folienverbot!