Von Nutella-Öffnern, (Extra-)Frauenwürsten und Programmier-Kursen

Es fasziniert mich immer wieder auf was für Produktideen Leute kommen. Ich wäre niemals auf einen “Nutella-Folien-Schneider” oder auf “Bacon-Pflaster” gekommen.

Nur leider sind nicht alle Produktdesigner so kreativ und finden eine unbesetze Produktnische, sondern nehmen einfach ein bestehendes Teil ihres Sortiments und machen daraus geschlechtsspezifische Varianten. So gibt es nicht nur Frauen-Klebeband oder Frauen-Gehörschutz (diese und andere sinnlose Produkte auf buzzfeed), sondern auch die Frauenbratwurst. Mit weniger Fett. Klar.

Meistens lässt mich solche Art der Vermarktung kalt und ich hoffe einfach, dass es sich als teurer Produkt-Flop herausstellt und die Marketing-/Produkt-Entwicklung aus dem Fehler auf lahmen Klischees herumzureiten, lernt. Aber manchmal regt es mich dann doch auf. Zum Beispiel bei der Aktion von Gravis am Frauentag.

gravis spezialangebot zum Frauentag

Nun, wie passt das zusammen mit den Programmier-Kursen?

Die Liste der Gruppen die Frauen das Programmieren nahe bringen wollen ist lang und wird immer länger. Es gibt die Rails Girls, die Geekettes, girls who code, etc… Und ich frage mich: Wieso ist an dieser Stelle nun die FrauenExtrawurst nötig und wird positiv bewertet? Passt das zusammen?

Meiner Meinung nach brauchen Frauen keine Spezialbehandlung. Auch nicht beim Erlernen einer Programmiersprache.

Ich habe selbst gern die Rails Girls in Hamburg unterstützt, aber nicht weil es ein spezieller Workshop für Frauen ist, sondern einer für interessierte und lernwillige Menschen, egal welchen Geschlechts.

Als ich angefangen habe zu programmieren hat mich der geringe Frauenanteil nicht abgeschreckt. Weder damals als 14 jährige beim Volkshochschulkurs “Basic” noch als ich angefangen habe Informatik zu studieren. Eigentlich habe ich mir darüber nie Gedanken gemacht und wurde von meinen männlichen Kollegen selten darauf angesprochen. Klar gibt es hin und wieder mal einen Spruch, aber es gibt sogar noch mehr blöde Sprüche und Witze über den favorisierten Editor oder Betriebssystem.

Tineidscha hören zi des

Ich liebe die Freundebücher meiner Kinder. Ganz besonders seitdem die Einträge selbst geschrieben sind und nicht mehr von Eltern verfasst (und beeinflusst) werden. Es ist so ein Spaß zu lesen, was die Kinder denken, wie sie priorisieren und ihre Hobbys, Lieblingsfilme und -bücher buchstabieren.

Hier ein paar Highlights aus den Büchern und für die, die es nicht decodieren können ist die Auflösung am Ende des Artikels.

Ambitionierte Berufswünsche [1]: ertztin

OK, das ist einfach, aber schön zu lesen, dass es wichtigeres als Erfolg, Ruhm und Reichtum ist, das sich die Kinder von der Zukunft wünschen [2]:
fil_schpas

War das nicht das Lied mit “laf Olaf” im Refrain [3]:
leikaseteleit

Bin ich auch ein großer Fan von [4]:
fankuchen

Steilisches Lieblingslied [5]:
wopamgagnam

Ui, ein junger Misanthrop und Arachnophobiker [6]:
wasichnochloswerden

Wer findet es nicht toll mit Becherlupe durch das Gelände zu streifen und ein echter “Worscher” zu sein [7]:
worschen

Die Abenteuer von Arjen Robben mit Hut aus dem Sherwood Forest begeistern mich auch [8]:
roben_hut

Dieses Fundstück aus den Hausaufgaben meiner Tochter bezeichnet einen jungen Menschen. Zum Glück sind Geheimschriften und ihre Entschlüsselung mein Hobby [9]:
tineidscha

Einfach nur süß [10][11]:
was_ich_mag
was_ich_nicht_mag

Die Auflösung:
[1] Ärztin + Malerin
[2] Viel Spaß
[3] Like a Satellite, you…
[4] Pfannkuchen
[5] Gangsam Style
[6] Spinnen, eklige Tiere und Menschen
[7] forschen
[8] Robin Hood
[9] Teenager
[10] Regenbogen, CDs hören
[11] Krieg, streiten, Rosinen, Zecken (oder Zicken??). Mücken, weh tun

Es ist übrigens völlig in Ordnung, dass sie schreiben wie sie wollen.

Anstatt wie früher sich jeden Buchstaben und jedes Wort mit der Fibel einzeln zu erarbeiten werden die Kinder ermutigt einfach drauf los zuschreiben.

Fehler machen ist ok, denn grammatikalisch korrekt schreiben lernen ist ein Prozess. Genau so wie beim Laufen lernen, es muss nicht gleich anmutig los spaziert werden, sondern es darf gestakst und gestolpert werden.

Wer mehr dazu lesen will, kann sich hier gut informieren: http://www.lehrer-online.de/lesen-durch-schreiben.php

Frequency + Impact = FRIM

Bei der Suche nach neuen Methoden um den Gather Data-Teil meiner nächsten Retrospektive zu bestücken über die FRIM-Methode von Diana Larsen gestolpert.

Ich wollte eine Möglichkeit um über einen längeren Zeitraum zurückzublicken und insbesondere über unseren doch sehr angepassten Prozess nachzudenken (und mit angepasst meine ich eigentlich, dass wir alles sehr schleifen lassen haben).

Der Klassiker für so einen Fall ist natürlich die Timeline, die mich aber bisher nicht überzeugen konnte, da sich dabei alle Teilnehmer, fast ausschließlich Entwickler,  sehr damit aufhielten die Vorkommnisse im letzten Sprints genaustens in die zeitliche Abfolge zu bringen.

Ziel:
Bei der FRIM-Methode soll das Team auch über alles nachdenken was passiert ist, was sie positiv und negativ beeinflusst hat.

Wichtig ist hierbei die Auswirkung/Stärke (Impact) und die Häufigkeit (Frequency). So wird klar was wirklich dringend verändert werden muss.

Oft werden die Dinge die einen gerade einen Tag vor der Retrospektive passiert sind und noch unter den Fingernägeln brennen, aber selten auftreten, überbewertet.

Vorgehen:
An das Whiteboard wird ein 6×6 Raster gezeichnet.

Die x-Achse bildet die Häufigkeit ab:
0 = sehr selten
1 = maximal einmal pro Iteration
2 = 1-2 mal pro Iteration
3 = alle 2-3 Tage
4 = täglich
5 = mehrmals täglich

Die y-Achse bildet die Grad der Auswirkung ab mit den folgenden Einteilungen:
0 = keine Auswirkung
1 = Sehr kleine Auswirkung
2 = Geringe Auswirkung
3 = Moderate Auswirkung
4 = Signifikante Auswirkung
5 = Maximale, sehr starke Auswirkung

Nun dürfen die Teilnehmer auf farbigen Karten dokumentieren:

  • was sie erfreut hat, vorangebracht hat (grün)
  • was sie geärgert, aufgehalten, gestört hat (rot)
  • welche Ereignisse ihnen im Kopf hängen geblieben sind (gelb)

und frei im Raster aufhängen.

Die Karten werden mit der Unterstützung vom Moderator von rechts oben (5er Auswirkung – 5er Häufigkeit) nach links unten (0er Auswirkung – 0er Häufigkeit) durchgesprochen.

in der Praxis:
Die Team-Teilnehmer und ich kamen mit FRIM gut klar und erzielten schnell weiterverwertbare Ergebnisse.frim-board
Nur mir den “Ereigniskarten” hatten die meisten Schwierigkeiten, da die Ereignisse immer positiv oder negativ belegt waren. Zum Beispiel unsere neue Art die Stories beim Review in großer Runde abzunehmen wurde von allen Teilnehmern nicht als gelbe wertfreie Karte aufgehängt, sondern durchweg als grünes positives Feedback an die Wand gehängt.

Besonders erfreut hat mich, dass die rechte obere Ecke des Rasters (maximale Auswirkung und maximale Häufigkeit) sich mit jedem weiteren Teilnehmer wie eine schützende Hecke um die restlichen roten Karten legte.

Hals über Kopf

kopfstandDie Kopfstandmethode oder Anti-Methode kann immer verwendet werden, wenn kreative Ideen gesucht werden oder um eine Denk-Blockade zu zerstören. Die Ideen werden durch einen gedanklichen Kopfstand ermittelt. Es wird nicht versucht das Problem zu lösen, sondern genau das Gegenteil.

Was ist das schlimmste Szenario?

Das ist eine schöne Abwechslung und gerade für Menschen, die sich nicht für kreativ halten oder wenig motiviert sind, bei andere “Spielen” mitzumachen.

Es fällt eben leichter schlecht zu denken und zu meckern.

Und das allerschlechteste was wir zu einem Thema oder Problemstellung finden, wird genommen um mit dem Gegenteil das Ziel zu formulieren.

 

Beispiel “Software-Dokumentation”

Dies Beispiel stammt aus dem Entstehungsprozesses unserer Werte-Liste.

Ein Punkt der auf dieser Werte-Liste für ein gutes Produkt sein sollte war: “Software-Dokumentation”.

Kopfstand-Frage: Was sieht die schlimmste Dokumentation aus?

Die erste Idee war: “Keine Dokumentation”

Aber in der weiteren Diskussion kam heraus, dass vielleicht falsche/veraltete Dokumentation noch schlimmer ist.

Denn bei fehlender Dokumentation würden wir Entwickler und gleich den Code anschauen um zu verstehen, wie es benutzt wird.

Bei falscher Dokumentation würden wir viel Zeit auf mit der falschen Benutzung und Debugging verwenden, oder mit falschen Resultaten weiterarbeiten.

Aus dem Kopfstand-Ergebnis: “falsche Dokumentation” ist nun das Ziel “korrekte und aktuelle Dokumentation” entstanden.

Tut das Not, dass ihr hier so lange rumoxidiert?

oder anders gefragt: Kann man eine Retrospektive abkürzen? Denn alle 2-3 Wochen das komplette Team sich für eine Retrospektive zusammen setzen zu lassen kostet.

Wir können uns ja mal vorstellen was passiert wenn einer der Teile ausgelassen wird.

1. Set The Stage:

-> Jeder hat jeden Tag dringende Emails, Bugs, Feature Requests, Telefonate, etc und jeder benötigt Zeit um diese Gedanken beiseite zu schieben und sich auf das bevorstehende Meeting zu fokusieren. Ohne diese Einstimmung, würden die meisten Teilnehmer erst nach der Hälfte des nächsten Teils auf Drehzahl kommen.

-> Eine Erinnerung an die Meetingregeln ist die beste Prävention gegen Geklingeln und den darauf resultierenden Ärger der anderen Teilnehmer (z.B.: “Mach sofort das Händy aus, du fräche Schnoddä ! Das is verbotn !”)

-> Ohne den Review der letzten Iteration würden im Gather Data – Teil garantiert die ein oder andern Dinge vergessen werden (z.B. ob das Bug/Feature-Verhältnis im grünen Bereich ist, oder welche Konzeption besonders gut für die Entwicklung war)

-> Ohne die Verkündigung der Agenda und des Fokus der Retrospektive (z.B.: “Wie gut passt der Prozess zu uns?”, “”continuous improvement”, “Zusammenspiel Product Owner / Entwicklungsteam”), kommt es zu einem sehr großem Feld an gesammelten Daten. Diese ganzen Daten können nicht einer angemessenen Timebox analysiert werden. Zum einen versanden wichtige Punkte und es kann sich Frust bei den Teilnehmern aufbauen, deren Punkte in den folgenden Teilen der retrospektive besprochen und analysiert werden.

-> Der Icebreaker ist nicht nur für schüchterne Teilnehmer eine Hilfe um aktiv an der Retrospektiv teilzunehmen, sondern kann auch als Teambuilding  beitragen, wenn dadurch gemeinsame Hobbys, Konzertbesuche oder Lieblingsfilme erkannt werden.

2. Gather Data

-> Die Teilnehmer würden nicht die Sichtweisen und Probleme der Anderen erfahren. Die gesamte gemeinsame  Grundlage für alle weiteren Teile der Retrospektive würde fehlen.

3. Generate Insights

-> Es würde nur eine ganz gewöhnliche, meist oberflächliche Problemfindung sein. Die Aktivitäten dieses Teils der Retrospektive sorgen im Normalfall für einen tiefes Verständnis und Ursachenforschung der Probleme. Den meist liegen die Probleme tiefer als sie scheinen.

4. Decide what to do

Ok, hier fällt mir wirklich nichts ein. Wer würde ernsthaft eine Retrospektive abhalten ohne daraus Aktivitäten abzuleiten. Selbst früher als wir noch keine Retrospektiven,  sondern nur wenn ein Projekt besonders schlecht lief im nachhinein eine Manöverkritik abhielten, haben wir uns Aktivitäten überlegt.

5. Close

-> Die Retrospektive an sich würde sich nicht verbessern, da das Closing nicht nur die Verabschiedung und das Herrichten des Raumes beinhaltet, sondern die Retrospektive der Retrospektive.shortcut

Ich bin selbst überrascht wie wichtig die Randphasen einer Retrospektive sind, gerade wie viele Gegenargumente ich für das Auslasen des Meetingbeginn ich gefunden habe. Also nehmt euch Zeit dafür und kürzt es nicht ab. Jeder Teil ist absolut sinnvoll oder in Meister Röhrichs Worten: „Ihr bleibt heute solange, bis das fertich is!”

Retrospektiven moderieren auf der developers conference Hamburg 2012

IMG_4626-e1347390248470-300x225

Trotz aller schlimmen Kopfkinofilme (kein Publikum, blutrünstiges Publikum, vergessene Slides, und komplettem Blackout meinerseits) habe ich meinen ersten Vortrag gut überlebt (und hatte sogar richtig Spaß dabei).

Leider habe ich vor lauter Nervosität meinem überallemaßen freundlichem und kooperativem Publikum vieles vorenthalten, was ich mir in meinem Kopf zurecht gelegt hatte.

Das möchte ich hier in meinem Blog nachholen und ausführlich über die Aktivitäten schreiben.

Hier die Slides zu meinem Vortrag als pdf.

Für alle die nicht auf der developer conference Hamburg waren: Ihr habt was verpasst!

Es waren wie auch im Jahr zuvor so viele nette Menschen vor Ort, viele interessante Vorträge und das Catering von Otto war grandios!

Besonders angetan haben mir die

  • Keynote von Lutz Prechelt “Meine Plattform ist besser als deine Plattform???” in die wissenschaftliche Ausarbeitung eines Programmierer Wettbewerbs vorgestellt wurde. Nachzulesen ist es unter plat-forms
  • die Vorträge von Johannes Mainusch “Agiles Management – ein Widerspruch in sich?” und Judith Andresen “Steuerung von Projekten” die beide noch einmal deutlich machten wie wichtig Kommunikation ist
  • der REST-Vortrag (mit Überlänge) von David Zülke
  • Felix Geisendörfer, der mit der “Power of node.js” in einer Live-Coding-Session einen Quadcopter fliegen ließ ( und ja, ich hatte etwas Angst in der ersten Reihe)
  • die Programmierer-Witze im sehr kurzweiligen Grunt-Vortrag von Sebastian Golasch (youtube-Video vom Braincamp)

und all die netten Gespräche mit den Leuten.

Mein einziger Verbesserungsvorschlag wäre eine 5 minütige Pause zwischen den Vorträgen für die Raumwechsel.

Nächstes Jahr bin ich auf jeden Fall wieder dabei!

Jeder kann Programmierer werden! Wirklich?

Letztens habe ich mit anderen Programmierern über unsere Versuche anderen das Programmieren beizubringen gesprochen. Es kam die Frage auf, ob wirklich jeder Programmieren lernen kann. Im Gegensatz zu dem Artikel “The Camel has two humps” ist meine Meinung: ”Ja, aber…”

Ja, aber nur wenn ein generelles Interesse an Computern besteht.

Klar, um mal in eine Programmiersprache hinein zuschnuppern, reicht es sich mal durch ein lustiges Tutorial (z.B. tryruby) zu klicken. Aber sobald man sich eine Entwicklungsumgebung installiert und wirklich anfangen will, muss man sich mit seinem Computerauseinandersetzen und ich kenne keinen Programmierer, der nur Programmierer ist, ganz ohne Ahnung von Administration.herz

Bei allen Programmierern ist eine Liebe zum Computer vorhanden. Jeder hat schon mal an seinem Werkzeug geschraubt und die Festplatte oder sonstige Komponenten ausgetauscht, kennt die kleinen Unixtools wie grep, find, sed oder awk und kann damit kleine Einzeiler zusammenstecken.  Das ist besonders praktisch, wenn einem wirklich versteckte Programmfehler unterkommen oder man eben schnell ein paar Tonnen Logfiles auswerten muss.

Ja, aber nur wenn man gerne rätselt und kreativ ist.

Manche Programmieraufgaben machen besonders viel Spaß, weil sie kniffelig sind und man rätseln muss, wie das Problem zu lösen ist. Ein Klassiker für Anfänger ist: Zahlen in römische Schreibweise umwandeln. Dabei müssen einige Randbedingungen abgefragt werden, wann wird welcher Buchstabe benutzt, wann schreibt man links und rechts, etc.  (Hier wird das Problem in verschiedenen Programmiersprachen gelöst.)

Andere Programmieraufgaben klingen eigentlich ganz einfach, aber die Randbedingungen ein problematisch. Zum Beispiel darf das Programm nur eine bestimmte Laufzeit haben oder die Datenbankstruktur ist so hysterisch gewachsen, dass man über verschiedene Zwischenschritte erst an die gewünschte Auswertung kommt.

Zusätzliche Kreativität erfordert die Ehre und der Sinn für das Schöne, das Craftmanship. Zwar funktionieren einige Lösungen, aber sind umständlich programmiert. Wir Programmierer finden es toll, wenn der Code kurz, lesbar, ohne Doppelungen und leicht modifizierbar ist. Gerade um Codedopplungen zuvermeiden und den Code modular zu halten, damit auch zukünftige Programmteile den Teile weiter benutzen können, benötigt es neben Gehirnschmalz eine gewisse Portion Abstraktionsvermögen und im Voraus denken.

Ja, aber nur wenn die Frust-Toleranz hoch ist.

Das erste was einem nach dem Start des selbstgeschrieben Programms begrüßt sind Fehlermeldungen. Das ist in 99,123% aller Fälle so.

Das darf einen nicht frustrieren und dazu bewegen alles Hinzuschmeissen. Manchmal ist man stundenlang auf der Suche nach einem fehlenden “;”. Dann fängt man an den Fehler zu umkreisen und einzuzingeln, bis man endlich die Stelle gefunden hat.error1-300x86

Je länger und je tiefer der Fehler in der Struktur ist, manchmal sogar in der Programmiersprache selbst oder in der Speicherverwaltung des Betriebssystems, desto größer ist die Freude über den Fehlerfund. Zusätzlich lernt man bei der Fehlersuche viel über das System und die Interna der Programmiersprache.

Ja, aber nur wenn der Wille ständig  und freiwillig weiter zu lernen vorhanden ist.

Dass Weiterbildung eine Voraussetzung ist, muss ich eigentlich nicht unbedingt erklären. Es geht nicht nur um neue Programmiersprachen, neue coole Frameworke oder Plugins, sondern auch um neue Geräte (Tablets, Smartphones, Kühlschränke ;) ) auf denen die Software plötzlich laufen muss.

Das lernen wir Programmierer nicht alles während unserer Arbeitszeit. Wir lesen freiwillig Fachmagazine, Blogs, folgen bestimmten Twitter-Accounts und gehen zu Konferenzen und Usergroups und das alles in unserer Freizeit, weil es uns interessiert.

Ja, dann kann es jeder lernen!

Wenn alle Voraussetzungen erfüllt sind und ein echtes Interesse vorhanden, bin ich der Meinung das jeder programmieren lernen kann.die Freude wenn der Fehler gefunden und beseitigt ist.

Ich hoffe, ich habe mit meinen “Ja, aber …” niemanden abgeschreckt, denn programmieren ist eine wirklich toll. Es ist ein erfüllendes Gefühl, was eigenes erschaffen zu haben.

Es gab sie schon immer und es wird sie auch immer geben: die Frauen in der IT

Momentan ist das Thema Frauen im Beruf und speziell Frauen in der IT wieder in aller Munde (und Blogs).

Die Frage die sich stellt ist, warum sind es gerade in der IT so wenige? Dazu habe ich als Software-Entwicklerin natürlich auch eine Meinung und eine Idee wie es besser werden könnte:

Schenkt euren Töchtern Technik!

IMAG0187Der erste Schritt ist schon früh die Kinder zu begeistern und eine verpatzten Mathearbeit nicht mit “ach die meisten Mädchen sind nicht so gut in Mathe” abzutun und ruhig einen Elektrobaukasten unter den Tannenbaum zu legen.

Gebt den Kindern Selbstbewusstsein und Durchhaltevermögen!

Die nächste Hürde auf dem Weg zur IT-lerin ist die nicht technikinteressierte Peergroup. Zumindest war das in meinem Fall so. Nachdem ich die ersten paar Zeilen BASIC geschrieben hatte und Listings aus dem 64er Magazin erfolglos abgetippt
hatte, fehlte es an Gleichgesinnten.

Macht anständigen Informatikuntericht an Schulen!

Ein essentielles Problem ist wahrscheinlich, dass gute Informatiker selten Lehrer werden. Denn in der Wirtschaft lauern viele interessante und gut bezahlte
Herausforderungen.

Das nächste Problem ist die Schülerinnen fůr den Unterricht zu begeistern. Viele Mädchen scheuen sich einen Kurs zu wählen der von angehenden Nerds nur so wimmelt.

An meiner Schule gab es einen separaten Kurs für Mädchen. Der war ein voller Erfolg, auch wenn ich eigentlich gegen Extrawürste für Mädchen bin.frau_computer

Entwicklerinnen, Administratorinnen, etc.: Macht Werbung für
euren Job!

Ich bin Entwicklerin und begeistert vom Programmieren. Es ist wie ein Spiel ohne Grenzen mit Rätseln und Herausforderungen.
Es ist Kunst!

Oder wie die Computerwissenschaftlerin Andere Beaulieu sagte:

Programmieren ist wie küssen: Man kann
darüber reden, man kann es beschreiben, aber man weiß erst
dann, was es bedeutet, wenn man es getan hat.

Falls ihr jetzt Interesse habt: in jeder Stadt gibt es Treffen von Programmierern. Schaut doch einfach mal bei den Railsgirls vorbei. Am 14./15.9. ist deren erster Workshop. Vielleicht sehen wir uns?

Oder versucht es selbst mit einer Anleitung: tryruby von der Codeschool,  eigenen Homepage der w3cschool, Grundlagen der Programmierung auf coursera oder oder oder.

Legt los, es macht Spaß!

Ich schreibe einen Erziehungsratgeber!

(… oder auch nicht. )

Als beim Ausmisten meines Bücherregals sich erstaunlich viele Erziehungsratgeber in der IMAG0186Kellerkiste sammelten und wieviele ich schon in den Regalen meiner Freundinnen gesehen habe,  kam mir die Idee. Ich schreibe auch einen Erziehungsratgeber, denn der Markt dafür ist da!

Mein Buch soll zeitlos sein.
Es soll keine Erziehungsmode abbilden, die die antiauthoritäre Erziehung Ende der 60er Jahre.  Mein letzter Stand der Erziehungsmode war, dass man sich keine “Tyrannen züchten” soll.  Aber wer lässt sich schon freiwillig auf der Nase herumtanzen und merkt nicht, wenn sein kleines Mäuschen gerade die Grenzen austestet?

Mein Buch soll Tipps beinhalten die auch umsetzbar sind.
Nicht immer hat man die Zeit und auch den nötigen Geduldsfaden um all die bunten pädagogisch wertvollen Ideen der Konfliktbewältigung umzusetzen.
Es gibt niemanden der nicht mal mit Dingen droht die nicht einhaltbar sind.Ausserdem darf man auch mal ausrasten.
Niemand kann immer perfekt, ruhig und ausgeglichen sein und ich bin mir mehr als sicher, dass Kinder von 100% perfekten Eltern mit Minderwertigkeitskomplexen ausgestattet sind.

Mein Buch soll keinen Druck ausüben oder Ängste schüren.
baby

Dann kam die Realität dazwischen und nach einem Kaiserschnitt lagen mein Kind und ich vollgepumpt mit Chemie auf verschiedenen Stockwerken.
Bei diversen Gesprächen mit anderen Müttern musste ich feststellen, dass ich nicht die einzige war, die darauf verlassen hat, was andere behaupten.

Mein Buch soll für alle gelten.
Menschen sind verschieden. Manche basteln gern mit ihren Kindern andere singen und
tanzen lieber. Es gibt ängstliche, verschmuste, freizügige und/oder  spontane Eltern. Niemand sollte gegen sein Ich handeln müssen. Kinder können nur authentische Erwachsene ernst nehmen, die auch selbst die aufgestellten Regeln befolgen können.

Einen Titel für das Buch hätte ich auch schon parat:IMAG0143

“Handel vernünftig, aber mindestens authentisch!”

So und dann…  Ja und dann? Eigentlich ist mit dem Satz schon alles gesagt und jedes Wort mehr würde wieder in irgendeine Richtung weisen, die nicht auf das Kind/die Eltern/die aktuellen Umstände oder sonst was passen.
Also doch kein Buch. Vielleicht eine Postkarte?