Viele Coder und Coderinnen kennen beide Typen. Nicht immer wollen sie sich einer Seite zuordnen. Doch eine Tendenz zum Kunstvollen oder Pragmatischen steckt in den meisten. Der Software-Entwickler Dominik Seemann ist beispielsweise eher der nüchterne Typ. Er liebt simple, direkte Lösungen und arbeitet Projekte schnell ab, indem er auf bestehende Frameworks zurückgreift und sie effizient kombiniert. Er hat schon als Kind mit dem Programmieren angefangen, später Medieninformatik studiert und ist jetzt Head of Development bei Candylabs. Er schreibt Anwendungen für das Testen der Customer Demands für Innovationsprodukte, die anzeigen, ob Business-Modelle funktionieren oder nicht. Seemann hat festgelegte Standards entwickelt, einen bestimmten Stil vorgegeben, hasst Bugs und liebt React.

Alexander Dubovoy dagegen kann React nicht leiden und freut sich sogar über Code, der nicht tut, was er soll: "Ich benutze Bugs gelegentlich für interessante Effekte", sagt er. "Zum Beispiel für Musik-Performances." Der "Artist Coder" will in seinem Code Perfektion erreichen und sieht dabei auch den Weg als Ziel. Dubovoy ist gelernter Historiker und Impro-Jazz-Pianist, was seine andere Herangehensweise erklärt. Entwickeln lernte er erst später im Coding-Bootcamp, um Netzwerk-Musik damit machen zu können. Jetzt hat er seine eigene Firma für Web- und App-Entwicklung, Obst Digital, und unterrichtet selbst im Bootcamp.

Eigentlich bergen die unterschiedlichen Coding-Stile eine Menge Konfliktpotenzial. Wir hatten Seemann und Dubovoy als typische Vertreter eines pragmatischen und eines künstlerischen Coders zum Streitgespräch per Zoom eingeladen - das erstaunlich harmonisch verlaufen ist. Das könnte allerdings auch daran liegen, dass sie nicht zusammenarbeiten müssen.

Golem.de: Dominik, wie sieht dein Alltag als Programmierer aus? Wie viel ist kreativ, wie viel standardisiert?

Dominik Seemann: Was ich mache, ist zu 90 Prozent immer das Gleiche: ein Interface und das Backend erstellen. Alle Schritte sind standardisiert. Ich habe die Standards eingeführt, als ich 2016 als Head of Technology angefangen habe. Wie ist das bei dir, Alexander?

Alexander Dubovoy: Für mich ist die Frage der Standardisierung eine ganz andere! Ich bin Freelancer und arbeite viel an kreativen Projekten. Vor ein paar Monaten habe ich eine App für eine Kunstperformance gebaut. Dabei würde ich nichts Standardisiertes verwenden. Ich experimentiere mit Code und benutze Bugs, die dabei entstehen, manchmal sogar für interessante Effekte.

Dominik Seemann: In meiner Arbeit sind Bugs nichts Interessantes, sondern das Zeichen dafür, dass etwas falsch läuft. Ich verwende meinen Code nie auf so eine Art. Ich debugge vor dem Compilen.

Alexander Dubovoy: Ich kümmere mich schon um ungewollte Bugs und auch um Standards. Zum Beispiel finde ich Barrierefreiheit wichtig und wende WAI-ARIA Standards an. Manchmal arbeite ich auch für Kunden, die eine sehr konkrete Vorstellung vom Endprodukt haben, wie aktuell eine Text-App. Da muss ich mich an mehr Standards halten und bediene mich mehr aus meinen Libraries und meiner Toolbox als bei freien Projekten.

Dominik Seemann: Unser Ansatz mit erprobten Frameworks ist ähnlich. Moderne JavaScript-Frontends wie React und eine Toolchain, die damit kommt, erzwingen bestimmte Standards. Vermutlich benutzen wir sogar eine ähnliche Toolbox. Privat verfolge ich eher einen Hacker-first-Approach, probiere viel aus und integriere das dann vielleicht sogar in die Toolbox, wenn es funktioniert. Leider habe ich dafür nur noch wenig Zeit, seit ich Vollzeit vor dem Bildschirm arbeite.

Alexander Dubovoy: Bei Sprachen wie Javascript gibt es ja auch mehrere konkurrierende Vorstellungen, wie Code aussehen sollte. Meine Herangehensweise ist insofern standardisiert, dass ich mich für eine Version der Styleguides entscheide. Mein Code soll in sich stimmig sein - auch mit dem meiner Mitarbeiter, sonst wird es schwierig, einander zu verstehen.

Dominik Seemann: Klar, wenn man sich nicht an einen Stil hält, funktioniert die Zusammenarbeit einfach nicht. In unserer Firma ist ein Stil genau vorgegeben. Das läuft automatisch und ein Linter überprüft meinen Code. Das spart Zeit, weil ich direkt sehe, was geändert werden muss. Es gibt so keine Ambiguität, und das führt dazu, dass man sich auf wichtigere Dinge fokussieren kann. Am Ende macht das den Code sogar besser und kreativer als ohne Vorgaben.