Conseils pour les nouveaux développeurs software qui ont déjà lu tous les autres essais de conseils
(buttondown.email)- En début de carrière, même les conseils de développeurs célèbres ne doivent pas être suivis tels quels : il faut d’abord vérifier s’ils correspondent à votre situation, et beaucoup d’affirmations dans le software reposent sur peu de preuves définitives
- Si une idée vous plaît, vous pouvez l’essayer vous-même, mais tant que cela ne gêne pas vos collègues, passer par des essais et erreurs fait partie du processus d’apprentissage
Debugging: The 9 Rulesest recommandé comme ouvrage d’introduction accessible sur la compétence en débogage, souvent laissée de côté par les livres pour débutants- La « bonne manière » ou les « best practices » viennent souvent de cas d’échec précis et de trajectoires historiques ; il faut donc distinguer la technique elle-même de sa manière d’être diffusée
- Découvrir tôt les fonctions cachées des outils, le travail des autres équipes et différents types de programmation aide à trouver le travail software qui vous convient
Attitude à adopter face aux conseils
- Les conseils de développeurs largement lus se diffusent parfois non parce que leur auteur est un programmeur exceptionnel, mais parce qu’il écrit bien
- Il ne faut pas rejeter automatiquement tous les conseils, mais examiner avec soin comment ils s’appliquent à votre propre situation
- Les affirmations de « vérité objective » sur le software doivent être accueillies avec prudence : peu de choses ont été étudiées scientifiquement, et les résultats sont en général peu conclusifs
- Pas besoin de trop s’inquiéter à l’idée d’apprendre « de mauvaises choses »
- Si l’idée de quelqu’un vous plaît, vous pouvez l’essayer vous-même
- Tant que vous ne perturbez pas activement vos collègues, même si vous réalisez plus tard qu’il aurait fallu faire autrement, cela peut malgré tout devenir un apprentissage
- Debugging: The 9 Rules est un livre recommandé aux développeurs débutants
- Il se lit facilement et traite du débogage, une compétence importante que la plupart des autres livres pour « programmeurs débutants » abordent à peine
- Vous pouvez aussi l’emprunter en bibliothèque ou demander à votre entreprise de l’acheter
Les limites de la « bonne manière » et des best practices
- À un moment donné, on peut être persuadé d’avoir trouvé la « Right Way » du programming, et que le domaine progresserait si tout le monde suivait cette approche
- Sont cités comme exemples le développement piloté par les tests, la programmation fonctionnelle, Lisp ou encore les méthodes formelles
- Il est difficile d’éviter complètement ce genre d’enthousiasme, et cela peut même être agréable, mais l’important est de ne pas faire de la « Right Way » son identité
- Avec le temps, on apprend que n’importe quelle approche peut rendre le programming frustrant et désordonné, et qu’il est aussi possible de produire un excellent software sans l’utiliser
- Quand on connaît plusieurs « Right Way », on peut les combiner selon le problème
- La première « Right Way » que l’on découvre vient souvent de quelqu’un qui y croit totalement
- Mieux vaut ne pas trop lui en vouloir plus tard, et éviter de confondre la technique elle-même avec la façon dont cette personne en fait la promotion
- Beaucoup d’idées doivent être ajustées pour être utilisées avec d’autres, plutôt que d’être appliquées dans leur forme pure
- Comme le dit Julia Evans, « derrière chaque best practice, il y a une histoire d’horreur »
- Si une best practice vous semble incompréhensible, vous pouvez chercher le cas d’échec qui l’a fait naître
- Si ce cas n’a rien à voir avec votre situation, il est acceptable de choisir une autre approche
- Beaucoup de best practices et de conventions sont dépendantes du chemin historique
- On les suit parce qu’un mentor les faisait, et ce mentor les suivait lui-même parce qu’un mentor précédent les faisait
- Des pratiques créées pour résoudre des problèmes du passé peuvent être moins pertinentes aujourd’hui
- Une convention qui ressemble à une explication plausible a posteriori peut réellement en être une, et il est souvent possible d’en retracer la formation
Comment élargir son sens du terrain
- Marcher est proposé comme une habitude utile pour clarifier ses idées
- Les outils que vous utilisez ont presque toujours une profondeur cachée
- Il n’est pas nécessaire de maîtriser au niveau expert tous les langages de programmation, Git ou des outils comme JIRA
- En revanche, il est recommandé d’investir 5 à 10 minutes pour voir ce qu’ils peuvent faire de plus
- Parler avec des personnes d’autres équipes dans l’entreprise permet d’élargir sa compréhension du travail
- Vous pouvez échanger avec le support, le métier, les ventes, etc.
- Si vous en avez le temps et que la demande est facile à faire, il est aussi suggéré d’observer leur travail de près
- En début de carrière, il vaut mieux, si possible, expérimenter plusieurs types de programmation
- Cela ne veut pas forcément dire changer d’entreprise, car la plupart des sociétés font plusieurs types de programmation en parallèle
- Dans une entreprise de développement web, vous pouvez essayer le frontend, le backend, l’exploitation ou le travail sur les bases de données
- Cela aide à apprendre, mais surtout à augmenter vos chances de trouver le type de travail software que vous aimez vraiment
- Un exemple personnel est donné : le premier poste était en frontend, difficile à vivre, puis un passage au backend a rendu les choses plus agréables
- Comme le domaine du software évolue sans cesse, le conseil consistant à ne pas se laisser emporter par les modes des frameworks et à se concentrer sur les compétences fondamentales a ses raisons
- À cause d’Internet, de l’open source, des conférences, etc., l’information circule très vite dans le software
- Les barrières au partage d’idées sont faibles, si bien qu’un projet personnel utilisé par une seule personne peut sembler connu de tous
- Une grande partie des technologies dont on entend parler ont une base d’utilisateurs réduite et peuvent ne jamais être largement adoptées
- Si cela vous passionne, vous pouvez devenir early adopter ; sinon, attendre quelques années pour voir ce qui dure réellement est aussi une bonne option
- Personne ne peut prédire l’avenir, et le présent lui-même est le résultat de choses qui étaient difficiles à prévoir
- Il faut faire de son mieux, vivre en accord avec ses valeurs et adopter une attitude qui permet de profiter du processus
1 commentaires
Avis sur Hacker News
J’ai récemment travaillé sur un projet perso avec un développeur junior et un autre un peu moins junior, et tous deux étaient obsédés par « la bonne manière de faire ».
Pour un bot Discord + du code Rust d’environ 300 lignes, que seuls nous allions faire tourner, ils exigeaient une documentation complète, des VM séparées pour la QA et la « production », un déploiement systemd, un système de templates pour quelques chaînes de caractères, et même une couche ORM pour quatre requêtes SQL.
C’était un projet destiné à tout au plus une dizaine d’utilisateurs, et cela ne représentait encore que la moitié des exigences de la version « 0.3 » ; comme ils prévoyaient déjà une conception encore plus excessive, je me suis retiré du projet.
À mes débuts en programmation, j’ai moi aussi été comme ça pendant quelques années, mais j’ai appris qu’au-delà des bonnes pratiques ou du style de code, l’informatique contient des sujets bien plus profonds, et qu’au final ce qui compte, c’est du code qui fonctionne.
Autrement dit, consacrer une attention disproportionnée à des détails dérisoires plutôt qu’au problème central ; il existe cette analogie où un comité d’approbation d’une centrale nucléaire délaisse la centrale elle-même pour débattre de la couleur de l’abri à vélos à côté.
Dans ce cas aussi, se concentrer sur la séparation de VM QA/production, le déploiement systemd, des templates pour quelques chaînes, ou un ORM pour quelques requêtes SQL dans un projet de 10 utilisateurs ressemble à un exemple typique de la loi de la trivialité.
Ces aspects sont particulièrement faciles à comprendre et à débattre pour des développeurs juniors, ce qui les pousse à s’y impliquer davantage, tandis que les fonctionnalités centrales, plus difficiles, risquent d’être négligées.
Cela dit, documenter correctement les parties significatives d’un projet ne me semble pas relever de cette obsession des détails insignifiants.
Écrire une unité systemd ou utiliser un ORM ne prend pas forcément autant de temps qu’on l’imagine, et cela aide beaucoup plus tard quand quelqu’un revient sur le projet ou qu’une autre personne veut y contribuer.
C’est plus facile de le faire tant que le contexte est encore frais dans la tête ; une fois le projet devenu plus gros, ce genre de corvées est rarement traité.
Et comme c’était un projet perso, ils voulaient peut-être justement le faire proprement pour apprendre les outils et en tirer de la satisfaction.
Au début, il y a une scène où ils doivent acheter un routeur à 50 dollars ; quand l’un des personnages propose de réparer le routeur existant, les autres répondent « on a essayé » avant même qu’il ait presque fini sa phrase.
Cela montre qu’ils se connaissent si bien et passent tellement de temps ensemble qu’ils en sont presque à lire dans les pensées les uns des autres.
Mais quand quelqu’un dit « yes » pour acheter un nouveau routeur, un autre répond qu’il faut dire « aye ».
Les règles de vocabulaire à employer lors des votes de décision dans leur activité annexe sont donc très strictes ; peu importe qu’ils soient assez proches pour finir les phrases les uns des autres, qu’il s’agisse d’un routeur à 50 dollars, ou que les revenus de l’activité soient dérisoires.
La règle exige aye.
Certains obsédés de « la bonne manière de faire » ressemblent à des gens qui ont réussi en copiant des connaissances stockées dans l’intelligence collective sociale, sans vraiment savoir ce qui se passe dans leur propre tête.
Il y a l’avantage d’hériter de méthodologies éprouvées sans avoir à les redécouvrir péniblement soi-même, mais aussi l’inconvénient de ne pas comprendre littéralement dans quelles situations cette approche mène à l’échec.
Dans le commentaire du réalisateur, il est dit que cette scène a été placée intentionnellement pour montrer que certains personnages prennent les règles trop au sérieux, tandis que d’autres ne les prennent pas assez au sérieux.
La raison pour laquelle on recommande ce genre de pratiques de culte du cargo aux autres me semble similaire : plus il y a de gens qui les suivent, plus il y a de chances que, quand cette pratique échoue de manière catastrophique, la personne qui échoue ne soit pas soi-même.
Je vois trop souvent ce genre de cas ces temps-ci, et j’appelle ces personnes des juniors intelligents. Peu importe qu’ils aient 1 an ou 20 ans d’expérience.
Le junior intelligent connaît la plupart des design patterns et a lu The Mythical Man-Month, mais il veut essayer une nouvelle technologie, un nouveau langage ou un nouveau framework ; il se met donc à courir partout avec un nouveau marteau brillant, à la recherche de tout ce qui ressemble à un clou.
Puis il prend de mauvaises décisions parce qu’il ne comprend pas la puissance que peut offrir une vieille base de données bien optimisée.
Avec 20 ans d’expérience, j’ai souvent vu comment ce genre de projet finit 5 à 10 ans plus tard, quand plus de la moitié de l’équipe d’origine est partie ; je garde ce qui a une vraie valeur et je coupe la moitié inutile.
Nous ne tenons pas une maternelle pour développeurs prêts à tout pour s’amuser ; nous travaillons pour une entreprise qui paie et attend des résultats stables et relativement rapides.
Essayer du neuf pour utiliser une technologie de pointe ou éviter l’ennui a, à long terme, cassé plus de choses que cela n’en a réparées.
Il faut adopter des technologies que toute l’équipe peut comprendre et maîtriser, pas introduire une technologie que seul un superstar qui s’ennuie connaît.
Si vous voulez remplir votre CV de lignes de technologies, faites-le dans une entreprise de ce type ; elles ont aussi leurs qualités.
Mais ces personnes ne restent de toute façon souvent pas longtemps, donc leur valeur ajoutée globale est également douteuse. Certains trouveront ça ennuyeux, mais moi, j’appelle cela une approche expérimentée.
Si l’objectif d’un side project est de donner envie aux entreprises de regarder votre GitHub, cela paraît encore plus logique.
La documentation est très importante. J’ai des projets assez simples de moins de 300 lignes, y compris un bot et un web scraper, mais comme je ne les ai pas documentés, je ne peux plus les exécuter aujourd’hui.
Le Raspberry Pi sur lequel ils tournaient est mort, et je ne sais pas comment réparer le framebuffer virtuel headless ni comment déboguer une erreur obscure pour laquelle les recherches ne donnent aucun résultat utile.
Si j’avais conteneurisé le tout, ou au moins documenté la procédure de configuration, je n’aurais pas ce problème.
C’est un bon article, et j’aimerais que davantage de gens le lisent
En 15 ans dans le logiciel, en particulier dans la gestion de données, c’est exactement ce que j’ai appris
Le Kesamutti Sutta, que j’ai découvert via un contexte bouddhiste Theravada, m’a aussi beaucoup aidé
Il dit en substance de ne pas suivre quelque chose tel quel simplement parce qu’on l’a entendu plusieurs fois, parce que c’est la tradition, une rumeur, écrit dans les textes, fondé sur une conjecture, un axiome ou un raisonnement plausible, parce qu’on est biaisé envers une idée longtemps méditée, parce que quelqu’un semble compétent, ou parce que c’est la parole d’un maître
Le conseil de l’accepter quand on sait soi-même que « ceci est bon, irréprochable, loué par les sages, et que sa mise en pratique mène au bénéfice et au bonheur » m’a été très utile dans la vie, même après être devenu athée au collège
Certains affirment que quelqu’un a déformé la traduction pour lui donner un sens plus rationaliste
Si c’est vrai, c’est dommage. J’avais envie de croire que Buddha était quelqu’un d’aussi « éclairé »
https://fakebuddhaquotes.com/do-not-believe-in-anything-simply-because-you-have-heard-it/
Je suis d’accord avec le passage qui dit de ne pas trop s’inquiéter d’avoir été « trompé » ou d’avoir « appris quelque chose de faux »
Ai-je appris à l’époque où le TDD était à la mode ? Oui. Est-ce que j’utilise le TDD aujourd’hui ? Non. Est-ce que le TDD m’a quand même appris à écrire du meilleur code ? Oui
C’est pareil pour les langages que je n’utilise plus professionnellement. Tout enseigne quelque chose
On ne peut pas trouver le bon juste milieu sans dépasser un peu dans les deux directions
Si du code existe déjà et qu’on veut l’étendre, écrire quelques tests autour de ses usages est raisonnable
S’il n’y a pas encore de code, mais qu’on a une structure en tête et qu’on peut distinguer ce qui peut être construit puis testé en premier, cela a aussi du sens
Ce n’est pas du TDD au sens pur, c’est plus proche d’un développement assisté par les tests, mais cela exploite l’esprit du TDD
Apprendre de mauvaises choses joue aussi un grand rôle pour comprendre quelles approches sont meilleures ou moins bonnes
Cela ne veut pas dire que le TDD lui-même est mauvais, mais une obsession excessive peut le rendre néfaste
Au fond, cela rejoint aussi l’idée reçue selon laquelle « les erreurs sont le chemin de l’apprentissage »
Ces lignes directrices et principes sont généralement bons à connaître, mais le problème commence quand les gens les adoptent comme une religion
Dans notre secteur, les idéologues sont vraiment une plaie
Elle est courte, juste, et parle immédiatement
C’est un bon article et de bons conseils
Au bout du compte, une fois la lune de miel terminée, on apprend que, quelle que soit la « bonne façon » employée, programmer est frustrant et désordonné, et qu’on peut aussi créer d’excellents logiciels sans suivre cette méthode
Avec le temps, on apprend encore des dizaines d’autres « bonnes façons », puis on les combine selon le problème
Mais ces dernières années, j’ai l’impression que beaucoup de développeurs restent prisonniers de l’obsession de la bonne façon, sans élargir leurs connaissances ni leur perspective
Si c’est vrai, c’est triste, et je ne sais pas très bien pourquoi
C’est peut-être parce que la baisse de la capacité d’attention rend plus difficile l’élargissement efficace de ses connaissances, et parce que la position actuelle est devenue trop confortable
Ou peut-être parce que les récompenses qui poussent à n’apprendre qu’un framework précis sont trop fortes, tandis que les incitations à comprendre les bases de son fonctionnement interne sont trop faibles
Ils n’ont donc pas le temps de tirer des leçons de leur travail actuel, et il est très probable qu’ils soient déjà partis au moment où ces leçons les atteignent
En même temps, ils n’ont pas le luxe de ne pas se concentrer sur les nouvelles technos à la mode
Cette dynamique freine fortement la progression
Mon conseil à deux centimes est celui-ci : l’état est l’ennemi. Il faut réduire l’état partout où c’est possible
Cela inclut non seulement l’état dans le code, mais aussi le nombre de choses qu’il faut garder en mémoire à court terme pour travailler, ainsi que tous les détails spécifiques à un projet dont il faut se souvenir
L’état est l’ennemi. Si l’on peut le déduire à partir des premiers principes, il faut toujours essayer de le faire
Certains de ces conseils dépassent le cadre des seuls programmeurs
Le premier point mérite que tout le monde y réfléchisse. Beaucoup d’auteurs et d’essayistes sont lus non pas parce qu’ils sont experts du sujet, mais parce qu’ils écrivent bien
Il faut aussi aller marcher
Il est bon d’essayer différents types de tâches et d’apprendre aussi d’autres fonctions au sein de l’entreprise
Surtout dans les grandes entreprises, ce que je fais peut être quelque chose qui doit ensuite être corrigé ou contourné ailleurs ; si je le change, cela peut rendre la vie plus facile à tout le monde
Le premier point est aussi une raison de se méfier de ce qu’on apprend sur des services de partage de vidéos comme YouTube
Quand quelqu’un parle avec assurance et présente ses idées de manière professionnelle, les gens les prennent au sérieux même si elles sont défectueuses
Dans un monde où il est apparu que certains « essayistes » ne faisaient en réalité guère plus que lire des articles Wikipedia et des posts Reddit, il faut s’efforcer de dissocier la vraisemblance de la présentation de l’exactitude
J’aimerais aussi prolonger le point 10. En parlant avec les personnes concernées, on voit mieux quel problème le logiciel ou le travail de développement cherche à résoudre, et on découvre aussi des points de douleur qu’on n’avait pas vus soi-même
À de très rares exceptions près, on n’écrit pas du logiciel pour lui-même, mais pour résoudre un problème
Quelque part sur Internet ou dans le processus d’entraînement, ils peuvent avoir lu une réponse « correcte » et la répéter de façon plausible sans se demander si elle est réellement vraie
J’aime tellement le livre sur le débogage recommandé dans l’article que j’en ai acheté plusieurs exemplaires pour les offrir
Je l’ai donné à des amis, des stagiaires, des data scientists, et même à des cadres dirigeants ; toutes les personnes qui l’ont lu m’ont remercié
Il contient quelques techniques simples et utiles à presque tout le monde pour résoudre des problèmes dans de grands systèmes techniques
Il est facile à lire et intéressant, avec beaucoup d’« histoires de guerre » qui ajoutent de la couleur et du contexte à des conseils qui pourraient autrement être arides
https://debuggingrules.com/
L’idée selon laquelle « les gens m’écoutent non pas parce que je suis un bon programmeur, mais parce que je suis bon rédacteur » ne signifie pas seulement qu’il faut se méfier lorsqu’on lit les contenus de quelqu’un qui écrit bien ; elle s’applique aussi à notre façon d’aborder notre travail.
Bien écrire améliore généralement aussi la capacité à interagir avec les autres.
Pour un développeur logiciel, l’écriture et la communication font partie du cœur du métier.
Si vous débutez, je vous recommande de mettre par écrit les difficultés rencontrées, vos expérimentations et votre cheminement de pensée.
Si possible, écrivez aussi des essais. Ce sera une compétence vraiment utile plus tard dans votre carrière.
Il y a une phrase difficile à expliquer correctement aux débutants : « votre travail n’est pas d’écrire du code ».
Nous utilisons le code comme un outil pour résoudre des problèmes.
Le code est un moyen d’atteindre un objectif, pas l’objectif lui-même.
Si vous codez pour le code lui-même, vous obtiendrez de mauvais résultats.
Il faut se concentrer sur la résolution de problèmes ; si vous ne savez pas clairement quel problème votre code résout, arrêtez de coder et commencez par le déterminer.
Selon l’entreprise, il peut s’agir d’e-mails.
Répondre aux questions, collaborer, influencer la direction de l’équipe et de l’organisation peut donner l’impression d’être le travail lui-même, mais la communication, comme le code, est un outil pour produire quelque chose d’utile ; elle n’est pas utile en soi.
La plupart du code, même le code écrit « pour le code », résout tout de même un problème.
Beaucoup de programmeurs le savent, au moins inconsciemment, et c’est pour cela qu’ils écrivent ce type de code.
Le vrai problème, c’est que d’autres personnes — par exemple les profils business en costume — veulent que ce code résolve un autre problème.
Mais ce code doit être le bon code.
Plus généralement, on peut décrire le travail comme « résoudre des problèmes business en appliquant des systèmes logiciels ».
Dit ainsi à un junior, cela l’amène à se concentrer sur les besoins business, et à juger de façon critique les propos des MBA, des managers ou des PM afin de faire ce qu’il faut.
Mais le fait même d’avoir un logiciel à vendre à des VC a de la valeur.
Donc, parfois, vous êtes réellement payé pour écrire du code.