Diesmal haben wir (Peter, Schepp, Hans und Anselm) Mathias Schäfer eingeladen und unterhalten uns über Unlearning und Diversity, sowie den Einstieg in die Webentwicklung.
Schaunotizen
- [00:01:40] Unlearning
- Mathias hat durch seine Arbeit früher bei selfhtml und heute bei OpenTechSchool tiefe Einblicke in die „Kultur“ der Webentwickler-Community. Wir nehmen das als Anlass und lassen uns von Problemen erzählen, wie schwierig es für Neulinge ist, sich in einer Entwicklergemeinde willkommen zu fühlen. Wir sprechen über Initiativen wie die RailsGirls, nehmen ein Velocity-Conference Video als Anlass darüber, wie wir mehr Diversity erreichen können und kommen leider zwangsläufig auf Negativbeispiele und die Nicht-Willkommenskultur zu sprechen. Wir finden jedoch auch Lösungen, wie zum Beispiel die, privat oder bei der Open Tech School Mentor zu werden.
[00:58:51] Links
- A Cartoon Intro To Redux
- Eine anschauliche Erklärung der Unterschiede zwischen Flux und Redux als Cartoon.
- JavaScript dates, trains, Passover, and Henry VIII
- Wir haben einen sehr interessanten, wenn auch lang und komplizierten Beitrag zum Thema JavaScript Dates gefunden.
- Mozilla’s Service Workers Cookbook
- Eine Kollektion an Service Worker Beispielen. Und hier könnt ich nachsehen, welche Service Worker features ihr wo benutzen könnt.
- Model View Culture Magazine
- Passend zu unserem Hauptthema haben wir hier noch einen Link zu einem guten Magazin über Technologie und Diversity-Kultur.
Kommentare
Dieter #
Geschrieben am 6.12.2015 um 13:31
TL;DR: Die im Podcast beschriebenen neuen Communities werden langfristig keinen Bestand haben, da sie die Fehler der alten wiederholen und die eigentlichen Herausforderungen nicht angehen.
Disclaimer: Ich beziehe mich allein auf die Aussagen aus diesem Podcast. Sollte ich etwas falsch verstanden haben, bitte korrigieren Sie mich.
Hallo Herr Schäfer, hallo Working-Draft-Team,
ich wage eine steile These: So wie die Alternativen zur etablierten Entwicklerkultur vorgestellt wurden, werden sie langfristig nicht funktionieren.
Denn sie wiederholen essentielle Fehler der alten Entwicklerkultur, enthalten einen neuen und lösen einige wichtige Probleme nicht.
Die wiederholten Fehler sind zum einen das Kritik abwertend an Menschen geübt wird („Arschpirat“ statt z.B. „arschiges Verhalten“). Daraus folgt, dass Menschen als Feinde betrachtet und geächtet werden, statt Verhaltensweisen („den Arschpiraten aus der Community schmeißen“ statt z.B. „dein Verhalten war unakzeptabel weil […] Bitte kommentiere nur, wenn du auch bereit bist dich an die vereinbarten Regeln zu halten“). Der Unterschied ist: bei Variante eins ist der rüde Mensch für die Community verloren, stänkert aber woanders weiter rum. Bei Variante zwei hat man die Chance (alle wird man nicht von ihrer Art abbringen, aber die meisten) den Menschen nach einer kurzen Auszeit in die Community zu integrieren und es gibt insgesammt (nicht nur in der Community) einen rüden Menschen weniger.
Der zweite Fehler ist Fähigkeiten an Sachen abzuleiten, die keine kausalen Zusammenhang haben. In der alten Entwicklerkultur z.B. wird aus weiblichem Geschlecht mangelndes Interesse und mangelnde Bereitschaft zu lernen abgeleitet. In der neuen wird aus männlichem Geschlecht eine Zugehörigkeit zur alten Entwicklerkultur abgeleitet. „Die Veränderung musste von Leuten kommen, die in der Community unterrepräsentiert sind“ An sich richtig (Systeme ändern sich nicht ohne Druck von außen), aber die Repräsentation an etwas anderem (Geschlecht, Hautfarbe, sexuelle Orientierung, Vorbildung) als die Bereitschaft zu einer humanen Kommunikation und Koorperation festzumachen führt zum Verschrecken potentieller Mitschtreiter.
(Ich gehe mal von mir aus: alte Entwicklerkultur spricht mich nicht an, weil ich nicht gern entwürdigt werde. Neue Communities wollen mich nicht so gern haben, weil ich äußerlich den Leuten in der alten Entwicklerkultur ähnlich bin. [So kommt es zumindest bei mir an, genauso wie sich z.B. Frauen in der alten Entwicklerkultur nicht willkommen fühlen, obwohl keiner ein „No Girls“-Schild aufgehängt hat.])
Natürlich ist dieser Fehler absolut verständlich, da man weder Kompetenz, noch Kommunikationstil auf den ersten Blick ableiten kann und sich eben auf vergangene Erfahrung (sprich Korrelationen) verlassen muss. Umso wichtiger ist es sich dem bewusst zu sein.
Der neue Fehler liegt darin, keine Kritik vermitteln zu wollen. Es wurde erwähnt, dass man z.B. Anfänger nicht kritisieren und auch Programmiersprachen nicht abwerten soll. Aber ohne die Korrektur von Fehlern gibt es keinen Lernfortschtschritt, ohne ansprechen von Fehlern gibt es keine Korrektur und das Ansprechen von Fehlern ist nunmal Kritik. In Sachen Programmiersprachen ist es nunmal Fakt, dass es sehr schwer ist in PHP sicheren Code zu schreiben und es ebenfalls sehr schwer ist in Perl wartbaren Code zu schreiben. Persönlich würde ich Anfängern daher immer von diesen Programmiersprachen abraten bzw. klar machen, was die Schwachstellen und die Alternativen sind.
Dies brint mich zu den nicht gelösten Problemen.
Nummer eins ist das vermitteln von Kritik ohne den Kritisierten emotional in die Ecke zu drängen. Die alte Entwicklerkultur „löst“ es durch die Forderung Emotionen (besonders Anderer) zu ignorieren („dickes Fell entwickeln“, „nimm das doch nicht perönlich, dass er dich inkompetent genannt hat“). Damit vergrault man Anfänger (offensichtlich die „unterrepräsentierten Bevölkerungsanteile“, aber sicher auch einen Teil der eigenen Bevölkerungsgruppe) und setzt die Mitglieder unnötigem Stress aus. Die neuen Communities versuchen die Kritik einfach ganz zu vermeiden. Ohne Kritik keine Diskussion, ohne Diskussion (langfristig) kein Fortschritt. Mein Ansatz wäre eben die Kritik nicht persönlich zu formulieren (die Sache kritisieren, nicht den Menschen) und auch bei Kritik an Kritik ganz klar zwischen dem (technischen) Inhalt, der Form und den Menschen zu unterscheiden. (Das ist natürlich leichter gesagt, als getan.)
Nummer zwei ist die effiziente Nutzung von Ressourcen zum Entwickeln von Projekten und zum einbinden von Anfängern. Einerseits bleibt eine Community, die jeden „Anwärter“ erst durch dutzende teilweise veraltet und widersprüchliche Tutorials quält auf jeden Fall hinter ihrem vollen Potential zurück. Wird allerdings jede Frage eines Außenseiters sofort kompetent und ausführlich beantwortet, auch wenn die gleich Frage gestern schon dreimal gestellt und einzeln beantwortet wurde, verkommt die Community zu einem kostenlosen Dienstleister, der nur damit beschäftigt ist Standardprobleme Außenstehender zu lösen, die nicht bereit sind selbst Zeit und Energie in die Lösung zu investieren. Für echte Entwicklung bleibt keine Zeit. Damit schwindet auch wieder die Attraktivität für motivierte (aber noch unerfahrene) Entwickler in die Community einzusteigen. An diesem Punkt sehe ich die OpenTechSchool eher als sinnvolle Erweiterung einer Entwicklercommunity, als als Alternative. Zwar ist der Overhead (Anreise, Materialvorbereitung) viel größer als z.B. bei einem Foreneintrag, dafür ist die Lerneinheit an sich viel effizienter, da nur lernbereite Menschen da sind (nicht Problemlösung ist die angebotene Leistung, sondern Lehre), Nachfragen Sekunden statt Stunden dauern und Fragender und Antwortender sich im selben Kontext befinden (Programmiersprache ist bekannt, Tools sind bekannt und zur Not kann jeder schnell mal auf das „Problemsystem“ schauen). Neue Entwicklung (Experimentieren mit unbekannten Lösungen, Diskussionen über Vor- und Nachteile, Implementierung neuer Lösungen) kann (und will?) die OpenTechSchool aber nicht leisten.
Grüße von Dieter
Schepp #
Geschrieben am 6.12.2015 um 17:46
Hallo Dieter, danke für Deinen Kommentar. Hat Spaß gemacht zu lesen und es ist sicherlich einiges dran an dem was Du sagst. Auf jeden Fall muss das Thema noch weiter entwickelt werden, zumindest in meinem Kopf. Nochmals danke und schöne Woche!
RSS-Feed zu diesem Beitrag
Kommentare sind für diesen Beitrag geschlossen.