HMww39 - Verantwortungslose Spielkinder mit Sandra Parsick
Heute besucht mich Sandra Parsick wieder im Podcast und wir haben einiges zu besprechen.
Bevor es losgeht bedanken wir uns erstmal bei @nerdpressblog für den Hinweis, Pixum als Lösung für Fotobücher zu nutzen.
Bevor es zum eigentlichen Thema kommt sprechen wir noch kurz über "Schätzen" und tauschen unsere Erfahrungen aus.
Aber natürlich haben wir auch noch ein richtiges Thema und das hat es in sich: Eberhard Wolff hat auf heise einen Artikel mit dem Titel "Developer sind verantwortungslose Spielkinder!" veröffentlicht und da wollen wir auch unsere Meinung kundtun. Wieviel Freiheit ist für Entwickler in Ordnung? Welche Typen von Entwicklern gibt es neben dem Bild, das im Artikel beschrieben wird? Muss ich unbedingt in meiner Freizeit programmieren? Wie machen wir das, wenn wir neue Technologien in einem Team einbringen wollen?
Wenn ihr noch was zum Lesen sucht, dann empfehlen wir Euch heute die folgenden Bücher:
- Homo Deus (amazon)
- What if? und How to von Randall Munroe
- Die Nomen (amazon)
Wenn es dann doch eher ein Film oder eine Serie sein soll, haben wir auch ein paar Vorschläge für Euch:
Aufnahmedatum: 23.06.2020
Webmentions
16 Likes
13 Retweets
27 Replies
Höre die Podcast-Folge zu den "verantwortungslosen Spielkindern" gerade unter Palmen nach. Danke für die fein nuancierte und vielsichtige Diskussion dieses Themas und den Hinweis auf ADRs. Nehme einiges mit. #meinsonntag
Hmja, guter Gedanke. Da würde ich jetzt vielleicht zu @antoraproject greifen, einfach weil das auf einen ersten unvollständigen Blick sinnvoll und der Aufgabe, Doku über viele Repositories hinweg zu aggregieren, gewachsen schien. Ist halt #AsciiDoc. :D
Es soll sogar so weit gehen, dass man mehrere Repos managen kann. Es gibt IMHO Entscheidungen, die innerhalb von mehreren Projekten getroffen werden. Wir haben diese mal "GADR" genannt: github.com/adr/gadr. Und dann sollen Verknüpfungen gezeigt werden. Initialer Prototyp:
Idee: GitHub Repo als Datenbasis. Also dass auch PRs möglich sind und auch dargestellt werden. Insbesondere keine eigene Datenbasis, die wegdriftet. - Fast wie #gitpod mit mächtigerem Editor.
Okay, wenn es 1) im Projektrepo lebt und 2) sinnvolle Diffs hat (zum Auflösen von Konflikten).
Würd ich nicht benutzen. Ich fand _gerade_ die Ablage und Behandlung als Quelltext im Repository des Codes. Ein autarkes Team pflegt die Dinger als Teil ihrer Pull Requests gleich mit, stelle ich mir vor. Da käme ein UI Tool wohl eher in den Weg.
Spannender fände ich da eine strukturiertere Sprache als MD (vgl. zB Gherkin für Tests), die dann Ableitungen zuließe. Wenn zB ADRs einander verlinken ("extends", "supersedes", ...) könnte man sich schon Visualisierungen ausdenken, die über eine bloße Liste von Links hinausgehen.
Evtl. könnte man in einem #hackathon auch mal den ADR-Manager angehen. Bisher habe ich ihn als Studentenprojekt ausgeschrieben; nur meldet sich bisher kein Team; wohl zu "abstrakt" --> conf.researchr.org/home/icse-2021…
MADR bietet eine Variante "minimum" und "medium". Leider nicht "richtig" dokumentiert. "minimum" erhält man durch löschen aller Optionalen Einträge. "medium" ist alles mandatory und pro/con der Optionen. - Ist auf meiner TODO-List; pull-requests trotzdem willkommen :)
Genau
Ja, man braucht dieses Erfolgserlebnis ... ist ähnlich wie beim Sport ...
Besonders gut fand ich den Hinweis auf den Respekt gegenüber Managern. Das war der Anlass für den Beitrag und ist am Artikel ja nur kurz und am Ende.
Wäre schön, wenn Testen und Clean Code etc reine Gewohnheitsache wäre 😅
Ich glaube schon, dass viele ihren Schweinehund überwinden müssen, um einfach mal damit anzufangen. Da es am Anfang länger dauert als dass was sie sonst machen, dass kann schon abschrecken und wenn man übt wird man schneller und gewöhnt sich dran und kann nicht mehr ohne. 😊
Der fehlt noch wobei das wäre ja bei der Menge an Kommentaren einfach gewesen
Ja nice! Den hatte ich auch in meiner Bubble gesehen und überlegt, ob wir da was zu machen sollen. Freue mich aufs durchhören! Ich hoffe es gibt auch einen Heise Kommentar der Woche bei dir 😉
Wir hatten gerade erst die Woche so einen Fall. "Etwas" durfte als Namen max 40 chars, einen Punkt und einen Unterstrich haben. WTF - denkt man da. Es gab dann einen technischen Grund den der Entwickler noch wusste. Ohne diese Info wären wir voll in die 💩 getreten.
Ja und daher Wissen immer möglichst viel teilen und am besten und einfachsten in einem ADR oder MADR, dass ist eine reine Gewohnheitssache, wie Testen, Clean Code, Formatieren u.s.w. Und wenn man es mit ins Projekt integriert, kann man so gar in der IDE bleiben 😊
mE das wichtigste sind Entscheidung, Grund und ggf. Alternativen. Ich versuche ADRs schon seit langem in Projekten einzuführen. Doku ist halt leider ein Thema das von vielen gern vergessen wird. Deshalb klappt das auch nicht in allen Teams.
Ja, genau meine Meinung, wie oft hat man es schon in Projekten erlebt: “warum machen wir es eigentlich nicht so? Hm, da war was, weiß einer noch warum wir dass nicht so machen?” Besonders bei Projekten die länger laufen o. mit Wartungsvertrag und nach Jahren mal wieder auftauchen
Entscheidungsdokumentation ist mir auch eine Herzensangelegenheit, denn so oft habe ich sie bisher vermisst. Ich finde es super, dass es #MADR als Vorlage/Good Practice gibt. Doku-scheue Kollegen kann eine so umfangreiches Template aber auch abschrecken.
Shoutout für @koppor und github.com/adr/madr -- fand ich wirklich einfach einzuführen! Das Template führt den Gedankengang und dokumentiert dann die Entscheidung. Super Sache.
@jschnatterer ist das vielleicht etwas für uns? Wir haben ja zum Thema Decision Records eine ähnliche Haltung 🙂
Es lohnt sich auf jeden Fall, kann super in die Projekte integriert werden. Wir hatten sie in unserer arc42 Doku mit drin, welche beim Build auf dem Jenkins immer mit erstellt und bereitgestellt wurde. Es hat nicht lange gedauert bis alle sich dran gewöhnt habe zu dokumentieren.
Danke für die Reaktion! Ich fühle mich gut verstanden und Danke für die Referenz. 🙂
ADRs 🎉. Da muss ich dich gleich adr.github.io verlinken. Und Werbung für #MADR einstreuen. Mit ist die Abwägung zwischen verschiedenen Optionen stets wichtig - und das ist in MADR besonders ausgeprägt 😇
Super. Ich kann auch wieder nur Sandra beipflichten in vielen Punkten. ADRs sind wirklich sehr hilfreich und es gibt tatsächlich selbstorganisierte Teams wo 100% Teamentscheidungen gelebt und umgesetzt werden. 😊 Beim nächsten Renovieren sage ich Bescheid. 😜
Dies sind Webmentions über das IndieWeb und webmention.io.