Ich habe neulich einen Auftritt von Kate Gregory auf der Pacific ++ 2018-Konferenz gesehen.
Kate ist eine gute Programmiererin und eine großartige Rednerin. Der Bericht selbst wirft viele interessante Dinge über C ++ - Programmierung und Programmierung im Allgemeinen auf (einen Blick wert). Aber am allermeisten war ich von einem (buchstäblich im Vorbeigehen) Gedanken begeistert, den sie ausdrückte. Kate konnte sehr kurz und in dem Fall die Motivation von Programmierern identifizieren. Sie klang so: "Der Programmierer versucht während seiner Arbeit, sein Glück zu maximieren." Es klingt kitschig, ist es aber wirklich.
Wir können sagen, dass wir das Projekt, den Kunden, das Unternehmen, die Menschheit und den Weltfrieden unterstützen (und dies kann sogar zutreffen). Aber seien wir ehrlich. Wir sind Menschen und wie alle Menschen bemühen wir uns vor allem, unser Glück zu maximieren - global während unseres gesamten Lebens, strategisch in unserer Karriere, taktisch im aktuellen Projekt und kleinlich hier und jetzt, wenn wir diese Funktion, diese Codezeile schreiben. Ja, wir machen das und es wäre gut herauszufinden, was uns glücklicher macht und was uns weniger macht. Dadurch können wir unsere Kollegen, Untergebenen und uns selbst besser verstehen.
Ich möchte die Themen Vergütung, Arbeitsbedingungen, Vorgesetzte, Mitarbeiter und andere sofort zusammenfassen. Wenn Sie dort arbeiten, wo Sie arbeiten, passt das alles ungefähr zu Ihnen. Konzentrieren wir uns auf das, was uns glücklich und unglücklich macht, wenn wir direkt am Code arbeiten.
Tests
Alle Projekte mit Tests sind gleich glücklich, jedes Projekt ohne Tests ist auf seine Weise unglücklich. Ich kann mit Zuversicht sagen, dass Programmierer in Projekten mit guter Testabdeckung im Durchschnitt glücklicher sind als in Projekten ohne Tests im Allgemeinen. Ich habe sogar gesehen, wie Programmierer, mit denen ihre Vorgesetzten nicht einverstanden waren, vollwertige Tests zu schreiben, sie heimlich geschrieben haben (manchmal sogar nach Stunden). Warum ist das passiert? Der schriftliche Test macht den Programmierer glücklicher. Seine Existenz ist bereits ein Zeichen dafür, dass zumindest etwas in Ihrem Projekt gemäß den besten Branchenpraktiken durchgeführt wird (auch wenn der Rest nicht der Fall ist). Ein erfolgreich abgeschlossener Test zeigt ein schönes grünes Häkchen, lobt den Programmierer (und schließlich wird ihn vielleicht niemand anderes loben). Der erfolgreiche Abschluss von 100% der Tests bietet eine Art stabilen Boden unter Ihren Füßen, wenn Sie bereits an etwas glauben können - dies erhöht unser Vertrauen in heute und morgen und macht uns glücklicher. Und selbst ein fehlgeschlagener Test macht seinen Job - informiert uns, dass wir ihn aus gutem Grund geschrieben haben, und lobt uns für unsere Weitsicht. Wenn Sie einen Programmierer glücklicher machen möchten, lassen Sie ihn (oder zwingen Sie ihn sogar dazu) Tests schreiben (natürlich ist alles in Maßen gut).
Bugfixing und Entwicklung neuer Funktionen
"Ich werde es Ihnen nicht für ganz Odessa erzählen", aber die meisten Programmierer, die ich in meinem Leben getroffen habe, schrieben lieber neue Funktionen als das Reparieren von Legac-Code. Und warum? Aber weil das Berühren eines Fehlers das Unglück eines anderen berührt. Für jemanden lief etwas schief und es war so wichtig, dass er nicht zu faul war, um seine Trauer direkt zum Entwickler zu bringen. Müssen in seine Position gehen, versuchen, sich zu reproduzieren. Und schließlich gelingt es entweder, sich zu reproduzieren - und das Selbstwertgefühl wird durch einen bekannten Fehler beeinträchtigt, oder es funktioniert nicht, und Sie müssen (oh mein Gott, nein!) Kontakt mit einer lebenden Person aufnehmen, die das Problem entdeckt hat, und versuchen, weitere Informationen zu erhalten. All dies kann nicht als angenehm bezeichnet werden.
Gleichzeitig ist das Schreiben einer neuen Funktion ein potenzieller Hauch von Glück. Wir haben noch nichts kaputt gemacht, es ist nicht unsere Schuld. Wir schreiben neuen Code, um neue Probleme zu lösen. Vielleicht wird es gelingen. Vielleicht erhalten wir das verdiente Lob (Bonus, Beförderung). Dies liegt
laut Maslow bereits näher an den oberen Ebenen der Pyramide der menschlichen Bedürfnisse.
Was ist die Schlussfolgerung? Die Arbeit des Programmierers muss ausgewogen sein, es sollte keine einzige Fehlerbehebung geben. Jeder Programmierer muss von Zeit zu Zeit die Entwicklung neuer Funktionen anvertrauen. Ja, es gibt kein Entrinnen vor Bugfixing, aber wir können zumindest versuchen, in dieser Angelegenheit ein Gleichgewicht zwischen Glück und Unglück von „ungefähr Null“ zu erreichen.
Refactoring
Mit gutem Code zu arbeiten ist schön. Leider fällt guter Code nicht vom Himmel. Es ist sogar unmöglich, es beim ersten Mal zu nehmen und zu schreiben. Wir müssen aus schlechtem Code guten Code machen, weil wir nichts mehr daraus machen können. Hier treffen Programmierer eine Wahl: Jeden Tag, wenn sie zur Arbeit kommen, leiden sie weiter und arbeiten mit schlechtem Code oder versuchen immer noch, guten Code daraus zu machen. Im zweiten Fall müssen Sie häufig mit einer Führung kämpfen, die nicht versteht, wofür diese N Stunden Zeit aufgewendet werden könnten, wenn dem Produkt keine neuen Funktionen hinzugefügt und alte Fehler ebenfalls nicht behoben würden. Ja, du musst kämpfen. Glücklicherweise haben wir in diesem Krieg Argumente: Prägnanter und schöner Code ist weniger fehleranfällig, seine Unterstützung nimmt weniger Zeit in Anspruch (und kostet weniger Geld), er eignet sich besser für Änderungen, wenn neue Geschäftsanforderungen auftreten usw. Außerdem dauert dieser Krieg in der Regel nicht lange: Er endet mit einem Kompromiss wie "Nein, ich werde keinen Monat für das Refactoring geben, aber wir sollten ihn freitags 2 Stunden pro Woche zuweisen." Okay, das ist gut. Wir haben uns gerade ein Stück Glück geholt. Ja, es muss noch mit eigenen Händen gebaut werden, aber das ist bereits möglich geworden.
Verwendung moderner Bibliotheken und Tools
Viele kennen wahrscheinlich den Schmerz, vor vielen Jahren in einem Projekt arbeiten zu müssen, das aus irgendeinem Grund auf einem Compiler (Framework, Bibliothek) steckt. Sie erklären uns, dass es aus diesen und jenen Gründen unmöglich ist, hier und jetzt auf die neue Version zu aktualisieren, aber eines Tages wahrscheinlich, wenn es klappt ... Was können Sie tun? Nun, erstens müssen wir uns eingestehen, dass die Umstände nicht zu unseren Gunsten sind und die Situation uns unglücklicher macht, als wir sein könnten. Zweitens kann die gleiche Idee von den Behörden (oder dem Kunden) geäußert werden. Es ist unwahrscheinlich, dass jemand damit streiten wird. Und in diesem Moment können Sie versuchen, selbst zu verhandeln: zum Beispiel Zeit für die Tests, neue Funktionen und Refactoring. (Sie können das Gehalt erhöhen, aber am Anfang des Artikels habe ich versprochen, es aus dem Bild zu lassen.)
Übrigens kann die Zeit, die für solche nützlichen Aufgaben aufgewendet wird, Sie nicht nur hier und jetzt ein wenig glücklicher machen, sondern auch die sehr „beängstigenden“ Gründe beseitigen, warum es unmöglich war, auf neuere Tools umzusteigen. Die reale Situation aus meinem Leben:
- Wir sind uns nicht sicher, ob der Übergang zu einer neuen Bibliothek keine neuen Probleme mit sich bringt ...
- Und hier habe ich 200 Tests für den Code mit dieser Bibliothek geschrieben. Versuchen wir zu bestehen, und wir werden sie starten.
- Hmm, komm schon.
Nach 2 Wochen - eine neue Bibliothek in Produktion.
Sie können wahrscheinlich weitere Aspekte untersuchen. Die allgemeine Idee ist jedoch dieselbe: Einige Aufgaben und Umstände machen den Programmierer glücklicher, andere - unglücklicher. Wenn es mehr zweite als die erste gibt - die Stimmung und Produktivität des Programmierers wird sinken, wird dies früher oder später zu Problemen im Projekt oder zu seinem Ausscheiden aus dem Team führen. Daher sollten sowohl der Programmierer als auch sein Manager nicht nur über das „globale Gut“ des Projekts, des Unternehmens oder des Benutzers nachdenken, sondern auch darüber, wie man mit dem Entwickler relativ zufrieden ist. Ansonsten, worum geht es?