Salut La programmation est un sujet complexe et le développement de logiciels industriels est très complexe. Dans notre industrie informatique, il n'est pas si rare d'entendre des questions de collègues juniors dans la série "Comment puis-je développer?", "Que dois-je faire pour devenir un professionnel de haut niveau et le plus rapidement possible?", "Que dois-je faire si je ne peux pas développer, mais il n'y a pas de projets intéressants? »,« que doit savoir le milieu? ». Si vous avez de 0 à 3 ans d'expérience en informatique, vous êtes un spécialiste débutant (ou sur le point de le devenir) et fixez des objectifs similaires pour la croissance professionnelle et professionnelle, recherchez les bonnes façons d'atteindre ces objectifs - ce poste est pour vous, bon se plaindre sous le chat. Peut-être intéressera-t-il également les chefs d'équipe et les managers, en général, tous ceux impliqués dans la formation et le développement des spécialistes.
Pour commencer, permettez-moi de me présenter. Je m'appelle Anatoly, et si j'oublie les postes et les rangs, je suis tout d'abord développeur, car au sens large du terme j'ai été engagé dans le développement, la recherche et la gestion de développeurs tout au long de ma carrière. Mon expérience dans l'industrie est de plus de 10 ans. Il est assez diversifié et s'étend des systèmes financiers et des sites Web aux produits, aux algorithmes et aux systèmes d'apprentissage automatique. L'essentiel, cependant, il me semble, c'est que j'étais moi-même à la place des lecteurs cibles de cet article et que j'ai ensuite commencé à m'engager dans divers aspects du développement des jeunes programmeurs. À l'heure actuelle, plus de 2 douzaines de développeurs et stagiaires juniors sont passés par moi. Par conséquent, je crois que j'ai quelque chose à dire. Un grand nombre de documents sur la question en discussion qui peuvent être trouvés sont consacrés soit à des sujets purement techniques, soit, par exemple, à suivre presque aveuglément Scrum. (comme - "si vous ne savez pas quoi faire, essayez de travailler sur la mêlée et tout se fera mal" :)) Comme si d'après les réalités et les statistiques des équipes individuelles et des spécialistes, c'est loin de tout ce qui fait la pratique et la culture du développement logiciel. Par conséquent, réfléchissant à quoi écrire, j'ai décidé de ne pas répéter ces informations, mais plutôt d'essayer de me concentrer sur des sujets sur lesquels peu de choses sont écrites ou discutées. C'est parti!
Oui, à titre d' exclusion de responsabilité , je voudrais dire que ce qui est décrit est mon opinion personnelle, confirmée par l'expérience et les connaissances théoriques, qui ont été testées sur cette expérience. Il peut ne pas correspondre à la réalité dans laquelle vous vous trouvez, alors laissez-moi vous donner tout de suite la première astuce de l'article: tout d'abord, dans toutes les situations difficiles, il convient d'analyser sa conception avant d'appliquer les pratiques et les schémas connus comme «si, alors. " Les détails sont très importants. Maintenant c'est parti! :)
1. Spécialisation large vs étroite
Souvent, les gens qui veulent simplement apprendre à programmer se demandent quelle technologie choisir pour étudier et, en fait, dans quelle langue, en gros, "il vaut mieux écrire du code". Les personnes qui obtiennent leur premier emploi se demandent si leur technologie actuelle sera prometteuse et en demande dans quelques années et au-delà. (certains - ils ne pensent pas du tout, mais ce n'est souvent pas bon) " Mieux " et "plus prometteur " sont des concepts très subjectifs, définis au niveau des sentiments et des bénéfices possibles pour une future carrière. Assez rapidement, il peut devenir clair pour les nouveaux arrivants en informatique que de nombreux projets sont réalisés sur un nombre suffisamment important de technologies, et il est impossible de tout savoir. Est-il donc nécessaire de chasser tous les lièvres?
Par exemple, au cours de ma première année de travail, j'ai reçu un précieux commentaire de la part de mon chef d'équipe selon lequel il est nécessaire de se concentrer sur un domaine particulier, car un spécialiste est soit un spécialiste de quelque chose ou, grosso modo, pas un spécialiste de quoi que ce soit. Pour connaître quelque chose à un niveau assez élevé, vous devez le faire constamment et profondément dans les détails - pure vérité et il est difficile de contester cela. En effet, la pratique le confirme: la plupart des spécialistes que je connais (qui peuvent être considérés comme tels) sont des spécialistes étroits. Certains d'entre eux connaissent simplement avec brio leur Sujet et résolvent donc les problèmes de raideur sans précédent en son sein. À ce stade, on pourrait dire «OK, cela signifie que le principe est correct - tout va de pair», si ce n'est pour quelques MAIS. Le fait est que l' éventail des projets où de tels spécialistes étroits seront demandés est beaucoup plus restreint que, bien sûr, parmi les spécialistes de profil plus large. Plus d'une fois, j'ai rencontré des projets dans lesquels la participation serait tout simplement impossible sans la disponibilité de vastes connaissances dans plusieurs technologies à la fois. Les personnes qui possédaient ces connaissances ont découvert de nouvelles portes, parfois inaccessibles. Et la participation à un excellent projet unique est un test de carrière très sérieux et utile qui peut vous apporter beaucoup d'expérience précieuse et d'autres avantages. Le deuxième MAIS est que le monde de la technologie est en constante évolution et se limite strictement à la connaissance d'une ou deux technologies ou PL, vous pouvez naturellement commencer à perdre votre avantage concurrentiel et devenir un spécialiste moins recherché.
Bref, on peut le dire brièvement: n'ayez pas peur d'essayer les technologies que vous aimez! Vous ne pouvez pas devenir un expert dans 3 langages de programmation à la fois, ou dans 5 cadres, mais la connaissance de leurs fondamentaux et de leur structure interne est un sérieux avantage concurrentiel, si, toutes choses étant égales par ailleurs, vous obtenez un emploi qui nécessite une solide connaissance de 1 technologie et basique plusieurs autres. L'essentiel ici est la mesure et la limitation. Il est important de hiérarchiser clairement la technologie que vous passez le plus de temps à étudier et ce qui reste pour apprendre quelle technologie.
2. Domaine fonctionnel
De la spécialisation dans les langages de programmation et les technologies de développement, nous passons en douceur à la prochaine chose importante - le domaine fonctionnel . Il est facile de donner un exemple de la vie: tout comme les médecins ont des dentistes et il y a des cardiologues, il y a donc une spécialisation parmi les développeurs, et il ne s'agit pas seulement des technologies ou des langages de programmation mentionnés ci-dessus. Les développeurs se spécialisent de différentes manières: quelqu'un s'occupe des interfaces utilisateur, quelqu'un traite les données sur les clusters, quelqu'un reconnaît les images et quelqu'un écrit la logique d'un bot de jeu. Beaucoup d'exemples.
Peut-être qu'au cours des 2 premières années de travail, ou même plus, vous ne serez pas dérangé par la question de la spécialisation, car entrer dans les projets et les technologies dans lesquels vous entrez prendra beaucoup de temps, et cette question ne sera tout simplement pas pertinente de manière naturelle. Cependant, à partir d'un certain moment, vous sentirez la facilité à résoudre des problèmes de plus en plus complexes dans un certain domaine, et le résultat sera déterminé à bien des égards pas par le degré de détail, par exemple, que vous connaissez la bibliothèque standard de cette langue avec laquelle vous travaillez, ou à quel point vous possédez magistralement la syntaxe avancée de ce PL, et votre expérience dans un domaine fonctionnel spécifique. Infographie, linguistique informatique, programmation financière - tous ces domaines sont spécifiques à l'étude et à l'acquisition d'une expérience pratique au cours des mois et des années. Si vous vous fixez comme objectif de devenir un spécialiste de haut niveau, trouvez le domaine que vous aimez vraiment. Et si vous l'aimez vraiment - développez et travaillez avec plaisir, et tout ira bien!
3. Mentors et auto-apprentissage
Il n'y a pas deux projets complètement identiques. Il n'y a pas d'équipes identiques. Parfois, il n'y a pas de solution unique, que ce soit une décision globale sur l'architecture d'une grande partie du système ou une décision locale sur la façon de stocker des fichiers dans le référentiel. Un spécialiste novice fait face à de nombreuses questions et doutes. Questions auxquelles, faute d'expérience, il se peut que l'on ne réponde pas immédiatement. Vous avez un code prêt à l'emploi et cela ne fonctionne pas du tout, même si d'autres collègues vont bien; la procédure d'installation du service dans 1 cas sur 6 se termine par une erreur - et au moins tuez-vous, mais on ne sait pas pourquoi; vous ne pouvez pas configurer la partie réseau du service, bien que vous fassiez tout selon les instructions et que vous l'ayez relu 7 fois déjà. De telles situations pour les développeurs, les testeurs et les administrateurs se produisent constamment. Le degré de difficulté des problèmes peut varier du niveau de "probablement vous devez creuser quelque part là-bas" à "où creuser - ce n'est pas du tout clair." Le premier conseil bien connu et donné par des professionnels expérimentés (et vous en avez probablement déjà entendu parler) est que vous devez apprendre à gérer les problèmes de la manière la plus indépendante possible lorsque vous êtes coincé. En règle générale, pour cela, il est nécessaire de se concentrer sur une relation causale et d'apprendre à formuler les bonnes questions sur le problème. Tout d'abord, à lui-même et, deuxièmement, à Google. Ce n'est pas seulement «tout ne fonctionne pas», même si vous en êtes sûr, essayez de revenir «au début» pour trouver la véritable cause du problème. Et, très probablement, vous n'êtes pas le seul à avoir un problème similaire, recherchez-le sur Google et voyez par vous-même. De plus, le conseil simple suivant: seulement après avoir fait plusieurs tentatives infructueuses et analysé le problème vous-même, après avoir passé un temps important (généralement mesuré en heures, parfois en jours), contactez des collègues seniors. Vous ne passerez donc pas leur temps précieux à résoudre un problème de conneries, que vous pourriez facilement résoudre vous-même en utilisant beaucoup de persévérance. De cette façon, vous montrerez que vous avez développé la bonne approche pour résoudre les problèmes. De nombreux problèmes qui semblent compliqués et incompréhensibles à première vue sont résolus par la recherche sur Google au sens littéral de 5 minutes.
Mais parler est facile, mais en réalité une connaissance insuffisante des technologies de développement et un manque d'expérience pratique seront un facteur très douloureux. Par conséquent, la tâche numéro 1 correcte est l'étude des technologies de développement et des exemples de leur utilisation dans un mode assez intensif. Et encore une fois: c'est facile à dire, mais en fait il y a plus de matériel de formation Dofig, tous ne sont pas compréhensibles, pas tous pertinents, ils ne couvrent pas tous les problèmes qui devront être résolus dans la pratique sur le projet. Et ici, l' environnement peut vous aider. Faire partie d'une équipe d '«experts» qui non seulement possèdent un haut niveau de connaissances, mais sont également disposés à partager habilement ces connaissances - c'est le meilleur qui puisse être au début d'une carrière. Oui, c'est vrai, vous devez d'abord vous concentrer sur l'auto-apprentissage, mais d'une manière ou d'une autre, vous aurez un plafond naturel pour la vitesse. Des mentors compétents aideront à le surmonter. Cependant, avant de vous tourner vers eux, posez-vous la question: êtes-vous sûrement coincé et ne pouvez pas avancer de manière indépendante dans la résolution du problème au moins une étape?
Total: cherchez un emploi où il y a des gens qui connaissent le sujet et qui souhaitent vous faire mieux connaître! Cela vous permettra d'augmenter considérablement le niveau de votre expertise en un temps assez court. Évitez les endroits où vous n'êtes pas du tout prêt à partager vos connaissances. 4 ans de travail dans un tel lieu équivaudront à deux (ou moins) dans un autre.
4. Il n'y a pas de solution miracle
Le travail dans l'industrie informatique est un dialogue constant, un débat, parfois une lutte d'opinions, et parfois une guerre de principes. Croyez-moi, vous rencontrerez beaucoup de gens qui vous convaincront qu'eux seuls ont la décision ou l'opinion la plus correcte, qu'ils la soutiennent ou non par des faits. Parfois, ce sentiment vous éclatera aussi!
Est-il possible ou impossible de terminer la tâche à temps? Quelle est la meilleure: la technologie A ou la technologie B pour la tâche C? Selon quelle méthodologie vaut-il la peine de développer un projet et d'organiser le processus de travail? Le code écrit est-il assez bon et est-il temps d'arrêter de le polir, ou a-t-il encore besoin d'être refactoré? Saisissez-vous l'opportunité d'étendre le système dès le début, même si vous ne vous attendez pas à une expansion, et vous ne voyez pas l'image complète de votre niveau de développeur junior? Comment évaluer la qualité du produit et quel rôle les développeurs ont-ils dans ce processus? Et une douzaine ou deux questions similaires différentes.
Souvent, il est impossible de donner une solution sans ambiguïté à ces questions et à bien d'autres dans une situation spécifique. J'aimerais bien l'avoir, mais parfois ce n'est tout simplement pas visible objectivement, car le niveau d'incertitude sur le projet peut être assez élevé. Dans un sens, cela va à l'encontre d'une culture tacite largement acceptée dans la programmation: la recherche constante et l'offre de meilleures solutions utilisant des technologies plus avancées. Nous nous forçons constamment et instinctivement à prendre des décisions basées sur des données incomplètes.
Et ici, la programmation dans son microcosme et le développement de projets informatiques déjà à grande échelle cessent d'être des disciplines arbitrairement précises et commencent à être de l'art. L'art est construit sur des principes et des approches, il est déterminé par eux.
Lorsque vous terminez un autre projet ou une tâche moins massive, regardez en arrière et analysez: quels principes ont aidé cette tâche ou ce projet à réussir (ou vice versa - zafeylyat)? Était-ce la question de savoir quel langage de programmation a été choisi et comment il fonctionnait à merveille, ou peut-être que le niveau d'interaction avec votre client ou partenaire était si bon que vous pouviez gérer la tâche la plupart du temps sans perdre de temps les frais de communication? Analysez constamment, recherchez de nouveaux principes et consultez les mentors pour voir et définir ces principes.
5. Sur les grandes et petites entreprises, sur l'informatique et non l'informatique
De nombreux jeunes professionnels souhaitent travailler pour des entreprises dont ils ont entendu parler et dont ils ont utilisé les produits ou les produits. Dans certains Apple, Google ou Microsoft (récemment un bon terme est apparu - "Guyandbuk") ou leurs homologues russes (autant que possible). Commencer une carrière dans une grande entreprise est une expérience très, très précieuse. (Vous comprenez cela en particulier au cours de la 11e année de cette expérience :)) Pour voir comment une grande entreprise fonctionne de l'intérieur et comment les processus y sont organisés - croyez-moi, ça vaut le coup. Il est probablement difficile pour moi d'imaginer quelque chose de mieux qu'un ensemble d'une grande entreprise informatique et d'une équipe intelligente au début de ma carrière. Cependant, il y en a toujours MAIS.
Le premier MAIS est qu'une "grande entreprise informatique" est très différente d'une simple "grande entreprise" (en particulier dans les réalités russes). Si vous avez le choix, rendez-vous dans une petite ou moyenne entreprise informatique ou dans une grande entreprise non informatique (par exemple, une banque ou une autre société financière ou commerciale), vous devez comprendre les conséquences possibles. Et les conséquences dans le pire des cas seront les suivantes: si la société informatique ferme ou si vous voulez la quitter, vous partez avec des connaissances et des principes. Si vous ne souhaitez pas quitter une entreprise informatique pour une entreprise informatique, cela rendra la tâche plus difficile pour un certain nombre de raisons. Cela peut être le manque d'expérience nécessaire et pertinente, et la spécificité des projets et la préparation des recruteurs et des collègues d'embauche pour vos emplois passés (rappelez-vous le cabinet Pearson Hardman d'une célèbre série qui n'a embauché que de Harvard. De telles histoires ne sont pas rares et en réalité. Type "nous n'engageons que des entreprises alimentaires ", etc.). Dans les entreprises où l'informatique n'est pas le principal type d'activité, tout tourne littéralement autour de cette activité. Le résultat est très important, le processus pour y parvenir l'est beaucoup moins. Mais c'est le bon processus qui établit les principes corrects, qui vous aident ensuite à prendre des décisions et à produire quelque chose de très haute qualité et complexe dans la sortie de projets plutôt compliqués. Si vous produisez quelque chose de haute qualité et utile - c'est votre objectif, pensez-y.
6. Entreprises d'alimentation et d'externalisation
Un de mes sujets préférés, puisque j'ai travaillé dans le premier et le deuxième. Poursuivant le sujet de la sélection, il existe une certaine opinion dans l'industrie selon laquelle travailler dans des entreprises informatiques alimentaires est non seulement plus prestigieux, mais aussi financier, et cela s'accompagne également d'un ensemble de projets les plus intéressants que vous pouvez trouver. Selon certains experts, l'externalisation des travaux sur des projets est une classe inférieure. Est-ce vrai ou non?
Je répondrai: non. Pas si simple.
Le principal avantage des entreprises agroalimentaires est qu'une personne qui y vient a en fait la possibilité de choisir un projet / produit ou un domaine d'activité, avec toutes les conséquences qui en découlent (par exemple, la capacité à travailler sur des tâches vraiment uniques et complexes). L'une des principales conséquences: vous développerez VOTRE produit, le rendant meilleur au quotidien. Cela ne se fera pas toujours simplement et comme vous le souhaitez, mais c'est votre produit. Vous influencez grandement son succès, au moins à votre niveau.
Dans les sociétés d'externalisation, en règle générale, un employé n'a pas un tel choix et, de plus, il est périodiquement obligé de s'asseoir sur des aiguilles pour cette raison. Les intégrateurs et les sous-traitants sont engagés dans les projets pour lesquels ils paient de l'argent ici et maintenant. Tous ces projets ne seront pas intéressants pour une certaine classe de programmeurs. Pour un employé d'une entreprise d'externalisation, il y a toujours un risque d'être sur un projet absolument inintéressant et stagnant, et, souvent, la seule façon de changer le projet est de quitter l'entreprise.
— 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 , , .
Conclusion
— , , . , . , , — . . , , ! , : ) hard skills ) c ) . , !
PS: L'auteur se fera un plaisir de critiquer et de faire des retours sur l'article dans les commentaires et hp. Surtout si vous avez aimé l'article et son sujet, écrivez sur les sujets connexes que vous souhaitez lire dans les articles suivants.