Pragmatic vs. Artist Coder: Treffen sich zwei Entwickler ...

Pragmatic vs. Artist Coder: Treffen sich zwei Entwickler ... | Golem Karrierewelt

(Bild: privat/Candylabs)

Aufgezeichnet von Maja Hoock veröffentlicht am 

Auch unter Entwicklern gibt es Künstler und Pragmatiker. In Firmen führt das öfter zu Konflikten. Aber dass diese Programmierertypen auch viel gemeinsam haben, stellten zwei typische Vertreter in diesem Golem.de-Gespräch fest.

Arbeiten Entwickler mit unterschiedlichen Vorstellungen vom Programmieren in einem Team, geraten Projekte schon mal ins Stocken. Etwa wenn die einen Code als Kunstwerke betrachten und deswegen anders ans Entwickeln herangehen als Pragmatiker, die alles möglichst effizient erledigen wollen.

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.

Alexander Dubovoy: Finde ich auch. Alles Verrückte und Kreative muss intendiert sein. Dann kann er auf kreative und interessante Arten verwendet werden.

Dominik Seemann: Man muss die Regeln kennen, um sie zu brechen. Coden ist das Werkzeug, egal ob man Kunst oder eine App damit entwickelt. Am Ende zählt das Produkt.

Alexander Dubovoy: Manchmal ist für mich aber auch der Weg das Ziel. Ich schreibe etwa Code und er tut nicht, was er soll. Aber was dabei rauskommt, ist trotzdem spannend. Ein Beispiel: Für mein letztes Projekt habe ich den Web Audio-API genutzt und Sounds produziert, die entstehen, wenn Code ausgeführt wird. Die Fonts wurden falsch geladen und aufgrund der Netzwerk-Geschwindigkeit verzerrt übertragen. Zuerst dachte ich, dass das schrecklich klingt. Dann mochte ich den Effekt aber und habe ihn gezielt eingesetzt. Das ist ein bisschen, wie wenn man mit einem Synthesizer herumspielt. Man entdeckt neue Töne, die gar nicht so vorgesehen waren.

Dominik Seemann: Normalerweise folgt Code aber einer neuen Idee und ist nicht selbst die Innovation.

Alexander Dubovoy: Ja, klar. Ich vergleiche Code oft mit meinem Piano. Er ist das Instrument. Manchmal komponiere ich etwas mit dem Piano, weil es eben dieses spezielle Instrument ist. Manchmal ist das Werkzeug aber auch nur dazu da, um etwas anderes damit auszudrücken. Das trifft für mich auch aufs Coden zu. Manchmal können innovative Ideen während des Programmierens Türen öffnen - wenn man etwa ein neues Framework entwickelt.

Dominik Seemann: Schön ist Code für mich, wenn sein Kernkonzept nachvollziehbar ist und man ihn leicht warten kann. Das heißt nicht, dass er kurz sein muss. Die Struktur muss gut durchdacht sein. Ich liebe die Code-Standardisierung, die die React-Community hervorbringt. Es gibt für alles einen Weg, und der wird von der ganzen Community repliziert. Gedanken, Muster und Ansätze werden geteilt und das hat mein Entwicklerleben deutlich beschleunigt. Das ist etwas, das ich wirklich zu schätzen weiß. Javascript, die Sprache, mit der ich am häufigsten zu tun habe, hat sich in den letzten zehn Jahren stark verbessert. Sie wurde immer kompakter und mittlerweile haben wir ein gängiges Standard-Set. Der Aufbau des React-Frameworks ist einfach klasse.

Alexander Dubovoy: Ich kann da nicht so zustimmen. Ich arbeite viel lieber in Vue. Aber sie haben ja kürzlich die Syntax von React geändert und vielleicht gebe ich ihm nochmal eine Chance. Oder Preact.

Dominik Seemann: Da ist die Community zweigeteilt (lacht).

Alexander Dubovoy: Ich interessiere mich für die Arbeit von David Heinemeier Hansson, der wohl das Gegenteil von React repräsentiert. Er hat Ruby on Rails entwickelt und richtet sich gegen viele Trends. Ruby hat eine simple Syntax und liest sich fast wie Englisch. Das mag ich. Privat schätze ich die funktionale Programmiersprache Elixir, weil sie schön und ein wenig verrückt ist: Normalerweise funktioniert das Gleichheitszeichen nur in eine Richtung. In Elixir ist das ganz anders und man muss so gut wie nie If-Else-Statements verwenden. Ich liebe aber auch Python und finde es sehr elegant.

Dominik Seemann: Ich verstehe dich da. Python ist meine private Lieblingssprache wegen der simplen Syntax. Man kann alles ändern und nachschlagen. Wie es bei Python heißt: Batteries included. Es gibt viele Libraries mit nützlichen Modulen. Sie ist meine Batteries included-Sprache für alles, was ich nicht im Netz arbeite: Texteditor auf, Python rein und ich kann fast alle Probleme lösen. Ich kann nicht nachvollziehen, was die Leute daran nicht mögen. Das ergibt für mich keinen Sinn.

Alexander Dubovoy: Vielleicht, weil es eine ganz andere Syntax hat, als viele es gewohnt sind.

Dominik Seemann: Stimmt. Ich habe mir sehr viele Tutorials von Wes Bos angesehen. Es hat einen richtigen Hands-on-Approach bei der Softwareentwicklung.

Alexander Dubovoy: Der beste Code, den ich je gelesen habe, stammt von Jen Simmons und ihrem Layout Land. Und aus dem CSS-Buch Every Layout von Hayden Pickering und Andy Bell. Sie haben einen sehr algorithmischen Ansatz, Layouts zu erstellen. Sie arbeiten mit dem, was vielen Entwicklern Probleme bereitet. Viele Coder ordnen die Power von CSS falsch ein und schreiben Code, der gegen die Sprache arbeitet, statt mit ihr. Komischerweise habe ich das mehr als Schönheit empfunden als alle komplexen Backend-Algorithmen, die ich bis dahin gelesen habe.

Dominik Seemann: Ich würde sagen, dass das Ergebnis wichtiger ist als der Style meines Codes. Wenn jemand mich damit beauftragt, Software zu schreiben, müssen die Auftraggeber nicht jeden Aspekt davon kennen. Aber es ist mein Job, ein gutes Produkt abzuliefern. Ich entwickle einfach zu lesenden und zu wartenden Code. Innovation passiert für mich nicht im Code selbst, sondern ist das, was man damit anstellt. Wenn es keine Überraschung gibt, gibt es keine Überraschung. Überraschungslos. Ein Wort, das meine Arbeitsweise beschreibt. Was ist mit dir?

Alexander Dubovoy: Der Stil spielt für mich eine große Rolle bei der Arbeit. Einfachheit finde ich wesentlich dabei. Ich unterrichte in einem Coding-Bootcamp. Oft schreiben die Schüler 20 Zeilen, obwohl es auch in zwei Zeilen ginge. Dann gibt es einen Syntaxfehler in Zeile 12 und solche Dinge. Mein Ziel ist es, dass sie das von selbst entdecken und alles Unnötige löschen. Manchmal kommt man erst durch diesen Prozess des Verkomplizierens zur eigentlichen, simplen Lösung.

Dominik Seemann: Ja genau! Manchmal muss ich etwas einmal falsch machen, um zu verstehen, was das eigentliche Ziel ist, und es dann das zweite Mal richtig und kompakter zu machen.

Alexander Dubovoy: Manchmal ist aber auch die etwas längere Antwort die bessere Antwort.

Dominik Seemann: Stimmt. Manchmal ist der Refactor länger als in die ursprüngliche Version, aber dafür trotzdem klarer und besser dokumentiert. Eine Zeile kryptisches Irgendwas, das ich eine Woche später nicht mehr verstehe, bringt auch wenig. Aber wir haben nicht so lange Zeit dafür. Ich messe meine Produktivität in abgelieferte Features pro Zeit. Wir haben strikte Deadlines, nach denen ich mich richten muss.

Alexander Dubovoy: Bei mir als Freelancer sieht das mit den Deadlines anders aus. Es kommt aufs Projekt an, aber es kommt vor, dass man mir ganz freie Hand lässt und ich kreativ arbeiten kann, bis ein Projekt eben fertig ist. Manche Kunden setzen mir aber auch unnötig strikte Deadlines. Das schadet der Qualität meiner Arbeit. Ich war in der Universität schon immer der Student, der die Hausarbeit erst kurz vor Abgabeschluss begonnen hat. Falscher Druck hindert mich daran, ein gutes, kreatives Produkt zu entwickeln. Das erkläre ich ihnen dann.

Dominik Seemann: Erwartungsmanagement ist der Schlüssel! Wenn Entwickler unter Druck geraten, wenn es nicht nötig ist, läuft etwas falsch. Das ist schlechtes Management. Manchmal wird aber ein Produkt in wahnsinnig kurzer Zeit benötigt. Das ist für mich dann auch in Ordnung - aber das Ergebnis kann dann auch nicht so sein, als wenn ich mehr Zeit gehabt hätte. Das muss man kommunizieren.

Alexander Dubovoy: Ich würde mit meiner Arbeit als Programmierer der Welt auch gerne etwas Gutes hinterlassen. Vielleicht ist es wegen meinem Background als Künstler. Meine Arbeit kann nicht die Welt retten, aber zumindest etwas Positives zur Welt beitragen und das Netz zu einem vielfältigeren Ort machen. Damit die Erlebnisse, die die Menschen online haben, nicht nur von großen Firmen diktiert werden. Ich hinterlasse in meiner Arbeit eine Art Fingerabdruck. Jeder, der mich kennt, wird meinen Code erkennen.

Dominik Seemann: Das ist bei erstaunlich vielen Entwicklern so. Ich sehe als Head of Development viel Code meiner Kollegen und erkenne, wer was geschrieben hat. Alle haben zwar die gleichen Coding-Standards bei uns, aber trotzdem entwickeln sie ihren Code alle ein bisschen anders.

Alexander Dubovoy: Da ist was dran. Jeder programmiert auf seine eigene Art und Weise. Ich lege zum Beispiel viel Wert auf die Struktur. Wenn es Frontend-Code ist, findet man bei mir einen Hauptordner mit all den Basiskomponenten, die ich für die Anwendung gebraucht habe. Einige davon haben sehr limitierte Funktionen. Ich habe zum Beispiel eine Komponente, die nur dazu gedacht ist, ein bisschen mehr Raum in eine Box zu bringen. Will der Kunde das Spacing verändern, kann ich eine Sache verändern, und es ändern sich dementsprechend in der ganzen Anwendung. Ich bin einer dieser Entwickler, wo alles nach einem festgelegten Verhältnis berechnet ist.

Dominik Seemann: Ich denke nie bewusst darüber nach, einen Fingerabdruck in meinem Code zu hinterlassen. Höchstens vielleicht unterbewusst. Ich komme von einem Python-Hintergrund und habe den knappen Stil beibehalten. Das prägt bis heute, wie ich meinen Code strukturiere. Wenn ich in anderen Sprachen wie Javascript arbeite, wird das sogar noch deutlicher. Das ist keine bewusste Stilistik, mit der ich mich ausdrücken möchte. So funktioniert mein Gehirn einfach.

Wir wollten eigentlich unterschiedliche Positionen vertreten und haben uns doch in fast allen Punkten zugestimmt. Das passiert oft, wenn ich mich mit anderen Entwicklern unterhalte.

Alexander Dubovoy: Wir sind uns also einig, was guter Code ist. Die Kernprinzipien sind bei den meisten Codern die gleichen. Der Unterschied ist eher, was dabei herauskommt.

Dominik Seemann: Genau. Ich stimme inhaltlich mit vielen Firmen im Silicon Valley nicht überein. Aber viele von ihnen entwickeln guten Code und gute Libraries.

Alexander Dubovoy: Sehe ich ganz genauso!

Dominik Seemann: Mein Coding-Stil zusammengefasst: positiv langweilig (lacht).

Alexander Dubovoy: Auf mich würde organisiert am besten passen. Ich lege viel Wert auf eine saubere Basis und feile sehr lange an Details. Was anderen Entwicklern vielleicht Angst einjagt, liebe ich.

Dominik Seemann: Ich würde auf jeden Fall jemanden wie Dich einstellen!

Individuelle Unterstützung zu Themen rund um Job & Karriere gibt Shifoo, der Service von Golem.de - in 1:1-Videosessions für IT-Profis von IT-erfahrenen Coaches und Beratern. 

Beliebte Fachgebiete in der Golem Akademie