t3n News Entwicklung

beyond tellerrand: Fail again, fail better – gelebt in CSS

beyond tellerrand: Fail again, fail better – gelebt in CSS

Zoe Mickley Gillenwater ist UX-Designerin und Buchautorin rund um und . Auf der „beyond tellerrand // BERLIN“ hat sie darüber gesprochen, wie sie scheitert und aus Fehlern lernt.

beyond tellerrand: Fail again, fail better – gelebt in CSS

(Foto: Christian Siedler/ @labuero)

Kreative Menschen sind nicht anders als unkreative, sie experimentieren einfach mehr und sind dadurch erfolgreich, allerdings machen sie dabei auch mehr Fehler aus denen sie lernen könnenZoe Mickley Gillenwater

Learning by doing. Zoe hat auf der „beyond tellerrand // BERLIN“ ihre Erfahrungen geteilt – darüber wie sie mit dem Scheitern umgeht, anhand der Flexbox in . Dabei gab sie Schritt-für-Schritt Einblicke und half den Zuschauern jeden einzelnen Gedanken anhand von Code-Zeilen zu verstehen. Aber allen voran: Sie zeigte, wie Entwickler CSS schreiben, aber nicht sollten.

beyond-gillenwater
beyond Tellerrand // BERLIN: Gillenwater über Scheitern und Code.

Gillenwater bringt es auf den Punkt: Entwickler müssen verstehen welche Befehle sie nutzen und wie die eingesetzten Properties funktionieren. Code-Zeilen zu kopieren, ohne zu verstehen, was sie bedeuten: „Das ist keine Schande, denn nur so lernt man“, sagt Zoe.

Zoe Mickley Gillenwater lebt die amerikanische „Kultur des Scheiterns“ als Entwickler vor und gibt offen zu, dass sie in ihren Projekten „mal schnell“ von Demos und Tutorials zusammenkopierten Code verwendet. Dass diese an sich falsche Vorgehensweise trotzdem zum Lernprozess beiträgt, verdankt sie ihrer Kreativität und Bereitschaft Neues auszuprobieren. Dabei ist sie dankbar, dass sie Fehler macht, denn „hätte der Code gleich beim ersten Mal funktioniert, hätte ich Flexbox nie verstanden“.

Ein „dünner Vortrag“ mit erstaunlichen Erkenntnissen

Der Vortrag, der in Berlin stattfindenden beyond tellerrand, „fühlte“ sich für mich etwas dünn an. Letztendlich hat jeder einmal so angefangen: Code kopieren, verstehen und verbessern. Ich war erstaunt, dass eine versierte Entwicklern wie Zoe Mickley Gillenwater immer noch nach diesem „Quick-n'-Dirty-Prinzip“ arbeitet und erst beim Auftreten eines Problems versucht, die jeweilige Property zu verstehen. Genau das machte sie nämlich anhand eines realen Beispiels rund um die perspective-Property klar.

Persönlich war ich von ihrem Vortrag enttäuscht. Die Kernaussage: „Versteht den Code, den ihr schreibt“, hätte sie auch kürzer fassen können.

Ich hätte mir gewünscht, dass sie mehr darauf eingegangen wäre, wo Entwickler gute Ressourcen beziehen können, um nicht die Dokumentation lesen zu müssen. Klar, ich wusste durch die Beschreibung des Vortrags was mich erwartet – und trotzdem: Auf einer Konferenz wie der und von einer Entwicklerin dieses Kalibers, habe ich mir deutlich mehr Nutzwert erwartet. Die einzige Erkenntnis bleibt: „Ich habe Code kopiert, das hat nicht funktioniert. Ich habe ihn gelesen und verstanden, jetzt funktioniert der Code.“ Na ja, und „ihr seid alle super, weil ihr Fehler macht“.

Der Vortrag fühlte sich wie streckenweise langatmiges Infotainment an: Viel Emotion und Motivation, wenig Nutzwert. Dass Entwickler verstehen müssen, was Code macht, bevor sie ihn verwenden, wird schließlich schon seit Jahren gepredigt.

Lest ihr vor dem Anwenden einer CSS-Eigenschaft die dazugehörige Dokumentation?

Vorheriger Artikel Zurück zur Startseite Nächster Artikel
6 Antworten
  1. von Mo am 05.11.2014 (16:25 Uhr)

    Bevor ich ein CSS-Feature produktiv nutze will ich es verstanden haben.

    Natürlich wurde dazu vorher die Doku und diverse andere Literatur zu Rate gezogen und etliche Test-Cases erstellt.
    Ich persönlich halte nicht viel von (meist ungesundem) maximal Halbwissen.

    Antworten Teilen
  2. von wefwefwefwefew am 05.11.2014 (18:07 Uhr)

    Da man heute als FrontendDev CSS-Guru, Markup-Gott, VanillaJS-Experte, MVC-Framework-Connoisseur und Builttool-Crack sein muss, ist es gar nicht anders möglich als auf bestimmten Gebieten anwendbares Halbwissen zu haben, was im Fehlerfall dann mit Hilfe einer Stackoverflowrecherche o.ä. um spezifisches Wissen erweitert wird.

    Antworten Teilen
  3. von coder am 05.11.2014 (18:41 Uhr)

    In unserem Kulturraum ist es nicht leicht zu verstehen, was die Frau Gillenwater sagen möchte. Viele junge Programmierer trainieren sich einen komplizierten und zeitaufwendigen Programmierstiel an. Meistens wird wieder und wieder an einzelnen Programmseiten gearbeitet, bis das Programm einem "Standard" entspricht. Zeit, Kosten und Erfolg werden oft außer Acht gelassen. Diese Dinge sind begrenzt und hängen in der Realität von externen Faktoren ab. Sich von der allgegenwärtigen Programmier-Doktrin zu lösen gibt mehr Freiraum die externen Faktoren zu verstehen. Sie beschreibt es eher so: Picasso wäre nicht Picasso, wenn es ihm nicht egal gewesen wäre zu kritzeln.

    Antworten Teilen
    • von wurmbock am 06.11.2014 (12:07 Uhr)

      +1

      Unser Kulturraum hat immer noch viel mit"akademischer Arroganz" und "selbstverliebter Ingenieursdenke" zu kämpfen... das gilt offensichtlich auch im Webdesign / Programming allgemein. Den Kreativköpfen in diesem Land würde ein bisschen mehr von diesem Trail & Error Ansatz gut tun. Um den wilden Oscar zu zitieren: Talent borgt - Genie stiehlt :-)

      Antworten Teilen
  4. von elnicknamio am 05.11.2014 (19:10 Uhr)

    Um ein wenig unkonventionelle konstruktive Kritik anzubringen, ganz nach dem Autor: Für mich fühlt sich eher der Artikel selbst etwas dünn an. Frau Gillenwater hatte nicht mehr und nicht weniger als einen gelungenen Motivationsvortrag erbracht. Was zum Teufel soll eigentlich dieser Artikel? Der bietet nicht mehr Inhalt.

    Antworten Teilen
  5. von Insomnia88 am 06.11.2014 (10:17 Uhr)

    Also ich finde es etwas seltsam, was sie da beschreibt. "Code Zeilen kopieren ohne sie zu verstehen" - Ja, ich "gestehe" Code aus Tutorials und Snippets zu kopieren aber das heißt doch nicht, dass ich nicht weiß, was dieser bewirkt? In der Regel gibt es eine ziemlich ausführliche Erklärung zu den Code-Fragment bzw. zur theoretischen Hervorgehensweise und wie man was bewerkstelligt. Ich habe mir ehrlich gesagt noch nie vorher "die" CSS Doku zur Brust genommen bzw. nur in Form von kurzen Info Texten ala w3schools und weiß trotzdem was die Deklarationen (bis auf immer neu hinzukommende CSS3+ Befehle, die ich wegen Kompatibilitäten eh nicht bzw. nur kaum nutzen darf ;)) bewirken.

    Antworten Teilen
Deine Meinung

Bitte melde dich an!

Du musst angemeldet sein, um einen Kommentar schreiben zu können.

Jetzt anmelden

Mehr zum Thema Beyond Tellerrand
Content first: Workflows im Zeitalter von responsive Webdesign
Content first: Workflows im Zeitalter von responsive Webdesign

Auch in diesem Jahr drehte es sich auf der Developer Week um UX- und UI-Design. Im Panel von Patrick Lobacher haben wir uns inspirieren lassen. » weiterlesen

Responsive Webdesign: 18 kostenlose Tools und Extensions zum Testen deiner Seite
Responsive Webdesign: 18 kostenlose Tools und Extensions zum Testen deiner Seite

Beim Responsive Webdesign können Tools und Test-Werkzeuge viel Zeit sparen. Das einfache Umschalten zwischen Viewport-Größen vereinfacht die Arbeit enorm. Wir stellen euch 18 kostenlose Tools, … » weiterlesen

Responsive Design: Zehn kostenlose Webdesign-Templates
Responsive Design: Zehn kostenlose Webdesign-Templates

Das Web findet längst nicht mehr nur auf dem Desktop statt und so ist es kein Wunder, dass Responsive Design in aller Munde ist. Damit passen sich die Webseiten dem Endgerät des Besuchers an und … » weiterlesen

Alle Hefte Jetzt abonnieren – für nur 35 €

Kennst Du schon unser t3n Magazin?