Le temps passe vite, non?

Ma carrière a débuté en 2012, avec le premier stage en C ++. Honnêtement, je n'avais aucune idée de ce que je faisais (en fait, rien n'a changé). Cependant, j'ai appris quelques leçons.

Avertissement: Il n'y aura pas de code dans ce message.

Question: Quel est le langage le plus important en programmation?

C'est l'anglais. Ou espagnol, chinois, polonais. Toute personne que vous utilisez pour communiquer avec des collègues.

Parler aux gens est beaucoup plus important que de parler aux voitures.

La programmation est un sport d'équipe. Il y a rarement un produit brillant créé à partir de zéro par une seule personne ( CodeSandbox est un excellent exemple, bien qu'Ives ait récemment embauché quelques employés), mais dans la grande majorité des cas, une équipe est nécessaire.

Les compétences en communication peuvent sauver ou enterrer un projet. Ne vous inquiétez pas, le problème n'est pas seulement le vôtre, même la NASA en souffre .

Les compétences professionnelles et de communication peuvent être plus importantes pour la réussite d'un projet que les compétences purement techniques. Peu importe que vous ayez embauché les cinq meilleurs experts en bases de données du monde s'ils refusent de se parler, et vous vous retrouvez avec cinq instances différentes de MySQL, Aurora et MongoDB.

Vous devez comprendre en profondeur ce que vous développez et pourquoi

La plupart des gens deviennent plus heureux lorsqu'ils ont un objectif. Cela vaut également pour le travail.

Votre objectif en tant que développeur n'est pas de traduire JIRA en JavaScript, Trello en C #, etc. Votre objectif est de résoudre les problèmes .

Si vous avez une compréhension approfondie du système que vous construisez / maintenez, vous pouvez prendre des décisions en dehors de la technologie pure. Posez des questions: cette fonctionnalité est-elle même nécessaire? Quel problème résout-il? Pouvons-nous résoudre ce problème différemment? Nous voulons résoudre ce problème en premier lieu?

Une telle réflexion est parfois appelée un contexte commercial, mais si vous voulez bien faire votre travail, vous devez non seulement comprendre le contexte, mais être capable de le façonner et de l'influencer. Pour influencer un produit, il n'est pas nécessaire d'occuper un poste de direction dans une organisation. À tout le moins, cela n'est pas nécessaire pour comprendre le produit.

Si une révision de code est stressante, c'est terrible

Oh mon dieu Vérification du code.

Nous n'y pensons vraiment pas, mais le fait de publier le travail avec son étude par plusieurs autres personnes est quelque peu unique à notre profession. Pas étonnant que cela cause du stress.

J'ai personnellement vu des gens envoyer une révision de code spécifiquement à un moment où X n'était pas au bureau ou Y était en voyage d'affaires. X est un programmeur brillant, mais difficile à maintenir sa révision de code. Des centaines de commentaires pointilleux dans le cadre de la demande de pool junior ne prouvent pas du tout votre supériorité en tant que développeur. Cela prouve seulement votre mauvaise nature.

OK, mais que dois-je faire lorsque cette fonction est complètement interrompue?

Lève toi. Contactez cette personne, parlez en personne . Parlez-lui, découvrez pourquoi il a implémenté le code de cette façon.

La plupart des gens ne veulent pas écrire de mauvais code. Et s'ils le font, ils sont probablement confrontés à des contraintes que vous ne connaissez pas. Ils peuvent également ne pas être très bons en programmation (pour l'instant), et ici vous pouvez faire vos preuves en tant que mentor.

Quelque chose DOIT mal tourner, préparez-vous

Selon Wikipedia:

La loi de Murphy est un proverbe ou une épigramme qui se lit généralement: "Tout ce qui peut aller mal ira mal."

C'est une de ces choses qui sont trop vraies. Lors de la conception d'un système, supposez toujours une sorte d'échec.

Si vous créez un formulaire de connexion, supposez que les gens vont copier et coller le texte de tout le livre dans le champ du mot de passe.

Si vous créez une fenêtre WYSIWYG, supposez que quelqu'un essaie de la casser et soit susceptible de le faire.

Si vous avez une base de données, elle sera déconnectée à un moment donné. Si vous n'avez pas testé la restauration d'une base de données à partir d'une sauvegarde, il ne s'agit pas d'une sauvegarde.

Si vous préparez une démonstration devant un public, assurez-vous que la démo fonctionne en ligne, hors ligne, à l'envers et sous l'eau.

N'ayez pas peur de dire "je ne sais pas"

Le privilège le plus agréable du titre "Senior" sur le badge est, enfin , l'occasion de répondre:

Je ne sais pas, je ne l'ai jamais essayé. Je vais vous regarder et vous rappeler.

Étant junior, j'avais terriblement peur: soudain, quelqu'un devinait que j'étais un imposteur. Après quelques années en tant que développeur - si je n'ai pas vu quelque chose, peut-être qu'il n'a toujours pas refait surface. Ou une autre technologie cool vient d'apparaître et doit être explorée. L'apprentissage tout au long de la vie n'est pas un mot à la mode, c'est une réalité en informatique.

Ou je suis juste un escroc incroyable qui a réussi à tromper tout le monde que je peux vraiment faire mon travail. On ne sait jamais.

Apprenez en public

Dès que vous passez de «Je ne sais pas» à «Eh bien, c'était intéressant» - partagez-le avec quelqu'un. Écrivez un blog, enregistrez une vidéo, parlez lors d'un événement de partage de connaissances, ou tout simplement ... parlez-en à quelqu'un. Si vous pensez que quelque chose est évident pour tout le monde, ce n'est pas le cas. Même les meilleurs professionnels ont quelque chose à apprendre des débutants et vice versa.

L'enseignement est un moyen incroyablement efficace de s'assurer que vous comprenez vraiment le sujet en question.

Comme quelqu'un a dit:

Quand on enseigne, deux apprennent.

Quelles leçons avez-vous apprises en tant que développeur?