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.

RailsGirls Hamburg 2013

Rails Gils HamburgNach dem schönen Workshop mit vielen motivierten Teilnehmerinnen letztes Jahr, freue ich mich auf das diesjährige Event. Ich bin gespannt was dieses Jahr gecodet wird.

Hier findet ihr die Slides zu meinen Talks:

Was wir heute so mit Ruby on Rails, dem Editor, dem Terminal machen und wie wir am Ende die App NICHT auf dem Handy laufen lassen

Zu diesem Talk kam es, weil wir letztes Jahr nicht auf die Idee kamen, einen Einführungstalk zu machen und die Erwartungen abzugleichen. So kam es, dass viele Teilnehmerinnen nicht wussten was denn nun dieses Terminal ist, ob der Befehl aus dem Tutorial in den Editor oder das Terminal kommt und warum wir die fertige App nicht auf das iPhone überspielen. Apps sind ja schließlich Handy-Programme.

Hier noch ein paar weiterführende Links:
About ruby - kurze Abhandlung warum ruby toll ist und sich schnell verbreitet hat
The Philosophy of Ruby – Interessantes Interview mit Matz
About David Heinemeier Hansson
Interview mit David Heinemeier Hansson
David Heinemeier Hansson erklärt warum er ruby liebt
Unix-Befehle für Anfänger
Einführung in die Unix-Shell für Mac OS X

 

Warum ich am allerliebsten Programmiererin bin

Ich bin wirklich sehr sehr gern Programmiererin und will mit diesem Talk das Bild, des Stereotypen Programmierer und seines Alltags zurecht rücken. Denn wir sehen nicht alle aus wie Alan Cox und bis spät in die Nacht stur am Schreibtisch im Keller bei Pizza und Cola durch programmieren, machen wir auch nicht (naja, zumindest immer seltener und nur in der Freizeit…).

Hier noch ein paar weiterführende Links:
Erklärung “Programmierer” auf Stupedia
Berufsbild Softwareentwickler
Agiles Manifest
Was ist Scrum
Was ist extreme programming
Paper Prototyping

Ich freue mich auf den heutigen Workshoptag!

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.

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!”

Warum? Warum? Warum? Warum? Warum?

Nein, was wird kein Blogpost über meine Kinder die mir täglich Löcher in den Bauch fragen,domino sondern über die “5 whys”.

In einer der letzten Retrospektiven haben wir diese Methode angewandt
um den Kern der Probleme aufzuspüren. Da wir diesen Weg das erste Mal gegangen sind, war er etwas holperig  aber trotzdem konnten wir gute Aktivitäten aus den Problemen ableiten.

Die Idee die hinter der 5 whys – Methode steckt, ist mit jedem why einen Schritt näher an den Ursprung des Problems zu kommen.

Also zum Beispiel:
Problem:  “Am Montag war die Site offline”

  • Warum?   “Weil der Server überlastet war”
  • Warum?   “Weil die Software nicht performant genug war”
  • Warum?   “Weil für die Optimierung keine Zeit war”
  • Warum?   “Weil bei der Projektplanung und Festsetzung der Deadline die Urlaubszeit der Entwickler nicht berücksichtigt wurde”
  • Warum?   “Weil der Urlaub sehr kurzfristig eingereicht wurde”

-> Lösung: Bessere Projektplanung durch frühe Urlaubsplanung!

Hierbei wird deutlich, dass eine schnelle Maßnahme, wie Hardware nachrüsten bei der schlechten Planung immer wieder zu Problemen und unperformantem Code geführt hätten.

Wie ist man sicher, dass die richtige Ursache gefunden wurde?
Dies kann mit einem wenn-dann-Umkehrschluß überprüft werden.
Also:

“Wenn der Urlaub frühzeitig geplant wird, dann wird die Projektplanung und Festlegung der Deadline das berücksichtigen”

Wie stellt man sicher, dass man am letzten Knoten angelangt ist?
Wenn man sich mit den Antworten irgendwo in Prozess Nähe befindet, ist die Chance groß, dann man am Ende angelangt ist.

Was ist, wenn man verschiedene Ursachen findet?
Dann verzweigt sich der Pfad, was in den meisten Fällen ein Indiz dafür ist, dass das Problem zu generell ist und kein spezifisches Problem.
In der strengen 5 why Methode wird nur ein Strang verfolgt, da nur so genau ein Ursprung gefunden werden kann.
Alternativ kann man die verschiedenen Stränge nacheinander abarbeiten und evtl. führen sie trotz Verzweigung zum gleichen Ziel.

Die wichtigste Regel ist, dass sich keiner von einer vermutlichen Problemlösung leiten lässt und die Fragetreppe in eine ganz bestimmte Richtung leitet.

Diese Methode der Ursache-Wirkung-Bestimmung ist wirksam, nur leider auch sehr anstrengend.

Viel Spaß damit!

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ß!