An der Universität habe ich das Codieren geliebt. Jetzt ist es zur Routine geworden. Wie kehre ich zur früheren Sicherung zurück?



Reflexion ist eine merkwürdige Sache. Noch interessanter, wenn es auf langjähriger Erfahrung basiert. Unter dem Schnitt die Geschichte über das Schicksal eines Programmierers durch die Lippen des Entwicklungsleiters von Parallels RAS Igor Marnat in der ersten Person. Viel Spaß!
„Wenn Sie sich nicht vorwärts bewegen, stehen Sie nicht still. Die Welt bewegt sich vorwärts, aber Sie sind es nicht. Du ziehst also zurück! “ © (Jemand ist sehr schlau)


Epigraph

Programmieren ist für mich noch keine Routine geworden, obwohl ich mich seit mehr als zwanzig Jahren entwickle. Ich denke, das liegt daran, dass ich bestimmte Maßnahmen ergriffen habe, bevor meine Sicherung endgültig ausgetrocknet ist.

Wenn das Programmieren für Sie zur Pflicht geworden ist, ist meine Erfahrung vielleicht hilfreich für Sie. Möchten Sie etwas ändern? Zumindest muss etwas geändert werden (tiefer Gedanke, nicht wahr?). Wir müssen irgendwohin ziehen. Und jetzt, zu verschiedenen Zeiten, versuchte ich mich nach innen zu bewegen, mich seitwärts zu bewegen und mich in der Breite zu bewegen.

Tiefe Bewegung


Die Besonderheit unserer Arbeit ist, dass jeder Entwickler ein Spezialist in zwei Bereichen sein muss - der Programmierung als solcher und in dem Themenbereich, für den er Software erstellt. Je besser und tiefer der Entwickler diese beiden Bereiche versteht, desto interessanter sind die Aufgaben, die er lösen kann. Je interessanter und umfangreicher die Aufgabe, desto auffälliger das Ergebnis.

Die meisten Programmierer beziehen ihre Motivation aus den oberen Ebenen der Maslow-Pyramide - Erkenntnis, Selbstverwirklichung und das Bedürfnis nach Respekt. Dazu ist es notwendig, dass erstens das Ergebnis ihrer Arbeit spürbar ist. Zweitens sollte dieses Ergebnis das Licht sehen, die Leute sollten es benutzen. Die Sichtbarkeit des Ergebnisses hängt offensichtlich eng mit der Größe dieses Ergebnisses mit seinem Wert und Gewicht zusammen.

Während der Entwicklung von Software für die Telekommunikation habe ich viel Zeit und Mühe in das Studium eines neuen Themenbereichs investiert: das Gerät von Allzweckprozessoren und DSP, Speicher, Speichersysteme, Netzwerkprotokolle, Signalisierungsarten, Signalverarbeitungsalgorithmen im Allgemeinen, eine Reihe verschiedener interessanter Dinge aus Telefonie, Schaltkreisen, Netzwerken.

Es dauerte mehrere Jahre (in denen ich merklich mehr als acht Stunden am Tag arbeitete). Fünf Jahre später arbeitete ich auf Architektenebene und war an der Erstellung der Softwarestruktur neuer Telefonzentralen und der Architektur ihrer Komponenten beteiligt. Ich habe weniger Code geschrieben, Spezifikationen für das Team entwickelt, komplexen Code überprüft und an einigen kritischen Komponenten, Protokollen und Treibern gearbeitet. Ein gutes Verständnis des Geräts jeder Komponente, der Funktionsprinzipien und der Kommunikation mit den anderen ermöglicht es Ihnen, eine Produktarchitektur, Kommunikationsprotokolle und externe Schnittstellen zu entwickeln.

Natürlich ist jedes Softwareprodukt das Ergebnis der Arbeit des gesamten Teams, aber mit meiner Beteiligung am Projekt fühlte ich mich daran beteiligt, nicht die einzelnen Komponenten, sondern das gesamte Produkt zu erstellen. Gleichzeitig bekommt man einen unglaublichen Antrieb, es gibt auch mehr Verantwortung.

Je tiefer der Programmierer in den Themenbereich eintaucht, mit dem er arbeitet, desto besser kennt er den Kontext, desto breiter sein Horizont, desto interessanter kann er seine Arbeit machen.
Dies gilt nicht nur für die interne Anordnung von Produktkomponenten. Je besser Sie Ihre Benutzer kennen, wie sie das Produkt verwenden, warum und nicht anders, welche Probleme sie haben, wie die Produkte der Wettbewerber angeordnet sind, desto interessanter wird es für Sie, zu arbeiten.

All dies ist leicht zu erlernen. Sie müssen mehr mit Support, Tests, Implementierungsteams und Endbenutzern des Produkts kommunizieren. Wenn es möglich ist, eine Arbeitsinteraktion herzustellen, einige Probleme für sie zu lösen und an gemeinsamer Arbeit teilzunehmen, dann ist es im Allgemeinen super.

Übrigens gibt es noch eine Bemerkung zur Organisation des Workflows selbst, die insbesondere von der DevOps-Philosophie und dem Entwicklungs- und Betriebsansatz SRE, der ursprünglich von Google stammt, eingehalten wird. Es muss versucht werden, die Trennung zwischen Entwicklungs-, Implementierungs- und Supportteams und die Bewegung in Richtung Zusammenarbeit zu beseitigen.

Für alle Fälle stelle ich fest, dass RFCs, Deckbücher mit Tieren, Herstellerdokumentation und Korrespondenz in den meisten Open-Source-Communities Englisch als Standardkommunikationsmittel verwenden. Übersetzungen enthalten weniger Informationen, sind oft verzerrt und fast immer zu spät. Viele Hersteller machen sich überhaupt nicht die Mühe, Dokumentationen zu übersetzen. Daher ist die Fähigkeit, Bücher auf Englisch zu lesen, zumindest eine ziemlich grundlegende, sozusagen hygienisch-hygienische Anforderung für einen Entwickler, der sich entwickeln möchte.

Seitwärtsbewegung


In vielerlei Hinsicht wird das Interesse des Programmierers an seiner Arbeit durch sein Interesse an dem Themenbereich bestimmt, in dem er arbeitet. Beispielsweise langweilen Sie sich möglicherweise bei Finanzanwendungen, aber es wird interessant sein, an der Infrastruktur für solche Anwendungen zu arbeiten.

Parallel zur Entwicklung eingebetteter Software für die Telefonie arbeitete ich an einem verteilten System zum Sammeln von Informationen und zur Abrechnung von Benutzern - und dies ist eine völlig andere Welt, andere Sprachen, andere Plattformen. Weiter - die Automatisierung von Bereitstellung, Konfiguration und Test, dies ist die dritte Welt, alles ist wieder anders.

Um Ihr Interesse wiederzubeleben, sollten Sie vielleicht mit einem Kollegen oder Chef sprechen und sehen, was die Teams in der Nähe tun. Schon ein kleiner Schritt von den üblichen Aktivitäten entfernt kann einen großen Unterschied in Ihrer Arbeit bewirken und Ihnen eine andere Sicht der Dinge geben. Wie das Sprichwort sagt, bestimmt der Standort den Blickwinkel

Bewegung in der Breite


Als ich in die Telefonie kam, stellte sich heraus, dass ich nicht genug Zeit hatte, um anderen Projekten, an denen ich arbeitete, genügend Zeit und Aufmerksamkeit zu widmen. Die Lösung lag auf der Hand - ich begann noch mehr zu arbeiten. Aber es skaliert nicht viel. Bei langer Arbeit in der Nacht und am Wochenende nach einiger Zeit habe ich keine Lust mehr zu arbeiten und es gibt keine Zeit zum Leben. Mein Chef und ich haben beschlossen, einen anderen Programmierer in unserem Team einzustellen. Ich führte ziemlich anmaßend ein paar Interviews mit einem Schlag (das erste in meinem Leben auf der anderen Seite des Tisches) und stellte fest, dass es nicht so einfach war, eine intelligente Person in mein Team zu bringen, wie es scheint.

Wie kann man einen Fremden in kurzer Zeit verstehen? Wie beurteilen Sie seine Professionalität und seine persönlichen Qualitäten? Sind sie allgemein wichtig, diese persönlichen Qualitäten? Oder ist Professionalität wichtig? Worauf müssen Sie bei der Einstellung achten? Und wie genau drehst du es? Jetzt scheint das alles ziemlich offensichtlich zu sein, aber als ich den ersten Ingenieur für mich engagierte, war es ein echter dunkler Wald für mich.

Wie immer habe ich mit Google angefangen. Ich fand mehrere Artikel von Joel Spolsky, schluckte sie, las die Bücher, auf die er sich bezog, dann Links aus diesen Büchern, studierte systematischer und begann allmählich, in ein neues Themengebiet einzutauchen - Projektmanagement, Team, Management des Entwicklungsprozesses selbst.

Der Softwareentwicklungsprozess hat wie jeder andere Produktionsprozess seine eigenen Forscher, Entwicklungshistorie, Best Practices und Organisationsansätze. Viele seiner Aspekte, die sich direkt auf die Entwicklung und die besten technischen Praktiken beziehen, sind noch recht jung.

Zum Beispiel erschien Agile vor relativ kurzer Zeit, vor weniger als zwanzig Jahren, CI - ungefähr dreißig, das klassische Buch von Frederick Brooks seit ungefähr fünfzig Jahren. Andere Aspekte in Bezug auf Teammanagement, Psychologie, Motivation und Prozessmanagement in der gesamten Organisation sowie die Organisation der Kommunikation sind universell, stammen aus anderen Fachgebieten vor vielen Jahren und sind im Bereich der Entwicklung perfekt anwendbar.

Ich habe ziemlich viel Literatur zum Thema Teammanagement gelesen. Es scheint mir, dass dieses Thema in Amerika und Japan am gründlichsten und tiefsten untersucht wurde. Zusätzlich zu den klassischen Büchern über Entwicklung, Technik und Management würde ich Bücher von sowjetischen und russischen Flugzeugdesignern und Raketendesignern empfehlen. Darüber hinaus investieren NASA, NAVY, Toyota - diese Organisationen und Unternehmen investieren viel in die Optimierung ihrer Prozesse, halten interne Konferenzen für ihre Manager ab, Materialien zu ihnen sind im Netzwerk verfügbar, es gibt viele interessante Kunstbücher von ihnen und über sie. Neben hervorragenden Informationen über die in diesen Unternehmen aufgebauten Managementprozesse ist das Lesen von Autos, Flugzeugen, Raketen, Schiffen und deren Entwicklung einfach sehr interessant.

Im Allgemeinen ist der Spielraum für die Steigerung Ihrer Kompetenz im Bereich Management riesig, die Aufgaben sind auch sehr unterschiedlich. Sie können beginnen, indem Sie Ihre eigene Arbeit organisieren, indem Sie bewährte technische Verfahren wie Komponententests, Codeüberprüfungen, kontinuierliche Integration und kontinuierliche Bereitstellung einführen. Sie können sehr weit aufhören. Und es ist besser nicht aufzuhören :)

Fazit


Die Praxis zeigt, dass, wenn Sie beginnen, sich aktiv in mindestens eine der oben genannten Richtungen zu bewegen, nach einiger Zeit unvermeidlich eine weitere Bewegung auftritt - die hierarchische Leiter hinauf. Wenn es einen solchen Wunsch gibt, dann ist dies auch eine sehr interessante Option. Die Hauptsache dabei ist, das notwendige Gleichgewicht zwischen organisatorischer und technischer Arbeit, das Sie beibehalten möchten, nicht zu vergessen.

Softwareentwicklung ist ein Marathon, der ein Leben lang dauert. Es gibt immer Fristen, Fristen, die ganze Zeit müssen Sie ein bisschen mehr pushen. Um Energie und Motivation zu sparen und sich vor Burnout zu schützen, müssen Sie unbedingt wechseln, den Kopf über die Routine heben, sich umschauen und sich und Ihre Arbeit von der Seite betrachten. Theater, Musik, Konzerte, gute Bücher und Filme sind für den regelmäßigen Gebrauch obligatorisch. Oder eine Sommerresidenz. Oder wandern. Im Allgemeinen etwas anderes als Arbeit. Andernfalls wird die Arbeit nach zwei oder drei Jahren auf jeden Fall keine Freude mehr sein.

Bei der Arbeit kümmert sich niemand besser um Ihre Motivation und Karriere als Sie. Ehrlich gesagt ist es nicht so, dass sich niemand besser interessiert - nur niemand kümmert sich überhaupt darum. Bücher über Fachgebiete, verwandte Bereiche, Konferenzen, Kommunikation mit Kollegen, Mitaps - eine Bewegung, die, wie Sie wissen, das Leben ist.

Wenn Sie das Gefühl haben, dass es Zeit ist, etwas zu ändern, können Sie mit kleinen Schritten beginnen. Sie benötigen keine Erlaubnis von oben, kein Budget oder arbeiten in einer großen Organisation. Alle Schritte, über die ich schrieb, habe ich in einer kleinen Firma in Teams von zwei bis zehn Personen durchgeführt.

Ein paar gute Bücher, viel Verlangen und ein bisschen Bewegung können einen großen Unterschied machen. Viel Glück

Z.Y. Teilen Sie Ihre Erfahrungen und Lebenshacks in den Kommentaren. Leider ist Igor noch nicht bei Habré, ich lade Karma herunter, damit ich ihn einladen kann. In der Zwischenzeit werde ich Ihre Fragen an ihn weiterleiten, falls sich solche ergeben. Vielen Dank für Ihr Interesse.

Source: https://habr.com/ru/post/de430994/


All Articles