Das zehnte Jahr wird bald kommen, da ich mich beruflich mit Programmieren beschäftige. Zehn Jahre alt! Und neben der formalen Arbeit habe ich fast zwei Drittel meines Lebens etwas im Internet geschaffen. Ich erinnere mich kaum an die Jahre, in denen ich HTML nicht kannte: Es ist sogar seltsam, wenn Sie darüber nachdenken. Einige Kinder lernen Musik oder Ballett, und stattdessen schuf ich magische Welten, die in meinem Kinderzimmer programmiert wurden.

Wenn ich an dieses erste Jahrzehnt denke, in dem ich regelmäßig Geld für die Eingabe fremder Charaktere in das Terminal erhalte, möchte ich einige Beobachtungen darüber teilen, wie sich mein Denken im Laufe der Jahre der Arbeit verändert hat .

Vielleicht finden die derzeitigen Junioren hier einige ihrer Überzeugungen und betrachten sie von der anderen Seite. Oder sie stellen fest, dass sie dies bereits beseitigt haben, und sind viel weiter gegangen als ich auf Ihrer Bühne.

Aktuelle Senioren möchten möglicherweise auch lustige (und leicht demütigende) Geschichten darüber erzählen, welche Lehren aus ihren Erfahrungen mit Junioren gezogen wurden.

Aus Gründen der Klarheit betone ich, dass Junioren erstaunlich sind : Nur bei der Arbeit zu erscheinen, um neue Dinge zu lernen - das erfordert bereits viel Mut. Dieser Artikel handelt von meiner eigenen Erfahrung und Ausbildung. Ich verallgemeinere überhaupt nicht, dass alle Junior-Entwickler so denken oder sich so verhalten.

Ich hoffe, Sie genießen die Post und erinnern Sie an etwas aus der Vergangenheit oder der Gegenwart.

Vielen Dank an Artyom und Sarah für das Feedback!

Absolute Wahrheiten des Junioren, von denen man verlernen musste

1. Ich bin ein leitender Entwickler

Als ich zum ersten Mal versuchte, einen Job zu finden, war ich 19 Jahre alt. Der Job wurde als "Student Webmaster" bezeichnet. Dies ist ein ziemlich überraschender Name für die Arbeit, da Sie gleichzeitig als „Schüler“ und „Meister“ betrachtet werden. Heutzutage möchte jeder "Ingenieur" sein, weil es modischer klingt, aber für mich ist "Meister" ein besseres Wort für dieses Handwerk. In jedem Fall bestand meine Aufgabe darin, PHP und MySQL zu schreiben, unsere Site in Drupal zu pflegen und einige interne Tools zu erstellen.

Da ich zuvor mehrere Jahre in meinem Schlafzimmer programmiert hatte, war ich mir sicher, dass diese Jahre als „jahrelange Erfahrung“ gelten. Auf die Frage, wie viel Erfahrung ich in PHP geschrieben habe, antwortete ich zuversichtlich: "3 oder 4 Jahre!"

Ich dachte, ich wüsste viel über SQL, weil ich äußere Verknüpfungen (äußere Verknüpfungen) ausführen kann.

Und als ich gegoogelt habe, habe ich herausgefunden, dass drei bis vier Jahre Erfahrung viel Geld bedeuten.

Fahren wir mit meiner letzten Arbeit fort, die ich nach fünf Jahren „kombinierter“ Studenten- und Berufserfahrung (die ich als normale Erfahrung betrachtete) erhalten habe. Zu diesem Zeitpunkt wurde mein Code fast nie einer Codeüberprüfung unterzogen. Ich habe ssh auf dem Server ausgeführt und Git Pull ausgeführt. Ich bin mir sicher, dass ich noch nie eine einzige Pull-Anfrage gesehen habe. Versteh mich nicht falsch, in den ersten beiden Arbeiten habe ich viele erstaunliche Dinge gelernt, ich habe einfach nie mit anderen Entwicklern in derselben Codebasis gearbeitet. Trotzdem habe ich mich als „Senior Front-End Engineer“ beworben, ein Angebot erhalten und angenommen.

So wurde ich im reifen Alter von 24 Jahren ein leitender Entwickler.

Schließlich würden sie mir diese Position nicht geben, wenn ich wirklich kein leitender Entwickler wäre, oder ?! Natürlich hat mich meine beeindruckende Erfahrung zu diesem Höhepunkt geführt, also sollten die Leute mir zuhören !!! Ich bin auf dem Höhepunkt meiner technischen Karriere, während ich der jüngste im Büro bin.

Genau wie ein Chef.

Was habe ich endlich verstanden?

Nicht alle Erfahrungen sind gleich . Meine Erfahrung als Programmierer im Schlafzimmer, die Arbeit eines studentischen Programmierers, unterscheidet sich von der wissenschaftlichen Forschung in der Informatik und der Arbeit in einem wachsenden Startup. Dies ist eine andere Erfahrung. Für ein Jahr Arbeit im technischen Support zu Beginn Ihrer Karriere können Sie zehnmal mehr als fünf Jahre in einzelnen Projekten lernen (oder mit minimalem Feedback). Wenn Ihr Code von Kollegen nie angezeigt wird, ist das Training viel langsamer.

Deshalb sind Mentoren so wichtig , und Ihr Team ist viel wichtiger als die Differenz von ein paar Dollar Gehalt. Geben Sie sich nicht mit einer Juniorposition zufrieden, in der Sie alleine arbeiten werden! Und wählen Sie Ihren ersten Job (oder ehrlich gesagt jeden Job) nicht nur auf Gehaltsbasis. Im Team liegt der wahre Wert.

Ich habe auch gelernt, dass Berufsbezeichnungen für sich genommen nichts bedeuten . Die CTO-Position kann in einem Team von 5 Personen, 50 oder 500 Personen sein. Dies ist ein völlig anderer Job, obwohl der Name identisch ist. Mein Titel "Senior" machte mich also überhaupt nicht zu einem führenden Programmierer. Darüber hinaus sind hierarchische Titel von Natur aus fehlerhaft und schwer zu vergleichen. Mir wurde klar, dass es wichtig ist, nicht in den Namen hängen zu bleiben, und dass Sie sie nicht als externe Prüfung verwenden sollten.

2. Jeder schreibt Tests

In der ersten Hälfte meiner Karriere habe ich im Forschungsbereich gearbeitet. Insbesondere dreieinhalb Jahre bei einem Projekt mit staatlicher Finanzierung und dann anderthalb Jahre an der Universität im Fachbereich Verarbeitung natürlicher Sprache. Ich kann eines sagen: Das Programmieren im wissenschaftlichen Umfeld unterscheidet sich grundlegend vom Programmieren in der kommerziellen Industrie .

Zum größten Teil erstellen Sie keine Anwendungen. Sie arbeiten an Algorithmen oder analysieren Datensätze. Wenn Sie alternativ eine Anwendung erstellen, wird die Arbeit höchstwahrscheinlich vom Staat finanziert. Dies bedeutet, dass es für andere kostenlos und normalerweise Open Source ist. Und wenn etwas kostenlos ist, bedeutet dies, dass Sie normalerweise nicht dafür verantwortlich sind, dass es immer verfügbar ist.

Weil ... nun, es ist kostenlos.

Sie sind auch nicht verantwortlich für finanzielle Erträge oder bestimmte Ergebnisse. Die Arbeit eines Programmierers in einer wissenschaftlichen Einrichtung ist jedoch ein Thema für einen völlig anderen Artikel.

Kurz gesagt, ich habe das Institut mit großen Erwartungen verlassen.

Erwartungen an die Funktionsweise der Branche. Automatische Bereitstellungen. Pull-Anfragen und Code-Reviews. Es wird großartig! Endlich die Qualität des Codes , von dem ich geträumt habe! Abgesehen von qualitativ hochwertigem Code mit den richtigen Standards und Best Practices war ich fest davon überzeugt, dass in der Softwareindustrie jeder Tests schreibt .

Hm ...

Stellen Sie sich meine Überraschung vor, als ich am ersten Arbeitstag im Startup keine Tests fand. Keine Tests in der Schnittstelle. Keine Tests im Backend. Überhaupt keine Tests.

Nda. Nichts. Null NaN. Tests fehlen als Phänomen.

Es gab nicht nur keine Tests , sondern niemand schien Probleme damit zu haben! Mit etwas Naivität schlug ich vor, dass der Grund dafür ist, dass die Leute einfach nicht wussten, wie man Tests für AngularJS schreibt. Wenn ich sie unterrichte, wird alles klappen - und wir werden anfangen, Tests durchzuführen. Fehler! Im Allgemeinen haben wir nur wenige Jahre später automatisierte Tests im Code implementiert, und es war nicht so einfach, wie ich dachte.

Aber nicht, weil die Leute nicht wissen, wie man sie schreibt.

Entweder hatten sie nie Probleme aufgrund fehlender Tests, oder sie hatten Probleme aufgrund des Vorhandenseins alter Tests. Zwei Dinge, denen ich noch nie begegnet bin.

Was habe ich endlich verstanden?

Viele Unternehmen und Startups haben praktisch keine Tests . Im Kampf um den Markt oder ums Überleben vernachlässigen viele Unternehmen das Testen in einem frühen Stadium. Selbst trendige Unternehmen, die Konferenzen oder Open Source sponsern, stellen häufig einen großen ungeschickten Monolithen mit minimalen Tests her. Fragen Sie einfach die Entwickler nach dem Status der Codebasis.

Kein Unternehmen hat eine ideale technische Installation . Jedes Unternehmen hat Probleme, jedes hat eine technische Verschuldung. Die Frage ist, was sie damit machen. Wenn Sie sich für eine Stelle bewerben, müssen Sie klar verstehen, dass dort nicht alles in Ordnung ist, sonst hätten sie keine freie Stelle eröffnet.

Übermäßig selbstbewusst in Angelegenheiten zu sein, in denen Ihnen echte Erfahrung fehlt, ist ziemlich arrogant . Ich handelte so ein Besserwisser und bestand auf der weit verbreiteten Implementierung von Tests, ohne Erfahrung, wie man dies wirklich in großem Maßstab umsetzt. Wiederhole meine Fehler nicht. Es ist wichtig, Prinzipien zu haben, aber es ist immer noch wichtig, offen und wirklich interessiert zu sein, um die Erfahrungen und Ansichten anderer Menschen wahrzunehmen.

3. Wir sind so hinter dem Rest (auch bekannt als die technische Version des Syndroms des entgangenen Gewinns )

Dies hängt eng mit dem Thema Unit Testing zusammen. Meine Firma hat keine Tests durchgeführt, aber natürlich haben alle anderen Firmen sie durchgeführt, oder?

Ich habe eine Reihe von Blog-Posts gelesen. Ich habe viele Konferenzreden auf YouTube gesehen. Verdammt, ich habe die ganze Zeit „diese orangefarbene Seite“ gelesen [wahrscheinlich unter Bezugnahme auf Hacker News - ca. trans.]. Jeder scheint hochentwickelte und qualitativ hochwertige Apps mit großartiger Leistung und trendigen Animationen zu schreiben, während ich nur Patches mache, um die Frist einzuhalten.

Ich habe buchstäblich alle anderen Unternehmen vergöttert, über die ich gelesen habe, und war enttäuscht darüber, wie sehr mein Unternehmen und das Projekt hinter ihnen zurückgeblieben sind.

Was habe ich endlich verstanden?

Viele Konferenzpräsentationen behandeln eher Proof of Concept als reale Szenarien . Nur eine Geschichte auf einer Konferenz über eine Technologie bedeutet nicht, dass das Unternehmen diese Technologie in seiner täglichen Arbeit verwendet oder dass der gesamte Code in perfektem Zustand ist. Konferenzredner präsentieren häufig eher Spielzeuganwendungen als echte Anwendungen: Es ist wichtig, zwischen ihnen zu unterscheiden.

Die Arbeit mit Legacy ist völlig normal . Nein, im Ernst, es ist leicht vorstellbar, dass ein anderes Unternehmen kein Vermächtnis hat. Aber nachdem wir Zeit auf Konferenzen verbracht haben und mit Leuten gesprochen haben, die in Top-Unternehmen arbeiten, wird klar, dass wir alle im selben Boot sitzen. Versuchen Sie, eine Firma zu finden, die KEINEN riesigen Monolithen in PHP oder Ruby hat, den sie zu zähmen versuchen (oder der irgendwann hätte zähmen sollen)? Legacy-Code ist an der Tagesordnung. Wenn Sie damit arbeiten, lernen Sie oft mehr als nur Anwendungen von Grund auf neu zu erstellen, da Sie mehr mit Konzepten arbeiten, die Sie noch nicht verstehen.

4. Die Qualität des Codes ist sehr wichtig.

Früher konnte ich eine sehr schwierige Codeüberprüfung durchführen .

Zumindest war ich sehr wählerisch in Bezug auf Stil. Mein Stil stellte sich als modifizierte Version des Airbnb-JavaScript-Styleguide-Stils heraus, passt aber zu meinem persönlichen Geschmack. Dinge wie Einrücken, Formatieren, Benennen - Gott bewahre, du wirst es anders machen. Es war völlig unmöglich, eine Codeüberprüfung ohne einen einzigen Kommentar von mir durchzuführen: Sie müssten die Fähigkeiten des Lesens von Gedanken erlernen und zusätzlich die Lotterie gewinnen.

Senden Sie mehr als 50 Kommentare an Ihre Pull-Anfrage, in denen alle Semikolons aufgelistet sind, die Sie verpasst haben!

Weil ich Augen wie ein Adler habe - und dieser Adler möchte alle seine hochwertigen Semikolons bekommen!

(Glücklicherweise ist nach vielen Jahren der Arbeit am Computer die Vision eines Adlers verschwunden, sodass Sie sich jetzt keine Sorgen mehr machen müssen - # lustige Witze)

Was habe ich endlich verstanden?

Gut genug - das ist genug . Bei Annäherung an den idealen Code gilt das Gesetz der Verringerung der Rendite. Der Code sollte nicht perfekt sein, aber sauber genug, um zu funktionieren, und keine vollständige Katastrophe für den Support. Oft ist Code, der sich zu oft wiederholt oder zu ausführlich ist, für andere leichter zu verstehen. Außerdem ist „guter Code“ nicht dasselbe wie „Code, der so aussieht, als hätte ich ihn selbst geschrieben“.

Architektur ist wichtiger als Nitpicking . Einige Linien können zwar verbessert werden, aber die Hauptprobleme sind die architektonische Ordnung. Es ist besser, sich sofort auf die Struktur der Anwendung zu konzentrieren, als auf einzelne winzige Codeteile.

Die Qualität des Codes ist wichtig , verstehen Sie mich nicht falsch. Aber die Qualität des Codes ist nicht das, was ich dachte. Dies ist nicht das Flusen, Formatieren oder irgendein Stil, der im letzten Artikel beschrieben wird, den ich gelesen habe.

5. Alles muss dokumentiert werden !!!

Als ich zu meiner ersten richtigen Firma kam, stieß ich zum ersten Mal auf einen seltsamen Code. Natürlich habe ich beim ersten Job ein wenig mit dem Code eines anderen gearbeitet, aber ich musste nie in die vorhandene Codebasis gehen und herausfinden, was zum Teufel hier los war. Das einzige Mal, dass dies geschah, habe ich den gesamten Code neu geschrieben, anstatt zu verstehen, wie er funktioniert.

Auf jeden Fall half die Tatsache, dass es sich um AngularJS-Code handelte, der von den Ruby-Entwicklern geschrieben wurde, der Situation überhaupt nicht, und ich war ein Junior, der sich einen Senior vorstellte.

Wie bin ich mit der Tatsache umgegangen, dass ich mich durch 300 Zeilen unbekannten Codes wie ertrunken fühlte?

JSDOC. ÜBERALL.

Ich fing an, alles zu kommentieren, um einen Sinn zu ergeben. Anmerkungen zu jeder Funktion, die ich erreichen konnte.

Ich habe all diese ausgefallene Angular-spezifische JSDoc-Syntax gelernt. Mein Code war immer doppelt so lang, weil er so viele Dokumentationen und Kommentare enthielt.

Was habe ich endlich verstanden?

Dokumentation lügt manchmal . Es ist leicht zu glauben, dass die Dokumentation alle Probleme löst. "Wir brauchen Docks!" Obwohl Dokumentation harte Arbeit ist, muss sie durchgeführt werden. Sie müssen nur die richtigen Dinge auf die richtige Weise dokumentieren. Eine übermäßige Dokumentation unnötiger Dinge verhindert in der Regel Menschen, die versuchen, ein echtes Problem zu lösen.

Konzentrieren Sie sich gegebenenfalls auf die Automatisierung anstatt auf die Dokumentation . Tests oder andere Formen der Automatisierung verlieren weniger wahrscheinlich an Relevanz. Daher versuche ich mich darauf zu konzentrieren, gute Tests mit einer klaren Sprache zu schreiben, damit andere Entwickler sehen können, wie das Projekt mit Arbeitscode funktioniert. Ein weiteres Beispiel ist die Automatisierung der Installation einer Anwendung mit wenigen Kommentaren anstelle einer langen und detaillierten Installationsanleitung.

6. Technische Schulden sind schlecht

Wenn Sie mich nach dem letzten Punkt als Neurotiker angesehen haben, lesen Sie einfach diesen! Für einige Zeit in meiner Karriere betrachtete ich jeden schmutzigen Code als technische Pflicht . Technische Schulden sind ein lustiger Begriff, denn wenn Sie nach einem Beispiel fragen, sagen sie ganz andere Dinge.

Da ich jeden „ungeordneten“ Code als technische Pflicht betrachtete, habe ich sofort versucht, ihn mit äußerster Härte zu beseitigen!

Einmal habe ich buchstäblich ein Wochenende damit verbracht, 800 Flusenfehler manuell zu korrigieren.

Das war ich als Neurotiker.

(Haftungsausschluss: Dies war, bevor automatische Korrekturen erschienen).

Was habe ich endlich verstanden?

Unorganisierter oder unordentlicher Code ist nicht dasselbe wie technische Pflicht . Nur ein unvollständiger Zustand bedeutet nicht, dass es sich um eine technische Pflicht handelt. Technische Schulden verlangsamen Sie tatsächlich auf irgendeine Weise oder machen bestimmte Arten von Änderungen schwierig oder fehleranfällig. Wenn der Code nur ein wenig chaotisch ist, ist er nur ein bisschen chaotisch. Die Reinigung ist Ihre Zeit möglicherweise nicht wert.

Technische Schulden zu haben ist normal . Manchmal verkürzen wir den Weg, weil wir die Arbeit dringend erledigen müssen, und dafür „verleihen“ wir einen Teil der Zeit in der Zukunft. Code-Schnipsel, die eine echte „technische Schuld“ darstellen, sind normal, wenn Sie anerkennen, dass Sie sie wahrscheinlich zurückgeben müssen. Wenn Ihre Codebasis Ihrer Meinung nach frei von technischen Schulden ist, überschätzen Sie höchstwahrscheinlich das Erscheinungsbild zum Nachteil der Lieferung . Und mein Gott, wie ich ihn überschätzt habe!

7. Je höher die Position eines Programmierers, desto besser programmiert er

Nachdem ich schon in jungen Jahren mit dem Programmieren begonnen hatte, wurde ich ein wahrer Profi für Loops und verfeinerte sie in 15 Jahren zum Automatismus. Programmieren an sich ist für mich wie Atmen. Wenn die Lösung offensichtlich ist, kann ich den Code einfach ohne Unterbrechung drucken, z. B. Text in einem Blog oder einer E-Mail. Ich kann die Lösung schneller als andere codieren und habe normalerweise komplexere Projekte übernommen.

Lange Zeit dachte ich, das sei die Essenz des Hauptentwicklers.

Scheint alles zusammen zu passen? Schließlich heißt die Position "Lead Developer" und nicht "Lead Communicator" oder "Lead Project Manager". Ich habe wirklich nicht verstanden, wie viel mehr Fähigkeiten entwickelt werden mussten, um ein wahrer „Führer“ zu werden.

Was habe ich endlich verstanden?

Hochrangige Ingenieure müssen neben dem Programmieren viele andere Fähigkeiten beherrschen . Im Vergleich zum Beginn einer Karriere musste ich eine astronomische Menge an Fähigkeiten entwickeln. Kommunikation, Abhängigkeitsmanagement, Kontextfreigabe, Projektmanagement, Bewertung der Projektvorlaufzeiten und Zusammenarbeit mit Kollegen, die keine Entwickler sind. Diese Fähigkeiten sind schwer zu quantifizieren und erfordern viel Versuch und Irrtum, bevor sie richtig erlernt werden.

Nicht jeder Programmierer wird ein "Senior" . Dies ist das Ergebnis langjähriger Erfahrung. Dennoch ist langjährige Erfahrung eine notwendige, aber nicht ausreichende Voraussetzung für den Herrn. Es muss auch die richtige Erfahrung sein, in der Sie die richtigen Lektionen gelernt haben und dieses Wissen in Zukunft erfolgreich anwenden können. Manchmal werden wichtige Lektionen in einem Jahr oder später herauskommen - deshalb sind jahrelange Erfahrung immer noch wichtig, selbst wenn Sie ein wirklich guter Programmierer sind.

In einigen Bereichen sind wir noch Junioren . Egal wie viel Erfahrung Sie haben, es gibt immer Orte, an denen Sie wenig Wissen haben. Das Erkennen Ihrer Inkompetenz in einem bestimmten Bereich ist der erste Schritt, um diese Lücke zu schließen und Hilfe von erfahreneren Kameraden zu erhalten.

Bonus : Der Artikel „Ein führender Programmierer sein“ hat mir sehr gut gefallen. Tolle Sache, wenn Sie sich zu welchem ​​Zeitpunkt fragen, was diese Arbeit bedeutet.