Das bisschen Code… | Ein Fehlurteil über Coding

"Eine einfache App. Nichts Aufwendiges."

Ende der 1970er-Jahre hat Johanna von Koczian die traditionell männliche Sicht auf den Haushalt besungen: "Das bisschen Haushalt macht sich von allein, sagt mein Mann. Das bisschen Haushalt kann so schlimm nicht sein […]." Wer schon mal selbst den Haushalt geschmissen hat weiß allerdings, dass das so wenig Arbeit gar nicht ist.

Ähnlich verhält es sich mit Aussagen wie:

• "Das bisschen Code schreibt sich doch fast von allein."
• "Ich möchte eine ganz einfache App. Nichts Aufwendiges."
• "Die Anwendung braucht nicht viele Funktionen. Da ist nicht viel zu tun."

In den allermeisten Fällen ein Fehlurteil über Coding und eine Fehleinschätzung des Aufwands, der damit zusammenhängt. Wenn die Entwickler unseres Teams ihre Arbeit beschreiben sollen, sagen viele unabhängig voneinander so was wie:

"Es ist, als sitzt man vor einem leeren Blatt Papier, das man füllen muss. Vorher ist nichts da, außer dem Wunsch eines Kunden. Dann wird darüber nachgedacht, wie man das Ganze angehen und die Probleme des Kunden möglichst elegant und effizient lösen kann."

An dieser Stelle scheint auch direkt die große Bedeutung eines Beratungsgespräches durch: Viele haben eine Idee, wissen aber gar nicht genau, was sie brauchen und welche Gedanken und Arbeitsschritte hinter einer App, Webanwendung, Software oder jedem anderen digitalen Produkt stecken.

Dazu kommen diverse Vorgaben, Richtlinien und Gesetze, an die es sich zu halten und über die es zu informieren gilt. All das inklusive der ungefähren Entwicklungsdauer und der Kosten Ihres Projekts erfahren Sie erst, wenn sie sich mit einer Agentur in Verbindung setzen, sich ausführliche Informationen und ggf. ein Angebot einholen.

Coding ist Arbeit!

Vielen Menschen ist nicht bewusst, wie viel Arbeit hinter einer App, Website oder Software steckt. Das ist auch völlig legitim, denn niemand, der einen Job nicht selbst macht, kann den genauen Aufwand oder die Abläufe im Hintergrund wirklich einschätzen.

Bei einer professionellen Anwendung oder Software müssen viele Dinge berücksichtigt werden, wie beispielsweise:

1. ausführliche Beratung
2. vernünftige Konzeption
3. UI-/UX-Design
4. professionelle Programmierung
5. Testphase
6. Korrekturläufe

Außerdem ist es die eine Sache, den Code technisch zu schreiben - eine ganz andere ist es, ihn auch sauber zu schreiben. Es gibt viele Variablen und Funktionen, die benannt werden müssen und in jeder Branche gibt es spezielle Begriffe. Lässt jemand beispielsweise eine Anwendung für die Gastronomie entwickeln, sollte jede Funktion im Code so benannt werden, dass der Name der Funktion für sich selbst spricht. Man sollte also nicht erst den Quelltext lesen müssen, um zu wissen, was genau diese Funktion macht.

Alle Entwickler:innen sollten sicherstellen, dass ihr Code fachlich gut und für andere Kolleg:innen lesbar ist. Spätestens wenn ein Projekt von einem Entwickler an einen anderen übergeben wird, muss sichergestellt sein, dass der Code verständlich ist. Ansonsten steht derjenige, der ein bisher unbekanntes Projekt übernimmt, vor einem großen Problem. Darauf, wie man einen guten und sauberen Code schreibt, gehen wir gleich noch näher ein: Ich habe zwei Entwicklern aus unserem Team genau diese Frage gestellt.

Grundsätzlich können wir aber Folgendes festhalten: Coding ist Arbeit und absolut keine einheitliche Sache. Jede:r Entwickler:in löst Probleme auf seine oder ihre eigene Art und hat eigene Gedanken dazu, wie eine Logik aufgebaut sein kann. Es führen also auch beim Coding viele Wege nach Rom.

INTERVIEW: Die Entwickler-Perspektive

Grundsätzlich ist es ziemlich einfach, ein Urteil über Menschen, Geschehnisse oder Berufe zu fällen. Das geht auch ohne Hintergrund- oder Faktenwissen. Einfach nur aufgrund von Dingen, die man zu wissen glaubt. Es sollte allerdings wenig überraschen, dass das nur selten gut ist und den Tatsachen entspricht.

Letztendlich können sich immer nur diejenigen wirklich fundiert zu etwas äußern, die sich wissenschaftlich mit einem Thema auseinandersetzen und Expert:innen auf dem jeweiligen Gebiet sind oder - wie in unserem Fall - einen Beruf selbst ausüben.

Deshalb habe ich intern einige Fragen gestellt und damit die wichtigen Inhalte an die Experten weitergegeben. Einerseits an unseren damaligen Geschäftsführer, andererseits an einen Entwickler. Denn auch ich kann als Redakteurin nicht fundiert beurteilen, was Coding so alles mit sich bringt.

FKT42-Gründer und ehemaliger Geschäftsführer, Michael Siedenbiedel, hat mit 16 Jahren angefangen zu programmieren und so ziemlich jede Entwicklungsstufe und Neuerung auf dem Gebiet mitbekommen. Außerdem hat er sich bis Ende 2022 bei uns um die Erstberatung von Neukund:innen gekümmert und weiß deshalb genau, mit welchen Vorstellungen viele auf Agenturen wie unsere zukommen. Mario Lüsse ist Senior-Entwickler bei uns gewesen und kennt sich vor allem in den Aufgabenbereichen Konzeptionierung und Webentwicklung aus.

Was sind die häufigsten Fragen von Neukund:innen?

MICHAEL:

Eine grundsätzliche Frage ist: Wie lange dauert’s? Zeit ist immer interessant und das einschätzen zu können, kann man von einem Kunden, der keine Ahnung von der Programmierung hat, auch gar nicht erwarten.

Viele kennen vielleicht die Aussage: "Ich geh mal eben an den Rechner und mach das mal eben" - und zack, sind plötzlich zwei Stunden um. Oder der Hobbyschrauber, der sagt: "Ich geh mal eben in die Garage und repariere was" - und plötzlich ist der ganze Abend vorbei.

Auch in der Entwicklung passiert viel, was man nicht vorhersagen kann. Das stellt man erst während des Entwicklungsprozesses fest.

Oder als Vergleich: Du sollst etwas zu einem Thema recherchieren und während Deines Rechercheprozesses hast Du plötzlich irgendwas entdeckt, was Dir vorher gar nicht bewusst war. Also musst Du auch in diese Richtung noch mal Rechercheaufwand stecken. Den Zeitaufwand dafür hattest Du vorher nicht auf dem Schirm.

Eine Frage, die auch oft kommt ist: "Warum ist der Aufwand für diese Funktion so hoch? Das macht der Computer doch von alleine. Macht der doch in einem anderen Programm auch." Das Schlagwort "User Experience Design" ist in den letzten fünf Jahren besonders hochgekommen. Der Nutzer ist es einfach gewohnt, bestimmte Dinge auf eine gewisse Art und Weise zu machen. Dadurch ist man in der Entwicklung dazu übergangen, in Apps zu gucken, was der Nutzer gewohnt ist - und dann wird das so nachgebaut. Dadurch entsteht beim Nutzer ganz schnell der Eindruck, dass der Rechner das alles von ganz alleine macht, weil das ja in dieser oder jener Anwendung auch so ist.

Das führt zu dem Problem, dass, wenn man sagt, dass etwas 40 Stunden Aufwand braucht, sich der Kunde wundert und sagt: "Wieso, das gibt’s doch fertig." Dazu kommen oft noch unvorhergesehene Sachen und deshalb kann man dem Kunden ganz schwer erklären, warum etwas so lange dauert. Das sind Erfahrungswerte, aber in der Begründung tun wir uns dann sehr schwer.

Die häufigsten Fragen sind also: "Was kostet’s?" Die geht einher mit: "Wie lange dauert’s?" Und daraus ergibt sich die Folgefrage "Geht das nicht schneller?" oder "Kann man nicht die Funktion aus der Anwendung XY rauskopieren?" Nein, kann man nicht. Man kann es zwar nachprogrammieren, aber das muss halt gemacht werden.

Das ist aber nicht nur speziell bei Entwicklern so. Wenn ich einen Motorschaden hätte, könnte ich auch nicht einschätzen, wie lange es dauert, einen neuen Motor einzubauen oder einen Kolbenfresser zu bereinigen. Das kann auch nur der Mechaniker beurteilen.

Und das ist das Problem, oder zumindest empfinde ich das so: Ich würde gar nicht auf die Idee kommen, den Mechaniker zu fragen: Wieso brauchst Du denn eine Woche dafür? Kannst Du das nicht in fünf Minuten machen? Aber das ist das, was ich bei Kundenanfragen erfahre. Manche sind der Meinung beurteilen zu können, wie lange Dinge am Rechner dauern.

MARIO:

Der Preis ist immer das größte Thema. Die Kunden, die mit dem, was sie machen, wirklich was verdienen, wissen, dass Qualität Geld kostet. Aber ein Shop-Betreiber, der beispielsweise 3.000 EUR netto verdient, ist dann schon eher schockiert, wenn man den Stundensatz eines Entwicklers nennt.

Es gibt auch Kunden, die wollen von Dir ganz genau wissen, wie Du das, was sie möchten, umsetzen würdest. Damit sie abwägen können, ob sie gedanklich vielleicht einen Fehler machen und mit denen man das dann zusammen erarbeitet.

"Wie lange dauert’s?", ist auch immer eine Frage.

Es gibt zwei Sorten von Kunden. Du hast diejenigen, die den Hintergrund zumindest ein bisschen verstehen - und dann hast du Kunden, die keine Ahnung haben. Sie haben eine Idee oder ein Bild vor Augen, wie das Ganze am Ende aussehen soll, aber das war’s dann auch schon. Zum Beispiel: "Das soll funktionieren wie eBay, aber mehr kann ich nicht sagen." Und die sind besonders darauf angewiesen, dass wir ihnen erklären, wie etwas am besten zu machen ist und in welche Richtung das geht.

Sind die Vorstellungen von Nicht-Entwickler:innen realistisch?

MICHAEL:

Habe ich in 20 Jahren noch nicht erlebt. Es sei denn, sie haben vorher schon mal ein Softwareprojekt gemacht. Dann kennen sie die typischen Probleme, die auftreten können.

Wenn man zum Beispiel an einen Shop denkt, da haben die Leute oft nicht auf dem Schirm, dass sie noch einen Bezahldienstleister brauchen, der Kreditkartenzahlungen etc. händelt. Oder so Sachen wie eine Schnittstelle zum Bankkonto. Das geht ein bisschen einher mit: Man ist das ja von anderen Onlineshops gewohnt, dass da eine Visa oder Mastercard auswählbar ist. Also geht man davon aus, das passiert automatisch. Nein, das geht nicht automatisch, weil man einen Bezahldienstleister braucht, der das Ganze abwickelt. Auch so Sachen wie Verified by Visa oder 3-D Secured bei Mastercard: Da muss man ja irgendwo eine Schnittstelle haben, die das dann mit Visa oder Mastercard abgleicht. Damit der Code, die TAN oder was auch immer geschickt wird auch funktioniert. Das ist ja nicht: Ich habe einen Shop installiert, ein paar Bilder hochgeladen und habe automatisch eine Schnittstelle zu Visa.

Diese ganze Infrastruktur wird oft außer acht gelassen und seit ein paar Jahren ist auch der Datenschutz noch wichtiger. Letztendlich kannst Du in der EU fast nichts mehr ohne eine anwaltliche Beratung machen. Oder irgendjemanden, der noch mal drüberguckt und dich da rechtssicher macht. Das ist auch ein Aufwand. Den decken wir zwar nicht ab, aber ich merke in vielen Gesprächen, dass die Kunden das gar nicht auf dem Zettel haben und dann erst mal geschockt sind.

MARIO:

Nicht immer. Manche verstehen das und wissen, dass das Zeit kostet und dass da Aufwand hinter steckt und für die ist das dann auch in Ordnung. Dann hast Du wiederum Kunden, bei denen Du jede Stunde rechtfertigen musst, weil die nicht verstehen, was für Abläufe dahinter sind.

Es ist aber auch immer die Frage, inwieweit man das einem Kunden überhaupt erklären kann, weil nicht jeder sich das anhören möchte und es auch nicht jeder versteht. Selbst wenn du versuchst, es zu erklären. Die kommen nicht aus dem Bereich, haben nichts mit Programmierung zu tun und da wird’s dann schwierig. Und gerade bei solchen Kunden ist es dann auch schwierig, Preise zu rechtfertigen. Oft suchen die sich dann jemanden, der das neben der Uni oder so für ein paar Euro macht, fallen aber irgendwann damit auf die Nase, weil derjenige dann nicht immer da ist, wenn sie support brauchen. Oder solche Geschichten wie: Da funktioniert was nicht oder man möchte etwas erweitert haben - und dann haben die Programmierer plötzlich keine Zeit oder Lust mehr.

Ich seh das auch in Facebook-Gruppen. Da werden Aufträge vergeben, bei denen die Leute dann sagen: Ich will das und das zahlen. Und ich denke: Da würde ich nicht mal ne Nachricht für schreiben. Da springen aber tatsächlich Entwickler drauf an und das sind oft Studenten oder so, die das dann für ein paar Euro machen. Da war letztens jemand, der wollte einen Onlineshop haben und nicht mehr als 500 Euro dafür bezahlen. Da haben in den ersten Stunden aber trotzdem direkt ein paar drauf reagiert und gesagt, dass sie das machen würden. Andererseits hast du aber auch da Leute, die das wirklich zu schätzen wissen und Aufträge im fünfstelligen Bereich vergeben. Das passiert da auch.

Was wird besonders oft fehleingeschätzt?

MICHAEL:

Insbesondere User Generated Content wird oft fehleingeschätzt. Also Sachen wie beispielsweise bei eBay oder Facebook. Wo Inhalte der Anwendung durch den Nutzer bereitgestellt werden. Warum wird das fehleingeschätzt? Weil die Leute nur sehen: Ich lade doch nur ein Bild hoch und schreibe ein bisschen Text dazu. Aber der ganze Validierungsprozess ist viel umfangreicher. Da sind ganz viele Details und Kleinigkeiten, die man, wenn man nicht drüber nachdenkt, gar nicht auf dem Schirm hat.

Oder auch Benutzerkontoverwaltung. In einem Onlineshop bin ich es als Benutzer gewohnt, meine Bestellliste zu sehen. Oder dass ich vielleicht noch mal eine Rechnung nachträglich runterladen kann. Oder eine Zwei-Faktor-Authentifizierung. Wie ich eingangs schon gesagt habe: Weil man es aus anderen Anwendungen so gewohnt ist, denken einige, es liegt doch als fertiger Baustein irgendwo rum und wir müssen es nur einsetzen.

Alles, was neu erscheint, kann hingegen auch ein Laie als aufwendig einschätzen. Augmented Reality zum Beispiel: Da kann man den Leuten einfacher erklären, dass da Aufwand hinter steckt, weil sie sich das schwieriger vorstellen können. Da geht man davon aus, dass die Technologie was Krasses kann. Aber wie ein Benutzerkonto aussieht, wissen alle.

MARIO:

Ganz klar: Auf jeden Fall die Zeit. Wenn auf einer Seite zum Beispiel ein Formular eingebaut werden soll, das man ausfüllen und dann abschicken können muss: Was man sieht, sind nur ein paar Elemente, in die man was schreiben kann. Da denken viele, dass das doch in einer Viertelstunde oder so durch sein müsste. Ja, die Optik kann man relativ schnell bauen, aber dann kommt’s ja auch darauf an, was dahintersteckt. Wenn man alles manuell macht, also nicht über WordPress mit einem fertigen Plug-in, ist das nicht in ein paar Minuten gemacht.

Oder zum Beispiel ein Shop-Update. Wenn du Shopware hast, kannst du als normaler User ein Update im Backend machen. Du kannst selbst auf Update klicken und in vielen Fällen geht das tatsächlich gut, sodass du innerhalb von 5 bis 10 Minuten damit durch bist. Aber du hast eben auch oft die Fälle, bei denen es zu Komplikationen kommt, wenn noch andere Plug-ins installiert sind, die nicht von Shopware kommen. Die können einen Crash verursachen, wenn Shopware geupdatet wird, aber die Plug-ins vielleicht zu alt sind oder sich das Ganze irgendwo in die Quere kommt. Und dann werden aus 10 Minuten mal locker zwei bis drei Stunden, bis die Fehler behoben sind.

Auch da verstehen viele nicht, warum man eine gewisse Summe für ein professionelles Shop-Update bezahlen sollte und drücken lieber selbst den Update-Knopf. Geht oft gut, aber wenn’s dann nicht gut geht, stehen sie da. Dann rufen sie die Firmen an und versuchen, ganz schnell Support zu bekommen, weil der Shop nicht mehr läuft und gar nichts mehr geht - und dann machen sie auch kein Geld mehr.

Da sollte man sich doch überlegen, ob man Geld in eine Firma investiert, die das professionell macht und wo dann auch sichergestellt ist, dass Probleme sofort behoben werden. Oder aber sie beißen in den sauren Apfel und legen unter Umständen den Shop für ein paar Stunden oder vielleicht sogar für ein bis zwei Tage komplett lahm, wenn sie keinen Entwickler finden, der da schnell mal rangehen kann. Und dann geht natürlich Umsatz flöten, sprich: Das Geld für einen Entwickler zu sparen war am Ende keine gute Rechnung.

Die Suche nach Fehlern ist oft ein Problem, weil viele Abhängigkeiten da sind. Das ist eine Spurensuche, die du teilweise betreibst. Oft sind es Erfahrungswerte, die da mit einfließen. Man weiß, der Fehler wird wahrscheinlich in einem bestimmten Bereich zu finden sein, sodass wir ihn dann oft auch relativ schnell finden. Aber es gibt auch Fälle, da sucht sich selbst ein Profi dumm und dämlich. Und das kann man dem Kunden auch nicht immer vorher sagen, du weißt es ja selber nicht. Manche verstehen das, manche nicht. Natürlich muss man dem Kunden früh genug Bescheid sagen, wenn man merkt, dass man für eine Sache statt ein oder zwei Stunden plötzlich vier oder fünf braucht. Damit er entscheiden kann, was wir machen.

Welche Sätze hörst Du oft?

MICHAEL:

"Für das bisschen Code habt ihr jetzt so lange gebraucht?" Oftmals besteht ein Großteil unserer Arbeit aber nicht aus der reinen Tipparbeit, sondern aus dem Erarbeiten selbst. Oft schreibt man auch viele Zeilen Code, erarbeitet dann eine viel elegantere Lösung und kann die Hälfte löschen. Es ist unheimlich schwer, das einem Nicht-Entwickler verständlich zu machen. Manchmal hast Du wirklich nur drei Zeilen, die das ganze Problem lösen, wo Du aber den ganzen Tag dran gearbeitet hast. Und dann zu sagen: Der Kunde zahlt einen ganzen Tag für drei Zeilen Tipparbeit - das ist für andere schwer nachvollziehbar.

Es gab mal ein T-Shirt mit der Aufschrift:

"Software Engineer – We do precision guesswork based on unreliable data

provided by those of questionable knowledge."

So krass würde ich es nicht formulieren wollen, aber es ist oftmals ein trial and error. Du überlegst dir, wie etwas funktionieren müsste, schreibst den Code, probierst es aus und es geht nicht. Dann stellst du fest, warum es nicht geht und besserst nach. So schreibst du immer mehr Zeilen Code dazu und dann stellst du fest, was du davon doch nicht brauchst. Am Ende bleibt dann was übrig, was funktioniert. Das ist so der typische Prozess.

Wieder der Vergleich zu Deinem Bereich: Wenn Du einen Text schreibst, dann schreibst Du ja auch nicht was hin und dann ist der fertig. Sondern Du gehst noch mal drüber und noch mal und am Ende hast Du ein paar Absätze neu geschrieben und ein paar rausgeschmissen. Das ist eigentlich ziemlich vergleichbar zu unserer Arbeit.

MARIO:

Ein Beispiel: Freunde von mir heiraten und wollen eine Internetseite haben. Für unsere Hochzeit hatte ich damals auch eine gebaut, wo man Fotos hochladen und sich einloggen konnte. Auf jede Einladungskarte kam ein Code drauf, mit dem sich die Gäste einloggen und dann angeben konnten, mit wie vielen Personen sie kommen. Sodass wir wussten, wie viele da sind. Im Anschluss konnten alle die Bilder von ihren Smartphones hochladen, die sie gemacht haben, damit wir jede Menge Fotos bekommen. Und wir konnten die Fotos vom Fotografen dort hochladen und sie für die anderen freigeben. Jetzt sind die Freunde von uns auf mich zugekommen und haben gefragt, ob ich sowas auch für sie machen kann. Ich habe gesagt, dass ich das schon machen kann, aber das wird ein bisschen dauern. Das mache ich nicht mal eben an einem Wochenende oder so.

Ich zeige dann ganz gerne mal eine Seite Quellcode und sage: Das ist jetzt nur ein Mini-Teil. Und jetzt stell Dir mal vor, ich baue das Ganze komplett und das sieht alles so aus im Hintergrund. Wenn sie das sehen, meinen die, du wärst ein totaler Freak. Die können das überhaupt nicht nachvollziehen, dass man da irgendwas draus lesen kann. Aus dem, was da auf dem Bildschirm ist. Ich hab auch nur wenige Freunde, die in der Programmierung tätig sind.

Was macht gute Entwickler:innen aus?

MICHAEL:

Da löse ich mich jetzt mal von der eigentlichen Arbeit. Was einen guten Entwickler ausmacht? Das sind jene, die das große Ganze überblicken können. Die sich nicht im Detail verlieren. Leute, die Verantwortung übernehmen können. Stichwort: Product Ownership. Also jemand, der sich mit dem Produkt, welches er baut, tatsächlich identifizieren kann und nicht mit der Denkweise daherkommt: Hat der Kunde so gewollt oder nicht gesagt, also habe ich es auch nicht gemacht.

Das klingt jetzt zwar plakativ oder allgemeingültig für jeden Job, aber es ist tatsächlich so. Wenn jemand sich nicht damit identifiziert - und das gilt ja für jeden Job - dann macht er ihn nicht wirklich gut. Dann mache ich ihn, weil ich dafür ein Gehalt bekomme, aber gehe dann halt pünktlich nach Hause. Jemand der wirklich sagt: Diese Plattform oder die App ist so gut, die würde ich auch selber nutzen, der schlägt dem Kunden vielleicht auch noch andere Features vor, die man einbauen könnte. Dass man Ideen einbringt. Dann wird am Ende ein gutes Produkt daraus und dann fängt das Ganze an zu leben und dann fängt auch der Job an noch mehr Spaß zu machen. Wenn man das Feedback vom Nutzer bekommt, dass er die Anwendung gerne benutzt. Das ist natürlich auch für Entwickler motivierend, wenn man feststellt: Ich habe das gebaut und es wird genutzt - und liegt nicht in einer Schublade rum.

Letztendlich: Programmieren lernen kann jeder. So lange er eine Begeisterung dafür entwickeln kann, dem Computer durch das Niederschreiben von Befehlen oder Algorithmen beizubringen, eine Aufgabe zu lösen. Das ist jetzt keine Raketenphysik, wo ich sagen würde, das sind die oberen Zehntausend. Das kann jeder lernen, der da Bock drauf hat. Wenn es dich fasziniert, irgendwas in den Rechner reinzuhacken und der Rechner macht dann das, was du erwartet hast: Das ist der Trigger. Wenn du den hast, dann kann das jeder lernen.

MARIO:

Eigenständig arbeiten finde ich ganz wichtig. Man muss bestenfalls um Ecken denken können, man muss ein bisschen abstrakt denken können. Es gibt viele Sachen, die man nicht nachvollziehen kann und dann muss man auch mal verrückt denken, um schneller zum Ziel zu kommen.

Du musst auf jeden Fall wissbegierig sein. Das hört nie auf. Ich habe mir das Ganze selbst beigebracht und du hörst nie damit auf. Es ist ein stetiges Lernen und du musst immer am Ball bleiben. Und wenn du kein Interesse daran hast, dann wir das auch nichts.

Du musst wirklich Bock drauf haben, dir immer wieder neue Sachen anzueignen, weil sich gerade in unserem Bereich so viel verändert. Im Bereich IT, Softwareentwicklung sowieso und die ganzen Programmiersprachen werden auch immer weiterentwickelt. Das heißt, du musst dich immer wieder an neue Dinge gewöhnen und damit klarkommen.

Was macht guten Code aus?

MICHAEL:

Gut ist der Code, wenn er funktioniert.

Das Wichtigste für den Kunden ist, dass die Anwendung fehlerfrei funktioniert und nicht zwingend, wie strukturiert der Code ist. Am Ende muss das Haus stehen und vielleicht auch bei Wind nicht umfallen. Mit welchem Zement das gemacht ist, spielt keine Rolle.

MARIO:

Guten Code macht eigentlich aus, dass er gut lesbar ist. Das heißt: Wenn ich etwas baue und werde vom Bus überfahren - dass der nächste Entwickler sofort ohne große Dokumentation grob verfolgen kann, was ich da gemacht habe.

Das kann über Kommentare sein, die man schreibt. Oder aber, dass man den Code an sich vernünftig beschreibt. Wenn du zum Beispiel den Namen einer Variable nimmst: dass du da kein Kauderwelsch hinschreibst, sondern diese Variable ordentlich benennst. Damit jeder sofort weiß: Da ist das und das drin. Also gute Lesbarkeit und eine gute Struktur auf jeden Fall. Dass du die Sachen nicht doppelt und dreifach an mehreren Stellen hast, was leider auch oft vorkommt.

Manchmal ist das aber schwierig. So eine Software wächst natürlich auch. Das heißt: Du baust eine Version, die funktioniert und auch gut aussieht - und dann entwickelst du da jahrelang dran weiter, weil immer neue Ideen einfließen und umgesetzt werden müssen. Und dann sind die Probleme oft Zeit und Geld. Ich habe es auch schon erlebt, dass Kunden dann gesagt haben: Aber nicht so teuer, dann mach die Lösung lieber etwas dreckiger und dementsprechend sieht das dann nach X Jahren auch aus.

Der perfekte Code ist eigentlich, wenn der Kunde sagt: "Mach, dass es ordentlich ist. Ich bezahle es." So, dass man Zeit dafür hat es wirklich gut zu machen. Dann wird es auch wirklich gut.

Wie schreibe ich sauberen Code?

MICHAEL:

Strukturiert. Dass Logik von Design-Sachen getrennt sind und Variablen einheitlich benannt werden. Funktionen setz ich so ein, meine Klammern setz ich so. Ich benenne die Funktionen so, dass der nächste Entwickler schon anhand des Funktionsnamens versteht, was da wohl passieren wird. Nicht irgendwas kryptisches hinschreiben. Und: Überflüssige Kommentare und Zeilen löschen.

Dass man vielleicht auch Guidelines innerhalb eines Unternehmens hat, damit alles einheitlich umgesetzt wird. Das ist sauberer Code.

Nur weil ein Code sauber ist, heißt das allerdings nicht, dass er funktioniert.

MARIO:

Das ist im Grunde das Gleiche wie guter Code. Variablen-Namen vernünftig benennen. Da, wo es Sinn macht, Zeilenumbrüche zu machen. Die Klammern richtig zu setzen.

Ich habe es tatsächlich auch erlebt, dass einer was programmiert und wirklich ohne Zeilenumbrüche gearbeitet hat. Der hat sehr vieles einfach in einer Zeile gehabt. Das konntest du nicht verstehen. Eine Anweisung schließt man mit einem Semikolon ab und dann machst du normalerweise einen Zeilenumbruch - der hat aber einfach das nächste dahinter gehangen. Wenn dir das aus dem Bild rutscht und du das auch nicht gewohnt bist, dann kriegst du das gar nicht hin. Dann musst du das Ganze erst mal komplett formatieren, damit du überhaupt was erkennst. Der hat zum Beispiel auch bei diesen Variablen-Namen $a, $b, $c und so weiter benutzt. Und keiner wusste etwas damit anzufangen. Nichts kommentiert und dann musstest du wirklich alles einzeln raussuchen.

Es macht mehr Sinn, dass du eine Variable mit 15 Zeichen nimmst, wo du aber genau rauslesen kannst, was das ist, als eine mit 3 Zeichen, wo du selbst zwar weißt, wofür diese drei Zeichen die Abkürzung sind, der Nächste, der da drauf guckt und nicht dein Gehirn hat, weiß aber nichts damit anzufangen.

Viele sagen, dass man super kommentieren muss und Kommentare das A und O sind. Ja, aber die wenigsten Entwickler machen das. Weil sich der Code auch ständig ändert und das heißt, du müsstest auch die Kommentare immer wieder ändern. Da ist es sinnvoller, den Code sauber und lesbar zu schreiben, dann kannst du dir die Kommentare in der Regel sparen.

Wie lange dauert Coding?

MICHAEL:

Das kann man pauschal nicht beantworten. Kommt ganz drauf an, was der Code machen soll. Wenn er nur "Hello World" ausdrucken soll, dann bin ich in einer Minute fertig, aber wenn er ein Passwort zurücksetzen soll, brauche ich vielleicht zwei Stunden.

MARIO:

Das ist immer unterschiedlich. Zwischen einer Minute und einem Jahr meistens. Das ist so grob die Spanne. Bei einer Minute ist jetzt keine Mittagspause drin, aber bei dem Jahr schon. 😉

Das kann man nicht sagen. Wenn ein Kunde auf einen zukommt und nur grobe Vorstellungen von dem hat, was er haben möchte, dann kannst du ihm auch keine genaue Zeit sagen. Grob vom Bauchgefühl her, ja. Aber du wirst in den seltensten Fällen eine Punktlandung machen können. Entweder bist Du schneller oder langsamer als das, was du vorher gesagt hast. Aber in den seltensten Fällen kommst du genau auf die Stunden, die du vorher gesagt hast. Das kann man nie hundertprozentig abschätzen, weil da so viele Faktoren reinspielen.

Werden sich viele Programme in Zukunft selbst schreiben?

MICHAEL:

Nein, das glaube ich nicht. Die Frage ist aber auch ein bisschen philosophisch. Da gibt’s vielleicht auch kein richtig oder falsch.

So Standardzeug, wenn zum Beispiel jemand sein Passwort vergessen hat: Da kann ich mir durchaus vorstellen, dass es möglich ist, dass da irgendwann vielleicht mal eine künstliche Intelligenz in der Lage ist, passend zur Anwendung Code zu generieren. Würde ich nicht ausschließen, sind wir aber noch weit von entfernt. Und wenn dann dort irgendwas Individuelles nötig wird, muss ja auch wieder einer da sein, der die KI anpasst. Also pauschal zu sagen, dass ein Großteil der Entwickler überflüssig wird und wir uns selbst wegrationalisieren, ist Unsinn.

Standardzeug zu generieren ist also durchaus denkbar. Aber alles entwickelt sich ja weiter und auch die Prozesse werden sich immer weiterentwickeln. Stillstand ist Rückschritt. Du musst dich ständig weiterentwickeln und das kann eine KI nicht leisten. Sehe ich zumindest nicht.

Egal, an welches Softwareprojekt ich denke: Wenn der Kunde anruft und sagt, dass wir hier noch andere Zertifikate generieren oder da noch irgendwas einbauen sollen - wie sollte eine KI das machen? Geht gar nicht.

MARIO:

Ich kann Dir nicht sagen, ob in 10 oder 15 Jahren eine KI so programmieren kann wie wir. Es weiß keiner, wo es da noch hingeht und ob das über KI laufen kann oder nicht.

Dass es in ein paar Jahren letztendlich so weit ist, dass eine KI einen Programmierer ablösen kann, wage ich aber zu bezweifeln. Niemand kann es wirklich sagen, aber allein den Bereich "Emotionen" wird eine Maschine ja nie hinbekommen. Vor allem, was die Benutzeroberfläche angeht.

Das ist das Gleiche bei SEO-Texten. Du kannst SEO-Texte schreiben, die wirklich gut sind. Für Keyword-Optimierung und so weiter. Aber der User liest das vielleicht ganz anders. Da ist der Text dann vielleicht einfach schlecht leserlich oder vom Inhalt oder Aufbau her einfach nicht gut für den Menschen, obwohl er für die Suchmaschine gut ist.

Ich denke, wenn es um die Benutzerführung einer Webseite oder App geht, also an die Bedienung, da wird eine Maschine den Menschen nicht ablösen können. Der Mensch weiß genau, wie er das bedienen möchte, wo er einen Knopf haben möchte oder wo er was lieber hätte. Und ich weiß nicht, ob eine Maschine das so hinkriegen würde.

Emotionen hängen mit dem Code zusammen. Weil alles Code ist, was man sieht. Die Benutzeroberfläche ist ja nicht mit Photoshop gemacht oder so, sondern das wird alles mit Code umgesetzt. Klar, du hast mal eine Grafik, die mit Photoshop gebaut wird. Aber alles andere, was an Steuerelementen da ist, wird durch Code dahin gesetzt. Die Sachen, die der User sieht: Das ist Code, der dahintersteckt. Das ist auch schon Programmierung, auch wenn es keine komplexen logischen Abläufe sind.

Nicht jede:r Programmierer:in kann alles

Wenn Sie sich die Mitarbeiter:innen von FKT42 auf unserer Website bei Unternehmen angucken und dabei die Aufgabenbereiche beachten, werden Sie Unterschiede feststellen. Und das nicht nur, weil wir hier zum Teil unterschiedliche Jobs machen, sondern auch, weil es innerhalb der Programmierung unterschiedliche Bereiche gibt und unsere Entwickler verschiedene Leistungen übernehmen.

Deshalb habe ich zum Schluss auch diese Frage weitergegeben um zu erfahren, wie sich die Spezialisierung von Entwickler:innen auf bestimmte Bereich ergibt. Weiß jeder von Anfang an genau, was er machen möchte? Ergibt sich das im Laufe der Ausbildung? Und: Hat jeder auch sofort die richtige Vorstellung von dem, was er beruflich machen möchte?

MICHAEL:

In Bewerbungsgesprächen kriege ich mit, dass bei vielen schon bestimmte Interessen da sind und sie sich das Unternehmen, bei dem sie sich bewerben, dementsprechend aussuchen.

Was häufig der Ansatz ist: Ich spiele viele Computerspiele, also möchte ich ein Spiel programmieren. Dann stellst du fest: Spieleprogrammierung habe ich mir anders vorgestellt. Ich bin irgendwie zu doof, um die 3-D-Grafiken zu machen. Also lasse ich das sein. Genauso kann es umgekehrt laufen.

Wenn du die Begeisterung dafür hast, dann kannst du jede Spezialisierung lernen. Du kannst aber auch auf dem Weg dorthin feststellen, dass du dir das anders vorgestellt hast und das doch nicht machen willst. Was nicht heißt, dass du es mental nicht könntest, sondern es interessiert dich einfach nicht genug. Dann machst du halt was anderes, aber bleibst ja streng genommen in der Programmierung. Unsere Firma ist da eher ein schlechtes Beispiel, weil hier eigentlich alles relativ ähnlich ist.

Der größte Unterschied zwischen verschiedenen Bereichen liegt darin, dass in unterschiedlichen Sprachen geschrieben wird - am Ende ist aber alles Text. Den generell größten Unterschied gibt es zum CAD-Umfeld. Im Web oder in der App hast du - runtergebrochen - Formulare, in die ein Nutzer etwas eingibt. Dann wird irgendwas mit der Eingabe gemacht und was anderes kommt raus. Im CAD-Bereich sind es Architekten oder Bauunternehmer, die irgendwas zeichnen oder konstruieren: Eine Maschine, ein Haus … völlig egal. Alles, was irgendwie technisch gezeichnet werden muss und am Ende durch eine Maschine produziert wird, wird in CAD gemacht. Autodesk-Produkte sind nach wie vor marktführend und da muss man sich einfach an dieses Rahmenwerk halten und sich in dem Schema bewegen. Da musst du Bock drauf haben und dich da reinfuchsen können. Weil das, was du dann hinterher mit deiner Software machen kannst, dir Spaß macht. Dann kannst du sagen: Ich mache auch AutoCAD-Programmierung.

Die Unterschiede sind also manchmal auch, dass hinter bestimmten Technologien noch mehr steckt als hinter anderen. Am Ende sieht aber der Weg zum Arbeitsergebnis bei allen gleich aus. Egal, was du machst. Ich bin auf der Schiene: Natürlich gibt es Talente, aber man kann vieles durch Ehrgeiz wettmachen.

MARIO:

Man spezialisiert sich in dem Sinne: Worauf du keinen Bock hast, machst du auch nicht gut. Das ist einfach so. Wenn du etwas hast, was dir liegt und woran du Spaß hast, machst du es auch gut. Bei mir ist das definitiv der Bereich Webseiten oder gerade der Bereich PHP. Alles andere würde ich zwar auch irgendwie hinkriegen, aber das ist nicht das, wo ich richtig Spaß dran habe. Und da muss ich gestehen, da stelle ich dann auch leider fest, dass ich darin nicht gut bin. Das muss man sich dann auch eingestehen. Deswegen hat man definitiv seine Bereiche, in denen man besser ist und da spezialisiert man sich auch.

Ich hätte auch Lust, mal eine App zu machen und habe mir das privat auch schon mal angeguckt. Aber es macht für mich dann wenig Sinn, mir das privat stunden- oder wochenlang anzugucken, mich da einzulesen und ein bisschen auszuprobieren, wenn du dann am Ende nur etwas machst, was nicht genutzt wird. Man braucht also einen konkreten Anwendungsfall. Aber da merkst du auch schon, ob das was wäre oder nicht. Ich hätte da also mal Bock drauf, aber ich weiß auch sicher, dass App nicht mein Spezialgebiet wäre. Windows-Entwicklung wäre zum Beispiel überhaupt gar nicht mein Fall. Vor acht oder neun Jahren habe ich mit .NET mal ein bisschen was gemacht, da hatte ich aber auch noch einen Windows-Rechner und das hat auch Spaß gemacht, ja. Aber dauerhaft … die Struktur von .NET liegt mir zum Beispiel nicht so sehr, wie PHP.

Das Prinzip ist bei jeder Programmiersprache fast immer das Gleiche. Das kannst du mit anderen Sprachen vergleichen. Englisch oder Chinesisch: Die Inhalte sind gleich, nur die Schrift und die Sprache an sich sind anders. Aber alles andere ist gleich. Die Logik dahinter ist immer die Gleiche, du musst nur mit anderen Werkzeugen hantieren. Du hast ja auch Frameworks, mit denen du arbeitest und bei .NET haste dann wieder andere, als bei PHP.

Theoretisch kann also jeder alles. Auch Nicht-Entwickler können theoretisch alles entwickeln. Man kann sich alles anlesen. Das ist überhaupt kein Problem. Habe ich ja auch gemacht. Ich bin dafür ja auch nicht zur Schule gegangen. Es geht definitiv, man muss aber den Biss haben. Man muss da Spaß dran haben. Jeder Entwickler kann alles, wenn er wirklich will - hat aber seine Vorlieben. Und ich behaupte auch, dass kein Entwickler seine Sache richtig gut macht, wenn er keinen Spaß daran hat.

Soft Skills vs. Hard Skills

"Hard Skills wie Programmieren sind gar nicht so entscheidend, denn ein grundsätzliches digitales Verständnis bringen die meisten Bewerber:innen sowieso mit. Durch die Tools und Kurse, die es heute gibt, kann man in zwei Monaten lernen, wie man ein selbstfahrendes Auto programmiert – in Zukunft werden sich die meisten Programme ohnehin von selbst schreiben."

Ein Zitat des Bildungsforschers Gerhard de Haan aus einem SPIEGEL-Artikel von 2021, in dem es um Kompetenzen und Qualifikationen von Bewerber:innen in der heutigen Zeit geht. Das Coden als Hard Skill ist demnach also nicht mehr das Wichtigste, wenn man sich um einen Job bewirbt, da man vieles heutzutage mithilfe von Tutorials und Seminaren schnell lernen kann. Zwar relativiert er seine Aussage durch die Anmerkung, dass Teams heutzutage möglichst heterogen aufgestellt sein sollten, um erfolgreich zu sein, dennoch hält er Soft Skills wie Kreativität und Kommunikationsfähigkeit für wichtiger.

Wie bei den Interviews deutlich geworden ist, ist das unserer Meinung nach eine Aussage, die nicht allgemeingültig ist und sicherlich auch nicht auf jede Branche und jedes Team übertragen werden kann. Mal ganz abgesehen davon, dass letztendlich für die meisten Jobs gewisse Hard Skills schlichtweg notwendig sind. Selbstverständlich spielen die Persönlichkeit und gewisse Soft Skills von Bewerber:innen eine wichtige Rolle - und dennoch ist es beispielsweise in einer Agentur wie unserer entscheidend, dass nicht nur ein oder zwei Mitarbeiter:innen Code schreiben können. In jedem Team braucht es mehrere Leute mit ähnlichen Kompetenzen, die die Arbeit der anderen verstehen und kontrollieren können. Und gleichzeitig ist es trotzdem wichtig, voneinander zu lernen. Denn: Auch auch innerhalb der Programmierung gibt es viele verschiedene Felder und Skills.

Letztendlich möchten wir festhalten, dass ein heterogenes Team durchaus von Vorteil ist, weil jeder seine ganz eigenen Kompetenzen mitbringt. Nur im Zusammenspiel mit anderen kann sich ein rundum gelungenes Produkt ergeben. Dass Hard Skills wie Programmieren gar nicht mehr so entscheidend sind und man heutzutage vieles in kürzester Zeit durch Tools und Kurse lernen kann, sehen und bewerten wir allerdings anders.

Fazit: Hat Coding eine Zukunft?

Die Geschäftsführung der FKT42 GmbH ist der Meinung: "Das ist schon die Gegenwart. Das kann nicht verschwinden, sondern wird eher mehr. Man wird immer mehr versuchen, Dinge durch Software oder Computer zu automatisieren. Die Unterhaltungsindustrie spielt auch eine nicht unerhebliche Rolle. Die wird ja auch nicht verschwinden. So wie diese ganze Metaverse-Sache, ob man das jetzt gut findet oder nicht. Aber: Es ist alles digital. In vielen Branchen heißt es immer noch: "Wir arbeiten an der Digitalisierung." Also ist da kein Ende in Sicht. Ganz im Gegenteil, es wird eher noch weiter wachsen.

Wir glauben nicht, dass die Zukunft ohne professionelle Entwickler:innen auskommt. Zurzeit scheint es sogar so, als wäre das komplette Gegenteil der Fall. Gute Entwickler:innen zu finden, die ihren Job verstehen, ist alles andere als einfach. Sie werden händeringend gesucht - und zwar deutschlandweit.

Selbst wenn die Zahl künstlicher Intelligenzen steigt, die Code generieren können oder Low Code und No Code-Ansätze noch mehr an Bedeutung gewinnen: Letztendlich bedarf doch alles der Kontrolle menschlicher Expert:innen. Ohne sie wäre die Gefahr von Fehlern, Sicherheitslücken und anderen Risiken viel zu hoch.

Deshalb sind Aussagen wie "Das bisschen Code schreibt sich doch fast von allein" unserer Meinung nach ein Fehlurteil über Coding. In erster Linie von Menschen, die sich selbst nicht in dieser Branche bewegen und deshalb eigentlich auch gar keine Chance haben, diesen Job mit all seinen Inhalten vollumfänglich zu greifen und zu beurteilen. Sobald einem bewusst ist, wie viel Arbeit hinter dem Programmieren steckt, wie viele Stolpersteine sich auf dem Weg zu einer App, Website oder Software ergeben können und wie wichtig Feedback und Korrekturphasen sind, sieht man die Sache mit anderen Augen.

Ja, es ist möglich, sich selbst in relativ kurzer Zeit die Grundlagen des Programmierens beizubringen. Sicherlich können jene, die ein gewisses Grundverständnis dafür mitbringen, recht schnell eine einfache Website oder App programmieren. Sobald es allerdings an individuelle Gestaltungswünsche und umfangreiche Funktionen geht wäre es anmaßend zu behaupten, dass es jede:r binnen kürzester Zeit schaffen kann, sich all das anzueignen, für das andere sich jahrelang und konsequent weiterbilden. Sei es durch Fortbildungen oder die Erfahrung, die mit jedem einzelnen Projekt, jedem Änderungswunsch, jedem Austausch mit Kolleg:innen und jedem Fehler dazukommt.

Mehr Informationen?

Sind Fragen offengeblieben? Haben Sie ein Feedback für uns? Interessieren Sie sich für eine App, eine Website, eine Webanwendung oder eine individuelle Software? Dann melden Sie sich gerne bei uns und wir beantworten Ihnen in einem offenen und ehrlichen Gespräch alle Fragen, die Sie zu einem bestimmten Produkt haben.

Schreiben Sie uns eine Mail, nutzen Sie unser Kontaktformular oder rufen Sie uns einfach an, um einen Termin zu vereinbaren. Wir erstellen Ihnen gerne ein Angebot – selbstverständlich kostenlos und unverbindlich!