Der Entwickler Justin Etheredge über zu große Systeme, zu kleine Ziele, die Bescheidenheit von Entwicklern und den Mythos des Superprogrammierers.
Dieser Text ist eine Übersetzung. Das Original des Software-Entwicklers Justin Etheredge ist hier zu finden.
Sie sind dabei, einen Blogbeitrag mit vielen Ratschlägen zu lesen. Von anderen zu lernen ist wichtig, aber oft vergessen wir dabei: Fast alle Ratschläge sind kontextabhängig, doch sie werden selten in einem Kontext geliefert.
"Man müsste einfach mehr Geld verlangen", sagt das Unternehmen, das seit 20 Jahren im Geschäft ist und jahrelang "zu wenig" verlangt hat, um Kunden zu gewinnen.
"Man sollte alles als Microservices aufbauen", sagt die Firma, die schnell einen Monolithen gebaut, Tausende von Kunden gewonnen hat - und dann auf Microservices umgestiegen ist, als es Probleme mit der Skalierung gab.
Ohne Kontext sind diese Ratschläge wertlos oder sogar schädlich. Hätten diese Leute ihre eigenen Ratschläge von Anfang an befolgt, hätten sie wahrscheinlich Probleme bekommen. Es ist schwer, diesem Widerspruch zu entkommen. Wir sind zwar immer die Summe unserer Erfahrungen, aber wir betrachten sie stets durch die Linse der Gegenwart.
Um Ihnen einen kleinen Einblick zu geben, in welchem Kontext meine Ratschläge zu sehen sind: Ich habe die erste Hälfte meiner Laufbahn als Programmierer für kleine Unternehmen und Startups gearbeitet. Dann bin ich in die Beratung gegangen und habe bei großen Unternehmen gearbeitet. Danach gründete ich Simple Thread und wir wuchsen von 2 auf 25 Mitarbeiter. Vor zehn Jahren arbeiteten wir hauptsächlich mit kleinen und mittleren Unternehmen, jetzt arbeiten wir mit einer Mischung aus großen und kleinen Firmen.
Mein Rat kommt von jemandem, der ...
- fast immer in kleinen, effizienten Teams gearbeitet hat, in denen mit sehr wenig viel erreicht werden muss.
- Working Software, also ein frühes Verwenden von Prototypen im Arbeitsalltag, über andere agile Praktiken stellt.
- ständig neue Projekte startet, aber auch einige bestehende Systeme pflegt.
- Entwicklungsproduktivität sehr wichtig findet.
Meine Erfahrungen der vergangenen 20 Jahre haben meine Sichtweise auf Software geprägt. Ich habe versucht, meine Erkenntnisse in einer Liste zusammenzufassen, die hoffentlich hilfreich für Sie ist.
1. Ich weiß immer noch nicht viel.
"Wie können Sie nicht wissen, was BGP ist?" - "Was? Sie haben noch nie von Rust gehört?" Die meisten von uns haben solche Fragen schon sehr oft gestellt bekommen, wahrscheinlich zu oft. Der Grund, warum viele von uns Software so lieben, ist, dass wir lebenslang lernen möchten. Gerade in der Softwarebranche gibt es in allen möglichen Bereichen viel zu wissen; und dieses Wissen lässt sich täglich erweitern. Das bedeutet, dass Sie Jahrzehnte in Ihrem Beruf arbeiten können und trotzdem einen enormen Wissensrückstand gegenüber jemandem haben können, der ebenfalls Jahrzehnte in einem scheinbar ähnlichen Job verbracht hat. Je eher Sie das anerkennen, desto eher können Sie Ihr Imposter- beziehungsweise Hochstaplersyndrom ablegen und sich stattdessen daran erfreuen, von anderen zu lernen und ihnen etwas beizubringen.
2. Es ist enorm schwierig, genau die "richtige" Software zu entwickeln.
Die meisten Entwickler glauben das nicht, weil sie denken, dass es ihre Arbeit abwertet. Ich halte das aber für Unfug. Für mich verdeutlicht dieser Satz vielmehr die Komplexität und Irrationalität mancher der Umgebungen, in denen wir arbeiten müssen, und vor welche Herausforderung uns das stellt. Man kann die technisch beeindruckendste Sache der Welt entwickeln - und am Ende will sie niemand benutzen. Das passiert andauernd. Softwareentwicklung ist in erster Linie eine Sache des Zuhörens; wir müssen Entwickler, Hellseher, Anthropologen sein. Die Investition in diesen Designprozess, sei es durch engagierte UX-Teammitglieder oder indem Sie sich weiterbilden, wird sich auszahlen. Denn die Kosten für die Entwicklung einer "falschen" Software lassen sich kaum abschätzen; sie belaufen sich jedenfalls auf viel mehr als nur die verlorene Entwicklungszeit.
3. Die besten Softwareentwickler denken wie Designer.
Gute Softwareentwickler machen sich viele Gedanken über die Benutzerfreundlichkeit ihres Codes. Sie mögen das nicht bewusst tun, aber gleich, ob es sich um eine externe API, eine Programmier-API, eine Nutzerschnittstelle, ein Protokoll oder eine andere Schnittstelle handelt - gute Entwickler überlegen, wer sie benutzen wird, warum sie benutzt wird, wie sie benutzt wird und was für die Nutzer wichtig ist. Deren Bedürfnisse im Auge zu haben, ist enorm wichtig für eine gute Anwendererfahrung.
4. Der beste Code ist kein Code - oder Code, den man nicht pflegen muss.
Wen auch immer Sie in egal welchem Beruf fragen: Jeder löst Probleme auf die Art und mit den Mitteln, die er oder sie am besten beherrscht. Das ist ganz natürlich. Und Coder coden eben. Die meisten Softwareentwickler werden bei einem Problem immer zu programmieren anfangen - vor allem, wenn eine nicht-technische Lösung nicht offensichtlich ist. Ähnliches gilt für die Wartung von bestehendem Code. Entwicklerteams neigen dazu, das Rad neu erfinden zu wollen, obwohl es bereits viele Räder gibt. Das Ganze ist eine Gratwanderung, denn es gibt gute Gründe, selbst zu entwickeln. Allerdings sollte man sich unbedingt vor dem schlimmen "Not Invented Here"-Syndrom hüten.
5. Software ist Mittel zum Zweck
Die Hauptaufgabe jedes Entwicklers ist, einen Mehrwert zu schaffen. Nur sehr wenige Entwickler verstehen das und noch weniger haben es verinnerlicht. Wenn es tatsächlich verinnerlicht wurde, werden Probleme auf andere Art gelöst und man bekommt eine andere Sichtweise auf die eigenen Werkzeuge. Wenn Sie wirklich daran glauben, dass Software dem Ergebnis untergeordnet ist, werden Sie bereit sein, tatsächlich das richtige Werkzeug für diese Aufgabe zu finden (das vielleicht gar keine Software ist).
6. Manchmal muss man einfach mal anfangen!
Manche Leute neigen dazu, sich in Probleme zu stürzen und einfach loszuschreiben. Andere wiederum forschen und recherchieren und geraten irgendwann in eine Art Analyse-Lähmung. Wenn Ihnen das passiert, sollten Sie sich eine Frist setzen und einfach anfangen, Lösungen auszuprobieren. Sie werden schnell dazulernen, wenn Sie anfangen, ein Problem zu lösen - was Sie wiederum dazu bringt, eine bessere Lösung zu finden.
7. Wenn man nicht weiß, was möglich ist, kann man kein gutes System entwerfen.
Damit habe ich oft zu kämpfen. Denn meine Aufgaben führen mich immer weiter weg vom Entwicklungsalltag. Mit dem Ökosystem der Entwickler Schritt zu halten, ist aufwendig. Aber es ist entscheidend, um zu verstehen, was möglich ist. Wenn Sie nicht verstehen, was in einem bestimmten Ökosystem möglich und verfügbar ist, werden Sie keine vernünftige Lösung für Ihre Probleme entwickeln können - außer für die einfachsten. Auf jeden Fall sollte man sich vor Leuten hüten, die Systeme entwerfen und seit langer Zeit keinen Code mehr geschrieben haben.
8. Jedes System ist irgendwann Schrott, finden Sie sich damit ab.
Von Bjarne Stroustrup stammt das Zitat: "Es gibt nur zwei Arten von Sprachen: die, über die sich die Leute beschweren, und die, die niemand benutzt." Das lässt sich auch auf große Systeme übertragen. Es gibt keine "richtige" Architektur, Sie werden nie alle technischen Schulden abbauen können. Sie werden nie die perfekte Schnittstelle entwerfen, Ihre Tests werden immer zu langsam sein. Das ist keine Ausrede dafür, nie etwas besser machen zu wollen. Es ist einfach ein anderer Blickwinkel. Kümmern Sie sich weniger um Eleganz und Perfektion, streben Sie stattdessen lieber nach ständiger Verbesserung und danach, ein praktikables System zu schaffen, in dem Ihr Team gerne arbeitet und das nachhaltig Werte schafft.
9. Niemand fragt genug nach dem "Warum".
Nutzen Sie jede Gelegenheit, um alles zu hinterfragen, was "schon immer so gemacht wurde". Sie bekommen neue Teammitglieder? Dann achten Sie darauf, an welchen Punkten sie nicht mitkommen und welche Fragen sie stellen. Oder: Sie haben eine neue Funktionsanforderung, die keinen Sinn ergibt? Stellen Sie sicher, dass Sie das Ziel und den Grund für den Wunsch nach dieser Funktion verstehen. Wenn Sie keine klare Antwort erhalten, fragen Sie so lange nach, bis Sie den Grund verstehen.
10. Wir sollten uns mehr darauf konzentrieren, keine 0,1x-Programmierer zu haben, als darauf, 10x-Programmierer zu finden.
Der 10x-Programmierer (also ein Programmierer, der zehnmal so gut ist wie die anderen, Anm. d. Red.) ist ein dämlicher Mythos. Die Vorstellung, dass jemand an einem Tag schafft, was andere kompetente, hart arbeitende, ähnlich erfahrene Programmierer in zwei Wochen schaffen, ist albern. Ich habe durchaus Programmierer kennengelernt, die das Zehnfache an Code produzieren - und musste sie zehnmal so oft korrigieren. Jemand kann nur dann ein 10x-Programmierer sein, wenn man ihn mit 0,1x-Programmierern vergleicht. Das ist jemand, der Zeit vergeudet, nicht um Feedback bittet, seinen Code nicht testet, Randfälle nicht berücksichtigt und so weiter. Wir sollten uns mehr darum kümmern, 0,1x-Programmierer aus unseren Teams fernzuhalten, als den mythischen 10x-Programmierer zu finden.
11. Einer der größten Unterschiede zwischen Senior- und Junior-Entwickler ist, dass erstere zu ihren Tools und zu Software an sich eine Meinung haben.
Nichts macht mir mehr Sorgen als ein Senior-Entwickler, der keine Meinung zu seinen Tools hat oder dazu, wie man Software entwickelt. Mir ist es lieber, wenn jemand eine Meinung hat, die ich nicht teile, als wenn er überhaupt keine Meinung hat. Wenn Sie Ihre Werkzeuge benutzen und sie nicht lieben oder hassen, müssen Sie mehr Erfahrungen sammeln. Sie müssen andere Sprachen, Bibliotheken und Paradigmen erkunden. Es gibt nur wenige Möglichkeiten, Ihre Fähigkeiten schneller zu verbessern, als aktiv herauszufinden, wie andere Aufgaben mit anderen Werkzeugen und Techniken gelöst werden können.
12. Innovation ist nicht wirklich gewünscht.
Es wird viel über Innovation geredet, in der Regel geht es dabei aber nur um schnelle Erfolge und kleinere Neuerungen. Wenn Sie wirklich innovativ sind und die Art und Weise ändern möchten, wie Menschen Dinge tun, rechnen Sie erst mal mit negativem Feedback. Wenn Sie fest an das glauben, was Sie tun, und wissen, dass es die Dinge wirklich verbessern wird, machen Sie sich auf einen langen Kampf gefasst.
13. Deine Daten sind der wichtigste Teil deines Systems.
Ich habe schon viele Systeme gesehen, die bei der Datenintegrität vor allem nach dem Prinzip Hoffnung funktionierte. In solchen Systemen führt alles, was abseits des goldenen Pfades passiert, zu unvollständigen oder ungültigen Daten. Damit umzugehen, kann zu einem Albtraum werden. Denken Sie einfach daran, dass Ihre Daten Ihre Codebasis wahrscheinlich lange überleben werden. Wenn Sie Energie darauf verwenden, sie ordentlich und sauber zu halten, wird sich das auf lange Sicht auszahlen.
14. Halten Sie Ausschau nach "Technologie-Haien".
Alte Technologien, die sich gehalten haben, sind Haie, keine Dinosaurier. Sie lösen Probleme so gut, dass sie den schnellen Wandel in der Tech-Welt bis heute überlebt haben. Verzichten Sie nicht auf diese Technologien und ersetzen Sie sie nur, wenn Sie einen sehr guten Grund dafür haben. Solche Tools sind unauffällig und wenig aufregend, aber sie erledigen die Arbeit, ohne dass Sie schlaflose Nächte haben.
15. Verwechseln Sie Bescheidenheit nicht mit Unwissenheit.
Es gibt viele Softwareentwickler, die ihre Meinung nur äußern, wenn sie gefragt werden. Gehen Sie nie davon aus, dass jemand nichts zu sagen hat, nur weil er Ihnen seine Meinung nicht aufdrängt. Manchmal sind die lautesten Menschen die, denen wir am wenigsten zuhören möchten. Sprechen Sie mit Ihren Mitmenschen, holen Sie sich ihr Feedback und ihren Rat ein. Sie werden froh sein, es gemacht zu haben.
16. Softwareentwickler sollten regelmäßig schreiben.
Softwareentwickler sollten regelmäßig bloggen, Tagebuch und Dokumentationen schreiben - einfach alles tun, was ihre schriftlichen Kommunikationsfähigkeiten verbessert. Schreiben hilft Ihnen, über Ihre Probleme nachzudenken, und es hilft Ihnen, sie effektiver mit Ihrem Team und Ihrem künftigen Ich zu besprechen. Gute schriftliche Kommunikation ist eine der wichtigsten Fähigkeiten von Softwareentwicklern.
17. Halten Sie Ihre Prozesse so schlank wie möglich.
Jeder möchte heutzutage agil sein, aber viele vergessen, dass es bei "agil" vor allem darum geht, Dinge in kleinen Stücken zu entwickeln, zu lernen und dann zu iterieren. Wenn jemand versucht, mehr daraus zu machen, will er wahrscheinlich etwas verkaufen. Das soll nicht heißen, dass Menschen keine Beratung oder Hilfe brauchen, um so zu arbeiten. Aber wie oft haben Sie schon gehört, dass jemand aus Ihrem Lieblings-Tech-Unternehmen oder einem großen Open-Source-Projekt damit geprahlt hat, wie toll sein Scrum-Prozess ist? Bleiben Sie bei den Kernpunkten, bis Sie wissen, dass Sie mehr brauchen. Vertrauen Sie Ihrem Team und es wird liefern.
18. Softwareentwickler brauchen wie alle Menschen das Gefühl der Verantwortung.
Wenn Sie jemanden vom Ergebnis seiner Arbeit abkoppeln, wird er sich weniger um seine Arbeit kümmern. Für mich ist das fast eine Tautologie. Es ist der Hauptgrund, warum funktionsübergreifende Teams so gut funktionieren und warum DevOps so populär geworden ist. Es geht nicht nur um Übergaben und Effizienz, sondern darum, den ganzen Prozess von Anfang bis Ende selbst in die Hand zu nehmen und direkt für das Entwickeln und Vertreten von Werten verantwortlich zu sein. Wenn man einer Gruppe engagierter Menschen die vollständige Verantwortung für die Entwicklung, Erstellung und Bereitstellung einer Software (oder eines anderen Produkts) überträgt, können erstaunliche Dinge geschehen.
19. Vorstellungsgespräche sagen wenig über die Teamfähigkeit aus.
Vorstellungsgespräche sind gut geeignet, um herauszufinden, wer das Gegenüber ist und wie interessiert es an einem bestimmten Fachgebiet ist. Sie sind aber nicht gut geeignet herauszufinden, wie gut jemand als Teammitglied ist. Auch die Intelligenz oder das Wissen einer Person ist nach meiner Erfahrung kein guter Indikator dafür. Niemand wird Ihnen in einem Vorstellungsgespräch sagen, dass er oder sie unzuverlässig, ausfallend oder eingebildet ist. Oder nie pünktlich zu Sitzungen erscheint. Manche behaupten, es gebe da bestimmte Anzeichen ("Wenn sie im ersten Vorstellungsgespräch nach Urlaub fragen, sind sie bestimmt nie da!"). Aber das ist Blödsinn. Wer auf solche "Anzeichen" hört, weist mitunter gute Bewerber ab.
20. Versuchen Sie immer, ein kleineres System zu bauen.
Es gibt viele Einflüsse, die Sie dazu bringen könnten, von Anfang an ein großes System zu bauen: Budgetzuweisungen, die Unfähigkeit zu entscheiden, welche Funktionen gekürzt werden sollen, der Wunsch, die "beste Version" eines Systems zu liefern. All das führt zu oft dazu, zu viel zu bauen. Sie sollten dagegen angehen. Während Sie ein System von klein auf aufbauen, lernen Sie so viel, dass Sie durch Iterationen am Ende ein viel besseres System bekommen, als Sie jemals von Beginn an hätten entwerfen können. Überraschenderweise ist das vielen Menschen aber schwer zu vermitteln.
... und Ihre Geschichte?
Das war's also: 20 Jahre Softwareentwicklung, in 20 knappe Weisheiten gegossen. Ich würde gerne wissen, wie Sie das wahrnehmen, und ob Sie vielleicht auch eine Weisheit haben, die Sie im Laufe Ihrer Karriere erworben haben und teilen möchten. Schreiben Sie, was Ihnen dazu einfällt, gerne in die Kommentare.
https://ift.tt/3HvK56y
Wissenschaft & Technik
Bagikan Berita Ini
0 Response to "Software: 20 Dinge, die ich in 20 Jahren als Entwickler gelernt habe - Golem.de - Golem.de"
Post a Comment