HMww39 - Verantwortungslose Spielkinder mit Sandra Parsick

Sandra Parsick spricht mit mir über den Artikel von Eberhard Wolff zu "verantwortungslosen Developern"

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:

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

7 Retweets

Sandra Parsick Dominique Clijsters Oliver Nautsch Sandra Parsick Daniel Mies Simon Martinelli Sandra Gerberding

26 Replies

Raphael Reitzig Raphael Reitzig
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
Oliver Kopp Oliver Kopp
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:
Oliver Kopp Oliver Kopp
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.
Raphael Reitzig Raphael Reitzig
Okay, wenn es 1) im Projektrepo lebt und 2) sinnvolle Diffs hat (zum Auflösen von Konflikten).
Raphael Reitzig Raphael Reitzig
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.
Raphael Reitzig Raphael Reitzig
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.
Oliver Kopp Oliver Kopp
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…
Oliver Kopp Oliver Kopp
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 :)
Sandra Parsick Sandra Parsick
Ja, man braucht dieses Erfolgserlebnis ... ist ähnlich wie beim Sport ...
Eberhard Wolff Eberhard Wolff
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.
Sandra Parsick Sandra Parsick
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. 😊
Daniel Mies Daniel Mies
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.
Raphael Reitzig Raphael Reitzig
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.
Oliver Milke Oliver Milke
@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.
Eberhard Wolff Eberhard Wolff
Danke für die Reaktion! Ich fühle mich gut verstanden und Danke für die Referenz. 🙂
Oliver Kopp Oliver Kopp
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.

Send a webmention