Hallo! Die Programmierung ist ein komplexes Thema, und die industrielle Softwareentwicklung ist sehr komplex. In unserer IT-Branche ist es nicht so selten, dass Nachwuchskollegen in der Reihe „Wie entwickle ich mich?“, „Was soll ich tun, um ein hochrangiger Fachmann und so schnell wie möglich zu werden?“, „Was soll ich tun, wenn ich mich nicht entwickeln kann, aber Es gibt keine interessanten Projekte? “,„ Was sollte die Mitte wissen? “. Wenn Sie über 0 bis 3 Jahre Erfahrung in der IT verfügen, sind Sie ein Anfängerspezialist (oder stehen kurz davor, einer zu werden) und setzen sich ähnliche Ziele für das berufliche und berufliche Wachstum. Sie suchen nach den richtigen Wegen, um diese Ziele zu erreichen - dieser Beitrag ist für Sie, gut beschweren sich unter Katze. Vielleicht ist er auch für Teamleiter und Manager im Allgemeinen von Interesse, für alle, die an der Ausbildung und Entwicklung von Spezialisten beteiligt sind.
Lassen Sie mich zunächst vorstellen. Mein Name ist Anatoly, und wenn ich die Beiträge und Ränge weglasse, bin ich zunächst einmal ein Entwickler, weil ich mich im weiteren Sinne des Wortes während meiner gesamten Karriere mit der Entwicklung, Forschung und Verwaltung von Entwicklern befasst habe. Meine Branchenerfahrung beträgt mehr als 10 Jahre. Es ist sehr vielfältig und reicht von Finanzsystemen und Websites bis hin zu Produkten, Algorithmen und maschinellen Lernsystemen. Die Hauptsache scheint mir jedoch zu sein, dass ich selbst an die Stelle der Zielleser dieses Artikels trat und mich anschließend mit verschiedenen Aspekten der Entwicklung junger Programmierer beschäftigte. Im Moment sind insgesamt mehr als 2 Dutzend Nachwuchsentwickler und Praktikanten durch mich gegangen. Deshalb glaube ich, dass ich etwas zu besprechen habe. Eine große Anzahl von Materialien zu dem zur Diskussion stehenden Thema, die zu finden sind, widmen sich entweder rein technischen Themen oder beispielsweise der fast blinden Verfolgung von Scrum. (wie - "Wenn Sie nicht wissen, was zu tun ist, versuchen Sie, an Scrum zu arbeiten, und alles wird verletzt" :)) Wie aus den Realitäten und Statistiken einzelner Teams und Spezialisten ist es weit entfernt von all den Dingen, die die Praxis und Kultur der Softwareentwicklung ausmachen. Als ich darüber nachdachte, worüber ich schreiben sollte, beschloss ich, diese Informationen nicht zu wiederholen, sondern mich auf Themen zu konzentrieren, über die nicht viel geschrieben oder gesprochen wird. Lass uns gehen!
Ja, als Haftungsausschluss möchte ich sagen, dass das Beschriebene meine persönliche Meinung ist, die durch Erfahrung und theoretisches Wissen bestätigt wird, die auf dieser Erfahrung getestet wurden. Es entspricht möglicherweise nicht der Realität, in der Sie sich befinden. Lassen Sie mich daher gleich den ersten Tipp des Artikels geben: In schwierigen Situationen lohnt es sich zunächst, das Design zu analysieren, bevor Sie die Ihnen bekannten Praktiken und Muster anwenden, z. dann. " Details sind sehr wichtig. Jetzt lass uns gehen! :) :)
1. Breite gegen enge Spezialisierung
Oft fragen sich Leute, die nur lernen wollen, wie man programmiert, welche Technologie sie für das Studium wählen sollen und in welcher Sprache sie grob gesagt sagen: "Es ist besser, Code zu schreiben." Menschen, die ihren ersten Job bekommen, überlegen, ob ihre aktuelle Technologie in ein paar Jahren und darüber hinaus vielversprechend und gefragt sein wird. (einige - sie denken überhaupt nicht, aber das ist meistens nicht gut) " Besser " und " vielversprechender " sind hier sehr subjektive Konzepte, die auf der Ebene der Gefühle und möglichen Vorteile für die weitere Karriere definiert werden. Schnell genug wird IT-Neulingen möglicherweise klar, dass viele Projekte mit einer ausreichend großen Anzahl von Technologien durchgeführt werden und es unmöglich ist, alles zu wissen. Ist es also notwendig, alle Hasen zu jagen?
In meinem ersten Arbeitsjahr erhielt ich beispielsweise von meinem Teamleiter eine wertvolle Bemerkung, dass es notwendig ist, sich auf einen bestimmten Bereich zu konzentrieren, da ein Spezialist entweder ein Spezialist für etwas oder grob gesagt kein Spezialist für irgendetwas ist. Um etwas auf einem ziemlich hohen Niveau zu wissen, müssen Sie dies ständig tun und tief in die Details eintauchen - reine Wahrheit und es ist schwer, damit zu streiten. In der Tat bestätigt die Praxis dies: Die meisten der mir bekannten Spezialisten (die als solche betrachtet werden können) sind enge Spezialisten. Einige von ihnen kennen ihr Thema einfach hervorragend und lösen daher die Probleme einer beispiellosen Steilheit darin. An dieser Stelle könnte man sagen "OK, das heißt, das Prinzip ist richtig - alles passt zusammen", wenn nicht für ein paar ABER. Tatsache ist, dass das Spektrum der Projekte, bei denen solche engen Spezialisten gefragt sein werden, viel enger ist als natürlich bei Spezialisten mit einem breiteren Profil. Mehr als einmal habe ich Projekte getroffen, bei denen eine Teilnahme ohne die Verfügbarkeit eines breiten Wissens in mehreren Technologien gleichzeitig unmöglich wäre. Menschen, die dieses Wissen besaßen, entdeckten neue, manchmal unzugängliche Türen. Die Teilnahme an einem hervorragenden, einzigartigen Projekt ist ein sehr ernsthafter und nützlicher Karrieretest, der Ihnen viele wertvolle Erfahrungen und andere Vorteile bringen kann. Das zweite ABER ist, dass sich die Welt der Technologie ständig verändert und sich streng auf das Wissen über eine oder zwei Technologien oder PL beschränkt. Sie können natürlich beginnen, Ihren Wettbewerbsvorteil zu verlieren und ein weniger gefragter Spezialist zu werden.
Kurz gesagt, wir können dies kurz sagen: Haben Sie keine Angst, die Technologien auszuprobieren, die Sie mögen! Sie werden vielleicht kein Experte in 3 Programmiersprachen gleichzeitig oder in 5 Frameworks, aber die Kenntnis ihrer Grundlagen und internen Struktur ist ein schwerwiegender Wettbewerbsvorteil, wenn Sie bei sonst gleichen Bedingungen einen Job erhalten, der gute Kenntnisse in 1 Technologie und Technologie erfordert Grund mehrere andere. Die Hauptsache hier ist Maß und Begrenzung. Es ist wichtig, klar zu priorisieren, welche Technologie Sie die meiste Zeit studieren und was noch übrig ist, um welche Technologie zu lernen.
2. Funktionsbereich
Von der Spezialisierung auf Programmiersprachen und Entwicklungstechnologien gehen wir reibungslos zum nächsten wichtigen Punkt über - dem Funktionsbereich . Es ist einfach, ein Beispiel aus dem Leben zu nennen: So wie Ärzte Zahnärzte haben und es Kardiologen gibt, gibt es auch eine Spezialisierung unter Entwicklern, und hier geht es nicht nur um die oben genannten Technologien oder Programmiersprachen. Entwickler sind auf verschiedene Arten spezialisiert: Jemand befasst sich mit Benutzeroberflächen, jemand verarbeitet Daten in Clustern, jemand erkennt Bilder und jemand schreibt Logik für einen Spielbot. Viele Beispiele.
Vielleicht werden Sie in den ersten zwei oder mehr Jahren Ihrer Arbeit nicht von der Frage der Spezialisierung gestört, da die Eingabe der Projekte und Technologien, mit denen Sie sich befassen, viel Zeit in Anspruch nimmt und diese Frage auf natürliche Weise einfach nicht relevant ist. Ab einem bestimmten Moment werden Sie jedoch die Leichtigkeit spüren, immer komplexere Probleme in einem bestimmten Bereich zu lösen, und das Ergebnis wird auf viele Arten bestimmt, nicht durch den Grad, in dem Sie beispielsweise im Detail die Standardbibliothek dieser Sprache kennen, mit der Sie arbeiten oder wie meisterhaft Sie die erweiterte Syntax dieses PL und Ihre Erfahrung in einem bestimmten Funktionsbereich besitzen. Computergrafik, Computerlinguistik, Finanzprogrammierung - all dies sind spezifische Bereiche für das Studium und das Sammeln praktischer Erfahrungen, die Monate und Jahre dauern. Wenn Sie sich zum Ziel gesetzt haben, ein hochrangiger Spezialist zu werden, finden Sie den Bereich, den Sie wirklich mögen. Und wenn es Ihnen wirklich gefällt - entwickeln und arbeiten Sie gerne daran, und alles wird klappen!
3. Mentoren und Selbststudium
Es gibt keine zwei völlig identischen Projekte. Es gibt keine identischen Teams. Manchmal gibt es keine einzige richtige Lösung, sei es eine globale Entscheidung über die Architektur eines großen Teils des Systems oder eine lokale Entscheidung darüber, wie Dateien im Repository gespeichert werden. Ein unerfahrener Spezialist steht vor vielen Fragen und Zweifeln. Fragen, die aufgrund mangelnder Erfahrung möglicherweise nicht sofort beantwortet werden. Sie haben einen vorgefertigten Code erhalten, der überhaupt nicht funktioniert, obwohl es anderen Kollegen gut geht. Der Service-Installationsvorgang endet in 1 von 6 Fällen mit einem Fehler - und bringt sich zumindest um, aber es ist nicht klar, warum; Sie können den Netzwerkteil des Dienstes nicht konfigurieren, obwohl Sie alles gemäß den Anweisungen ausführen und es bereits sieben Mal erneut lesen. Solche Situationen für Entwickler, Tester und Administratoren treten ständig auf. Der Schwierigkeitsgrad der Probleme kann von "wahrscheinlich müssen Sie irgendwo dort graben" bis zu "wo man gräbt - es ist überhaupt nicht klar" variieren. Der erste Ratschlag, den erfahrene Fachleute kennen und geben (und von dem Sie wahrscheinlich bereits gehört haben), ist, dass Sie lernen müssen, wie Sie mit Problemen so unabhängig wie möglich umgehen können, wenn Sie in ihnen stecken bleiben. Dazu muss man sich in der Regel auf einen Kausalzusammenhang konzentrieren und lernen, die richtigen Fragen zum Problem zu formulieren. Erstens für sich selbst und zweitens für Google. Es ist nicht nur "alles funktioniert nicht", auch wenn Sie sich sicher sind, versuchen Sie, "zum Anfang" zurückzukehren, um die wahre Ursache des Problems zu finden. Und höchstwahrscheinlich sind Sie nicht der einzige mit einem ähnlichen Problem. Google es einfach und überzeugen Sie sich selbst. Darüber hinaus die folgenden einfachen Ratschläge: Wenden Sie sich erst an ältere Kollegen, nachdem Sie mehrere erfolglose Versuche unternommen und das Problem selbst analysiert haben, nachdem Sie viel Zeit (normalerweise in Stunden, manchmal in Tagen gemessen) verbracht haben. Sie werden also nicht ihre wertvolle Zeit damit verbringen, ein Bullshit-Problem zu lösen, das Sie selbst mit viel Ausdauer leicht lösen könnten. Auf diese Weise zeigen Sie, dass Sie den richtigen Ansatz zur Lösung von Problemen entwickelt haben. Viele Probleme, die auf den ersten Blick kompliziert und unverständlich erscheinen, werden durch Googeln im wahrsten Sinne des Wortes von 5 Minuten gelöst.
Das Sprechen ist zwar einfach, aber in Wirklichkeit werden unzureichende Kenntnisse der Entwicklungstechnologien und mangelnde praktische Erfahrung ein sehr schmerzhafter Faktor sein. Die richtige Aufgabe Nummer 1 ist daher die Untersuchung von Entwicklungstechnologien und Beispiele für deren Verwendung in einem ziemlich intensiven Modus. Und noch einmal: Es ist leicht zu sagen, aber tatsächlich gibt es mehr Dofig-Schulungsmaterialien, nicht alle sind verständlich, nicht alle relevant, nicht alle decken Probleme ab, die in der Praxis des Projekts gelöst werden müssen. Und hier kann Ihnen die Umwelt helfen. In einem Team von „Experten“ zu sein, die nicht nur über ein hohes Maß an Wissen verfügen, sondern auch bereit sind, dieses Wissen gekonnt weiterzugeben - dies ist das Beste, was zu Beginn einer Karriere möglich ist. Ja, das stimmt, Sie sollten sich zunächst auf das Selbststudium konzentrieren, aber auf die eine oder andere Weise haben Sie eine natürliche Obergrenze für Geschwindigkeit. Kompetente Mentoren werden helfen, dies zu überwinden. Bevor Sie sich jedoch an sie wenden, stellen Sie sich die Frage: Sind Sie sicher festgefahren und können das Problem nicht mindestens einen Schritt unabhängig lösen?
Insgesamt: Suchen Sie nach einem Job, bei dem es Leute gibt, die das Thema kennen und daran interessiert sind, dass Sie es besser kennenlernen! Auf diese Weise können Sie Ihr Fachwissen in relativ kurzer Zeit erheblich verbessern. Vermeiden Sie Orte, an denen Sie überhaupt nicht bereit sind, Wissen zu teilen. 4 Jahre Arbeit an einem solchen Ort entsprechen zwei (oder weniger) an einem anderen Ort.
4. Es gibt keine Silberkugel
Die Arbeit in der IT-Branche ist ein ständiger Dialog, eine Debatte, manchmal ein Meinungskampf und manchmal ein Krieg der Prinzipien. Glauben Sie mir, Sie werden viele Leute treffen, die Sie davon überzeugen werden, dass sie und nur sie die richtigste Entscheidung oder Meinung haben und sie mit Fakten unterstützen oder nicht unterstützen. Manchmal platzt dich dieses Gefühl auch!
Ist es möglich oder unmöglich, die Aufgabe rechtzeitig zu erledigen? Was ist besser: Technologie A oder Technologie B für Aufgabe C? Nach welcher Methodik lohnt es sich, ein Projekt zu entwickeln und den Arbeitsprozess zu organisieren? Ist der geschriebene Code gut genug und ist es an der Zeit, ihn nicht mehr zu polieren, oder muss er noch überarbeitet werden? Nutzen Sie die Gelegenheit, das System von Anfang an zu erweitern, auch wenn keine Erweiterung erwartet wird, und Sie sehen nicht das ganze Bild von Ihrem Junior-Entwickler-Level? Wie bewertet man die Produktqualität und welche Rolle spielen Entwickler in diesem Prozess? Und ein Dutzend oder zwei verschiedene ähnliche Fragen.
Oft ist es unmöglich, diese und viele andere Fragen in einer bestimmten Situation eindeutig zu lösen. Ich hätte es gerne, aber manchmal ist es objektiv einfach nicht sichtbar, weil die Unsicherheit über das Projekt sehr hoch sein kann. In gewissem Sinne widerspricht dies einer unausgesprochenen Kultur, die in der Programmierung weithin akzeptiert wird: der ständigen Suche und dem Angebot besserer Lösungen unter Verwendung fortschrittlicherer Technologien. Wir zwingen uns ständig instinktiv, Entscheidungen auf der Grundlage unvollständiger Daten zu treffen.
Und hier hören die Programmierung in ihrem Mikrokosmos und die Entwicklung von IT-Projekten, die bereits in großem Maßstab stattfinden, auf, willkürlich genaue Disziplinen zu sein und beginnen, Kunst zu sein. Kunst baut auf Prinzipien und Ansätzen auf, sie wird von ihnen bestimmt.
Wenn Sie ein anderes Projekt oder eine weniger umfangreiche Aufgabe abschließen, schauen Sie zurück und analysieren Sie: Welche Prinzipien haben dazu beigetragen, dass diese Aufgabe oder dieses Projekt zum Erfolg geführt hat (oder umgekehrt - zafeylyat)? War es die Frage, welche Programmiersprache ausgewählt wurde und wie sie wunderbar funktionierte, oder war die Interaktion mit Ihrem Kunden oder Partner so gut, dass Sie die Aufgabe die meiste Zeit erledigen konnten, ohne Zeit zu verschwenden Kommunikationskosten? Analysieren Sie ständig, suchen Sie nach neuen Prinzipien und konsultieren Sie die Mentoren, wie Sie diese Prinzipien sehen und definieren können.
5. Über große und kleine Unternehmen, über IT und nicht über IT
Viele junge Berufstätige möchten für Unternehmen arbeiten, von denen sie gehört haben und deren Produkte oder Produkte sie verwendet haben. In einigen Apple, Google oder Microsoft (vor kurzem ist ein guter Begriff erschienen - "Guyandbuk") oder ihren russischen Kollegen (so viel wie möglich). Eine Karriere in einem großen Unternehmen zu beginnen, ist eine sehr, sehr wertvolle Erfahrung. (Sie verstehen das besonders im 11. Jahr dieser Erfahrung :)) Um zu sehen, wie ein großes Unternehmen von innen heraus arbeitet und wie Prozesse darin organisiert sind - glauben Sie mir, es lohnt sich. Wahrscheinlich fällt es mir schwer, mir zu Beginn meiner Karriere etwas Besseres vorzustellen als eine Gruppe großer IT-Unternehmen und ein intelligentes Team. Es gibt jedoch immer ABER.
Das erste ABER ist, dass ein "großes IT-Unternehmen" ganz anders ist als nur ein "großes Unternehmen" (insbesondere in der russischen Realität). Wenn Sie die Wahl haben, zu einem kleinen oder mittleren IT-Unternehmen oder zu einem großen Nicht-IT-Unternehmen (z. B. einer Bank oder einem anderen Finanz- oder Handelsunternehmen) zu gehen, sollten Sie die möglichen Konsequenzen verstehen. Und die Konsequenzen im schlimmsten Fall sind folgende: Wenn das IT-Unternehmen schließt oder Sie es verlassen möchten, verlassen Sie es mit Wissen und Grundsätzen. Wenn Sie nicht von einem IT-Unternehmen zu einem IT-Unternehmen wechseln möchten, wird dies aus mehreren Gründen schwieriger. Dies kann der Mangel an der notwendigen und relevanten Erfahrung und die Spezifität der Projekte sowie die Selektivität der Personalvermittler und Kollegen für Ihre früheren Arbeitsorte sein (erinnern Sie sich an die Firma Pearson Hardman aus der berühmten Serie, die nur von Harvard angeheuert wurde. Solche Geschichten sind nicht ungewöhnlich und in Wirklichkeit. Wir stellen nur ein von Lebensmittelunternehmen "usw.). In Unternehmen, in denen IT nicht die Hauptgeschäftsform ist, dreht sich buchstäblich alles um dieses Geschäft. Das Ergebnis ist sehr wichtig, der Prozess, um es zu erreichen, ist viel weniger wichtig. Aber es ist der richtige Prozess, der die richtigen Prinzipien festlegt, die Ihnen dann helfen, Entscheidungen zu treffen und etwas sehr Hochwertiges und Komplexes in der Ausgabe ziemlich komplizierter Projekte zu produzieren. Wenn Sie etwas von hoher Qualität und Nützlichkeit produzieren - dies ist Ihr Ziel, denken Sie daran.
6. Lebensmittel- und Outsourcing-Unternehmen
Eines meiner Lieblingsthemen, da ich im ersten und zweiten gearbeitet habe. In Fortsetzung des Themas Pickyness gibt es in der Branche eine gewisse Meinung, dass die Arbeit in Lebensmittel-IT-Unternehmen nicht nur prestigeträchtiger, sondern auch finanziell ist, und dies beinhaltet auch eine Reihe der interessantesten Projekte, die Sie finden können. Laut einigen Experten ist die Auslagerung von Auftragsprojekten eine Unterschicht. Ist das wahr oder nicht?
Ich werde antworten: Nein. Nicht so einfach.
Der Hauptvorteil von Lebensmittelunternehmen besteht darin, dass eine Person, die dorthin kommt, tatsächlich die Möglichkeit hat, ein Projekt / Produkt oder einen Tätigkeitsbereich auszuwählen, mit allen Konsequenzen, die sich daraus ergeben (zum Beispiel die Fähigkeit, an wirklich einzigartigen und komplexen Aufgaben zu arbeiten). Eine der Hauptfolgen: Sie entwickeln IHR Produkt und verbessern es jeden Tag. Es wird nicht immer einfach und so gehen, wie Sie es möchten, aber dies ist Ihr Produkt. Sie haben großen Einfluss auf seinen Erfolg, zumindest auf Ihrer Ebene.
In Outsourcing-Unternehmen hat ein Mitarbeiter in der Regel keine solche Wahl, und außerdem ist er aus diesem Grund regelmäßig gezwungen, auf Nadeln zu sitzen. Integratoren und Outsourcer sind an solchen Projekten beteiligt, für die sie hier und jetzt Geld bezahlen. Nicht alle derartigen Projekte werden für eine bestimmte Klasse von Programmierern interessant sein. Für einen Mitarbeiter eines Outsourcing-Unternehmens besteht immer die Gefahr, dass er sich in einem absolut uninteressanten und stagnierenden Projekt befindet. Oft besteht die einzige Möglichkeit, das Projekt zu ändern, darin, das Unternehmen zu verlassen.
— legacy ( ), . — . 5 . , , , .
7. vs
. : . , . , , . , – . , ( ) , . , , , . , . , , () () . . ? – . – . , , 2 : ) ) ( ). : , . , . , , , , , . – .
: - ( - ) , - . - , ( — , ) – .
8.
. , , - . - , . , , , . . . , . , . — . .
— , , , , . , , , , ( ), : , — , , .
? , ? .
, ? : , , , , , , , .
9.
(, ) , backend . (, Web , ). - . , ? , . , . , — . — . , . : , , . . , . , , . . , : , , UX/UI — , , , , .
10.
: . . - : , .
, , . : 1.5-2 . , , , , . . , 1-2 , - . — 4 , ? : , B. , . , , . , . , , — , , . , , , , .
: 1-3 , , . : skills 3 — 1. , — 2. — 3. , , , , 4 , , .
Fazit
— , , . , . , , — . . , , ! , : ) hard skills ) c ) . , !
PS: . , , , .