Entdeckungsreise in die selbst genutzte Programmiersprache

the next big thing  –  37 Kommentare

Gleichwohl in welcher Programmiersprache man entwickelt, für nahezu jeden Entwickler gibt es von Zeit zu Zeit noch Neues zu entdecken. Doch wie lässt sich eine systematische Entdeckungsreise in die eigene Programmiersprache mit dem Alltag vereinbaren?

Meine erste Programmiersprache war GW-BASIC. Die Entscheidung für gerade diese Sprache war nicht das Ergebnis zielgerichteter Überlegungen, sondern eher Zufall: Zum einen wurde GW-BASIC bei MS-DOS 3.3 kostenlos mitgeliefert, zum anderen konnte mir mein Großvater beim Einstieg und den ersten Schritten helfen, da er selbst Erfahrung in BASIC hatte.

Selbstverständlich hätte ich mich prinzipiell auch für Assembler, C oder Pascal entscheiden können – aber diese Frage stellte sich damals überhaupt nicht: Ich wusste mit zwölf Jahren nicht, was es "da draußen" alles gab, und es gab niemandem, der mir zu etwas anderem riet: Also habe ich GW-BASIC gelernt.

Götz & Golo

"Götz & Golo" ist eine gemeinsame Serie von Götz Martinek und Golo Roden. Der eine ist Geschäftsführer der sodge IT GmbH, der andere CTO der the native web GmbH. Was die beiden vereint, ist ihre große Leidenschaft für die Entwicklung von Software. Seit September 2019 nehmen sie sich monatlich ein Thema vor, zu dem dann jeder seine individuelle Perspektive beschreibt, ohne den Artikel des jeweils anderen im Vorfeld zu kennen. Der zugehörige Artikel von Götz findet sich im Blog von Sodge IT. Die Fragestellung zu diesem Beitrag lautete: "Entdeckungsreise in die eigene Programmiersprache"

Im Lauf der Zeit kam dann Wissen aus Büchern und Zeitschriften hinzu, und dort bin ich auch das erste Mal in Kontakt mit anderen Sprachen gekommen. In der "DOS International", die meine Familie damals abonniert hatte, gab es nämlich jeden Monat einen Wettbewerb: 1024 DM für das beste Programm mit höchstens 1024 Bytes. Gewonnen haben regelmäßig kryptische C-Programme, die ich nicht verstand – aber meine Neugier war geweckt.

Von GW-BASIC zu C#

Irgendwann, vermutlich so mit 14 oder 15 Jahren, habe ich begonnen, mich mit C und C++ zu beschäftigen, und auf einmal habe ich verstanden, was geschweifte Klammern und das Semikolon bedeuten: Beide Konstrukte kommen in BASIC nicht vor. Mein weiterer Weg führte mich dann zu Assembler und im Rahmen der .NET 1.0 Beta 1 schließlich zu C#.

Ich kann behaupten, dass C# die erste Programmiersprache war, mit der ich mich wirklich intensiv beschäftigt habe. Ein wesentlicher Grund dafür war ein Effekt, den wohl alle Entwickler kennen: Während man für das Lernen der ersten Programmiersprache noch unglaublich viel Zeit für das Verständnis von Konzepten aufwenden muss, wird es mit jeder weiteren Sprache einfacher.

Natürlich bietet C# konzeptionell mehr als GW-BASIC, aber die grundlegenden Konzepte der Programmierung wie Schleifen und Entscheidungen waren mir hinlänglich bekannt. Das eröffnete die Möglichkeit, die Sprache auf andere Art zu hinterfragen.

2005 begann ich außerdem, Artikel für Zeitschriften zu schreiben, unter anderem auch eine Kolumne für das C#- und .NET-Magazin dotnetpro, in der ich mich Monat für Monat mit Detailfragen zu C# beschäftigt habe, beispielsweise:

  • Wie verhalten sich statische Typkonstruktoren und wann werden sie ausgeführt?
  • Wie funktioniert das Generationenkonzept der Garbage Collection?
  • Wie kann man den Boolschen Wert true so mit sich selbst vergleichen, dass als Ergebnis false herauskommt?

Von C# zu JavaScript

2011 habe ich mich schließlich verstärkt JavaScript zugewandt, inzwischen beschäftige ich mich primär mit TypeScript in Verbindung mit Node.js und React. Dabei stellt TypeScript jedoch einen Sonderfall dar: Während alle bisherigen Sprachwechsel harte Brüche waren (C hat mit BASIC nichts zu tun, ebenso wenig C# mit Assembler), baut TypeScript erstmals auf einer anderen Sprache auf. Man muss JavaScript verstehen, wenn man TypeScript verstehen will – anders geht es nicht.

Nun entwickeln sich die meisten Sprache regelmäßig weiter, aber gerade die Web-orientierten Sprachen legen hier ein besonders hohes Tempo an den Tag. Von JavaScript erscheint jährlich eine neue Version, die neue Schlüsselwörter und Konstrukte enthält, hinzu kommen die ungefähr alle drei Monate stattfindenden Veröffentlichungen von TypeScript.

Das wirft die Frage auf, wie man hier auf dem Laufenden bleibt. Denn zu entdecken gibt es enorm viel, und stetig kommt Neues hinzu. Das Problem gibt es in anderen Sprachen aber ebenso – und vor kurzem war ich beratend bei einem unserer Kunden, wo mich dann ein C#-Entwickler fragte, ob ich ihm mal die Syntax mit dem Doppelpfeil erklären könne: Gemeint waren die Lambda-Ausdrücke, die es in C# seit der Version 3.0 gibt, die 2008 erschienen ist.

Das Beispiel zeigt, dass es durchaus schwierig sein kann, die Neuerungen einer Programmiersprache im Arbeitsalltag nicht nur zu bemerken, sondern sie auch zu verstehen, sie zu bewerten und sie gegebenenfalls in den Alltag zu übernehmen. Das Problem verschärft sich, je kürzer die Release-Zyklen werden.

Das betrifft wohlgemerkt aber nicht nur neue Sprachmerkmale, sondern auch alte, bislang nicht genutzte Eigenheiten. Teilweise ergibt sich das im Lauf der Zeit zufällig, weil man darüber stolpert, und dann doch einmal nachschlägt oder nachfragt – doch wäre es nicht sinnvoll, das etwas systematischer anzugehen? Und wenn ja, wie macht man das?

Können, wollen, dürfen, sollen

Um diese Frage zu beantworten, gilt es zunächst, einige Voraussetzungen zu klären. Diese sind teilweise persönlicher, teilweise aber auch organisatorischer Natur. Es müssen, je nach persönlicher Situation, nicht alle davon zusammenkommen, aber sie sind doch ein guter Leitfaden, um einzuschätzen, ob das Vorhaben überhaupt gelingen kann.

Die erste Voraussetzung ist, dass man sich überhaupt mit den Neuerungen zu beschäftigen vermag. Wer die Grundlagen einer Sprache nicht kennt, wird sich mit den Details schwer tun. Was logisch klingt, wird in der Praxis leider nicht immer gelebt: Häufig überschätzen Menschen ihre eigenen Fähigkeiten, beziehungsweise Unternehmen überschätzen die Fähigkeiten ihrer Mitarbeiter. Wer dann niemanden hat, der die Erwartungen gerade rückt und einen gegebenenfalls an die Hand nimmt, wird höchstwahrscheinlich scheitern.

Können alleine genügt jedoch nicht, man muss auch wollen. Zwar habe ich die Erfahrung gemacht, dass die meisten Entwickler gerne lernen und sich weiter entwickeln möchten, doch stößt nicht jedes Thema bei jedem auf gleiches Interesse. Wer gezwungen ist, sich wider Willen mit einer Programmiersprache zu befassen, wird kaum Motivation für deren Details aufbringen. Auch hier gilt, dass das Einarbeiten in die Details nur gelingen kann, wenn echtes Interesse besteht.

Wenn beides der Fall ist, muss aber auch noch das Umfeld gegeben sein, was die Entdeckungsreise zulässt: Wer sich weiterbilden kann und möchte, aber nicht darf, wird ebenfalls scheitern – wobei ein Umfeld, das Lernen nicht gut heißt, ohnehin sehr fragwürdig ist, nicht nur im Hinblick auf die konkrete Fragestellung dieses Blogposts. Auf jeden Fall muss man also Zeit zugestanden bekommen, um auf Entdeckungsreise gehen zu können.

Zu guter Letzt ist es zwar nicht erforderlich, aber doch hilfreich, wenn derartige Forschungsarbeit nicht nur erlaubt, sondern sogar explizit erwünscht ist: Wenn ein Unternehmen aktiv fordert, dass Entwickler sich weiterbilden und sich in die Details ihrer Programmiersprache einarbeiten, ist das eine weitaus bessere Voraussetzung, als wenn man diesem Thema mit Gleichgültigkeit begegnet. Wichtig für Unternehmen ist aber zu bedenken, dass dafür auch – siehe voriger Punkt – Zeit zugestanden werden muss. Weiterbildung passiert nicht, indem man lediglich einfordert.

Und nun?

Angenommen, alle Voraussetzungen sind gegeben, dann ist der nächste Schritt tatsächlich ziemlich einfach: Man macht einfach, denn man kann, will, darf und soll ja schließlich. Ob man das dann allein oder mit Kollegen gemeinsam angeht, ob das online oder offline stattfindet, ist weitgehend zweitrangig. Die Frage ist dann eher, welche konkreten Schritte man gehen kann, um tiefer in eine Sprache einzusteigen. Meistens ergibt sich das in dem Fall aber von selbst.

Hakt es irgendwo, liegt es in der Regel daran, dass eine der Voraussetzungen nicht erfüllt ist: Es fehlt die Hilfestellung (man kann nicht), es fehlt die Wahrnehmung der Relevanz (man will nicht), es fehlt die Zeit (man darf nicht), oder es fehlt der Auftrag (man soll nicht). Es ist in einem solchen Fall sehr einfach, den Fehler bei den Entwicklern zu suchen – aber tatsächlich gehen hier zwei Seiten Hand in Hand: Entwickler und Unternehmen, und beide müssen am gleichen Strang ziehen.

Glücklicherweise lässt sich im Bedarfsfall an allen Punkten etwas verbessern. Am einfachsten ist es dabei, das Können zu verbessern, denn hierfür kann man sich leicht extern Unterstützung holen, beispielsweise im Rahmen von Workshops.

Was die Motivation angeht, wird es schwieriger: Hier gilt es zunächst zu klären, warum jemand nicht will. Vor einigen Jahren habe ich bei einem unserer Kunden einen Entwickler getroffen, der sich faktisch geweigert hat, den vom Unternehmen verordneten Umstieg von Java zu Node.js mitzumachen. Es kamen Argumente wie "JavaScript ist für mich eine Write-only-Sprache, die versteht man gar nicht". Im persönlichen Gespräch hat sich schließlich herausgestellt, dass der Entwickler schlichtweg Angst hatte, der Veränderung nicht gerecht werden zu können, und blockiert von der Angst, seine Familie nicht versorgen zu können. Gelöst wurde das Problem, dass er in ein anderes Team wechseln konnte, in dem er sich inhaltlich wohl fühlt.

Wenn Entwickler nicht dürfen, wird es schließlich ganz schwierig, denn hier liegt der Fehler zumeist in der Kultur des Unternehmens begründet, und das ist nichts, was sich kurz- oder gar mittelfristig ändern ließe. Zum Glück sind solche Fälle selten, häufiger trifft man die Situation an, dass zwar gefordert wird, dass Weiterbildung stattfindet, aber mehr eben auch nicht – hier kann ein erster Schritt ein offenes Gespräch sein, in dem die Erwartungshaltung und die Unterstützung abgeglichen werden.

Konkrete Schritte

Abschließend bleibt nun noch die Frage, welche konkreten Schritte man denn gehen kann, wenn alle Voraussetzungen erfüllt sind. Wie schon erwähnt, ergibt sich das in den meisten Fällen von selbst, aber dennoch können ein paar Anregungen und Ideen nicht schaden. Sicherlich muss man hier unterscheiden zwischen den Phasen, die ich anfänglich schon einmal angesprochen habe.

Um neue oder noch nicht entdeckte Sprachkonstrukte überhaupt zu bemerken, hilft es, entweder Code von anderen zu lesen oder den eigenen Code durch jemanden reviewen zu lassen, der zwar die gleiche Programmiersprache spricht, aber einen anderen Hintergrund hat. Alternativ kann man sich auch im Team vornehmen, dass jeder die gleiche Aufgabe löst (beispielsweise im Rahmen eines Coding-Dojos), und man die Lösungen nachher vergleicht. Für das Bemerken neuer Sprachkonstrukte genügt es in der Regel, neue Releases der Programmiersprache aktiv zu verfolgen, und sich mit anderen auszutauschen.

Was ist neu? Wie verbreitet ist etwas? Wann wurde es hinzugefügt? …?

Wer auf ein unbekanntes Konstrukt gestoßen ist, muss zunächst dessen Bedeutung verstehen. Dazu kann man suchen, nachfragen, experimentieren … Es gilt zunächst gar nicht herauszufinden, wie man das Konstrukt einschätzt und bewertet, sondern erst einmal nur, ein umfassendes Verständnis davon zu erlangen, völlig wertneutral.

Wie funktioniert das? Welche Sonderfälle gibt es? Wie unterscheidet es sich von anderen Konstrukten? …?

Die Bewertung erfolgt danach, idealerweise wieder im Gespräch mit anderen. Das Ziel dabei ist herauszufinden, welche Sprachkonstrukte man in das eigene Portfolio übernehmen will und welche nicht. Dabei ist weniger wichtig, wie man die Entscheidung trifft, als vielmehr, dass es eine bewusste und explizite Entscheidung ist, die man vernünftig begründen kann.

Wer hat welche Erfahrungen gemacht? Welche Befürchtungen gibt es? Wo liegen Potenziale? …?

Zu guter Letzt gilt es, die ausgewählten Sprachmerkmale regelmäßig anzuwenden, damit sie sich einschleifen. Auch hier können wieder Code-Reviews helfen, wo speziell darauf geachtet wird. Auch Pair-Programming ist ein großartiges Mittel, um neue Sprachkonstrukte einzuführen, außerdem entstehen auf dem Weg gemeinsame Erfahrungen, die langfristig wertvoll sind.

Wer kann meinen Code reviewen? Was kann ich verbessern? Wie kann ich Code anders formulieren? …?

Wer das alles regelmäßig macht, lernt zunehmend mehr über die eigene Programmiersprache und bleibt zugleich auf dem Laufenden. Selbstverständlich kostet das Zeit, aber je länger man so arbeitet und das Entdecken neuer Dinge als positiv in der Kultur etabliert, desto leichter fällt es – und irgendwann kommt man an den Punkt, wo ein neues Sprachmerkmal genauso einfach zu lernen und anzuwenden ist wie die Syntax einer neuen Programmiersprache, weil man konzeptionell verstanden hat, was eine Schleife ist.

PS: Eine kleine Anmerkung in eigener Sache: Wer einen Partner für genau solche Themen sucht, wird eventuell bei uns – the native web – fündig. Wir bieten nämlich nicht nur Beratung und Entwicklungsunterstützung an, sondern auch Workshops zu verschiedenen Themen, unter anderem zu TypeScript, Node.js, CQRS und vielen weiteren Themen rund um Web und Cloud.