Das Geheimnis der Effizienz ist qualitativ hochwertiger Code und nicht ein effizienter Manager.

Eine der am stärksten mit Idioten überfüllten Berufe ist das Management von Programmierern. Nicht alle, aber die, die niemals selbst Programmierer waren. Die, die denken, dass man die Effizienz (oder „Effektivität“?) mit Methoden aus Büchern steigern kann. Ohne sich auch nur die Mühe zu machen, diese Bücher tatsächlich zu lesen – schließlich gibt es ein Video dazu.

Diejenigen, die nie Code geschrieben haben. Die, über die Hollywood-Filme über Programmierer gedreht werden – nun ja, die, in denen man die E-Mails über die Kommandozeile liest. Die, die sich für nichts interessieren außer für Kennzahlen, Fristen und ihr eigenes Gehalt.

Diejenigen, die die Mehrheit bilden.

Aber sie sind aus einem anderen Grund Idioten. Sie wollen Effizienz oder zumindest Effektivität (komm schon, Manager, google mal, wo der Unterschied liegt), ohne sich mit dem einen oder anderen auseinanderzusetzen. Sie verstehen nicht einmal die Essenz, den Prozess der Ergebnisgewinnung, die Verluste, die während dieses Prozesses auftreten, die Kosten für die Entwicklung. Kurz gesagt, sie arbeiten mit Programmierern wie mit einer Blackbox.

Die Programmierer sind aus einem einzigen Grund hierher geströmt: Es gibt Hype, Geld, einen Markt und eine Menge genauso Naiver. Hier kann man sich verstecken.

Wäre im Maschinenbau Hype, wären sie dorthin gelaufen. Schlechtes Allround-Talent. Ich wäre nicht überrascht, wenn der Typ, der im Dezember Weihnachtsbäume in unserer Nachbarschaft verkauft, ein IT-Manager im Urlaub ist.

Kurz gesagt, wenn möglich, schickt diese Kerle zum Teufel. Keine Sorge, sie finden Arbeit. Keiner von ihnen wird jemals etwas Anständiges zustande bringen, solange er nicht selbst Programmierer wird. Denn sie verstehen die Essenz, den Mechanismus, die Logik des Prozesses, den sie verwalten, nicht.

Genug über die Manager. Jetzt zum Wesentlichen, für Programmierer. Wie man die Effizienz der Entwicklung steigert, indem man lernt, qualitativ hochwertigen Code zu schreiben.

Um die Effizienz zu steigern, muss man Aufgaben schnell lösen, ohne die Qualität zu verlieren. Um Aufgaben schneller zu lösen, muss man in der Lage sein, sofort qualitativ hochwertigen Code zu schreiben. „Qualitativ hochwertig“, „schreiben“ und „sofort“. Ich werde das mit einer Metapher erklären.

Qualitativ hochwertigen Code zu schreiben ist wie richtig eine Fremdsprache zu sprechen. Wenn man die Sprache nicht beherrscht, verbringt man viel Zeit damit, seine Gedanken in dieser Sprache zu formulieren.

Wenn es schnell gehen muss, klebt man einfach ein paar Wörter aneinander, oft die falschen, vergisst die Artikel, die richtige Wortstellung, ganz zu schweigen von der Zeitform der Verben und der mangelhaften Aussprache.

Wenn man Zeit hat, eine Antwort zu formulieren, muss man in ein Wörterbuch oder einen Online-Übersetzer schauen und viel Zeit darauf verwenden, seine Gedanken zu formulieren. Das Gefühl bleibt trotzdem unangenehm: Man gibt eine Antwort und weiß nicht, ob sie richtig ist oder nicht. Ähnlich verhält es sich mit Code – man hat ihn scheinbar geschrieben, und er funktioniert, aber ob er qualitativ ist oder nicht – keine Ahnung.

Das führt zu einem doppelten Zeitverlust. Es dauert Zeit, eine Antwort zu finden. Auch die Formulierung dieser Antwort kostet Zeit – und zwar nicht wenig.

Wenn jedoch die Fähigkeit, qualitativ hochwertigen Code zu schreiben, vorhanden ist, kann man die Antwort sofort formulieren, sobald sie im Kopf gereift ist, ohne zusätzliche Zeit für die Übersetzung aufzuwenden.

Die Fähigkeit, qualitativ hochwertigen Code zu schreiben, hilft bei der Planung der Architektur. Man wird einfach keine falschen, unrealistischen oder minderwertigen Optionen im Kopf in Betracht ziehen.

Zusammenfassend lässt sich sagen, dass die Fähigkeit, qualitativ hochwertigen Code zu schreiben, die Lösung von Problemen erheblich beschleunigt.

Aber das ist noch nicht alles. Aufgrund der „Walenka-Manager“ gibt es einen Haken – es gibt keinen Grund, qualitativ hochwertigen Code zu schreiben. Der Manager sieht sich keinen Code an, der Kunde sieht keinen Code an. Wir zeigen uns gegenseitig selten Code, nur manchmal in bestimmten Projekten, wo es einen zugewiesenen 'Code-Reviewer' oder regelmäßiges Refactoring gibt.

Das bedeutet, dass in den meisten Fällen miserabler Code in die Produktion oder an den Kunden geht. Bei der Person, die miserablen Code geschrieben hat, entsteht eine feste neuronale Verbindung – miserablen Code zu schreiben ist nicht nur erlaubt, sondern auch nötig – er wird angenommen und man erhält dafür sogar Bezahlung.

Infolgedessen hat die Fähigkeit, qualitativ hochwertigen Code zu schreiben, überhaupt keine Chance sich weiterzuentwickeln. Der Code, der von einem hypothetischen Mitarbeiter geschrieben wurde, wird niemals von jemandem überprüft. Der einzige Grund, warum er lernen würde, richtig zu programmieren, ist die innere Motivation.

Doch diese innere Motivation steht im Widerspruch zu den Plänen und Anforderungen hinsichtlich Effizienz und Produktivität. Dieser Widerspruch wird offensichtlich nicht im Sinne von qualitativ hochwertigem Code gelöst, denn für schlechten Code wird man nicht einmal bestraft. Doch für das Nichteinhalten des Plans schon.

Was tun? Ich sehe und schlage zwei Wege vor, die man kombinieren kann.

Der erste Weg ist, seinen Code jemandem innerhalb des Unternehmens zu zeigen. Nicht reaktiv (wenn man darum bittet/zumuten), sondern proaktiv (hey, schau dir bitte meinen Code an). Hier ist es wichtig, nicht um den heißen Brei herumzureden, sondern die Kritik am Code direkt auszusprechen. Wenn der Code schlecht ist, sagen wir: der Code ist schlecht. Natürlich mit Erklärungen und Empfehlungen, wie man ihn besser machen kann.

Doch dieser Weg hat auch seine Tücken. Seine Anwendbarkeit hängt davon ab, an welchem Punkt der Kontakt stattgefunden hat. Wenn die Arbeit bereits in der Produktion ist und sich herausstellt, dass der Code von schlechter Qualität ist, macht es keinen Sinn, ihn zu überarbeiten. Genauer gesagt, wird es noch einen weiteren Grund geben – die Kennzahlen werden leiden. Die Manager werden kommen und mit Anforderungen zur Effizienz überfluten. Und versuche erst gar nicht, ihnen zu erklären, dass schlechter Code sich zwangsläufig in Form von Bugs zurückmelden wird – das wird dir nur schaden. Man kann nur die Verpflichtung übernehmen, so etwas in Zukunft zu vermeiden.

Ist die Arbeit jedoch noch nicht eingereicht oder gerade erst begonnen, kann es durchaus sinnvoll sein, den Code (oder sein Projekt, seine Idee) scharf zu kritisieren – dann wird die Person es richtig machen.

Der zweite Weg, der beste – sich in der Freizeit mit Open-Source-Entwicklung zu beschäftigen. Schließlich ist das Ziel: dass viele Programmierer, eben Programmierer, deinen Code sehen und sich dazu äußern. Innerhalb des Unternehmens hat niemand Zeit. Aber Programmierer auf der ganzen Welt haben nichts anderes zu tun und wenn du etwas Nützliches schreibst, das aus praktischer Sicht hilfreich ist, werden sie garantiert einen Blick darauf werfen.

Das Hauptmerkmal, meiner Meinung nach, ist das Programmieren in der Freizeit, da so kein Widerspruch zwischen Codequalität und Schnelligkeit des Ergebnisses entsteht. Du kannst ein Jahr lang an deiner Entwicklung arbeiten. Weder Fristen, noch Anforderungen, noch Geld, noch der Chef setzen dich unter Druck. Vollkommene Freiheit und Kreativität.

Nur in der freien Kreativität wirst du verstehen und empfinden, was tollen Code ausmacht, die Schönheit von Programmiersprachen und Technologien sehen und die Faszination von Geschäftsaufgaben spüren. Und du wirst lernen, hochwertigen Code zu schreiben.

Allerdings wird dies von dir persönliche Zeit erfordern. Wie jede andere Form der Weiterentwicklung. Betrachte dies nicht als Kosten, sondern als eine Investition – in dich selbst.

Quelle: habr.com