1. Laissez l'ego à la porte
Les développeurs ont des ego gonflés. C'est un fait. Mais pourquoi? Je dirais que quiconque prend au sérieux sa profession se considère comme une personne d'art. Oui, on ne chante pas devant des millions et on ne dessine pas "Mona Lisa", mais parfois on écrit du code qui résout des problèmes complexes si efficacement et élégamment qu'on ne peut s'empêcher d'être fier de notre travail. Je pense que le développeur, de par son approche des problèmes, est un homme d'art autant qu'un mathématicien. En tant que tel, nous avons tendance à ramper autour du code, tout comme une mère ours autour de sa progéniture. Nous l'écrivons, l'adorons et le détestons quand les gens autour de nous se disputent à quel point le code est erroné ou non.
D'un autre côté, cela n'a encore aidé personne. Nous aimons notre travail, mais nous devons comprendre que nous résolvons des problèmes. En discutant de nos idées et solutions avec d'autres personnes, une meilleure alternative peut se présenter. Il n'y a rien de mal. En fait, la collaboration tend à produire de meilleures solutions. J'ai observé toutes sortes d'ego, mais je n'ai jamais vu une situation où l'ego travaillerait pour un développeur.
Quels conseils puis-je donner? Dès que vous commencez à travailler en tant que développeur, laissez votre ego à la porte. Avalez-le et écoutez ce que les autres ont à dire sur votre travail. Acceptez que les meilleures idées ne soient pas dans votre tête et qu'elles puissent améliorer votre professionnalisme. Vous ne bénéficierez que d'écouter les commentaires.
2. Les langues sont un outil. Connaissez-vous seulement le marteau? Alors tous les problèmes sont comme des ongles
Arrêtez de vous appeler un développeur Java ou un développeur JavaScript. Oui, il y a des langues que vous aimez en raison de leur syntaxe ou de leurs capacités. C'est tout à fait normal. Cependant, vous gagnez si vous passez du temps à étudier autre chose. Apprendre de nouvelles langues, surtout si elles suivent un paradigme différent de votre paradigme habituel, peut vous aider à ouvrir votre esprit à différentes approches de résolution de problèmes.
Je ne sais même pas à quel point c'est important: apprendre de nouvelles langues et les appliquer profitera à vos compétences. J'ai lu le livre Sept langues en sept semaines il y a quelques années, et il m'a ouvert beaucoup d'options simplement parce qu'il montrait les moyens de résoudre des problèmes disponibles dans d'autres langues.
Nous sommes des développeurs. Nous savons comment résoudre les problèmes avec le code. Ne vous limitez pas. Regardez au-delà des limites, sortez des sentiers battus, apprenez d'autres options, langues, façons de résoudre les problèmes. Même si vous ne le faites pas longtemps, vous reviendrez à votre outil familier avec de nouvelles idées et une réflexion plus large.
3. Il ne s'agit pas de mémoriser des algorithmes, mais de les trouver
Certains développeurs débutants pensent qu'ils doivent connaître les algorithmes par cœur, alors ils se sentent mal dès qu'ils se rendent compte qu'ils ont commencé à oublier comment écrire une boucle for. Ce n'est pas seulement normal. Je dirais que c'est même utile. Nous avons juste trop de choses à retenir. Mais cela est également inutile. Nous devons accepter le fait qu'Internet n'est qu'un autre outil nécessaire en tant que notre IDE pour trouver des réponses.
Nous faisons tous cela. Et si cela vous fait vous sentir mal, ne perdez pas de temps avec ce sentiment. Recherchez simplement la réponse sur Google et comprenez votre problème. Penses-y. Chaque langage a des façons similaires, mais légèrement différentes d'implémenter le modèle Observer. Qu'est-ce qui est plus utile? Comprendre à quoi sert un modèle et quels problèmes il résout, ou se rappeler comment le mettre en œuvre dans chaque langue avec laquelle vous travaillez?
Si vous savez que le modèle résoudra votre problème, vous l'avez déjà résolu. Tout le reste n'est qu'une recherche de la meilleure façon de l'implémenter sur Google. Cette recherche ne vous enlève aucun respect pour vous, votre travail ou votre expérience. Il en va de même pour toute autre recherche. Concentrez-vous sur ce qui est important, sur la résolution du problème et laissez Google pousser votre mémoire. Voilà pourquoi cela existe.
4.
Ou plutôt, vous devez étudier toute votre carrière. La décision de suivre ou non les derniers développements de l'industrie vous appartient. Mais il est préférable de le faire si vous voulez correspondre.
Les langues et les technologies évoluent, et c'est parfaitement normal. Bien sûr, certains écosystèmes changent plus rapidement que d'autres, et les suivre peut sembler une tâche titanesque, mais concentrez-vous sur les choses importantes, rappelez-vous que vous êtes seulement humain et que vous ne pouvez pas tout savoir. Par conséquent, si vous avez besoin d'apprendre une chose, je vous suggère d'apprendre à apprendre.
Je sais que cela peut sembler idiot, mais peut-être que le développeur a cette compétence numéro un. Nous devons apprendre à acquérir rapidement de nouvelles compétences. Sinon, vous courez le risque d'obtenir l'étiquette «obsolète».
C'est là que certaines des autres leçons de cet article entrent en jeu. Variation, changement, nouveaux défis, manque d'ego - tout cela vous aidera à apprendre et à élargir votre gamme de compétences. Plus vous le pratiquez, mieux c'est. Finalement, vous constaterez que toutes les langues sont similaires. Vous commencerez à voir leurs racines communes et à pouvoir travailler avec n'importe lequel d'entre eux. Tout ce que vous avez à faire est de lire quelques éléments clés. Tout au long de votre carrière, vous étudierez:
- Nouvelles langues.
- Nouveaux (et anciens) paradigmes de programmation.
- Nouvelles approches du travail.
- De nouvelles façons de résoudre les problèmes.
- De nouvelles façons d'interagir avec les coéquipiers.
- De nouvelles approches pour réviser et tester votre code.
Si vous n'êtes pas prêt à être un étudiant éternel, demandez-vous si une telle carrière est pour vous. Remarquez que je n'ai pas dit «Partez immédiatement», mais demandez-vous si vous êtes prêt à ouvrir votre esprit à l'apprentissage continu.
5. Fonctionne mieux que l'idéal
En tant que manager, j'ai entendu cela trop souvent. Mais en tant que développeurs, nous avons tendance à penser que le code doit être parfait avant la sortie. Et ce n'est pas seulement faux, mais potentiellement un problème. L'optimisation précoce est un problème car vous finissez par passer beaucoup de temps et d'efforts sur des choses qui n'ont peut-être pas besoin d'optimisation. Et dans certaines situations, lors de cette optimisation, vous faites des hypothèses qui cassent la fonctionnalité.
Alors concentrez-vous sur le travail à faire et le problème que vous essayez de résoudre. Après avoir résolu le problème, testez-le, parcourez les résultats et voyez ce que votre équipe pense de votre solution, même si vous pouvez déjà voir des moyens de l'améliorer. Si vous allez passer deux jours de plus à perfectionner le code, mais qu'il peut entrer en production maintenant, il y a de fortes chances qu'il soit en production maintenant.
En fin de compte, vous résolvez le problème. Plus vite vous résolvez le problème, mieux c'est pour vos utilisateurs.
6.Faire fonctionner le code, puis optimiser
Selon certains des points précédents, ne tombez pas dans le trou noir de l'optimisation précoce. Même si vous pensez que vous obtiendrez rapidement le code dès sa sortie (le cas échéant), vous constaterez que l’effet de dilatation du temps est réel.
Votre première priorité en tant que développeur de logiciel qui écrit une nouvelle fonctionnalité ou corrige un bogue est de la faire fonctionner, peu importe la laideur du code ou l'inefficacité de la solution. Si le code fonctionne, vous venez de prouver qu'il est possible d'écrire du code. C'est la moitié de la bataille.
La deuxième étape est l'optimisation. Cette étape est facultative. Des détails que certaines personnes ont tendance à oublier. Le temps dont vous disposez pour optimiser votre code dépend de nombreuses variables que vous ne maîtrisez parfois pas. Alors concentrez-vous sur le fonctionnement du code, puis déterminez si vous avez réellement le temps de l'optimiser.
Optimiser tôt signifie optimiser votre code au fur et à mesure que vous l'écrivez. Il s'agit d'une pratique dangereuse car lors de l'optimisation, nous émettons des hypothèses sur le temps d'exécution, les besoins en données, les besoins en mémoire et d'autres facteurs que nous n'avons pas encore vu en action. Une telle hypothèse peut être erronée et vous finirez par introduire des erreurs dans votre logique.
Pensez au workflow TDD:
- Écrivez un test pour comprendre tout ce qui doit être fait pour votre fonction (le test échouera).
- Écrivez votre code pour que le test réussisse.
- Maintenant, souciez-vous d'optimiser votre code.
La deuxième étape est requise. Vous devez d'abord vous occuper du test, ce qui signifie que la fonction fonctionne. Le test ne se soucie pas que vous utilisiez trois instructions if imbriquées dans vos algorithmes. Cela deviendra important, peut-être au stade de la révision du code.
7. Les derniers 10% du projet prennent 90% du temps
Ceci est particulièrement important si vous travaillez seul, mais les équipes souffrent également de ne pas obtenir ce petit détail mathématique. Quiconque a terminé un projet dira la même chose (et franchement, ce n'est pas seulement le cas dans notre industrie). Tout d'abord, vous vous précipitez dans de nombreux détails pour y réfléchir plus tard.
Et c'est tout à fait normal. Nous avons tendance à nous concentrer principalement sur les grandes fonctionnalités, laissant de petits détails ou même des bogues connus jusqu'à la toute fin. Mais néanmoins, vous devez les combattre - et ici 90% supplémentaires apparaissent. Vous devez tester, corriger le code, tester à nouveau, apprendre aux utilisateurs à gérer la solution, soumettre la version finale de la solution, etc. Bien sûr, tout dépend du contexte, de l'identité de votre client et de nombreux autres facteurs, mais il y a toujours quelque chose. Alors rappelez-vous, quand vous pensez que vous avez presque fini avec le code, vous avez probablement oublié quelque chose.
8. Lorsque vous êtes en équipe, vous avez besoin d'abstraction.
Le codage concerne le comportement des abstractions. En faisant abstraction de la logique générale, on peut la réutiliser ailleurs, mais au début on oublie l'importance des abstractions. Voici ma règle personnelle: si le code est répété à deux endroits, il est envoyé à une fonction (méthode, module); vous avez eu l'idée. Si deux répétitions ressemblent à un petit nombre à vos yeux, gardez à l'esprit qu'il peut y avoir d'autres endroits dans le futur pour appliquer le code que vous venez d'abréger. Et en extrayant le code tout de suite, vous y aurez immédiatement accès.
L'abstraction évolue. Un morceau de logique abstraite peut être utilisé plusieurs fois avec un minimum d'effort, tandis que le copier-coller (bien que ce soit facile à faire) - plus vous l'utilisez, plus cela demande d'efforts. Pensez à ce qui se passe si, à cause d'un bug, vous devez changer un morceau de logique qui se répète 5 fois. Pour corriger un bogue, vous modifiez littéralement la même partie du code 5 fois.
La même logique s'applique aux tâches quotidiennes. Si vous faites quelque chose plus d'une fois, cela peut probablement être automatisé d'une manière ou d'une autre. C'est la clé de l'efficacité, alors recherchez la répétition non seulement dans votre code, mais aussi dans vos actions. Si vous automatisez une tâche qui prend 10 minutes par jour, vous économiserez 5 heures par mois.
9. Les projets parallèles sont facultatifs, mais peuvent aider
Certains disent que si vous voulez être un développeur performant, vous avez besoin de projets parallèles. Je ne pense pas que ce soit vrai. Je connais personnellement de nombreux grands développeurs qui n'écrivent que du code au travail, "de 9 à 17". Pour être honnête, je les admire. Ils sont maîtres de leur métier, et pendant leur temps libre, faisant autre chose, ils apprécient la vie. Il n'y a absolument rien de mal à cela. Cependant, vous avez parfois besoin d'un peu de pratique supplémentaire. Parfois, vous avez l'impression d'être en retard sur vos collègues; ici et aider les projets parallèles.
Je ne parle pas d'une révolution dans l'industrie - développer un cadre avec des millions d'utilisateurs. Écrivez-le si vous voulez, mais je parle de copier les projets de quelqu'un d'autre pour apprendre d'eux. Je parle également de contribuer aux projets d'autres personnes, de corriger les bugs et d'ajouter des fonctionnalités.
Vous pouvez écrire des projets parallèles pour découvrir d'autres aspects du développement que vous ne toucheriez normalement pas. Si vous écrivez des tests unitaires 8 heures par jour, vous pouvez envisager d'écrire quelque chose à partir de zéro ou de développer certaines fonctionnalités. Si vous êtes fatigué de travailler seul, contribuez à un projet existant d'autres personnes et découvrez ce que signifie coordonner votre travail avec les autres. Vous pouvez rédiger un projet parallèle pour améliorer votre niveau de compétence en corrigeant les faiblesses. Mais là encore, ne vous sentez pas obligé de travailler dessus avec une barre d'activité verte Github pour être considéré comme un développeur sérieux. C'est juste idiot.
Conclusion
Voici mes 9 leçons difficiles en tant que développeur au cours des 18 dernières années. J'espère qu'en partageant mon expérience, j'ai mis en lumière votre carrière future ou actuelle. Avez-vous appris autre chose que vous aimeriez partager? J'adorerais vous entendre dans les commentaires, j'aimerais apprendre quelque chose de vous.
Autres professions et cours