Ein Schritt-für-Schritt-Prozess, um Designs in Code umzuwandeln

Das Umwandeln von Website-Design-Dateien in eine Kombination aus HTML, CSS und JavaScript ist das tägliche Brot vieler Front-End-Webentwicklungsjobs, aber es gibt einen Teil dieser Arbeit, der nicht gut in Tutorials zu einem bestimmten Thema passt. Es gibt einen Prozess des Zerlegens eines Designs und des Überlegens, wie die Umsetzung angegangen werden soll, der für neue Front-End-Entwickler eher im Rahmen des On-the-Job-Trainings stattfindet. Es ist nichts, das neben den Kerntechnologien gelehrt wird (unabhängig davon, wo wir diese Technologien lernen – Hochschule, Bootcamp oder auf eigene Faust).

In diesem Beitrag werfen wir einen Blick darauf, wie man vom Design zum Code kommt und warum man einen solchen Prozess befolgen sollte, anstatt sich kopfüber in den Code zu stürzen – was, seien wir ehrlich, wir gerne tun! Die Inhalte dieses Beitrags basieren auf meinen Erfahrungen bei der Einarbeitung neuer Entwickler, den Gesprächen, die wir geführt haben, und der Hilfe und dem Feedback, das ich in diesen Situationen gegeben habe.

Ein Grund, warum der Prozess des Übergangs von Design zu Code eine Kernkompetenz für einen Front-End-Entwickler ist, ist, dass **ohne eine Möglichkeit, sich einzuarbeiten und vorherzusagen, wie man etwas angehen wird, es sehr schwierig ist, eine Schätzung abzugeben, wie lange die Erstellung dauern wird oder welche Fragen beantwortet werden müssen, bevor man beginnt.** Viele Designs mögen auf den ersten Blick einfach aussehen, werden aber schnell komplex, sobald man ins Detail geht. Ich habe erlebt, wie dies zu Überversprechen führte, was oft zu engeren Fristen, Stress und noch schlimmeren Nebenwirkungen führt. Plötzlich dauert alles viel länger, als wir ursprünglich dachten. Igitt. Sehen wir zu, dass wir das vermeiden können.

Bewertung eines Designs

Um darüber zu sprechen, verwenden wir ein Beispiel-Design für eine „Marketing-Website“ und gehen davon aus, dass wir gebeten wurden, es zu implementieren. Wir können auch davon ausgehen, dass diese Website in einem Kontext erstellt wird, in dem Marketingfachleute über ein Content-Management-System (CMS) Inhalte bearbeiten, Abschnitte neu anordnen, Bilder ersetzen und Stiländerungen vornehmen können. Wir müssen also über die Komponenten der Seite entscheiden, die als Bausteine für das CMS dienen.

Das ist ein weiterer Grund, warum dies in der Ausbildung oft übersehen wird: Bei unseren eigenen Solo-Projekten haben wir oft statische Inhalte direkt im HTML, und Komponententeile werden nicht von Fremden zusammengesetzt, um völlig neue Seiten und Abschnitte zu bilden. Aber sobald man in realere Entwicklungssituationen eintritt, werden die Dinge dynamischer, und wir arbeiten oft auf der Ebene „Erstelle Dinge, die ein Nicht-Entwickler verwenden kann, um eine Webseite zu erstellen.“

Durchgang 1: Layout-Ideen

In diesem Design gibt es auf Anhieb ein paar Layout-Ideen, die hervorstechen.

• Ein Header mit einem horizontalen Navigationsbereich
• Eine Hauptinhaltsspalte innerhalb des Inhaltsbereichs – linke und rechte Kanten stimmen in allen Abschnitten vom Header bis zum Footer überein
• Abschnitte mit zwei Spalten
• Abschnitte mit einer einzelnen zentrierten Spalte
• Abschnitte mit einer einzelnen linksbündigen Spalte
• Ein Footer mit drei Spalten
• Ziemlich großzügige Abstände innerhalb jedes Abschnitts

Erste Eindrücke

Wir sollten alle weiteren ersten Eindrücke, die wir während dieses ersten Durchgangs haben, gute oder schlechte, festhalten. Wir können einen ersten Eindruck nie zweimal haben, und einige unserer Bauchentscheidungen und Fragen können vergessen werden, wenn wir es versäumen, sie jetzt zu notieren. Außerdem kann es schön sein, bestimmte Dinge, die einem am Design gefallen, festzuhalten, wenn man mit dem Designer spricht. Es hilft sowohl, die guten Dinge zu würdigen als auch sie mit anderem konstruktivem Feedback zu vermischen.

Unsere ersten Eindrücke könnten Dinge sein wie

• 👍 Das Design wirkt sauber und gut lesbar.
• 👍 Die Abschnitte sind alle mit Fragen betitelt (gut, das zieht den Leser an und gibt jedem Abschnitt einen klaren Zweck).
• 🤨 Fragezeichen werden inkonsistent in den Titeln verwendet (möglicherweise nur ein Versehen?).
• 🙋‍♀️ Manchmal liegen sehr ähnliche Schriftgrößen direkt nebeneinander (muss nachgefragt werden, ob das beabsichtigt ist, da es weniger elegant und professionell wirkt als der Rest der Seite).
• 👍 Das Logo ist schön mit diesem kleinen Farbverlauf.

Durchgang 2: Element-Ideen

Hier sind Dinge, die uns bei diesem zweiten Durchgang auffallen könnten

• Primäre (blaue) und sekundäre (weiße) Schaltflächenstile, sowie eine „Mehr erfahren“-Schaltfläche im Header mit einem kleinen Pfeil (vielleicht ein erweiterbares Menü?)
• Überschriften- und Unterüberschriftenstile
• Drei „Fließtext“-Größen (16px, 18px, 20px)
• Ein „Dark-Mode“-Bereich, in dem die Textfarbe weiß und der Hintergrund dunkel ist
• Eine konsistente Darstellung von „Bild & Bildunterschrift“-Sets
• Benutzerdefinierte Aufzählungspunkte verschiedener Art
• Inline-Links im Text sind unterstrichen, andere Links, wie die im Footer, nicht.
• Eine wiederkehrende Kartenkomponente mit einem Icon oben, und einer Überschrift und einer Liste in der Karte
• Das Logo wiederholt sich mehrmals in verschiedenen Kontexten/Größen.
• Der Footer enthält GROSSBUCHSTABIGE Überschriften, die anderswo nicht vorkommen.

Durchgang 3: Farbpalette

Farblich ist in diesem Design nicht viel los.

• blau/lila Primärfarbe
• helle/dunkle Textfarben
• helle/dunkle Linkfarben
• schöner Farbverlauf unter dem Wort „Hoffnung“ im Logo
• hellgrauer Hintergrund
• dunkelmarineblauer Hintergrund
• spezifische rote und grüne Farben für „Häkchen“- und „Stopp“-Icons

Einige Design-Tools ermöglichen es Ihnen, die im Design-Datei verwendeten Farbwerten als Hex-Code zu exportieren, oder sogar vollständige Sass- oder CSS-Variablendeklarationen. Wenn Sie diese Option haben, nutzen Sie sie. Andernfalls finden Sie Ihren eigenen Weg, diese Werte zu erfassen und ihnen Namen zu geben, da sie die Grundlage für einen Großteil unserer anfänglichen CSS-Arbeit bilden.

Wir möchten Farben in unserem CSS und anderem Code mit Bezeichnungen oder Klassen wie „primary“ und „secondary“ referenzieren, die wir im gesamten Code wiederverwenden können. Dies erleichtert die zukünftige Anpassung von Werten und das Hinzufügen von Themes, wenn wir dies jemals benötigen.

Durchgang 4: Strukturelle Ideen

Hier benennen wir die Bereiche der Seite möglicherweise so, dass sie für uns Sinn ergeben, und identifizieren die Hierarchie des Inhalts. Wir können die Barrierefreiheitsanforderungen unserer Implementierung verstehen, indem wir in einfacher Sprache dokumentieren, was wir als die **Beschaffenheit** und **Struktur** des Inhalts auf der Seite erkennen. Wie immer gehen wir bei unserer Bewertung von außen nach innen, von oben nach unten, von links nach rechts vor.

Die Konzentration auf die Struktur hilft uns, die zugrunde liegenden Muster zu ermitteln, die schließlich zu unseren Komponenten werden, und hilft uns auch zu verstehen, wie wir möchten, dass Menschen, die assistive Technologien nutzen, den Inhalt wahrnehmen. Dies wiederum leitet uns bei der Auswahl der HTML-Elemente, die wir für das Schreiben von **semantischem HTML** benötigen. Semantisches HTML spricht die Beschaffenheit und Struktur des Inhalts an, so dass er von Browsern korrekt wahrgenommen werden kann. Browser verwenden unser HTML, um den Barrierefreiheitsbaum zu erstellen, den assistierende Technologien wie Screenreader verwenden, um die Seite darzustellen. Sie benötigen eine starke Gliederung, damit dies gelingt, und semantisches HTML bietet diese solide Struktur.

Das bedeutet, wir müssen die Beschaffenheit dessen, was auf der Seite steht, gut genug verstehen, um es verbal ohne visuelle Unterstützung erklären zu können, falls nötig. Aus diesem Verständnis können wir rückwärts arbeiten, um das korrekte HTML zu ermitteln, das dieses Verständnis über den Barrierefreiheitsbaum ausdrückt, der in den Entwicklertools Ihres Browsers inspiziert werden kann.

Hier ist ein kurzes Beispiel für den Barrierefreiheitsbaum in Chrome, wenn alles auf der Seite ein div ist, und wenn die Elemente korrekt ausgewählt wurden, um die Beschaffenheit des Inhalts abzubilden. Die Bestimmung der besten Elementauswahl in einer gegebenen Situation liegt außerhalb des Rahmens dieses Beitrags, aber es genügt zu sagen, dass der ausdrucksstarke, nicht „generisch generisch generisch“ Barrierefreiheitsbaum unten vollständig aus HTML-Elementen und Attributen erstellt wurde und den Inhalt und seine Organisation für jemanden, der assistive Technologien nutzt, wesentlich leichter wahrnehmbar macht.

Also, in diesem vierten Durchgang könnten wir folgende Notizen machen

• Oberste Struktur
  • Überschrift
  • Hauptinhalt
  • Footer

Nicht schlecht für den ersten Durchgang von oben nach unten. Gehen wir eine Ebene tiefer. Wir sind immer noch nicht an den Kindelementen der Abschnitte selbst interessiert – wir wollen gerade genug Informationen, um die obersten Elemente innerhalb jedes Abschnitts zu benennen.

• Innerhalb des **Headers** befindet sich
  • Home-Link
  • Navigationsbereich
• Innerhalb des **Hauptinhalts** befindet sich
  • Hero-Bereich
  • Kurze Erklärung zur Krankheit selbst
  • Erklärung zur Behandlung
  • Einführung in die Studie
  • Erklärung mit weiteren Details zur Studie
  • Aussage, wer an der Studie teilnehmen kann
  • Handlungsaufforderung zur Teilnahme
  • Kurze Erklärung über das Unternehmen
• Innerhalb des **Footers** befindet sich
  • Logo
  • Zusammenfassender Satz
  • Einige Linklisten mit Titeln
  • Trennlinie
  • Copyright-Hinweis

Dieser Durchgang offenbart ein paar Dinge. Erstens sind die Header- und Footer-Abschnitte ziemlich flach und enthüllen bereits rohe Elemente wie Links und Text. Zweitens hat der Hauptbereich acht verschiedene Unterabschnitte, jeder mit seinem eigenen Thema.

Wir werden hier noch einen Durchgang machen und uns die tieferen Details in diesen Abschnitten ansehen.

• Header Home-Link – Hurra, es ist nur ein Link und wir sind fertig.
• Header Nav – Dies ist eine erweiterbare Hover-Navigation, die JavaScript benötigt, um korrekt zu funktionieren. Es gibt wahrscheinlich viele zugängliche Beispiele, denen man folgen kann, aber es wird trotzdem mehr Zeit für die Entwicklung und das Testen benötigen, als wenn wir mit reinen Links arbeiten würden.
• Hero
  • Titel
  • Spalte 1
    • Untertitel (haben wir im ersten Element-Level-Durchgang übersehen)
    • Absatz
    • Primärer Schaltflächenlink
    • Sekundärer Schaltflächenlink
  • Spalte 2
    • Hero-Bild
• Krankheitserklärer
  • Titel
  • Absatz
  • Ungeordnete Liste
  • Großer Text
  • Ungeordnete Liste
  • Bild und Bildunterschrift (Figur und Fignote)
  • Linkliste
• Behandlungserklärer
  • Titel
  • Spalte 1
    • Absätze
  • Spalte 2
    • Bild und Bildunterschrift (Figur und Fignote)
• Studie – Intro
  • Titel
  • Spalte 1
    • YouTube-Videoplayer
  • Spalte 2
    • Absätze
• Studie – Weitere Details
  • Titel
  • Untertitel
  • Karten (mit Icon, Titel und Liste)
• Aussage „Wer kann teilnehmen“
  • Titel
  • Spalte 1
    • Absatz
    • Ungeordnete Liste
  • Spalte 2
    • Absatz
    • Ungeordnete Liste
• Handlungsaufforderung
  • Titel
  • Absatz
  • Sekundärer Schaltflächenlink
• Über das Unternehmen
  • Titel
  • Absatz

Hui, das ist schnell lang geworden! Aber jetzt verstehen wir ziemlich gut, welche Arten von Dingen wir bauen müssen und welche Teile schwierig sein könnten. Wir sehen auch, dass es möglicherweise einige Hilfskomponenten geben wird, die nicht ganz durch einen dieser Abschnitte repräsentiert werden, z. B. eine Zwei-Spalten-Layout-Komponente, die auf Mobilgeräten zu einer Spalte wird und oben eine Überschrift hat, oder eine generische „Abschnittscontainer“-Komponente, die eine Hintergrund- und Vordergrundfarbe annimmt und die richtigen Stile sowie standardisierte interne Abstände liefert.

Nebenbei bemerkt, haben wir mit dieser Aufschlüsselung eine ziemlich gute Arbeit geleistet, um den endgültigen Barrierefreiheitsbaum auszudrücken, den unser HTML erstellen soll, so dass wir auf dem besten Weg sind, die Implementierung zu einer reibungslosen Erfahrung zu machen, ohne viel Nacharbeit, um die Barrierefreiheit richtig hinzubekommen.

Durchgang 5: Alles andere

Welche anderen Ideen stecken in diesem Design, was fällt auf oder welche Herausforderungen erkennen wir? Vielleicht nicht viel, aber dies ist sozusagen die andere Seite der Notizen zu den „ersten Eindrücken“. Jetzt sind unsere Köpfe voller Kontext für das, was im Design steckt.

Wenn etwas auffällt, besonders wenn es eine Frage zur Funktionsweise ist, erfassen Sie es. Ein Beispiel ist: „Hmm, was soll der Link ‚Mehr erfahren‘ in der Navigation bewirken?“ Die Antwort könnte sein: „Es ist eine Liste von Links zu jedem Abschnitt, die sich beim Hovern öffnen.“ Hin und wieder erwartet ein Designer, dass diese Art von Dingen bereits im Design impliziert ist, auch wenn sie nicht explizit dokumentiert ist, und sie taucht erst in der Designprüfungsphase auf, *nachdem* diese Sache entwickelt wurde – was oft zu spät ist, um Korrekturen vorzunehmen, ohne Termine und Fristen zu beeinflussen.

Wir sollten nun auch tiefgründig nach versteckter „Klebstoffarbeit“ suchen – Dinge wie das Ordnen unserer Stile, der Umgang mit Mobilgeräten, die Konfiguration des CMS, das Hinzufügen und Testen von Autoreoptionen und Anordnungen für unsere Bausteine sowie das Hinzufügen automatisierter Tests. Solche Dinge.

An diesem Punkt sind wir bereit, genau festzulegen, welche Komponenten im CMS erstellt werden können. Möglicherweise haben wir in unserem aktuellen System aus früheren Arbeiten bereits einige grundlegende Einrichtung vorgenommen. Was auch immer der Fall ist, wir haben genug Anhaltspunkte, um eine angemessene Schätzung der benötigten Arbeit abzugeben, gruppiert nach Kategorien. Zum Beispiel könnten wir Komponenten kategorisieren, die

• bereits zu 100 % fertig sind (keine Entwicklungszeit benötigt),
• existieren, aber für diesen neuen Zweck angepasst werden müssen (vorhersehbare Entwicklungszeit benötigt),
• völlig neu sind, aber der Weg klar und sicher ist (vorhersehbare Entwicklungszeit benötigt),
• völlig neu sind und etwas Recherche zur Implementierung benötigen. Oder das Design ist unklar, oder etwas daran gibt Ihnen ein mulmiges Gefühl und Sie müssen Diskussionen mit Stakeholdern führen. Je früher Sie dies erkennen, desto besser. Besprechen Sie es mit dem Projektleiter.

Jetzt haben wir genügend Informationen, um eine vernünftige Schätzung abzugeben. Und was noch wichtiger ist: Wir haben die Gesamtzeit des Projekts reduziert und die möglichen Schwierigkeiten unterwegs begrenzt, weil wir durch die Planung mehrere Vorteile erzielt haben.

Die Vorteile eines Prozesses

Die genauen Schritte, die wir unternehmen, und die Reihenfolge, in der sie abgeschlossen werden, sind nicht der Hauptpunkt. Am wichtigsten ist das Verständnis der Art von Informationen, die Sie beim Start eines Projekts sammeln müssen. Möglicherweise haben Sie eigene Vorstellungen davon, wie die Arbeit erledigt wird und in welcher Reihenfolge. Was auch immer für Sie funktioniert, ist großartig.

Hier sind die Vorteile, die ich beim Bewerten eines Designs mit einem Prozess im Hinterkopf festgestellt habe, im Vergleich zum einfach „draufloslegen“, „Dinge zum Laufen bringen“ und Dinge behandeln, wie sie auftauchen.

Sie betreiben ein wenig zusätzliche Recherche

So sehr wir uns wünschen, dass jedes Projekt vollständig ausgearbeitet und perfekt bereit für den Start ankommt, in Wirklichkeit enthalten Designs oft Annahmen, die unpraktisch zu implementieren sein könnten oder etwas widersprechen, das uns sonst wichtig ist, wie z. B. Barrierefreiheit. In diesem Fall können Sie das Ganze im Voraus bewerten und die Gespräche mit den Personen beginnen, die diese Probleme frühzeitig im Prozess lösen können. Dies kann geschehen, während Sie sich mit den Teilen beschäftigen, die zur Implementierung bereit sind, und verhindert, dass Sie auf diese Hindernisse stoßen, wenn Sie gerade dabei sind, diesen Teil zu erstellen. Das frühe Aufzeigen von Bedenken wird von den Leuten, die sie lösen müssen, definitiv geschätzt.

Sie können von anderen Hilfe erhalten

Ohne Plan kann es schwierig sein zu verstehen, wie weit Sie bei der Fertigstellung des Projekts sind und ob Sie Hilfe benötigen, um eine Frist einzuhalten. Selbst wenn Sie Hilfe benötigen und sie erbitten können, ist es schwierig, zusätzliche helfende Hände effektiv einzusetzen, ohne dass die Arbeit in separate kleine Blöcke unterteilt wird, die leicht aufgeteilt werden können. Wenn Sie einen sinnvollen Plan haben, können Sie bestimmte Aufgaben schnell delegieren und wissen, dass die Puzzleteile am Ende zusammenpassen.

Es ist leicht (und üblich), dass ein neuer Entwickler denkt, dass riesige Arbeitslasten und Arbeit rund um die Uhr eine gute Sache sind. Aber wenn Sie in Ihrer Rolle reifer werden, werden Sie sehen, dass ein tiefes Verständnis des Gesamtbildes eines Projekts oder sogar einer einzelnen Aufgabe wertvoller ist und einen besseren Eindruck vermittelt, dass Sie „alles im Griff haben“. Wenn Sie frühzeitig erkennen, dass ein Zeitplan nicht stimmt, haben Sie Optionen, wie Sie ihn angehen können, anstatt zu versuchen, ein Held zu sein und ein paar Wochenenden dafür zu opfern.

Die Komponentenarchitektur läuft besser

Architektonische Entscheidungen sind für mich am schlimmsten. Komponenten benennen, überlegen, wo etwas hingehört, welche Komponenten miteinander sprechen müssen, wo man Dinge in kleinere Komponenten aufteilt. Viele dieser Entscheidungen ergeben erst dann Sinn, wenn wir das Gesamtbild betrachten und über alle verschiedenen Arten nachdenken, wie bestimmte Elemente von Besuchern und Content-Erstellern verwendet werden könnten. Und viele dieser Entscheidungen sind marginal – die Wahl der „besten“ Option zwischen zwei akzeptablen Lösungen kann zu einem riesigen Zeitfresser oder völlig subjektiv sein.

Ein Prozess hilft dabei, weil Sie alle oder die meisten Informationen über die Designs erhalten, bevor Sie sich tief in die Entwicklungsarbeit stürzen. Für mich sind die Überlegung, welche Teile ich erstellen muss, und die Überlegung, wie ich diese Teile am besten mit Code erstellen kann, zwei verschiedene Dinge. Manchmal ist das, was ich brauche, nicht das, was am natürlichsten aus dem Code entsteht. Und manchmal, nachdem ich ein wenig darüber gelernt habe, was benötigt wird, kann ich Zeit vermeiden, die mit marginalen Entscheidungen verschwendet wird, weil klarer ist, welche Entscheidungen wirklich keine Rolle spielen.

Natürlich lernt man beim Schreiben des Codes immer noch neue Dinge, aber man ist jetzt besser darauf vorbereitet, mit diesen Dingen umzugehen, wenn sie auftauchen. Man hat sogar eine gute Vorstellung davon, welche Art von Problemen auftreten könnten.

Stile ergeben mehr Sinn

Bei der Planung der Arbeit können Sie wirklich herausfinden, welche Stile global sind, welche abschnittsspezifisch sind, welche komponenten- oder komponenten-spezifisch sind und welche Ausnahmen sind. Wenn Sie noch kein System dafür haben, das Ihnen gefällt, passt Andy Bells Cube CSS sehr gut zu der Art von Aufschlüsselung, von der ich spreche. Hier ist ein Video, in dem Andy mit Chris Coyier ein Beispiel durcharbeitet, das Sie sich für mehr über diesen Ansatz ansehen können.

Barrierefreiheit beginnt früh im Prozess

Das ist für mich riesig. Indem Sie die im Design enthaltenen Ideen wirklich verstehen, wird es Ihnen leichter fallen, semantische HTML-Elemente auszuwählen und geeignete zugängliche Muster zu finden, um das, was Sie dort sehen, zu erstellen. Barrierefreiheit kann in die tägliche Arbeit einfließen, anstatt nachträglich oder als zusätzliche Belastung. Unsere Perspektive wird sein, dass **hochwertiger Front-End-Code die Beschaffenheit und Struktur seines Inhalts für alle Benutzer korrekt ausdrückt**, und Barrierefreiheit ist, wie wir das messen.

Nach einer ziemlich kurzen Zeit werden Sie sehen, wie oft Designs einem bekannten Muster folgen oder einem anderen, und der Fluss des Zerlegens von etwas in bekannte Muster zur Implementierung wird sich dramatisch beschleunigen. Carie Fisher fasst Ideen im Zusammenhang mit diesem „Accessibility-first“-Ansatz gut zusammen.

Zusammenfassung

Wie ich am Anfang sagte, fällt vieles davon unter das „On-the-Job-Training“, die „mündliche Überlieferung“ der Webentwicklung. Es ist die Art von Dingen, die Sie vielleicht von einem Senior-Entwickler in Ihrem Team hören, wenn Sie Ihre erste Front-End-Rolle antreten. Ich bin sicher, viele Leute hätten andere Prioritäten als ich und würden einen etwas anderen Prozess empfehlen. Ich weiß auch sicher, dass viele Leute da draußen in Situationen ohne einen soliden Prozess arbeiten und niemanden haben, an den sie sich wenden können.

Wenn Sie sich in dieser Situation befinden oder noch nicht in Ihrer ersten Rolle sind, hoffe ich, dass Ihnen dies eine Grundlage bietet, auf die Sie sich beziehen können, wenn Sie darüber nachdenken, wie Sie die Arbeit erledigen. Idealerweise ist die Arbeit nicht nur ein Eintauchen und das Platzieren von Dingen in Divs, bis die Dinge „richtig“ aussehen, aber das ist oft unser Betriebsmodus. Wir sind bestrebt, Fortschritte zu machen und Ergebnisse zu sehen.

Ich bin sehr dankbar, dass jemand in meinem ersten Entwicklungsjob mit mir gearbeitet hat, der mir gezeigt hat, wie man Designtteile aufteilt und Arbeit für große, langfristige Projekte schätzt. Das hat mich inspiriert, darüber nachzudenken und – als ich anfing, andere Entwickler und Teams zu betreuen – darüber nachzudenken, wie ich den Prozess anpassen und zu meinem eigenen machen wollte. Mir wurde auch klar, dass es nichts war, worüber die Leute viel sprachen, wenn sie technische Fähigkeiten für die Verwendung einer bestimmten Sprache unterrichteten. Also danke, Nate!

---

Vielen Dank auch an Drew Clements und Nerando Johnson für das frühe Feedback zu diesem Beitrag. Ihr seid die Besten.