Nouveaux programmeurs, bienvenue dans l’industrie du développement logiciel, sans avoir à investir une carrière de dix ans pour apprendre ces leçons à la dure.
Maintenant, certaines choses ne peuvent être apprises que par l’expérience. Je peux vous dire que ces choses sont importantes, ou qu’elles se produisent vraiment dans l’industrie, mais vous ne me croirez peut-être pas avant de les voir se produire dans votre propre carrière. La décision vous appartient, mais voici les conseils à votre avantage, si vous choisissez de les apprendre facilement.
1. Les compétences humaines sont également importantes pour les programmeurs
Vous êtes fraîchement sorti de l’université. Votre tête est un jardin où vous plantez beaucoup de choses intéressantes et créatives – après tout, vous allez y vivre le reste de votre vie, alors pourquoi pas? Vous êtes réticent à laisser entrer les gens parce qu’ils pourraient détruire et ruiner tout votre travail acharné avec leurs propres façons de penser et de faire les choses. Vous êtes bon pour assimiler — trouver de nouvelles idées, les décomposer et les analyser, puis les planter dans le vaste magasin de données de votre cerveau de programmeur. Cela décrit assez bien la plupart des programmeurs, et cela m’a certainement décrit. Si c’est le cas, vous êtes dans un ajustement complet.
Il a fallu près de la moitié de ma carrière de dix ans dans l’informatique pour réaliser que les gens peuvent parfois être difficiles à travailler, et que le travail d’un programmeur comprend bien plus que de simplement travailler avec des ordinateurs. Avant de travailler avec des ordinateurs, quelqu’un doit déterminer à quoi il veut réellement dépenser son argent — l’argent avec lequel vous êtes payé. Une fois qu’ils l’auront compris, il y aura beaucoup de temps passé dans les réunions à discuter de tout et de tout à ce sujet — combien de temps cela va prendre, quelle est la bonne façon de le concevoir et qui doit être impliqué. Ces discussions sont rarement rapides ou faciles, et si vous avez déjà du mal à communiquer efficacement et à persuader les gens de vos convictions, cela ne deviendra pas plus facile lorsque vous devrez utiliser des termes techniques que tout le monde ne comprendra pas. Si, comme le programmeur typique décrit précédemment, vous êtes timide ou réservé et évitez de parler en réunion, c’est un autre obstacle sur votre chemin.
Ensuite, ajoutez au mélange le fait que tout le monde n’est pas facile à comprendre, et vous avez une recette pour les problèmes. La plupart des programmeurs manquent déjà de compétences humaines, alors ils imaginent le frisson de ne travailler qu’avec des ordinateurs, quelque chose qu’ils comprennent beaucoup mieux que les gens. Comme l’explique le paragraphe précédent, c’est l’inverse. Qu’on le veuille ou non, vous passerez beaucoup plus de temps à travailler avec les gens qu’avec les ordinateurs. Au moment où vous arriverez enfin à vous retrousser les manches et à commencer à « coder comme le vent », vous en aurez probablement marre des réunions et vous en aurez assez d’être traité comme une ressource plutôt que valorisé pour votre expertise. Bien que chaque entreprise soit différente, les entreprises ayant une culture d’entreprise conviviale et confortable sont difficiles à trouver. Non seulement cela, mais les choses changent même de jour en jour.
2. Expertise sans autorité
Très souvent, vos idées sur ce qui sera une solution logicielle utile entrent radicalement en conflit avec les idées des personnes qui prennent réellement ces décisions. Vous devez être capable de vivre avec cela, de travailler sur des projets redoutables / fastidieux et de prendre vos morceaux comme un adulte. Fred Brooks dans Le Mythique Mois de l’Homme a appelé cette expertise sans autorité.
Il est beaucoup plus probable que vous finissiez par conserver le code mal écrit de quelqu’un d’autre d’il y a 10 ans, réveillé par un téléavertisseur bourdonnant à 3 heures du matin lors de votre quart de travail de support, que d’être choisi pour écrire une nouvelle application Web complète à partir de zéro, avec tous les nouveaux outils juteux que vous lisez et salivez. Après tout, les nouveaux outils peuvent coûter cher, et ce n’est généralement pas vous qui prenez les décisions.
Bien sûr, c’est une idée stupide de tondre une pelouse entière avec un mangeur de mauvaises herbes. Mais lorsque vous demandez une tondeuse à gazon et qu’on vous dit « Non », vous pouvez soit jeter l’éponge, soit vous contenter du mangeur de mauvaises herbes.
3. La curiosité naturelle pour expérimenter est UN MUST
Avoir une bonne compréhension de la syntaxe, de la sémantique et du langage — comme vous pourriez gagner en étant un majeur en anglais, en mathématiques ou en ingénierie — fait de vous un bon programmeur, mais ce n’est pas tout.
Plus grand que cela, c’est de ne pas avoir peur d’essayer des choses — de pousser des boutons — de faire des erreurs — de voir ce qui se passe. Fouillez un peu. Écrivez un mauvais code et regardez-le tomber à plat sur son visage. C’est la principale et la meilleure façon d’en apprendre davantage sur les ordinateurs. Si vous comptez sur les autres pour le comprendre pour vous, vous ne faites que vous limiter. Vous devez être prêt à l’essayer vous-même et apprendre des résultats, bons ou mauvais.
4. Le compilateur / ordinateur exige une perfection absolue
Imaginez ne pas pouvoir envoyer un e-mail avant d’avoir corrigé chaque erreur de grammaire, mot mal orthographié et virgule manquante. Ça a l’air ridicule ? Avec un ordinateur comme patron, cela décrit CHAQUE e-mail. Sauf qu’au lieu d’un e-mail, nous parlons d’écrire un programme informatique.
Atteindre la perfection nécessite beaucoup d’engagement, de motivation et de persévérance — plus que beaucoup de gens. Le programmeur potentiel n’est peut-être pas suffisamment motivé ou persistant pour franchir les obstacles, les erreurs, les bogues, les spécifications techniques de 100 pages et les défis de débogage pour enfin atteindre cette dernière étape de la perfection absolue. C’est un long chemin à parcourir, surtout sans curiosité naturelle et aptitude linguistique.
5. Les idées sont simples; les programmes informatiques sont complexes
Lors de la programmation, vous demandez à l’ordinateur de faire quelque chose. L’ordinateur peut être fait pour faire à peu près tout ce que vous pouvez imaginer. Vous travaillez avec des idées pures abstraites. Cela peut ressembler au ciel, et il y a certainement de bonnes choses à ce sujet; mais comme tout le reste, cela a ses inconvénients.
Souvent, les idées semblent très simples. Une idée unique et nouvelle semble assez simple pour les êtres humains qui possèdent une intelligence inhérente aux concepts du monde réel. Les ordinateurs manquent de cet intellect inhérent, de sorte que même l’idée la plus simple, traduite en langage informatique, devient rapidement compliquée. Trouver les bonnes instructions est une tâche difficile, même pour les programmeurs experts et chevronnés— en particulier pour quelque chose qui n’a pas été fait auparavant. Et si cela a été fait auparavant, pourquoi ne pas simplement acheter ce programme, au lieu d’en écrire un nouveau? Le temps d’un programmeur coûte cher – généralement 30/ / heure ou plus. Si un programme coûte 30 $ par utilisateur, ce programme peut généralement être acheté en permanence. Même si cela coûte 300 $ par utilisateur, cela reste beaucoup moins cher que 30/ / heure.
6. Toutes les erreurs ne sont pas un bug
De nombreux nouveaux programmeurs sont intimidés la première fois qu’ils construisent ou compilent quelque chose, seulement pour avoir 50 marques rouges, des lignes gribouillées, ou des erreurs et des avertissements apparaissent. Pour aggraver les choses, chaque erreur est une absurdité cryptique comme « un membre non statique ne peut pas être consulté à partir d’un contexte statique. »
Mon conseil à vous: détendez-vous! Détendez-vous une seconde. Toutes les erreurs ne sont pas un bogue. Toutes les erreurs ne sont pas de votre faute. Toutes les erreurs ne doivent même pas être corrigées immédiatement. De plus, les erreurs PEUVENT être corrigées.
La plupart des éditeurs de code modernes seront tellement occupés à trouver des erreurs, avant même que vous ayez fini de taper le code, qu’il peut rapidement sembler impossible de mettre les crochets aux bons endroits. Encore une fois — calmez-vous, reculez et réalisez que ce n’est pas aussi grave qu’il n’y paraît.
Je programme depuis plus d’une décennie, et je ne pense pas avoir déjà écrit un programme qui fonctionnait parfaitement la première fois que je l’ai essayé. Il va y avoir des erreurs dans votre code! Habituez-vous à l’idée de voir ces marques agaçantes, rouges et squiggly partout.
Ensuite, une erreur n’est pas nécessairement un bogue. Oui, les erreurs doivent être corrigées éventuellement, avant de pouvoir exécuter votre programme. Cependant, l’effort de suppression des bogues est secondaire à côté de la tâche d’écriture du code. Et comme indiqué précédemment, la plupart des éditeurs d’aujourd’hui trouveront TOUTES les erreurs possibles bien avant que vous ayez fini d’écrire le code. Cela ne rend pas ces erreurs plus importantes que ce que vous faisiez déjà. Ne les laissez pas vous faire trébucher; ils vont se produire, alors soyez prêt et apprenez à les mettre en attente jusqu’à ce que vous ayez compris les choses. En apprenant à penser comme un ordinateur, vous commencerez à comprendre quelles erreurs sont importantes et quelles sont les parties manquantes de votre programme que vous n’avez pas encore terminées.
Pour résumer: rouge, squiggly et ennuyeux (une erreur) ne se traduit pas automatiquement par important.
7. Aucune erreur ne signifie pas aucun bogue
Imaginez-vous assis après beaucoup de travail acharné, satisfait que vous ayez enfin corrigé toutes ces erreurs gênantes. Maintenant, vous pouvez être sur votre chemin joyeux, n’est-ce pas? Faux.
Toutes les erreurs ne sont pas un bogue, et l’inverse est également vrai: un manque d’erreurs n’est pas nécessairement un manque de bugs. Ce n’est pas parce que votre code n’a pas d’erreurs qu’il fonctionnera correctement. Généralement, vous devez supposer que votre code ne fonctionnera pas correctement, même après avoir corrigé toutes les erreurs.
Il existe deux types généraux d’erreurs : les erreurs de compilation (de type rouge, gribouillé) et les erreurs d’exécution ou de logique. C’est de ce dernier que nous parlons maintenant.
Dites que votre code s’exécute réellement. Cela signifie que l’ordinateur le comprend et est capable de l’exécuter, mais cela ne signifie pas que les instructions elles-mêmes ne sont pas défectueuses. Ce que votre cerveau propose la première fois a du sens pour vous, mais un ordinateur a généralement besoin de plus de détails qu’un cerveau humain pour comprendre un processus ou un algorithme.
Un exemple parfait consiste à diviser par zéro. Cette expression mathématique n’est pas définie, mais le problème n’est pas apparent si vous divisez simplement x par y. x ou y peuvent être n’importe quoi. Ce n’est que lorsque le programme est en cours d’exécution que y a une valeur réelle, qui peut ou non être nulle.
8. Résoudre LE problème, pas seulement un problème
Il est incroyablement facile lors du dépannage ou du débogage de se perdre dans la confusion quant au véritable problème: faire passer vos fils et passer des heures de manière improductive à chasser une oie qui n’a rien à voir avec le problème réel.
Devenir un meilleur programmeur a beaucoup à voir avec la capacité d’identifier rapidement la cause profonde d’un problème — puis de le résoudre. Comme j’aime le dire, résolvez LE problème.
Dans le processus, vous rencontrez souvent des problèmes mineurs et connexes qui peuvent également nécessiter une correction — Un problème, mais pas LE problème. Ne reculez pas juste parce que vous avez résolu quelque chose. Il faut beaucoup de concentration pour résoudre un problème jusqu’à la fin.
Le débogage est souvent considéré comme étant effectué à 99%, la plupart du temps que le débogage prend. En effet, jusqu’à ce que la cause profonde soit réellement connue, savoir combien de temps il faudra pour la résoudre est une discussion discutable. Trouver la cause profonde peut souvent prendre beaucoup de temps en soi.
Ainsi, rappelez-vous ces règles simples pour le dépannage et le débogage:
A) TESTEZ toujours votre code
B) Vérifiez la santé mentale et validez tout — en particulier les choses dont vous pensez qu’elles n’en ont pas besoin
C) Essayez de ne pas faire de changements « brusques », une supposition aléatoire pour inciter l’erreur à disparaître; ceux-ci introduisent souvent plus de problèmes
D)Puis REVÉRIFIEZ
Le débogage en soi est une simple preuve que les ordinateurs ou les robots ne envahiront jamais le monde. Montrez-moi un ordinateur qui peut se déboguer, et je vous montrerai un monde qui n’a pas besoin de programmeurs.
9. Le problème fondamental du développement de logiciels
Peu importe la qualité de votre programme ou logiciel, quelqu’un trouvera un moyen de l’utiliser mal, mais sera totalement convaincu que cela devrait fonctionner de cette façon. Ne me croyez pas ? Développez un logiciel, publiez-le et lisez les commentaires et les e-mails que vous recevez. Vous constaterez bientôt que c’est absolument vrai.
Chacun a sa propre façon de travailler. Une taille ne peut jamais convenir à tous, mais malheureusement pour vous en tant que programmeur, une taille est BEAUCOUP moins chère et plus efficace que trois ou quatre tailles. Vous aurez rarement la chance d’implémenter toutes les fonctionnalités possibles — toutes les cloches et les sifflets auxquels vous pouvez penser. Souvent, c’est tout le contraire que la direction vous demande. Ils veulent un produit minimum viable (MVP) pour tester le concept et voir si les clients l’aiment et si la version à part entière vaudra même la peine d’être construite.
10. La technologie est une cible imprévisible et mobile
Parfois, les gens ne peuvent pas se décider sur ce qu’ils veulent — et vous devez faire face aux conséquences, voire nettoyer le désordre. Edward Berard l’a dit de cette façon: « Marcher sur l’eau et développer un logiciel à partir d’une spécification sont faciles si les deux sont gelés. »Parfois, les exigences changeront au milieu du projet, et vous devrez vous ajuster et vous adapter, un peu comme si vous utilisiez le moteur d’une voiture pendant que vous conduisez sur l’autoroute. Fou, mais vrai.
Au moment où vous avez terminé votre projet, vous constaterez peut-être qu’il est devenu obsolète ou inutile. Peut-être une bibliothèque ou un framework cela dépend des besoins mis à jour, et votre entreprise ne veut pas financer la mise à niveau. Peut-être que vous le livrez réellement aux clients et qu’ils ne veulent même pas l’utiliser (j’ai vu cela arriver à mon propre projet).
La technologie dépend de l’interaction réussie entre les personnes et les autres personnes, les personnes et les ordinateurs, et les ordinateurs avec d’autres ordinateurs. Les personnes et les ordinateurs peuvent être imprévisibles, et toute cette imprévisibilité inhérente ne disparaîtra pas simplement parce que vous le souhaitez.
11. L’estimation est difficile
Les projets les plus intéressants et les plus précieux sont normalement ceux qui n’ont jamais été réalisés auparavant. Parce qu’ils n’ont jamais été faits, estimer le temps qu’ils vont prendre est un point particulier de frustration, de difficulté et de douleur. L’imprévisibilité (point 10 ci-dessus) est par définition difficile à prévoir!
Les dirigeants d’entreprise ne veulent jamais savoir combien de temps quelque chose va prendre. Ils sont généralement intéressés par la façon de le faire plus rapidement et avec un budget minimal.
Les programmeurs ne veulent jamais entendre le peu de temps ou le peu de ressources dont ils disposeront. Ils ont besoin de temps libre pour l’innovation et la recherche. Ils ont besoin de nouveaux outils coûteux pour coder plus rapidement et mieux. La programmation est à la fois technique et créative, et elle ne peut être précipitée sans gâcher le résultat final — mais c’est souvent le cas. Une chaîne de montage ne fonctionne qu’avec un processus simple, qui change peu et qui peut être répété à l’infini — aucun d’entre eux ne s’applique au développement de logiciels. Cela ne semble jamais empêcher les gestionnaires d’essayer d’en faire une chaîne de montage.
L’effort d’estimation est la bataille sans fin dans laquelle vous êtes sur le point de vous lancer en tant que programmeur. En conclusion de cet aperçu de carrière, je ne peux que dire: n’oubliez pas de rire et de vous amuser. Vous trouverez peut-être un jour que l’humour est ce qui vous a amené à la fin avec votre santé mentale intacte.
Les programmeurs PS sont maintenant plus précieux pour les entreprises que l’argent. Ne soyez pas trop dur avec vous-même; l’ordinateur s’en chargera. Donnez-vous une tape dans le dos pour vous intéresser à une profession aussi difficile mais enrichissante.