La dixième année viendra bientôt, car je suis professionnellement engagée dans la programmation. Dix ans! Et en plus du travail formel, près des deux tiers de ma vie, j'ai créé quelque chose sur Internet. Je me souviens à peine des années où je ne connaissais pas le HTML: c'est même étrange si on y pense. Certains enfants étudient la musique ou le ballet, et au lieu de cela j'ai créé des mondes magiques, en codant dans ma crèche.

En pensant à cette première décennie de recevoir régulièrement de l'argent pour entrer des personnages étranges dans le terminal, je voudrais partager quelques observations sur la façon dont ma pensée a changé au fil des années de travail .

Peut-être que les juniors actuels trouveront ici certaines de leurs croyances et les regarderont de l'autre côté. Ou ils se rendent compte qu'ils se sont déjà débarrassés de cela, alors ils sont allés beaucoup plus loin que moi à votre stade.

Les aînés actuels peuvent également vouloir partager des histoires drôles (et légèrement humiliantes) sur les leçons tirées de leur expérience junior.

Pour plus de clarté, j'insiste sur le fait que les juniors sont incroyables : juste apparaître au travail pour apprendre de nouvelles choses - cela demande déjà beaucoup de courage. Cet article concerne ma propre expérience et ma formation. Je ne généralise pas du tout que tous les développeurs juniors pensent ou se comportent de cette façon.

J'espère que vous apprécierez le message et vous rappellerez quelque chose du passé ou du présent.

Merci à Artyom et Sarah pour leurs commentaires!

Vérités absolues du junior dont il fallait désapprendre

1. Je suis développeur senior

Quand j'ai essayé pour la première fois de trouver un emploi, j'avais 19 ans. Le travail a été appelé un «webmaster étudiant». C'est un nom assez surprenant pour le travail, car vous êtes considéré à la fois comme «étudiant» et «maître» à la fois. De nos jours, tout le monde veut être «ingénieurs», car cela semble plus à la mode, mais pour moi, «maître» est un meilleur mot pour ce métier. Dans tous les cas, mon travail consistait à écrire PHP et MySQL et à maintenir notre site en Drupal, ainsi qu'à créer des outils internes.

Depuis avant que je codais depuis plusieurs années dans ma chambre, j'étais sûr que ces années comptaient comme des «années d'expérience». Par conséquent, lorsqu'on m'a demandé combien d'expérience j'avais écrit en PHP, j'ai répondu en toute confiance: "3 ou 4 ans!"

Je pensais en savoir beaucoup sur SQL car je peux faire des jointures externes (jointures externes).

Et quand j'ai googlé, j'ai découvert que trois à quatre ans d'expérience signifiaient beaucoup d'argent.

Passons à mon dernier travail, que j'ai obtenu après cinq ans d'expérience «combinée» étudiante et professionnelle (que je considérais comme une expérience normale). À cette époque, mon code n'a presque jamais fait l'objet d'une révision de code. J'ai couru ssh sur le serveur et j'ai fait git pull. Je suis sûr que je n'ai jamais vu une seule demande de tirage. Ne vous méprenez pas, dans les deux premiers travaux, j'ai appris beaucoup de choses incroyables, je n'ai jamais travaillé avec d'autres développeurs dans la même base de code. Néanmoins, j'ai postulé pour le poste d '«ingénieur front-end senior», j'ai reçu une offre et l'ai acceptée.

Je suis donc devenu développeur senior à l'âge de 24 ans.

Après tout, ils ne me donneraient pas ce poste si je n'étais vraiment pas développeur senior, non?! Bien sûr, mon expérience impressionnante m'a conduit à ce sommet, donc les gens devraient m'écouter !!! Je suis au sommet de ma carrière technique, alors que je suis le plus jeune au bureau.

Comme un patron.

Qu'est-ce que j'ai finalement compris

Toute expérience n'est pas la même . Mon expérience de codage dans la chambre, le travail d'un étudiant programmeur est différent de la recherche scientifique en informatique et du travail dans une startup en pleine croissance. C'est une expérience différente. Pour une année de travail en support technique en début de carrière, vous pouvez apprendre dix fois plus de cinq ans en projets individuels (ou avec un minimum de feedback). Si votre code n'est jamais consulté par vos collègues, la formation est beaucoup plus lente.

C'est pourquoi les mentors sont si importants , et votre équipe est beaucoup plus importante que la différence de quelques dollars de salaire. Ne vous contentez pas d'un poste junior où vous travaillerez seul! Et ne choisissez pas votre premier emploi (ou, franchement, n'importe quel emploi) uniquement sur une base salariale. L'équipe est là où se trouve la vraie valeur.

J'ai également appris que les titres d'emploi ne signifient rien en soi. Le poste de CTO peut être dans une équipe de 5 personnes, 50 ou 500 personnes. C'est un travail complètement différent, bien que le nom soit identique. Donc mon titre de "senior" ne fait pas du tout de moi un programmeur de premier plan. De plus, les titres hiérarchiques sont intrinsèquement imparfaits et difficiles à comparer. J'ai réalisé qu'il était important de ne pas rester coincé dans les noms et que vous ne devriez pas les utiliser comme une sorte de vérification externe.

2. Tout le monde écrit des tests

La première moitié de ma carrière, j'ai travaillé dans le domaine de la recherche. En particulier, trois ans et demi sur un projet financé par l'Etat, puis un an et demi à l'université dans le département de traitement du langage naturel. Je peux dire une chose: la programmation dans l'environnement scientifique est complètement différente de la programmation dans l'industrie commerciale .

Pour la plupart, vous ne créez pas d'applications. Vous travaillez sur des algorithmes ou analysez des ensembles de données. Alternativement, si vous créez une application, le travail est probablement financé par l'État. Cela signifie qu'il est gratuit pour les autres et généralement open source. Et quand quelque chose est gratuit, cela signifie que vous n'êtes généralement pas responsable de vous assurer qu'il est toujours disponible.

Parce que ... eh bien, c'est gratuit.

Vous n'êtes pas non plus responsable des revenus financiers ou des résultats spécifiques. Cependant, le travail d'un programmeur dans une institution scientifique fait l'objet d'un article complètement différent.

Bref, j'ai quitté l'institut avec de grandes attentes.

Attentes sur le fonctionnement de l'industrie. Déploiements automatiques. Tirez les demandes et les revues de code. Ce sera génial! Enfin, la qualité du code dont je rêvais! Mais à part un code de haute qualité avec les normes et les meilleures pratiques appropriées , je croyais fermement que dans l'industrie du logiciel, tout le monde écrit des tests .

Hm ...

Imaginez donc ma surprise lorsque le premier jour ouvrable de la startup, je n'ai trouvé aucun test. Aucun test dans l'interface. Aucun test dans le backend. Pas de tests du tout.

Sda. Rien. Zéro NaN. Les tests manquent en tant que phénomène.

Non seulement il n'y avait pas de tests , mais personne ne semblait avoir de problèmes à cause de cela! Avec une certaine naïveté, j'ai suggéré que la raison en était que les gens ne savaient tout simplement pas comment écrire des tests pour AngularJS. Si je leur enseigne, tout ira bien - et nous commencerons à effectuer des tests. Erreur! En général, seulement quelques années plus tard, nous avons implémenté des tests automatisés dans le code, et ce n'était pas aussi facile que je le pensais.

Mais pas parce que les gens ne savent pas les écrire.

Soit ils n'ont jamais rencontré de problèmes en raison du manque de tests, soit ils ont rencontré des problèmes en raison de la présence d' anciens tests. Deux choses que je n'ai jamais rencontrées.

Qu'est-ce que j'ai finalement compris

De nombreuses entreprises et startups n'ont pratiquement aucun test . Lorsqu'elles se battent pour le marché ou pour la survie, de nombreuses entreprises négligent les tests dès les premiers stades. Même les entreprises à la mode qui parrainent des conférences ou des logiciels libres font souvent un gros monolithe maladroit avec des tests minimaux. Il suffit de demander aux développeurs l'état de la base de code.

Aucune entreprise n'a une installation technique idéale . Chaque entreprise a des problèmes, chacune a une dette technique. La question est de savoir ce qu'ils en font. Lorsque vous postulez pour un emploi, vous devez comprendre clairement que tout n'est pas en ordre là-bas, sinon ils n'auraient pas ouvert un poste vacant.

Être trop confiant dans des sujets sur lesquels vous manquez d'expérience réelle est plutôt arrogant . J'ai agi TELLEMENT en tant que je-sais-tout, en insistant sur la mise en œuvre généralisée des tests, avec presque aucune expérience sur la façon de vraiment mettre en œuvre cela à grande échelle. Ne répétez pas mes erreurs. Il est important d'avoir des principes, mais il est toujours important d'être ouvert et vraiment intéressé afin de percevoir l'expérience et les points de vue des autres.

3. Nous sommes tellement derrière le reste (aka la version technique du syndrome du manque à gagner )

Ceci est étroitement lié au sujet des tests unitaires. Mon entreprise n'a pas effectué de tests, mais, bien sûr, toutes les autres entreprises l'ont fait, non?

J'ai lu un tas de billets de blog. J'ai regardé beaucoup de discours de conférence sur YouTube. Merde, je lis tout le temps «ce site orange» [se référant probablement à Hacker News - env. trans.]. Tout le monde semble écrire des applications super sophistiquées et de haute qualité avec de grandes performances et des animations à la mode, tandis que je fais juste des correctifs pour rattraper le retard.

J'ai littéralement idolâtré toutes les autres entreprises sur lesquelles j'ai lu, et j'ai été déçu par le retard de mon entreprise et du projet.

Qu'est-ce que j'ai finalement compris

De nombreuses présentations de conférence couvrent la preuve de concept, plutôt que des scénarios réels . Une simple histoire lors d'une conférence sur une technologie ne signifie pas que l'entreprise utilise cette technologie dans son travail quotidien ou que tout son code est en parfait état. Les conférenciers présentent souvent des applications jouets plutôt que des applications réelles: il est important de les distinguer.

Travailler avec Legacy est tout à fait normal . Non, sérieusement, il est facile d'imaginer qu'une autre entreprise n'a pas d'héritage. Mais après avoir passé du temps lors de conférences, discuté avec des personnes travaillant dans les meilleures entreprises, il devient clair que nous sommes tous dans le même bateau. Essayez de trouver une entreprise qui N'A PAS un énorme monolithe en PHP ou Ruby qu'ils essaient d'apprivoiser (ou auraient dû apprivoiser à un moment donné)? Le code hérité est courant et son utilisation vous apprend souvent plus que la création d’applications à partir de zéro, car vous travaillez davantage avec des concepts que vous ne comprenez toujours pas.

4. La qualité du code est très importante.

Dans le passé, je pouvais faire une revue de code très difficile .

Au moins, j'étais très pointilleux sur le style. Mon style s'est avéré être une version modifiée du style de guide de style JavaScript Airbnb, mais il correspond à mes goûts personnels. Des choses comme l'indentation, le formatage, le nommage - Dieu ne plaise, vous le ferez différemment. Il était complètement impossible de passer en revue le code sans un seul commentaire de ma part: il faudrait apprendre les compétences de lecture des pensées et, en plus, gagner à la loterie.

Soumettez plus de 50 commentaires à votre demande de tirage qui répertorie tous les points-virgules que vous avez manqués!

Parce que j'ai des yeux comme un aigle - et cet aigle veut obtenir tous ses points-virgules de haute qualité!

(Heureusement, après de nombreuses années de travail à l'ordinateur, la vision comme celle d'un aigle a disparu, alors maintenant vous n'avez plus rien à craindre - # blagues amusantes)

Qu'est-ce que j'ai finalement compris

Assez bien - ça suffit . À l'approche du code idéal, la loi des rendements décroissants s'applique. Le code ne doit pas être parfait, mais suffisamment propre pour fonctionner et pas une catastrophe complète pour le support. Souvent, un code trop répétitif ou trop verbeux est plus facile à comprendre pour les autres. De plus, «bon code» n'est pas la même chose que «code qui ressemble à ce que j'ai écrit moi-même».

L'architecture est plus importante que la piqûre . Bien qu'une certaine ligne puisse être améliorée, mais les principaux problèmes sont l'ordre architectural. Il vaut mieux se concentrer immédiatement sur la structure de l'application plutôt que sur de minuscules morceaux de code individuels.

La qualité du code est importante , ne vous méprenez pas. Mais la qualité du code n'est pas ce que je pensais. Ce n'est pas le peluchage, la mise en forme ou tout autre style décrit dans le dernier article que j'ai lu.

5. Tout doit être documenté !!!

Quand je suis arrivé dans ma première vraie entreprise, pour la première fois je me suis heurté pour la première fois à un code étrange. Bien sûr, j'ai travaillé un peu avec le code de quelqu'un d'autre au premier emploi, mais je n'ai jamais eu à aller dans la base de code existante et à découvrir ce qui se passait. La seule fois où cela s'est produit, j'ai réécrit tout le code, au lieu d'essayer de comprendre comment cela fonctionne.

En tout cas, le fait que ce soit du code AngularJS écrit par les développeurs Ruby n'a pas du tout aidé la situation, et j'étais un junior qui s'imaginait être un senior.

Alors, comment ai-je géré le fait que 300 lignes de code inconnu m'ont donné l'impression de me noyer?

JSDOC. PARTOUT.

J'ai commencé à tout commenter pour essayer de donner un sens. Annotations pour chaque fonctionnalité à laquelle j'ai pu accéder.

J'ai appris toute cette syntaxe JSDoc spécifique à Angular. Mon code était toujours deux fois plus long car il avait tellement de documentation et de commentaires.

Qu'est-ce que j'ai finalement compris

La documentation ment parfois . Il est facile de penser que la documentation résout tous les problèmes. "Nous avons besoin de quais!" Bien que la documentation soit un travail difficile, elle doit être effectuée. Il vous suffit de documenter les bonnes choses de la bonne manière. Une documentation excessive de choses inutiles, en règle générale, empêche les gens qui essaient de résoudre un problème réel.

Le cas échéant, concentrez-vous sur l'automatisation plutôt que sur la documentation . Les tests ou autres formes d'automatisation sont moins susceptibles de perdre de leur pertinence. Par conséquent, j'essaie de me concentrer sur l'écriture de bons tests avec un langage clair afin que les autres développeurs puissent voir comment le projet fonctionne avec du code de travail. Un autre exemple est l'automatisation de l'installation d'une application avec quelques commentaires, plutôt qu'un guide d'installation long et détaillé.

6. La dette technique est mauvaise

Si après le dernier point vous me considérez comme un névrosé, lisez celui-ci! Pendant un certain temps dans ma carrière, j'ai considéré tout code sale comme un devoir technique . La dette technique est un terme amusant parce que si vous demandez un exemple, ils disent des choses très différentes.

Comme je considérais tout code «désordonné» comme un devoir technique, j'ai immédiatement essayé de l'éliminer avec la plus grande sévérité!

Une fois, j'ai littéralement passé un week-end à corriger manuellement 800 erreurs de peluchage.

C'est ce que j'étais névrosé.

(Avertissement: c'était avant l'apparition des corrections automatiques).

Qu'est-ce que j'ai finalement compris

Un code non organisé ou salissant n'est pas la même chose que le devoir technique . Un état imparfait ne signifie pas qu'il s'agit d'un devoir technique. La dette technique vous ralentit d'une certaine manière ou rend certains types de changements difficiles ou sujets aux erreurs. Si le code est juste un peu en désordre, c'est juste un peu en désordre. Le nettoyage ne vaut peut-être pas votre temps.

Avoir une dette technique est normal . Parfois, nous raccourcissons le chemin, parce que nous devons faire le travail de toute urgence, et pour cela nous «prêtons» une partie du temps à l'avenir. Avoir des extraits de code qui sont une véritable «dette technique» est normal si vous reconnaissez que vous devez probablement le retourner. Si votre base de code, à votre avis, est exempte de dettes techniques, vous surestimez probablement l' apparence au détriment de la livraison . Et mon Dieu, comme je l'ai surestimé!

7. Plus la position d'un programmeur est élevée, mieux il programme

Ayant commencé la programmation à un âge assez jeune, je suis devenu un vrai professionnel des boucles, les perfectionnant à l'automatisme en 15 ans. La programmation en soi, c'est comme respirer pour moi. Lorsque la solution est évidente, je peux simplement imprimer le code non-stop, comme du texte sur un blog ou un e-mail. Je peux encoder la solution plus rapidement que les autres et j'ai généralement entrepris des projets plus complexes.

Pendant longtemps, j'ai pensé que c'était l'essence même du développeur principal.

Tout semble-t-il s'emboîter? Après tout, le poste est appelé «développeur principal» et non «communicateur principal» ou «chef de projet principal». Je ne comprenais vraiment pas combien de compétences supplémentaires devaient être développées pour devenir un véritable «leader».

Qu'est-ce que j'ai finalement compris

Les ingénieurs seniors devront maîtriser de nombreuses compétences en plus de la programmation . Comparé au début d'une carrière, j'ai dû développer une quantité astronomique de compétences. Communication, gestion des dépendances, partage de contexte, gestion de projet, évaluation des délais de réalisation des projets et collaboration avec des collègues qui ne sont pas des développeurs. Ces compétences sont difficiles à quantifier et nécessitent beaucoup d'essais et d'erreurs avant d'être correctement apprises.

Tous les programmeurs ne deviendront pas des "seniors" . C'est le résultat de nombreuses années d'expérience accumulée. Néanmoins, de nombreuses années d'expérience sont une condition nécessaire mais non suffisante pour le seigneur. Cela doit également être la bonne expérience dans laquelle vous avez appris les bonnes leçons et êtes capable d'appliquer avec succès ces connaissances à l'avenir. Parfois, des leçons importantes sortiront dans un an ou plus tard - c'est pourquoi des années d'expérience comptent toujours, même si vous êtes un très bon programmeur.

Dans certains domaines, nous sommes encore juniors . Quelle que soit votre expérience, il y a toujours des endroits où vous avez peu de connaissances. Reconnaître votre incompétence dans un domaine particulier est la première étape pour combler cette lacune et obtenir l'aide de camarades plus expérimentés.

Bonus : j'ai vraiment aimé l'article «Être un programmeur de premier plan» . C'est une bonne chose, si à quel moment vous vous demandez ce que signifie ce travail.