Ich habe in meiner Karriere viele verschiedene Rollen innegehabt, vom Entwickler bis zum CEO und so ziemlich alle möglichen Positionen dazwischen, aber ich habe mich immer weiterentwickelt. Für mich ist es nicht nur eine Quelle der Freude, sondern auch und vor allem eine zwingende Notwendigkeit, das ultratechnische und ultraschnelllebige Umfeld, in dem wir uns entwickeln, weiterhin zu verstehen und zu meistern. Ich halte es für notwendig, schnelle und fundierte Entscheidungen treffen zu können. Ich weiß, dass es ein kontroverses Thema ist, aber ich glaube, dass ein CTO, ein Engineering Manager oder noch mehr ein Lead Dev wissen sollte, wie man programmiert und programmieren muss, entweder beruflich oder für persönliche Projekte. Warum ich IDEs aufgegeben habe möchte ich hier mal erläutern.
In diesen mehr als 20 Jahren mehr oder weniger intensiver Softwareprogrammierung hatte ich die Gelegenheit, eine breite Palette von Entwicklungstools und IDEs zu verwenden. In letzter Zeit habe ich mich allmählich von den ausgefeiltesten Werkzeugen zugunsten von Leichtigkeit und Effizienz entfernt. Lassen Sie mich meine Reise erklären.
Die 2000er Jahre
Ich bin Ende der 80er / Anfang der 90er Jahre in den professionellen Markt eingestiegen. Die in den 90er Jahren entwickelten „weborientierten“ Sprachen (d.h. alles außer C, C++) (JavaScript, Python, Java usw.) wurden immer besser, und die Entwicklungswerkzeuge folgten diesem Trend.
Dies war die Blütezeit von Eclipse IDE (veröffentlicht 2001), Visual Studio (1997) und anderen, die mehr oder weniger verschwunden sind. Bereits damals hat mich eine Studie fasziniert, welche die Produktivität der amerikanischen und russischen Programmierer verglich. Die russischen Programmierer waren aufgrund der reduzierten Verfügbarkeit der Hardware wesentlich effektiver. Sie mussten zwangsläufig mehr nachdenken.
Es war auch eine Zeit des (vergeblichen) Widerstands gegen spezialisiertere Tools aus proprietären Umgebungen wie SunOS, HP-UX und AIX. Zu dieser Zeit musste ich zwischen einer großen Anzahl von ihnen navigieren, ohne von einem von ihnen besonders abhängig zu werden.
2010–2020
Im Jahr 2003 fand ich mich in einem Unternehmen mit 300 Mitarbeitern wieder, das wiederum Teil eines Konzerns mit 100.000 Mitarbeitern war.
Meine Aufgaben verlagerten sich in Richtung Management, aber glücklicherweise gelang es mir, meine engen Verbindungen zur Technik im Allgemeinen und zum Code im Besonderen aufrechtzuerhalten. Dies war auch die Zeit, in der ich IntelliJ entdeckte, die IDE der Wahl für Javaisten.
Zugegeben, es war eine kleine Revolution. Im Gegensatz zu Eclipse, das am Ende ausnahmslos wie Frankensteins Kreatur aussah, kam IntelliJ mit einem „All-in-One“/“Batterien enthalten“-Ansatz.
Für eine sehr lange Zeit war es (und scheint es in vielerlei Hinsicht immer noch zu sein) anderen IDEs auf dem Markt voraus, was seine massive Akzeptanz erklärt.
Im Jahr 2013 war ich Mitbegründer eines Startups, dessen Mission es war, eine Plattform für Digital Signage war.
Als ich die Rolle des CTO eines Unternehmens übernahm, das in den Anfangstagen nur aus mir und meinem Partner bestand, wechselte ich wieder in den intensiven Programmiermodus. Ich musste das gesamte System entwerfen, das MVP und die nächsten Schritte entwickeln.
IntelliJ blieb mein Hauptarbeitswerkzeug, nicht mehr für Java, sondern für Scala (mit dem es sehr gut umgehen konnte) und GoLang (mit dem es auch sehr gut umgehen konnte).
Die „intelligenten“ Autocomplete-Funktionen begannen überzeugend auszusehen, und der Anwendungsbereich des Tools wurde weiter erweitert (Datenbankverwaltung, SQL-Abfragen aus Code, Code-Konsistenzprüfungen anhand des Datenbankschemas, HTTP-Abfrageverwaltung zum Testen von APIs usw.).
Als das Jahr 2020 näher rückte, begann mich die Umständlichkeit des Tools, die durch all diese Funktionen impliziert wurde, zu ärgern.
Einige der Entwickler, die wir für unser Startup rekrutiert hatten, zogen es vor, mit VSCode zu arbeiten, das bereits ausgereift war.
Also testete ich das Tool und stellte fest, dass der Leistungsgewinn und die Fließfähigkeit meines Workflows den (relativen) Verlust an Funktionalität mehr als wettmachten.
2020–2021
Wieder einmal befand ich mich in einer Situation, in der ich mir „die Hände schmutzig machen“ musste, diesmal hauptsächlich mit Rust und Golang (mit vielen Kubernetes-YAML-Dateien…).
VSCode ist immer noch mein bevorzugtes Tool, aber wie bei IntelliJ gilt: Je mehr ich meine Tage damit verbringe, desto mehr werden mir die kleinen Verzögerungen, Verlangsamungen und Fehler bewusst. Und vor allem die Stabilität kostete immer wieder Arbeitszeit.
Mir kam der Gedanke, dass die guten alten Tools, die ich zu Beginn meiner Karriere nutzen durfte (VIM, um nur einige zu nennen), sich wahrscheinlich weiterentwickeln mussten, und dass es vielleicht möglich sein könnte, das gleiche Produktivitätsniveau zu erreichen, ohne sich mit einem VSCode herumschlagen zu müssen, der immer mehr wie Eclipse mit all seinen Plugins aussah.
In dieser Zeit nahm ich an einer Entwicklerkonferenz teil, auf der der Referent eine überzeugende Demo von NeoVIM (so angepasst, wie es sein sollte) gab, die mich schließlich überzeugte.
Jetzt
Heute beschäftige ich mich mit der Optimierung des Software-Entwicklungsprozesses. Denn in Zeiten von Scrum etc. ist der Output der Entwicklung immer noch weit hinter den Erwartungen. Und dies trotz bester und intelligentester Werkzeuge. Hier berate ich Unternehmen in der Optimierung der Prozesse und der Organisation, um die Unternehmensziele zu erreichen.
Ende 2021 habe ich Helix (fast) zufällig entdeckt (ich war auf der Suche nach einer Rust-Version von NeoVIM).
Helix ist eine Art NeoVIM mit „Batterie inklusive“, d.h. das Beste aus beiden Welten: die Leichtigkeit und Effizienz eines (modalen) Editors im Terminal-Modus ohne das Durcheinander von Konfigurationen und Plugins, das NeoVIM benötigt.
Obwohl es sich um ein relativ junges Projekt handelt, hat es sich schnell weiterentwickelt und ist nun vollständig für den täglichen Gebrauch ausgereift, sei es zum Programmieren, Schreiben von Dokumenten, Verwalten meiner Notizen und TODOs, Erstellen meiner Meerjungfrauendiagramme usw.
Es ist leicht über das LSP-Protokoll erweiterbar (von Microsoft mit VSCode populär gemacht), sodass Sie die gleichen Funktionen zur automatischen Vervollständigung, Diagnose und Aktionsvorschläge finden wie in jeder viel schwereren IDE.
Es definiert noch kein Plug-in-System, was in gewisser Weise im Widerspruch zu seiner ursprünglichen Philosophie steht. Aber unter dem Druck der Community gab der Schöpfer schließlich nach, und es ist eine Entwicklung, die im Gange ist.
Warum also ein terminalbasierter Modaleditor?
In einer Zeit, in der Cursor und andere KI-fähige IDEs immer ausgefeilter werden, mag diese Wahl kontraintuitiv oder sogar kontraproduktiv erscheinen.
Es ist in der Tat das Gegenteil des Werkzeugwettlaufs, aber mit der Zeit (und der Weisheit, die damit einhergeht, muss es einige Vorteile geben) wurde mir klar, dass diese Tools am Ende „Lärm“ zwischen meinem Gehirn und meinem Code erzeugten.
Das Ziel dieser Tools ist es, die Produktivität der Entwickler zu verbessern, indem einige der Aufgaben automatisiert und ein Teil der Komplexität verborgen wird (z. B. die Grobheit der Kompilierungsoptionen oder die Argumente, die zum Starten einer Debug- oder Unit-Test-Sitzung verwendet werden).
Dadurch entsteht letztlich eine Distanz zwischen dem Entwickler und den Tools (hauptsächlich dem Compiler), mit denen er tatsächlich interagiert.
Distanz
Diese Distanz wirft mehrere Bedenken auf:
- Erstens kann der Entwickler sein Programm nicht mehr ohne seine bevorzugte IDE entwickeln oder kompilieren (es ist nicht einfach, CI-Skripte danach zu schreiben).
- Zweitens, aber das ist eine persönliche Meinung, finde ich, dass sie der mentalen Repräsentation der Codestruktur abträglich sind. Sie navigieren mit einem Klick von einer Funktionssignatur zu ihren Aufrufen, mit einem weiteren Klick durch eine Baumstruktur (die ziemlich verwirrend sein kann), und am Ende machen Sie nicht den Auswendiglernaufwand, der erforderlich ist, um sich die Struktur Ihres Codes zu merken. Und doch ist diese mentale Repräsentation für die kontinuierliche Verbesserung des Codes unerlässlich. Entwickler denken nicht nur nach, wenn sie vor ihrer IDE stehen (es ist wahrscheinlich sogar marginal).
Wenn Sie einen Editor wie Helix (oder NeoVIM) verwenden, haben Sie das Gefühl, Ihrem Code „näher“ zu kommen. Helix zum Beispiel verfügt nicht über eine baumartige Darstellung des Codes oder der Dateistruktur, sondern über ein äußerst effizientes und schnelles Suchsystem.
Dieser „Mangel“ erweist sich tatsächlich als unglaublich effizienter, wenn Sie eine gute Vorstellung von der Datei- und Codestruktur haben.
Geschwindigkeit
Ein weiterer, nicht minder wichtiger Aspekt ist die Geschwindigkeit, mit der gewohnte Benutzer arbeiten können.
Navigieren im Code, Auswählen eines Wortes, einer Funktion, eines Teils einer Funktion, gleichzeitiges Bearbeiten – all dies ist im Handumdrehen erledigt, ohne dass Sie jemals die Tastatur verlassen müssen, um die Maus oder das Trackpad zu holen.
Für die reine Textbearbeitung sind modale Editoren einfach unschlagbar für diejenigen, die ein Minimum an Aufwand betreiben, um ihre Verwendung zu erlernen, selbst auf Codebasen von mehreren hunderttausend Zeilen.
Aber Helix ist mehr als nur ein Texteditor: Mit seiner Fähigkeit, externe Tools über das LSP-Protokoll zu verwenden, bietet es fast das gleiche Maß an Informationen und Automatisierung wie eine viel schwerere IDE: direkter Zugriff auf die Funktionsdokumentation, Autovervollständigung, Beschreibung von Funktionssignaturen, Indizierung der Codestruktur (wer ruft wen auf, wer wird von wem verwendet, wer setzt was um, etc.).
Fazit
Modale, terminalbasierte Editoren zwingen Sie, sich ohne Ablenkungen auf Ihren Code zu konzentrieren. Sie sind unglaublich effizient und werden heutzutage immer umfassender. Ohne KI oder Copilot müssen Sie jedoch Ihr Gehirn einsetzen. Und vielleicht richtet es sich deshalb nicht an ein so breites Publikum.
Weiterer interessanter Beitrag: CORS einfach erklärt