Ach, Entwickler. Die mythischen Wesen, die schnell tippen, Kaffee trinken, als wäre es eine olympische Sportart, und irgendwie “Computer reparieren” für Freunde und Familie. Aber was machen sie wirklich den ganzen Tag? Lass mich dir ein Bild malen – Spoiler: es ist viel komplizierter (und lustiger) als nur “Code tippen”.
Lass uns das mit einem Flussdiagramm aufschlüsseln, das ich angehängt habe. (Ja, Flussdiagramme, weil wenn es etwas gibt, das Entwickler lieben, dann ist es die visuelle Organisation des Chaos.)
Die Anfrage beginnt meistens mit etwas Unschuldigem wie “Kannst du einfach die Farbe dieses Buttons ändern?” oder “Wir brauchen diese Funktion morgen live – sollte nicht schwer sein.” Nicht-Techniker denken, Entwickler tippen einfach wie Zauberer: abrakadabra! Neue Funktion live!
Wirklichkeit? Diese “kleine” Änderung löst eine Kettenreaktion aus, die länger ist als deine Netflix-Watchlist.
Zuerst müssen Entwickler herausfinden, wo diese Funktion überhaupt im Code lebt. Stelle dir vor, du suchst eine einzelne Socke in einem Haus mit 500 Schubladen. So fühlt es sich an, fremden Code zu lesen. Oh, und die Socke ist in Flammen.
Nach dem Durchforsten des Codes richten sie eine lokale Entwicklungsumgebung ein. Klingt fancy, nicht wahr? Es ist eigentlich ihr privater Testplatz, wo Fehler das Unternehmens-Website nicht kaputt machen. Nur, dieser “Spielplatz” nimmt Stunden in Anspruch, weil Tools plötzlich entscheiden, nicht mehr zu funktionieren. (“Warum ist Docker heute so wütend?” “Oh, keine Ursache, es hasst dich einfach.”)
Entwickler schreiben dann etwas Code. Dann merken sie, dass sie etwas kaputt gemacht haben. Dann reparieren sie das, was kaputt ist, was unabsichtlich etwas anderes kaputt macht. Schließlich, nach vier Runden Fluchen und ein bisschen Weinen (leise, während sie Kaffee schlürfen), funktioniert der Code! Etwas. Vielleicht.
Der Code geht durch Versionskontrolle (Git) – ein Werkzeug, um zu verhindern, dass jeder auf die Füße tritt. Nur, Änderungen zusammenführen in Git fühlt sich an wie der Versuch, einen Friedensvertrag zwischen Kleinkindern auszuhandeln, die alle das gleiche Spielzeug wollen. Konfliktlösung ist eine echte Superkraft von Entwicklern.
Bevor der Code ins Rampenlicht tritt, testen Entwickler ihn. Sie klicken jeden Knopf, füllen jedes Formular aus und führen Rituale durch, um die QA-Götter heraufzubeschwören. Dann kommt jemand aus QA (Qualitätssicherung) und findet Bugs an Orten, an die Entwickler nicht einmal gedacht haben. (“Warte, der Knopf funktioniert nicht, wenn man als linkshändiger Internet Explorer 11-Nutzer eingeloggt ist???”)
Schließlich ist der Code bereit, live zu gehen. Nicht-Techniker denken, Entwickler drücken einen großen grünen “GO”-Button. Nein. Es ist mehr wie auf einer Minenfeld tippelnd, während man jongliert. Etwas immer schlägt fehl. Der Server stürzt ab. Die Datenbank vergisst, dass sie existiert. Die Funktion verschwindet mysteriös, als wäre es ein schlechter Zaubertrick. Entwickler reparieren alles in Echtzeit, während sie in Schweiß gebadet sind.
Wenn die Funktion live ist, rollen die Rückmeldungen ein: “Warum ist der Button nicht blau anstatt grün?” “Kannst du ihn 3 Pixel nach links verschieben?” Cue internes Schreien. Entwickler aktualisieren heimlich das Flussdiagramm und kehren zu Schritt 1 zurück.
Also wenn Sie das nächste Mal hören, „Es ist nur eine kleine Änderung“, denken Sie daran: hinter jedem Klick, Scroll und Swipe steckt eine epische Saga, die Codekämpfe, Koffein und eine Prise Chaos beinhaltet. Entwickler tun mehr als „Dinge in einen Computer einzugeben“ – sie sind Problemlöser, Zauberer, Therapeuten (für ihren Code) und gelegentlich Wunderheiler.
Kaufen Sie also Ihrem Entwicklerfreund heute einen Kaffee. Er hat es verdient.
Robert Mejlerö ist ein fractional CTO und Gründer von CTO als Service (ctotmc.com)
We are a Swiss Company (LLC) based in
Switzerland.