Voici ce que j'ai appris neuf mois après mon travail en génie logiciel

Je travaille depuis environ neuf mois chez Dexter en tant que développeur de logiciels. J'ai écrit un article de blog sur l'obtention du poste au départ, ainsi qu'un article technique sur un composant d'auto-positionnement que j'ai créé au cours de mes premiers mois dans l'entreprise. Obtenir un emploi était mon objectif initial, et le garder et grandir en tant que développeur était la prochaine étape naturelle.

Ma vision de mon rôle a considérablement changé depuis que j'ai commencé. Je pensais qu'être développeur consistait à créer du code le plus rapidement possible. C'est la chose la plus éloignée de la réalité. Frapper rapidement beaucoup de code merdique n'est pas un moyen évolutif de créer une entreprise ou une carrière dans le développement. Heureusement, j'ai trouvé un employeur qui ressentait la même chose et dont le produit est un logiciel.

Le but est d'écrire juste la bonne quantité de bon code et de bien communiquer. Vous n'êtes pas payé pour coder, vous êtes payé pour réfléchir et résoudre les problèmes. Le sous-produit est une pensée cristallisée et une instruction qu'une machine doit suivre sous forme de code. Je préfère résoudre un problème en une seule ligne de code clair et lisible plutôt qu'en 10 lignes de code difficile à comprendre. Je préfère résoudre un problème en 5 lignes de code commenté lisible qu'une seule ligne de code multi-imbriqué très complexe avec plusieurs opérateurs ternaires. Vous avez eu l'idée.

Posez beaucoup de questions et documentez les réponses

Mon patron m'a envoyé ce lien qui résumait beaucoup de stress et d'anxiété que je ressens en tant que nouvel ingénieur. C'est un euphémisme de dire que je suis très gêné de poser des questions.

J'utilise cette liste de contrôle avant de demander de l'aide aux autres:

  • Est-ce une question que j'ai déjà posée, et si oui, où ai-je documenté la réponse?
  • Est-ce quelque chose que je pourrais Google?
  • Est-ce documenté quelque part par quelqu'un d'autre en interne?
  • Que se passe t-il ici? Quelle est la cause première de l'erreur ou du comportement inattendu que je rencontre?
  • Est-ce que je comprends vraiment la question à laquelle j'essaie de répondre? Il est normal de prendre un peu de temps et de relire le problème plutôt que de donner une réponse à moitié ou précipitée.

Après avoir suivi ces étapes, je résous le problème par moi-même, je trouve une solution documentée ou je pose une question avec un contexte et des détails bien meilleurs, ce qui permet à quelqu'un d'autre de m'aider plus facilement. Mieux encore, si je pose une bonne question et qu'on peut y répondre par chat, mon coéquipier n'a pas besoin de tout laisser tomber pour m'aider.

Si j'ai parcouru 90% du chemin pour résoudre le problème et que j'ai juste besoin des 10% d'aide restants, un développeur senior sera heureux de vous aider en sachant que je suis allé aussi loin que je le pouvais tout seul. Chercher quelqu'un d'autre pour résoudre vos problèmes n'est pas un excellent moyen de renforcer la confiance au sein de votre équipe.

Les gens intelligents aiment les bonnes questions - alors posez-les.

Évitez de faire les mêmes erreurs et de poser les mêmes questions encore et encore

C'est plus facile à dire qu'à faire et cela pourrait être vrai pour n'importe quel travail, pas seulement la programmation. De nombreux nouveaux concepts et informations vous sont proposés et il est inévitable de faire des erreurs. Soyez conscient de cela. Réfléchissez avant de demander. Trucs de Google. Regardez les documents. C'est ton ami. Si vous voyez une tendance, essayez de l'identifier. Faites un effort actif pour vous surprendre à poser le même type de question. Écrivez-le et fixez-vous comme objectif de le réparer.

Assurez-vous que la prochaine fois que vous rencontrez le même problème, vous savez quoi faire. Nous faisons tous des erreurs, mais être conscient de soi et faire un effort pour changer est la façon dont tout le monde s'améliore.

Passez en revue votre travail, toujours

Personne n'aime passer par un PR et vous dire de supprimer vos consoles.logs et débogueurs ou vous dire de corriger les erreurs de peluchage. Je ne publierais pas cet article sans l'avoir lu plusieurs fois et sans demander à un ami d'y jeter un œil.

Regardez vraiment votre code et posez-vous ces questions:

  • J'ai écrit une logique complexe. Existe-t-il des fonctionnalités similaires dans l'application qui peuvent le faire d'une manière plus lisible, flexible ou générique?
  • Sinon, est-ce que je me souviendrai pourquoi j'ai écrit ce code en une semaine? Si la réponse est non, je veux probablement changer le code ou le commenter. La personne qui examine le PR devrait avoir un certain contexte dans pourquoi j'ai pris cette décision.
  • Assurez-vous que votre code réussit le linting et les tests avant de le donner à quelqu'un d'autre.
  • Est-ce que je me répète? Puis-je encapsuler la logique que je répète dans une fonction?
  • Si c'était le code de quelqu'un d'autre que j'examinais, quels commentaires devrais-je faire? Qu'est-ce que je voudrais changer pour le rendre plus simple?

Regardez votre code avec un regard neuf (peut-être le lendemain). Y a-t-il une logique spécifique qui dégage des composants qui ne devraient pas l'être? Votre composant gère-t-il la logique métier qui devrait entrer dans un conteneur?

De plus, une bonne révision du code personnel permet à l'entreprise d'économiser du temps et de l'argent. Il est beaucoup moins coûteux pour vous de trouver vos propres bogues et de les corriger vous-même plutôt que de laisser quelqu'un d'autre les trouver deux jours plus tard.

Dernière chose à propos de la révision de votre code. Touchez et cliquez sur TOUT CE sur lequel vous avez travaillé. Je veux que le code que j'envoie à n'importe qui soit très difficile à casser. S'ils cliquent sur une nouvelle page et obtiennent une grosse erreur ou un écran blanc de mort, cela montre que je n'ai pas vraiment revu mon travail. Grep pour le code que vous avez édité et assurez-vous vraiment de ne pas casser autre chose avec votre ajout à un composant partagé.

Cela peut sembler idiot, mais les bases de code volumineuses sont complexes et vous ne réaliserez peut-être pas que vous cassez quelque chose avant de le faire.

Sérieusement, vous ne voulez pas voir le premier brouillon de ce billet de blog :)

Rien n'est magique

Il y a généralement une bonne raison pour laquelle le code a été LGTM (approuvé et dans la base de code). Si vous ne comprenez pas comment cela fonctionne, prenez le temps de le comprendre. Enregistrez des trucs, cassez des trucs, regardez une documentation des fonctions et des modèles qui ont été utilisés.

Pourriez-vous dire à votre canard en caoutchouc comment cela fonctionnait? Si vous n'êtes toujours pas sûr, posez des questions sur des lacunes spécifiques dans votre compréhension.

Obtenez un débogage confortable, car vous le faites beaucoup

Déboguer, c'est comprendre le problème sous-jacent dans la fonctionnalité de votre code puis résoudre le bogue. Vous devez comprendre comment cela fonctionne pour comprendre pourquoi cela ne fonctionne pas en premier lieu. Pouvoir utiliser les outils de débogage du navigateur vous facilitera la vie et votre travail. Les méthodes de débogage et de console sont vos amis.

Une ressource utile que j'ai trouvée:

  • Astuces CSS sur le débogage
  • Débogage Front-End Masters (c'est payant mais plutôt bon)

Conseil de pro : la sortie console.log peut être stylisée en utilisant CSS. Cela rend le journal que vous souhaitez voir plus facile à identifier.

console.log('%c I want this to be big and red', 'font-size: 30px; color: red;');

Suivez les données

Cela revenait maintes et maintes fois, car c'était une erreur que je continuais à faire. C'est quelque chose dans lequel je me suis amélioré, mais j'ai encore besoin de travail.

Une grande partie du développement logiciel implique la manipulation des données dans un format afin qu'un utilisateur puisse en tirer des informations exploitables ou les mettre à jour par lui-même.

Les applications avec un flux de données unidirectionnel et un état global ont une ligne directe de données à suivre. Toutes ces données viennent de quelque part. Une fois que vous découvrez d'où cela vient, il est plus facile de déboguer.

Isolez vos problèmes puis intégrez-les dans ce sur quoi vous travaillez

Codepen.io est un de mes amis proches, et cela devrait aussi être le vôtre. Quand je ne peux pas comprendre ce qui cause le problème, je crée une version simple de ce que je construis. Je m'assure que cela fonctionne, puis je l'intègre dans mon environnement de développement. Il est plus facile de comprendre ce qui pourrait briser votre interface utilisateur dans un environnement dépouillé.

Réfléchissez au fonctionnement de la fonctionnalité

Ecrire comment quelque chose devrait fonctionner à partir d'un niveau de 30 000 pieds, puis d'un niveau technique, m'a aidé à comprendre ce que je devrais construire, comment je devrais le construire et à atténuer les chutes de puits. Si je ne peux pas expliquer comment fonctionne la chose que je construis (à partir d'un niveau haut et bas), je me rend mal. Sans plan, je vais faire beaucoup de patinage dans un avenir très proche.

De plus, je peux me référer à ce que j'ai écrit ou montrer à quelqu'un ce que je pense, ce qui contribue à réduire les problèmes de communication.

Embrassez la lutte

Après 10000 heures de lutte au travail, vous serez bien meilleur pour surmonter et résoudre les problèmes. Vous allez devoir le faire de toute façon, alors profiter de l'expérience rendra votre quotidien beaucoup, beaucoup mieux. Riez un peu de vous-même et essayez de vraiment résoudre le problème. Vous y arriverez, même si vous avez besoin d'un peu d'aide supplémentaire.

Prenez des critiques constructives et répétez constamment dessus

Vos coéquipiers veulent que vous fassiez mieux. Les développeurs seniors veulent faire de vous un développeur plus fort. Suivez leurs conseils même si vous ne comprenez pas initialement pourquoi ils vous disent de le faire. Il n'y a jamais qu'une seule personne qui sait tout. Discutez-en.

Prends ton temps

Se précipiter dans votre travail provoque des allers-retours, beaucoup de confusion et une frustration supplémentaire. Mon patron préfère voir un meilleur code plus tard qu'un mauvais code plus tôt. Je veux dire, ne serait-ce pas tous?

Continuez à apprendre en dehors du travail

Autant que j'apprends sur le tas, je veux continuer à apprendre de nouvelles choses en dehors de simplement travailler sur notre base de code. Cela peut être de prendre Python, de créer un bot, de travailler sur une série de vidéos ou de travailler sur un projet personnel. J'ai créé un tableau avec Zenhub + Github pour suivre où j'en suis et ce que je me suis engagé pour le mois. Garder un objectif général pour le mois m'a obligé à continuer à apprendre, à construire et, oui, à bloguer à mon rythme.