Apprendre comment devenir un bon programmeur

Robert L. Read with Community

Traducteurs

| vavavoum74 | bboulch |

Pour réagir au contenu de ce tutoriel, un espace de dialogue vous est proposé sur le forum. Commentez

- Titre : Apprendre comment devenir un bon programmeur

- Auteur : Robert L. Read with Community

- Traducteurs : vavavoum74, bboulch

- Parution : 12 avril 2019

- Mise à jour : 6 septembre 2019

- Licence : Comment devenir un bon programmeur (How To Be A Programmer : Community Version by Robert L. Read with Community) est sous licence Creative Commons Attribution-ShareAlike 4.0 International License.

Sommaire

- I. Introduction

- II. Débutant

- II-A. Compétences personnelles

- II-A-1. Apprendre à déboguer

- II-A-2. Comment déboguer en décomposant le problème

- II-A-3. Comment enlever une erreur

- II-A-4. Comment déboguer en utilisant un journal

- II-A-5. Comment comprendre les problèmes de performance

- II-A-6. Comment remédier aux problèmes de performance

- II-A-7. Comment optimiser les boucles

- II-A-8. Comment traiter les dépenses d'E/S

- II-A-9. Comment gérer la mémoire

- II-A-10. Comment traiter les bogues intermittents

- II-A-11. Comment apprendre les compétences en design

- II-A-12. Comment faire des expériences

- II-B. Compétences d’équipe

- II-B-1. Pourquoi l’estimation est importante

- II-B-2. Comment estimer le temps de programmation

- II-B-3. Comment trouver l’information

- II-B-4. Comment utiliser les personnes comme source d’information

- II-B-5. Comment documenter judicieusement

- II-B-6. Comment travailler avec un code médiocre

- II-B-7. Comment utiliser le contrôle de code source

- II-B-8. Comment faire des tests unitaires

- II-B-9. Prenez des pauses lorsque vous êtes bloqué

- II-B-10. Comment reconnaître quand rentrer chez soi

- II-B-11. Comment traiter avec les personnes difficiles

- III. Intermédiaire

- III-A. Compétences personnelles

- III-A-1. Comment rester motivé

- III-A-2. Comment être digne de confiance

- III-A-3. Comment concilier temps et espace

- III-A-4. Comment faire des tests de stress

- III-A-5. Comment équilibrer la brièveté et l'abstraction

- III-A-6. Comment apprendre de nouvelles compétences

- III-A-7. Apprenez à taper au clavier

- III-A-8. Comment faire des tests d'intégration

- III-A-9. Les langages de communication

- III-A-10. Les outils importants

- III-A-11. Comment analyser les données

- III-B. Compétences de l’équipe

- III-B-1. Comment gérer le temps de développement

- III-B-2. Comment gérer les risques liés aux logiciels tiers

- III-B-3. Comment gérer les consultants

- III-B-4. Comment communiquer de la bonne manière

- III-B-5. Comment être en désaccord honnêtement et s'en tirer

- III-C. Jugement

- III-C-1. Comment concilier qualité et temps de développement

- III-C-2. Comment gérer la dépendance des systèmes logiciels

- III-C-3. Comment décider si un logiciel est trop immature

- III-C-4. Comment décider d’acheter ou de fabriquer

- III-C-5. Comment grandir professionnellement

- III-C-6. Comment évaluer les candidats à l’embauche

- III-C-7. Comment apprendre quand utiliser des techniques sophistiquées de science informatique

- III-C-8. Comment parler aux non-ingénieurs

- IV. Avancé

- IV-A. Jugement technique

- IV-A-1. Comment discerner le difficile de l’impossible

- IV-A-2. Comment utiliser des langages intégrés

- IV-A-3. Choisir des langages

- IV-B. Faire des compromis judicieusement

- IV-B-1. Comment lutter contre la pression du calendrier

- IV-B-2. Comment comprendre les utilisateurs

- IV-B-3. Comment obtenir une promotion

- IV-C. Servir votre équipe

- IV-C-1. Comment développer les talents

- IV-C-2. Comment choisir sur quoi travailler

- IV-C-3. Comment tirer le meilleur parti de vos coéquipiers

- IV-C-4. Comment diviser les problèmes

- IV-C-5. Comment gérer les tâches ennuyeuses

- IV-C-6. Comment réunir du soutien pour un projet

- IV-C-7. Comment faire grandir un système

- IV-C-8. Comment bien communiquer

- IV-C-9. Comment dire aux gens les choses qu’ils ne veulent pas entendre

- IV-C-10. Comment gérer les mythes managériaux

- IV-C-11. Comment gérer le chaos organisationnel

- V. Note de la Rédaction de Developpez.com

I - Introduction

Être un bon programmeur est difficile et noble. La chose la plus difficile pour concrétiser une vision collective d’un projet de logiciel est de traiter avec ses collègues et ses clients. L'écriture de programmes informatiques est importante et requiert beaucoup d'intelligence et de compétences. Mais c’est vraiment un jeu d’enfant comparé à tout ce qu’un bon programmeur doit faire pour créer un système logiciel qui réussisse à la fois pour le client et pour la myriade de collègues dont il est partiellement responsable. Dans cet essai, je tente de résumer le plus succinctement possible les explications que j’aurais aimé recevoir à l'âge de vingt et un ans. Ceci est très subjectif et par conséquent, cet essai est condamné à être personnel et à refléter mes opinions. Je me limite aux problèmes qu’un programmeur risque de rencontrer dans son travail. Bon nombre de ces problèmes et de leurs solutions sont si inhérent à la condition humaine que je semblerai probablement moralisateur. J'espère malgré tout que cette contribution sera utile.

La programmation informatique est enseignée dans des cours. Les excellents livres : The Pragmatic Programmer [Prag99], Code Complete [CodeC93], Rapid Development [RDev96] et Extreme Programming Explained [XP99] enseignent tous la programmation informatique et les plus gros obstacles à surmonter pour être un bon programmeur. Les essais de Paul Graham [PGSite] et Eric Raymond [Hacker] devraient certainement être lus avant ou avec cet article. Cet essai diffère de ces excellents travaux en mettant l'accent sur les problèmes sociaux et en résumant de manière exhaustive l'ensemble des compétences nécessaires telles que je les vois.

Dans cet essai, le terme « patron » est utilisé pour désigner quiconque vous donne des projets à faire. J'utilise les mots « business », « entreprise » et « clan », comme synonymes, à l'exception du fait que « business » signifie « gagner de l'argent », que « entreprise » désigne le lieu de travail et que le « clan » est de façon générale l’ensemble des personnes de votre milieu professionnel.

Bienvenue dans le clan.

II - Débutant

II-A - Compétences personnelles

II-A-1 - Apprendre à déboguer

Le débogage est la pierre angulaire du programmeur. Le premier sens du verbe « déboguer » est de supprimer les erreurs, mais le sens qui importe vraiment est de voir l'exécution d'un programme en l'examinant. Un programmeur qui ne peut pas déboguer efficacement est aveugle.

Les idéalistes, ceux qui pensent que le design, l'analyse, les théories complexes et autres sont plus fondamentales que le débogage, ne sont pas des programmeurs en activité. Le programmeur qui travaille ne vit pas dans un monde idéal. Même si vous êtes parfait, vous êtes entouré et devez interagir avec le code écrit par des éditeurs de logiciels importants, des organisations comme GNU et vos collègues. L’essentiel de ce code est imparfait et insuffisamment documenté. Sans la possibilité de voir l'exécution de ce code, la moindre imperfection vous bloquera définitivement. Souvent, cette visibilité ne peut être obtenue que par l'expérimentation, c’est cela déboguer.

Le débogage concerne l’exécution des programmes, pas les programmes eux-mêmes. Si vous achetez quelque chose d'un grand éditeur de logiciels, vous ne verrez généralement pas le programme. Mais il restera toujours des endroits où le code ne sera pas conforme à la documentation (le crash de votre ordinateur est un exemple courant et spectaculaire) ou bien où la documentation est muette. Plus généralement, vous créez une erreur, examinez le code que vous avez écrit et n’avez aucune idée de la façon dont l’erreur peut se produire. Inévitablement, cela signifie que certaines des hypothèses que vous faites ne sont pas tout à fait correctes ou que certaines conditions n’ont pas été anticipées. Parfois, le tour de magie qui consiste à regarder dans le code source fonctionne. Quand ce n'est pas le cas, vous devez déboguer.

Pour avoir une visibilité sur l'exécution d'un programme, vous devez être capable d'exécuter le code et de l'observer. Parfois, cela est visible, comme ce qui est affiché sur un écran, ou le délai entre deux événements. Dans de nombreux autres cas, cela implique des éléments qui ne sont pas censés être visibles, tels que l'état de certaines variables dans le code, les lignes de code en cours d'exécution ou le fait que certaines assertions s'appliquent à une structure de données complexe. Ces choses cachées doivent être révélées.

- Utilisation d’un outil de débogage,

- Édition de ligne pour apporter une modification temporaire au programme, en ajoutant généralement des lignes imprimant des informations,

- Journalisation dans une fenêtre permanente montrant l'exécution des programmes sous la forme d'un journal.

Les outils de débogage sont formidables lorsqu'ils sont stables et disponibles, mais l’édition de ligne et la journalisation sont encore plus importants. Les outils de débogage sont souvent en retard sur le développement du langage, ils peuvent donc ne pas être disponibles à tout moment. De plus, comme l'outil de débogage peut modifier subtilement la façon dont le programme s'exécute, il peut ne pas être pratique. Enfin, certains types de débogage, tels que la vérification d'une assertion par rapport à une structure de données volumineuse, nécessitent l'écriture de code et la modification de l'exécution du programme. Il est bon de savoir comment utiliser les outils de débogage quand ils sont stables, mais il est essentiel de pouvoir utiliser les deux autres méthodes.

Certains débutants craignent le débogage lorsqu'il est nécessaire de modifier le code. C'est compréhensible. C'est un peu comme une chirurgie exploratoire. Mais vous devez apprendre à manipuler le code et à le faire sauter ; vous devez apprendre à expérimenter et à comprendre que rien de ce que vous faites temporairement ne fera empirer les choses. Si vous ressentez cette peur, recherchez un mentor. Nous perdons beaucoup de bons programmeurs au délicat moment de leur apprentissage de cette peur.

II-A-2 - Comment déboguer en décomposant le problème

Le débogage est amusant, car il commence par un mystère. Vous pensez que le programme devrait faire quelque chose, mais au lieu de cela, il fait autre chose. Ce n'est pas toujours aussi simple - les exemples que je peux donner seront artificiels par rapport à ce qui se passe parfois dans la pratique. Le débogage nécessite créativité et ingéniosité. S'il n'y a qu'une seule clé pour le débogage, c'est d'utiliser la technique diviser pour mieux régner afin de résoudre le mystère.

Supposons, par exemple, que vous ayez créé un programme devant exécuter dix tâches successives. Lorsque vous l'exécutez, il se bloque. Comme vous ne l'avez pas programmé pour qu’il se bloque, vous avez maintenant un mystère. Lorsque vous examinez la sortie, vous constatez que les sept premières opérations de la séquence ont été exécutées avec succès. Les trois derniers ne sont pas visibles sur la sortie. Votre mystère est donc plus petit: « Il s’est bloqué sur les objets n° 8, n° 9 ou n° 10 ».

Pouvez-vous concevoir une expérience pour voir sur quoi il s'est bloqué? Bien sûr. Vous pouvez utiliser un débogueur ou nous pouvons ajouter des instructions d’édition de ligne (ou l’équivalent dans la langue dans laquelle vous travaillez) après les numéros 8 et 9. Lorsque nous le repasserons à nouveau, notre mystère sera plus petit, comme «C’est bloqué par la chose n ° 9». Je trouve que garder à l’esprit ce qu’est le mystère à tout moment permet de rester concentré. Lorsque plusieurs personnes travaillent ensemble sous la pression pour résoudre un problème, il est facile d’oublier ce qui est le plus important dans le mystère.

La clé de diviser pour mieux régner en tant que technique de débogage est la même que pour la conception d’algorithmes : tant que vous faites du bon travail en décomposant le mystère au milieu, vous n’aurez pas à le diviser trop souvent et vous déboguerez rapidement. Mais quel est le milieu d'un mystère? C'est ici qu'interviennent la vraie créativité et l'expérience.

Pour un vrai débutant, l’espace de toutes les erreurs possibles ressemble à toutes les lignes du code source. Vous n’avez pas la vision que vous développerez plus tard pour voir les autres dimensions du programme, telles que l’espace des lignes exécutées, la structure de données, la gestion de la mémoire, l’interaction avec du code étranger, le code présentant des risques et le code qui est simple. Pour le programmeur expérimenté, ces autres dimensions forment un modèle mental imparfait mais très utile de tout ce qui peut mal se passer. Avoir ce modèle mental est ce qui aide à trouver efficacement le centre du mystère.

Une fois l'espace de travail subdivisé de manière égale pour tout ce qui peut mal tourner, vous devez essayer de décider dans quel espace se trouve l'erreur. Dans le cas simple où le mystère est: « Quelle ligne inconnue bloque mon programme ? », Vous pouvez vous poser la question suivante: « La ligne inconnue est-elle exécutée avant ou après cette ligne que j'estime être exécutée au milieu du programme en cours ? » Habituellement, vous ne serez pas assez chanceux pour savoir que l'erreur existe sur une seule ligne, voire sur un seul bloc. Le mystère ressemble souvent davantage à ceci: « Soit un pointeur dans ce graphique pointe vers le mauvais nœud, soit mon algorithme qui additionne les variables de ce graphique ne fonctionne pas. ». Dans ce cas, vous devrez peut-être écrire un petit programme pour vérifier que les pointeurs du graphique sont tous corrects afin de décider quelle partie peut être éliminée de votre recherche.

II-A-3 - Comment enlever une erreur

J'ai volontairement séparé l'acte consistant à examiner l'exécution d'un programme de l'acte consistant à réparer une erreur. Mais bien sûr, le débogage signifie également l’élimination du bogue. Idéalement, vous aurez une parfaite compréhension du code et atteindrez le moment où vous verrez parfaitement l’erreur et saurez comment la corriger. Mais comme votre programme utilisera souvent des systèmes insuffisamment documentés et dans lesquels vous n’avez aucune visibilité, ce n’est pas toujours possible. Dans d'autres cas, le code est tellement compliqué que votre compréhension ne peut être parfaite.

En corrigeant un bogue, vous voudrez effectuer le changement le plus petit possible pour le réparer. Vous pouvez voir d'autres choses qui ont besoin d'amélioration; mais ne les corrigez pas en même temps. Essayez d'utiliser la méthode scientifique qui consiste à changer une chose et une seule chose à la fois. Pour ce faire, le mieux est de pouvoir facilement reproduire le bogue, puis de mettre en place votre correctif, puis de relancer le programme et d’observer que le bogue n’existe plus. Bien sûr, il est parfois nécessaire de modifier plusieurs lignes, mais vous devez toujours appliquer conceptuellement un seul changement atomique pour corriger le bogue.

Parfois, il y a vraiment plusieurs bogues qui ressemblent à un seul. C'est à vous de définir les bogues et de les corriger un à la fois. Parfois, il est difficile de savoir ce que le programme doit faire ou ce que l’auteur original voulait. Dans ce cas, vous devez utiliser votre expérience et votre jugement et attribuer votre propre idée au code. Décidez ce qu'il doit faire, commentez-le ou clarifiez-le d'une manière quelconque, puis adaptez le code à votre idée. Il s’agit d’une compétence intermédiaire ou avancée parfois plus difficile que d’écrire la fonction d’origine, mais le monde réel est souvent compliqué. Vous devrez peut-être réparer un système que vous ne pouvez pas réécrire.

II-A-4 - Comment déboguer en utilisant un journal

La journalisation consiste à écrire un système afin qu’il produise une séquence d’enregistrements informatifs, appelée journal. La ligne d'impression ne fait que produire un journal simple, généralement temporaire. Les débutants doivent comprendre et utiliser les journaux, car leur connaissance de la programmation est limitée. Les architectes système doivent comprendre et utiliser les journaux en raison de la complexité du système. La quantité d'informations fournie par le journal doit être configurable, idéalement pendant l'exécution du programme. En règle générale, les journaux offrent trois avantages de base :

- ils peuvent fournir des informations utiles sur les bogues difficiles à reproduire (tels que ceux qui se produisent dans l'environnement de production mais ne peuvent pas être reproduits dans l'environnement de test) ;

- ils peuvent également fournir des statistiques et des données relatives aux performances, telles que le temps qui s'écoule entre les instructions ;

- lorsqu'ils sont configurables, les journaux permettent de capturer des informations générales afin de déboguer des problèmes spécifiques non anticipés sans avoir à modifier et /ou redéployer le code uniquement pour traiter ces problèmes spécifiques.

La quantité d’informations à afficher dans le journal est toujours un compromis entre information et concision. Trop d'informations rendent le journal coûteux et génèrent « un aveuglement du défilement », ce qui rend difficile la recherche des informations dont vous avez besoin. Trop peu d’informations et il se peut qu’elles ne contiennent pas ce dont vous avez besoin. Pour cette raison, il est très utile de rendre la sortie configurable. En règle générale, chaque enregistrement du journal identifie sa position dans le code source, la tâche qui l’a exécuté le cas échéant, le moment précis de l’exécution et, en général, une information utile supplémentaire, telle que la valeur d’une variable, la quantité de mémoire disponible, le nombre d'objets de données, etc. Ces instructions de journal sont dispersées dans tout le code source, en particulier aux points de fonctionnalité majeure et autour du code à risque. Chaque instruction peut être affectée à un niveau et ne produira un enregistrement que si le système est actuellement configuré pour générer ce niveau. Vous devez concevoir les instructions de journal de manière à résoudre les problèmes que vous prévoyez. Anticipez le besoin de mesure de performance.

Si vous avez un journal permanent, vous pouvez désormais effectuer une impression sur la base des enregistrements de celui-ci et certaines instructions de débogage seront probablement ajoutées de manière permanente au système de journalisation.

II-A-5 - Comment comprendre les problèmes de performance

Apprendre à comprendre les performances d'un système en fonctionnement est inévitable pour la même raison que l'apprentissage du débogage. Même si vous comprenez parfaitement le coût du code que vous écrivez, votre code fera des appels vers d'autres systèmes logiciels sur lesquels vous avez peu de contrôle ou de visibilité. Cependant, dans la pratique, les problèmes de performances sont un peu différents et un peu plus faciles que le débogage en général.

Supposons que vous ou vos clients considériez un système ou un sous-système trop lent. Avant d'essayer de le rendre plus rapide, vous devez construire un modèle mental pour comprendre pourquoi il est lent. Pour ce faire, vous pouvez utiliser un outil de profilage ou un bon journal afin de déterminer le temps pendant lequelles autres ressources sont réellement utilisées. Il existe un dicton célèbre selon lequel 90% du temps sera consacré à 10% du code. J'ajouterais à cela l'importance des dépenses d'entrée/sortie (E/S) pour les problèmes de performances. Souvent, la plupart du temps est passé en entrée/sortie d'une manière ou d'une autre. Trouver la coûteuse E/S et les 10% coûteux du code est une bonne première étape dans la construction de votre modèle mental.

Les performances d’un système informatique comportent de nombreuses dimensions et de nombreuses ressources. La première ressource à mesurer est le temps d'horloge, le temps total écoulé pour le calcul. La journalisation de l'horloge est particulièrement utile car elle peut informer sur des circonstances imprévisibles qui se produisent dans des situations où d'autres analyses ne sont pas pratiques. Cependant, cela peut ne pas toujours représenter la situation dans son ensemble. Parfois, quelque chose qui prend un peu plus de temps, mais ne consomme pas autant de secondes processeur, sera bien meilleur dans l’environnement informatique auquel vous devez faire face. De même, les accès à la mémoire, à la bande passante du réseau, à la base de données ou à un autre serveur peuvent, finalement, être beaucoup plus coûteux que plusieurs secondes processeur.

La contention des ressources partagées qui sont synchronisées peut provoquer un blocage . Le blocage est l'impossibilité de continuer en raison d'une synchronisation incorrecte ou de demandes de ressources incorrectes. La famine est l’échec de la planification correcte d’un composant. Si cela peut être anticipé, il est préférable de pouvoir mesurer ce conflit dès le début de votre projet. Même si cette contention ne se produit pas, il est très utile de pouvoir l'affirmer avec certitude.

II-A-6 - Comment remédier aux problèmes de performance

La plupart des projets logiciels peuvent être réalisés avec relativement peu d'effort, 10 à 100 fois plus rapidement qu'au moment de leur première publication. Sous la pression des délais de mise sur le marché, il est à la fois sage et efficace de choisir une solution qui effectue le travail simplement et rapidement, mais de manière moins efficace qu'une autre solution. Cependant, la performance fait partie de la convivialité et doit souvent être considérée avec plus de soin.

La clé pour améliorer les performances d’un système très complexe est de l’analyser suffisamment pour permettre de localiser les goulots d’étranglement ou les endroits où la plupart des ressources sont utilisées. Il n’y a pas beaucoup de sens à optimiser une fonction qui ne représente que 1% du temps de calcul. En règle générale, vous devriez bien réfléchir avant de faire quoi que ce soit, à moins que vous ne pensiez que cela va rendre le système ou une partie importante de celui-ci au moins deux fois plus rapide. Il y a généralement un moyen de le faire. Examinez les efforts de test et d’assurance qualité que votre changement nécessitera. Chaque changement entraîne un fardeau de test, il est donc préférable d’effectuer quelques gros changements.

Une fois que vous avez doublé la performance de quelque chose, vous devez a minima repenser et peut-être réanalyser afin de découvrir le prochain goulot d'étranglement le plus coûteux du système, et de le corriger pour obtenir un autre doublement de performance .

Souvent, les goulots d'étranglement dans les performances seront un exemple de comptage des vaches en comptant les pattes et en divisant par quatre, au lieu de compter les têtes. Par exemple, j'ai commis des erreurs, en omettant de fournir un système de base de données relationnelle avec un index correct sur une colonne que je consultais souvent, ce qui l'a probablement rendu au moins 20 fois plus lent. D'autres exemples incluent les entrées/sorties inutiles dans les boucles internes, les instructions de débogage qui ne sont plus nécessaires, l'allocation inutile de mémoire et en particulier, l'utilisation inexacte des bibliothèques et autres sous-systèmes souvent mal documentés en termes de performances. Ce type d'amélioration est parfois appelé « fruit à portée de main », ce qui signifie qu'il peut être facilement choisi pour apporter une amélioration.

Que faites-vous lorsque vous commencez à manquer de fruits à portée de main? Eh bien, vous pouvez atteindre les branches plus hautes ou couper l’arbre. Vous pouvez continuer à apporter de petites améliorations ou sérieusement modifier la conception d'un système ou d'un sous-système, (C’est une excellente occasion d’utiliser vos compétences en tant que bon programmeur, non seulement pour la nouvelle conception, mais également pour convaincre votre supérieur que c’est une bonne idée.) Cependant, avant de vous lancer dans une nouvelle conception du sous-système, vous devriez vous demander si votre proposition le rendra cinq à dix fois meilleur.

II-A-7 - Comment optimiser les boucles

Vous rencontrerez parfois des boucles ou des fonctions récursives, dont l’exécution prend beaucoup de temps et qui constituent des goulots d’étranglement dans votre produit. Avant d'essayer de rendre la boucle un peu plus rapide, prenez quelques minutes pour déterminer s'il existe un moyen de la supprimer complètement. Un algorithme différent le ferait-il? Pourriez-vous calculer cela en calculant autre chose? Si vous ne trouvez pas de solution, vous pouvez optimiser la boucle. C'est simple : sortez des éléments de celle-ci. En fin de compte, cela nécessitera non seulement de l'ingéniosité, mais également une compréhension des dépenses associées à chaque type de déclaration et d'expression. Voici quelques suggestions:

- supprimer les opérations en virgule flottante ;

- n’allouez pas de nouveaux blocs de mémoire inutilement ;

- placez les constantes ensemble ;

- déplacez les E/S dans un tampon ;

- essayez de ne pas diviser ;

- essayez de ne pas faire de coûteuses conversions de type ;

- déplacez un pointeur plutôt que de recalculer des index.

Le coût de chacune de ces opérations dépend de votre système. Sur certains , les compilateurs et le matériel font ces choses pour vous. Un code clair et efficace est préférable à un code qui nécessite une compréhension d'une plate-forme en particulier.

II-A-8 - Comment traiter les dépenses d'E/S

Pour de nombreux problèmes, les processeurs sont rapides par rapport au coût de communication avec un périphérique matériel. Ce coût est généralement abrégé en E/S et peut inclure les coûts de réseau, les E/S de disque, les requêtes de base de données, les E/S de fichiers et toute autre utilisation de matériel éloigné du processeur. Par conséquent, la construction d’un système rapide est souvent davantage une question d’amélioration des E/S que d’amélioration du code dans une boucle optimisée, voire d’optimisation d’algorithme.

Il existe deux techniques fondamentales pour améliorer les E/S: la mise en cache et la représentation. La mise en cache consiste à éviter les E/S (en général, à éviter la lecture de certaines valeurs abstraites) en stockant une copie de cette valeur localement afin qu'aucune E /S ne soit exécutée pour obtenir la valeur. La première clé de la mise en cache consiste à préciser clairement quelles sont les données maîtresses et quelles sont les copies. Il n'y a qu'un seul maître par période. La mise en cache entraîne le risque que la copie ne puisse parfois pas refléter instantanément les modifications apportées au maître.

La représentation consiste à rendre les E/S moins coûteuses en représentant plus efficacement les données. Cela est souvent en conflit avec d’autres exigences, telles que la lisibilité humaine et la portabilité.

Les représentations peuvent souvent être améliorées par un facteur deux ou trois dès leur première mise en œuvre. Les techniques pour ce faire incluent l'utilisation d'une représentation binaire au lieu d'une représentation lisible par l'homme, la transmission d'un dictionnaire de symboles avec les données afin que les longs symboles ne soient pas codés, et de façon extrême, des choses comme le codage de Huffman.

Une troisième technique parfois possible consiste à améliorer la localisation de référence en rapprochant le calcul des données. Par exemple, si vous lisez des données dans une base de données et en calculez quelque chose de simple, comme une somme, essayez de demander au serveur de base de données de le faire pour vous. Cela dépend fortement du type de système avec lequel vous travaillez, mais vous devriez l'envisager.

II-A-9 - Comment gérer la mémoire

La mémoire est une ressource précieuse dont vous ne pouvez pas vous permettre de manquer. Vous pouvez l'ignorer pendant un moment, mais vous devrez éventuellement décider comment la gérer.

L'espace qui doit persister au-delà de la portée d'un seul sous-programme est souvent appelé « mémoire allouée dans le tas ». Une partie de la mémoire est inutile, donc sans intérêt, quand rien ne s'y réfère. Selon le système que vous utilisez, vous devrez peut-être explicitement libérer la mémoire vous-même lorsqu'elle est sur le point de devenir inutile. Le plus souvent, vous pourrez peut-être utiliser un système fournissant un ramasse-miettes. Un ramasse-miettes remarque la mémoire inutile et libère son espace sans aucune action requise par le programmeur. Le ramassage des miettes est merveilleux : il réduit les erreurs et augmente la brièveté du code et la concision à moindre coût. Utilisez-le quand vous le pouvez.

Mais même avec le ramassage des parties inutiles, vous pouvez saturer la mémoire. Une erreur classique consiste à utiliser une table de hachage comme cache et à oublier de supprimer les références de celle-ci. Puisque la référence reste, le référent ne peut être collecté et devient inutile. Ceci s'appelle une fuite mémoire. Vous devez rechercher et réparer rapidement les fuites mémoire. Si vos systèmes fonctionnent longtemps, la mémoire risque de ne jamais être épuisée au cours des tests, mais sera épuisée par l'utilisateur.

La création de nouveaux objets coûte moyennement cher sur n’importe quel système. La mémoire allouée directement dans les variables locales d'un sous-programme est toutefois généralement peu coûteuse, car la politique de libération de celle-ci peut être très simple. Vous devez éviter la création d'objets inutiles.

Un cas important se produit lorsque vous pouvez définir une limite supérieure sur le nombre d'objets dont vous aurez besoin à la fois. Si tous ces objets utilisent la même quantité de mémoire, vous pourrez peut-être allouer un seul bloc de mémoire, ou un tampon, pour tous les contenir. Les objets dont vous avez besoin peuvent être alloués et libérés à l'intérieur de cette mémoire tampon selon un modèle de rotation défini. C'est ce que l'on appelle parfois une mémoire tampon en anneau. C'est généralement plus rapide que l'allocation de tas.

Parfois, vous devez explicitement libérer de l’espace alloué pour pouvoir le ré-allouer plutôt que de vous fier à la récupération de place. Ensuite, vous devez appliquer une analyse prudente à chaque bloc de mémoire alloué et concevoir un moyen de le désallouer au bon moment. La méthode peut différer pour chaque type d'objet créé. Vous devez vous assurer que chaque exécution d'une opération d'allocation de mémoire est associée à une opération de libération mémoire . Cela est si difficile que les programmeurs implémentent souvent une forme rudimentaire de récupération de place, telle que le comptage de références, pour le faire à leur place.

II-A-10 - Comment traiter les bogues intermittents

Le bogue intermittent est un cousin de celui du « scorpion invisible de l'espace extra-atmosphérique d'une vingtaine de mètres ». Ce cauchemar se produit si rarement qu'il est difficile à observer, mais suffisamment souvent pour qu'il ne puisse être ignoré. Vous ne pouvez pas déboguer le problème car que vous ne le trouvez pas.

Bien que vous commenciez à en douter après 8 heures, le bogue intermittent doit obéir aux mêmes lois de la logique que tout le reste. Ce qui le rend difficile, c'est qu’il ne se produit que dans des conditions inconnues. Essayez de noter les circonstances dans lesquelles le bogue survient, de manière à pouvoir deviner ce qu’est la variabilité. La condition peut être liée à des valeurs de données, telles que « Cela ne se produit que lorsque nous saisissons le Wyoming en tant que valeur ». Si ce n’est pas la source de la variabilité, le prochain suspect doit être un problème de concurrence.

Essayez et essayez encore de reproduire le bogue de manière contrôlée. Si vous ne pouvez pas le reproduire, définissez un piège en construisant un système de journalisation, spécial si nécessaire, qui peut enregistrer ce dont vous avez besoin quand il se produit réellement. Résignez-vous à cela si le bogue ne survient qu'en production et pas à votre guise, le processus peut être long. Les astuces que vous obtenez du journal peuvent ne pas fournir la solution, mais peuvent vous fournir suffisamment d'informations pour améliorer la journalisation. Le système de journalisation amélioré peut prendre beaucoup de temps pour être mis en place. Ensuite, vous devez attendre que le bogue se reproduise pour obtenir plus d'informations. Ce cycle peut durer un certain temps.

Le bogue intermittent le plus stupide que j'ai jamais créé était dans une implémentation multitâches d'un langage de programmation fonctionnel pour un projet de classe. J'avais très soigneusement veillé à ce que le programme fonctionnel soit évalué correctement, en même temps que tous les processeurs disponibles (huit dans le cas présent). J'ai simplement oublié de synchroniser le ramasse-miettes. Le système pouvait fonctionner longtemps, finissant souvent la tâche que j'avais commencée, avant que tout ce qui était visible ne se passe mal. J'ai honte d'admettre que j'avais commencé à remettre en question le matériel avant que mon erreur ne me vienne à l'esprit.

Au travail, nous avons récemment eu un bogue intermittent qui nous a pris plusieurs semaines pour l’identifier. Nous avons des serveurs d'applications multitaches en Java «  derrière des serveurs Web Apache ». Pour conserver des changement de page rapides, nous effectuons toutes les E/S dans un petit ensemble de quatre threads distincts, différents des threads de changement de page. De temps en temps, ceux-ci se coincent et ne font plus rien d’utile, et ce, d’après notre journalisation, pendant des heures. Comme nous avions quatre taches, ce n’était pas un problème en soi - à moins que toutes les quatre ne soient bloqués. Ensuite, les files d'attente vidées par ces threads remplissaient rapidement toute la mémoire disponible et plantait notre serveur. Il nous a fallu environ une semaine pour comprendre cela et nous ne savions toujours pas ce qui le causait, quand cela se produirait à nouveau, ni même ce qu’étaient en train de faire les taches quand elles se trouvaient plantées.

Ceci illustre certains risques associés aux logiciels tiers. Nous utilisions un code sous licence qui supprimait les balises HTML du texte. Bien que nous disposions du code source (heureusement !), Nous ne l'avions pas étudié attentivement. En mettant en place la journalisation sur nos serveurs, nous avons finalement réalisé que les fils de messagerie se bloquaient dans ce code problématique sous licence.

Le programme a bien fonctionné, sauf sur certains types de textes longs et inhabituels. Sur ces textes, le code était quadratique ou pire. Cela signifie que le temps de traitement était proportionnel au carré de la longueur du texte. Si ces textes avaient été fréquents , nous aurions tout de suite trouvé le bogue. . En l'occurrence, il nous a fallu des semaines pour enfin comprendre et résoudre le problème.

II-A-11 - Comment apprendre les compétences en design

Pour apprendre à concevoir un logiciel, étudiez l'action d'un mentor en étant physiquement présent lors de la conception. Puis, étudiez des bouts de logiciels bien écrits. Après cela, vous pourrez lire des livres sur les dernières techniques de design.

Ensuite, vous devez le faire vous-même. Commencez avec un petit projet. Lorsque vous avez enfin terminé, étudiez comment la conception a échoué ou a réussi et comment vous vous êtes écarté de votre conception initiale. Ensuite, passez à des projets plus importants, espérons-le en collaboration avec d'autres personnes. Le design est une question de jugement qui prend des années à acquérir. Un programmeur intelligent peut apprendre les bases de manière adéquate en deux mois et s'améliorer à partir de là.

Il est naturel et utile de développer votre propre style, mais rappelez-vous que le design est un art, pas une science. Les personnes qui écrivent des livres sur le sujet ont tout intérêt à le faire paraître scientifique. Ne devenez pas dogmatique à propos de styles de design particuliers.

II-A-12 - Comment faire des expériences

Le regretté Edsger Dijkstra a expliqué avec éloquence que la science informatique n’est pas une science expérimentale [ExpCS] et ne dépend pas des ordinateurs électroniques.

...the harm was done: the topic became known as “computer science” - which, actually, is like referring to surgery as “knife science” - and it was firmly implanted in people's minds that computing science is about machines and their peripheral equipment.

Comme il le dit se référant aux années 1960 … « le mal était fait : le sujet était devenu « informatique » - ce qui revient à comparer la chirurgie à « science du bistouri» - et il était fermement implanté dans l'esprit des gens que l'informatique concernait les machines et leurs équipements périphériques ».

La programmation ne devrait pas être une science expérimentale, mais la plupart des programmeurs qui travaillent n’ont pas le luxe de s’engager dans ce que Dijkstra entend par informatique. Nous devons travailler dans le domaine de l'expérimentation, comme le font certains physiciens, mais pas tous. Si dans trente ans, la programmation peut être réalisée sans expérimentation, ce sera un grand accomplissement de la science informatique.

Les types d'expériences que vous devrez effectuer incluent les actions suivantes :
• éprouver des systèmes avec de petits exemples pour vérifier leur conformité à la documentation ou pour comprendre leur réponse en l'absence de documentation ;
• tester de petits changements de code pour voir s’ils corrigent réellement un bogue ;
• mesurer la performance d’un système dans deux conditions différentes en raison d’une connaissance imparfaite de ses caractéristiques de performance ;
• vérifier l’intégrité des données ;
• collecter des statistiques pouvant laisser penser à la solution aux bogues compliqués ou difficiles à reproduire.

Je ne pense pas que dans cet essai je puisse expliquer la conception des expériences; vous devrez étudier et pratiquer. Cependant, je peux offrir deux conseils.

Tout d’abord, essayez d’être très clair sur votre hypothèse ou sur l’affirmation que vous essayez de tester. Il est également utile d’écrire l’hypothèse, surtout si elle vous semble confuse ou si vous travaillez en équipe.

Vous devrez souvent concevoir une série d'expériences, chacune basée sur les connaissances acquises lors de l’expérience précédente. Par conséquent, vous devez concevoir vos expériences de manière à fournir le plus d’informations possible. Malheureusement, il est difficile de garder chaque expérience simple - vous devrez développer ce jugement par la pratique.

II-B - Compétences d’équipe

II-B-1 - Pourquoi l’estimation est importante

Pour utiliser un système logiciel opérationnel le plus rapidement possible, il faut non seulement planifier le développement, mais aussi la documentation, le déploiement et le marketing. Dans un projet commercial, cela nécessite également les ventes et le gestion de l’aspect financier. Sans estimation du temps de développement, il est impossible de planifier ces éléments efficacement.

Une bonne estimation donne de la visibilité. Les décideurs ont besoin de cette visibilité. Le fait qu'il soit impossible, à la fois théoriquement et concrètement, de prédire avec précision le temps qu'il faudra pour développer un logiciel est souvent déroutant pour les gestionnaires. On nous demande de faire cette chose impossible tout le temps et nous devons y faire face honnêtement. Cependant, il serait malhonnête de ne pas admettre l'impossibilité de cette tâche et de l'expliquer si nécessaire. Il y a beaucoup de place pour une mauvaise communication à propos des estimations, car les gens ont une tendance surprenante à penser à souhait que la phrase :

« J’estime que si je comprends vraiment le problème, il est probable à 50 % que nous aurons terminé dans cinq semaines (si personne ne nous dérange pendant ce temps) ». Cela veut dire en réalité : « je m’engage à avoir tout fini d’ici cinq semaines. »

Ce problème d'interprétation courant nécessite que vous discutiez explicitement de la signification de l'estimation avec votre patron ou votre client, comme s'il s'agissait d'un niais. Reformulez vos hypothèses, aussi évidentes qu’elles vous paraissent.

II-B-2 - Comment estimer le temps de programmation

L'estimation demande de la pratique. Cela demande aussi du travail. Cela demande tellement de travail que ce peut être une bonne idée d'estimer le temps qu'il faudra pour faire l'estimation, surtout si vous êtes invité à estimer quelque chose de grand.

Lorsqu'on il est demandé de donner une estimation de quelque chose de grand, la chose la plus honnête à faire est d'esquiver. La plupart des ingénieurs sont enthousiastes et désireux de plaire, et gagner du temps ne va certainement pas déplaire à celui qui en fait les frais. Mais une estimation trop rapide ne sera probablement ni exacte ni honnête.

Tout en gagnant du temps, il peut être possible d’envisager de réaliser ou de prototyper la tâche. Si la pression politique le permet, il s’agit du moyen le plus précis de produire l’estimation et cela fait réellement avancer.

Lorsqu'il n'est pas possible de prendre le temps d'une enquête, vous devez d'abord établir très clairement le périmètre de l'estimation. Répétez ce périmètre en introduction et dans la conclusion de votre estimation écrite. Préparez un devis en décomposant la tâche en sous-tâches de plus en plus petites jusqu'à ce que chaque petite tâche idéalement ne dépasse pas un jour au maximum . Le plus important est de ne rien omettre. Par exemple, la documentation, les tests, le temps nécessaire à la planification, le temps nécessaire pour communiquer avec d'autres groupes et le temps des vacances sont tous très importants. Si vous passez une partie de votre journée à traiter avec des gens stupides, insérez un poste pour cela dans l'estimation. Cela donne à minima à votre patron une visibilité sur l'utilisation de votre temps et pourrait vous en donner plus.

Je connais de bons ingénieurs qui rallongent les estimations systématiquement, mais je vous recommande de ne pas le faire. Un des résultats de ce rallongement est que la confiance en vous peut être perdue. Par exemple, un ingénieur peut prévoir trois jours pour une tâche qui, à son avis, prendra un jour. L’ingénieur peut prévoir de passer deux jours à le documenter ou à travailler sur un autre projet utile. Mais,le fait que la tâche ait été accomplie en un jour seulement sera visible et l'apparition d'un relâchement ou d'une surestimation est née. Il est de loin préférable de donner une visibilité adéquate à ce que vous faites réellement. Si la documentation prend deux fois plus de temps que le codage et si l’estimation le dit, vous gagnerez en crédibilité auprès du responsable.

Si une tâche prend probablement une journée - mais peut prendre dix jours si votre approche ne fonctionne pas - notez ceci d'une manière ou d'une autre dans l'estimation si vous le pouvez; sinon, faites au moins une moyenne pondérée par la probabilité de vos estimations . Tout facteur de risque que vous pouvez identifier et auquel vous pouvez attribuer une estimation doit être inclus dans le calendrier. Il est peu probable qu'une personne soit malade au cours d'une semaine donnée. Mais un grand projet avec de nombreux collaborateurs sera plus exposé aux aléas ; de même pour les vacances. Et quelle est la probabilité d'un séminaire de formation obligatoire à l'échelle de l'entreprise? Si cela peut être estimé, ajoutez-le. Il y a bien sûr des « inconnus inconnus » ou des imprévus. Les imprévus, par définition ne peuvent pas être estimés individuellement. Vous pouvez essayer de créer une ligne supplémentaire globale ou les gérer d'une autre manière que vous communiquerez à votre responsable. Vous ne pouvez toutefois pas laisser votre supérieur oublier qu’ils existent et il est bigrement facile pour une estimation de devenir un emploi du temps sans tenir compte des imprévus.

Pour un travail en équipe, vous devriez essayer de faire en sorte que l'estimation soit faite par les personnes qui feront le travail, et vous devriez essayer d'obtenir un consensus à l'échelle de l'équipe sur les estimations. Les compétences, l'expérience, la préparation et la confiance varient considérablement. La situation est difficile lorsqu'un programmeur expérimenté estime pour lui même et que des programmeurs moins aguerris sont tenus de suivre cette estimation. Le fait de faire en sorte que l’ensemble de l’équipe s’entende ligne par ligne sur l’estimation clarifie la compréhension par l’équipe, tout en offrant la possibilité de réaffecter tactiquement les ressources (par exemple, en reportant la charge de travail des membres les moins capés de l’équipe vers ceux les plus aguerris).

S'il existe de gros risques qui ne peuvent pas être évalués, il est de votre devoir de le dire avec suffisamment de force à votre responsable afin d’éviter qu’il ne s'y engage et soit dans le pétrin si le risque se réalise. Espérons que dans un tel cas, tout ce qui sera nécessaire sera fait pour réduire les impacts.

Si vous parvenez à convaincre votre entreprise d’utiliser la programmation extrême, vous n’aurez plus qu’à estimer des choses relativement petites, ce qui est plus amusant et plus productif.

II-B-3 - Comment trouver l’information

La nature de ce que vous devez savoir détermine comment vous devez le trouver.

Si vous avez besoin d’informations sur des éléments concrets, objectifs et faciles à vérifier, comme le dernier niveau de correctif d’un logiciel, demandez poliment à un grand nombre de personnes en le recherchant sur Internet ou en le postant sur un groupe de discussion. Ne cherchez pas sur Internet quoi que ce soit qui renferme une opinion ou une interprétation subjective : le rapport entre les radotages et la vérité est trop élevé.

Si vous avez besoin de connaissances générales sur quelque chose de subjectif, l'historique de ce que les gens en ont pensé, allez à la bibliothèque . Par exemple, pour en savoir plus sur les mathématiques, les champignons ou le mysticisme, rendez-vous à la bibliothèque.

Si vous avez besoin de savoir comment faire quelque chose qui n’est pas trivial, procurez-vous deux ou trois livres sur le sujet et lisez-les. Vous pourrez peut-être apprendre à réaliser des tâches triviales, comme installer un progiciel, à partir d’Internet. Vous pouvez même apprendre des choses importantes, comme une bonne technique de programmation, mais vous pouvez facilement passer plus de temps à chercher et à trier les résultats et à tenter de deviner la fiabilité des résultats par rapport à la lecture de la partie pertinente d’un livre.

Si vous avez besoin d’informations que personne n’aurait pu connaître, par exemple, « ce logiciel tout nouveau fonctionne-t-il sur des ensembles de données gigantesques ? », Vous devez toujours effectuer une recherche sur Internet et à la bibliothèque. Une fois ces options épuisées, vous pouvez concevoir une expérience pour le vérifier.

Si vous voulez un avis ou un jugement de valeur qui tienne compte de circonstances uniques, parlez à un expert. Par exemple, si vous souhaitez savoir s'il est judicieux de créer un système de gestion de base de données moderne dans LISP, parlez-en à un expert LISP et à un expert en bases de données.

Si vous voulez savoir s'il est probable qu'un algorithme plus rapide et qui n'a pas encore été publié existe pour une application particulière, consultez quelqu'un qui travaille dans ce domaine.

Si vous souhaitez prendre une décision personnelle, par exemple si vous envisagez de créer une entreprise, essayez de rédiger une liste d'arguments pour et contre l'idée. Si cela échoue, envisagez la divination. Supposons que vous ayez étudié l'idée sous tous les angles, que vous ayez fait tous vos devoirs et que vous ayez compris toutes les conséquences, les avantages et les inconvénients dans votre esprit, tout en restant indécis. Vous devez maintenant suivre votre cœur et dire à votre cerveau de se taire. La multitude de techniques de divination disponibles est très utile pour déterminer vos propres désirs semi-conscients, car ces techniques présentent chacune un schéma ambigu et aléatoire complet auquel votre propre subconscient donnera un sens.

II-B-4 - Comment utiliser les personnes comme source d’information

Respectez le temps de chaque personne et comparez-le avec le vôtre. Poser une question à quelqu'un représente bien plus que recevoir la réponse. La personne apprend sur vous, à la fois en appréciant votre présence et en entendant la question. Vous apprenez sur la personne de la même manière et vous pouvez apprendre la réponse que vous cherchez. Ceci est généralement beaucoup plus important que votre question.

Cependant, plus vous le faites, plus sa valeur diminue. Après tout, vous utilisez le bien le plus précieux d’une personne : son temps. Les avantages de la communication doivent être comparés aux coûts. En outre, les coûts et les avantages dérivés varient d’une personne à l’autre. Je crois fermement qu'une personne qui en encadre 100 devrait consacrer cinq minutes par mois à chaque personne de son organisation, ce qui représente environ 5% de son temps. Mais dix minutes, c'est peut-être trop et cinq minutes, c'est trop dans le cas de mille employés. Le temps consacré à parler à chaque personne de votre organisation dépend de son rôle (plus que de son poste). Vous devriez parler à votre patron plus que le patron de votre patron, mais vous devriez parler un peu au patron de votre patron. C'est peut-être inconfortable, mais je pense que vous avez le devoir de parler un peu avec tous vos supérieurs, chaque mois, quoi qu'il arrive.

La règle de base est que tout le monde profite de vous parler un peu, et plus ils vous parlent, moins ils en retirent d'avantages. Il vous incombe de leur fournir cet avantage et de bénéficier de la communication avec eux, en veillant à trouver l’ équilibre avec le temps passé.

ll est important de respecter votre propre temps. Si parler à quelqu'un, même si cela va leur faire perdre du temps, vous en fera gagner beaucoup, vous devriez le faire à moins que vous ne pensiez que leur temps est plus précieux que le vôtre.

Un exemple étrange de ceci est le cas d’un stagiaire. On ne peut pas s'attendre à ce qu'un stagiaire occupe un poste hautement technique et accomplisse trop de tâches, on peut s’attendre à ce qu’il harcèle tout le monde . Alors, pourquoi est-ce toléré ? Parce que les harcelés reçoivent quelque chose d'important de la part du stagiaire. Ils ont la chance de se montrer un peu. Ils ont l'occasion d'entendre de nouvelles idées, peut-être; ils ont la chance de voir les choses sous un angle différent. Ils peuvent également essayer de recruter le stagiaire, mais même si ce n'est pas le cas, il y a beaucoup à gagner.

Vous devriez demander aux gens un peu de leur sagesse et de leur jugement chaque fois que vous croyez honnêtement qu'ils ont quelque chose à dire. Cela les flatte et vous allez apprendre quelque chose et leur apprendre quelque chose. Un bon programmeur n'a pas souvent besoin des conseils d'un vice-président des ventes, mais si c’est le cas, assurez-vous de le demander. Une fois, j'ai demandé à écouter quelques appels de vente afin de mieux comprendre le travail de notre personnel de vente. Cela n'a pas pris plus de 30 minutes, mais je pense que ce petit effort a fait bonne impression à la force de vente.

II-B-5 - Comment documenter judicieusement

La vie est trop courte pour écrire des foutaises que personne ne lira; si vous écrivez des foutaises, personne ne les lira. Par conséquent, un peu de bonne documentation est préférable. Les gestionnaires ne comprennent souvent pas cela, car même une mauvaise documentation leur donne un faux sentiment de sécurité, à savoir qu'ils ne dépendent pas de leurs programmeurs. Si quelqu'un insiste absolument pour que vous écriviez une documentation vraiment inutile, acceptez et commencez tranquillement à chercher un meilleur emploi.

Rien de plus efficace que de mettre une estimation précise du temps nécessaire pour produire une bonne documentation dans une estimation ce qui permettra de réduire la demande de documentation. La vérité est froide et difficile : la documentation, comme les tests, peut prendre beaucoup plus de temps que le développement de code.

Rédiger une bonne documentation est avant tout une bonne écriture. Je vous suggère de trouver des livres sur l'écriture, de les étudier et de les pratiquer. Mais même si vous êtes un mauvais écrivain ou que vous maîtrisez mal la langue dans laquelle vous devez documenter, la règle d'or est tout ce dont vous avez réellement besoin: « ne faites pas aux autres ce que vous voudriez pas qu'ils vous fassent ». Prenez le temps de bien réfléchir à qui lira votre documentation, ce dont ils ont besoin pour s’en sortir et comment vous pouvez leur apprendre. Si vous le faites, vous serez un rédacteur de documentation supérieur à la moyenne et un bon programmeur.

Lorsqu'il s'agit de documenter le code lui-même, par opposition à la production de documents pouvant être lus par des non-programmeurs, les meilleurs programmeurs que je connaisse ont une méthode universelle : écrire du code explicite et documenter le code uniquement aux endroits où vous ne pouvez pas le préciser en écrivant le code lui-même. Il y a deux bonnes raisons à cela. Premièrement, quiconque ayant besoin de consulter la documentation au niveau du code sera dans la plupart des cas capable de lire le code et préférera le lire. Certes, cela semble plus facile pour le programmeur expérimenté que pour le débutant. Plus important encore, le code et la documentation ne peuvent pas être incohérents s’il n’y a pas de documentation. Le code source peut au pire être faux et déroutant. La documentation, si elle n’est pas parfaitement écrite, peut mentir, et c’est mille fois pire.

Cela ne facilite pas la tâche du programmeur responsable. Comment écrit-on un code explicite? Qu'est-ce que ça veut dire ? Cela signifie :

- écrire du code en sachant que quelqu'un va devoir le lire ;

- appliquer la règle d’or ;

- choisir une solution simple, même si vous pouviez vous en tirer rapidement avec une autre solution ;

- sacrifier les petites optimisations qui obscurcissent le code

- penser au lecteur et consacrer une partie de votre temps précieux à lui faciliter la tâche ;

- ne jamais utiliser un nom de fonction comme foo, bar ou doIt !

II-B-6 - Comment travailler avec un code médiocre

Il est très courant de devoir travailler avec un code de mauvaise qualité écrit par quelqu'un d'autre. Ne pensez pas trop à eux, cependant, jusqu'à ce que vous ayez marché dans leurs chaussures. On leur a peut-être demandé très consciemment de faire quelque chose rapidement pour répondre à la pression du calendrier. Quoi qu'il en soit, pour travailler avec un code peu clair, vous devez le comprendre. Pour comprendre cela prend du temps et ce temps devra être intégré dans un emploi du temps, quelque part, et vous devrez insister dessus. Pour le comprendre, vous devrez lire le code source. Vous devrez probablement faire des expériences avec.

C'est un bon moment pour documenter, même si ce n'est que pour vous-même, car le fait d'essayer de documenter le code vous obligera à prendre en compte des angles que vous n'auriez peut-être pas pris en compte et le document résultant peut être utile. Pendant que vous faites cela, réfléchissez à ce qu’il faudrait pour réécrire tout ou partie du code. Est-ce que cela ferait gagner du temps de réécrire une partie? Pourriez-vous mieux vous y fier si vous le réécriviez ? Attention à l'arrogance ici. Si vous le réécrivez, ce sera plus facile pour vous, mais sera-t-il vraiment plus facile pour la prochaine personne qui doit le lire? Si vous le réécrivez, quel sera le poids des tests? Le besoin de le tester à nouveau l'emportera-t-il sur les avantages éventuels?

Quelle que soit l'estimation que vous faites pour travailler avec du code que vous n'avez pas écrit, la qualité de ce code devrait affecter votre perception du risque de problèmes et d’imprévus.

Il est important de se rappeler que l'abstraction et l'encapsulation, deux des meilleurs outils du programmeur, sont particulièrement applicables au code médiocre. Vous ne pourrez peut-être pas redéfinir un gros bloc de code, mais si vous pouvez y ajouter une certaine quantité d'abstraction, vous pouvez obtenir certains des avantages d'une bonne conception sans avoir à refaire tout le bazar. En particulier, vous pouvez essayer d’isoler les parties particulièrement mauvaises afin qu’elles puissent être refaites indépendamment.

II-B-7 - Comment utiliser le contrôle de code source

Les systèmes de contrôle de code source (également appelés systèmes de contrôle de version) vous permettent de gérer les projets efficacement. Ils sont très utiles pour une personne et essentiels pour un groupe. Ils suivent toutes les modifications dans différentes versions afin qu'aucun code ne soit jamais perdu et qu’une signification soit attribuée à chaque modification. Vous pouvez créer du code, le jeter et déboguer en toute confiance avec un système de contrôle du code source, car le code que vous modifiez est soigneusement gardé séparé du code officiel qui sera partagé avec l’équipe ou publié.

J'étais en retard pour apprécier les avantages des systèmes de contrôle de code source, mais maintenant, je ne vivrais pas sans, même sur un projet à une personne. Généralement, ces systèmes de contrôle sont nécessaires lorsque votre équipe travaille sur la même base de code. Cependant, ils ont un autre grand avantage : ils encouragent à considérer le code comme un système organique en pleine croissance. Chaque modification étant marquée comme une nouvelle révision avec un nouveau nom ou un nouveau numéro, le logiciel commence à être considéré comme une série d’améliorations visiblement progressives. Je pense que cela est particulièrement utile pour les débutants.

Une bonne technique pour utiliser un système de contrôle de code source est de rester à jour en tout temps. Le code qui ne peut pas être terminé au bout de quelques jours est archivé, mais il est inactif et ne sera pas appelé, et ne créera donc aucun problème pour quiconque. Commettre une erreur qui ralentit vos coéquipiers est une erreur grave; c'est souvent tabou.

II-B-8 - Comment faire des tests unitaires

Le test unitaire, le test d’une fonctionnalité individuelle codée par l’équipe qui l’a rédigée, fait partie du codage et n’en est pas pour autant différent. Une partie de la conception du code consiste à concevoir comment il sera testé. Vous devriez rédiger un plan de test, même s'il ne s'agit que d'une phrase. Parfois, le test sera simple: « Est-ce que le bouton est beau? » Parfois, ce sera complexe: « Cet algorithme de correspondance a-t-il retourné précisément les correspondances correctes? »

Utilisez la vérification des assertions et testez les pilotes chaque fois que possible. Cela permet de détecter les bogues au plus tôt, mais c’est aussi très utile ultérieurement et vous permet d'éliminer les mystères dont vous auriez autrement à vous soucier.

Les développeurs de programmation extrême écrivent beaucoup sur les tests unitaires de manière efficace; Je ne peux pas faire mieux que de recommander leurs écrits.

II-B-9 - Prenez des pauses lorsque vous êtes bloqué

Lorsque vous êtes bloqué, faites une pause. Je médite parfois pendant 15 minutes quand je suis bloqué et le problème disparaît comme par magie quand j'y reviens. Une nuit de sommeil fait parfois la même chose à plus grande échelle. Il est possible que le passage temporaire à une autre activité fonctionne.

II-B-10 - Comment reconnaître quand rentrer chez soi

La programmation informatique est une activité qui est aussi une culture. Le malheur est que ce n’est pas une culture qui valorise beaucoup la santé physique ou mentale. Pour des raisons à la fois culturelles et historiques (la nécessité de travailler la nuit sur des ordinateurs non chargés, par exemple) et en raison de la pression écrasante de mise sur le marché et de la pénurie de programmeurs, ceux ci sont traditionnellement surmenés. Je ne pense pas que vous puissiez faire confiance à toutes les histoires que vous entendez, mais je pense que 60 heures par semaine, c'est courant, et 50, c'est à peu près un minimum. Cela signifie que souvent beaucoup plus que ce qui est requis. C’est un problème grave pour un bon programmeur, qui est responsable non seulement de lui-même mais aussi de son équipe. Vous devez savoir quand rentrer chez vous et parfois quand suggérer que d’autres personnes rentrent chez elles. Il ne peut y avoir de règle fixe pour résoudre ce problème, pas plus qu'il ne peut en avoir pour élever un enfant, pour la même raison - chaque être humain est différent.

Au-delà de 60 heures par semaine c’est un effort extraordinaire pour moi, que je peux appliquer pendant de courtes périodes (environ une semaine) et que l’on attend parfois de moi. Je ne sais pas s'il est juste d'attendre 60 heures de travail d'une personne; Je ne sais même pas si 40 est juste. Je suis cependant persuadé que c’est stupide de travailler tellement si l’on gagne peu de ce temps supplémentaire. Pour moi , cela ne dépasse pas 60 heures par semaine. Je pense qu'un programmeur devrait être responsable et porter un lourd fardeau. Cependant, le programmeur n'a pas le devoir d'être un souffre douleur. Malheureusement, on demande souvent aux programmeurs de subir pour pouvoir présenter un spectacle à quelqu'un, par exemple un manager qui tente d'impressionner un dirigeant. Les programmeurs succombent souvent à cela parce qu'ils ont envie de faire plaisir et ne savent pas très bien dire non. Il y a trois défenses contre cela:

- communiquez autant que possible avec tous les membres de l'entreprise afin que personne ne puisse induire en erreur les dirigeants sur ce qui se passe ;

- apprenez à dire non, et dire non en équipe si nécessaire ;

- partez si vous le devez.

La plupart des programmeurs sont de bons programmeurs et les bons programmeurs veulent faire beaucoup de choses. Pour ce faire, ils doivent gérer leur temps efficacement. Il existe une certaine inertie mentale associée à la résolution d'un problème et à son implication profonde. De nombreux programmeurs trouvent qu'ils fonctionnent mieux lorsqu'ils disposent de longs blocs de temps ininterrompus pour s’immerger et se concentrer. Cependant, les gens doivent dormir et accomplir d'autres tâches. Chaque personne doit trouver un moyen de satisfaire à la fois son rythme humain et son rythme de travail. Chaque programmeur doit faire le nécessaire pour gagner du temps, par exemple pour réserver certains jours au cours desquels il n'assiste qu'aux réunions les plus critiques.

Depuis que j'ai des enfants, j'essaie de passer des soirées avec eux parfois . Le rythme qui me convient le mieux est de travailler une très longue journée, de dormir au bureau ou près du bureau (le trajet entre chez moi et mon domicile est long), puis de rentrer chez moi suffisamment tôt le lendemain pour passer du temps avec mes enfants avant qu’ils aillent au lit. Je ne suis pas à l'aise avec cela, mais c'est le meilleur compromis que j'ai pu trouver. Rentrez chez vous si vous avez une maladie contagieuse. Vous devriez rentrer chez vous si vous avez des idées suicidaires. Vous devriez faire une pause ou rentrer chez vous si vous avez des envies de meurtre pendant plus de quelques secondes. Vous devriez renvoyer quelqu'un à la maison s'il présente un dysfonctionnement mental grave ou des signes de maladie mentale allant au-delà d'une dépression légère. Si vous êtes tenté d'être malhonnête ou trompeur d'une manière inhabituelle à cause de la fatigue, vous devriez faire une pause. N'utilisez pas de cocaïne ou d'amphétamines pour lutter contre la fatigue. N’abusez pas de la caféine.

II-B-11 - Comment traiter avec les personnes difficiles

Vous devrez probablement faire face à des personnes difficiles. Vous pouvez même être une personne difficile vous-même. Si vous êtes le genre de personne qui a beaucoup de conflits avec des collègues et des figures d'autorité, vous devriez chérir l'indépendance que cela implique, mais travaillez sur vos compétences interpersonnelles sans sacrifier votre intelligence ou vos principes.

Cela peut être très dérangeant pour certains programmeurs qui n’ont aucune expérience de ce type et dont l’expérience antérieure leur a enseigné des schémas de comportement qui ne sont pas utiles sur le lieu de travail. Les personnes difficiles sont souvent habituées au désaccord et sont moins touchées que les autres par la pression sociale en faveur de compromis. L'important est de les respecter de manière appropriée, ce qui est plus que vous ne voudrez mais pas autant qu'ils pourraient vouloir.

Les programmeurs doivent travailler ensemble en équipe. Lorsqu'un désaccord survient, il doit être résolu d'une manière ou d'une autre, il ne peut être esquivé longtemps. Les personnes difficiles sont souvent extrêmement intelligentes et ont quelque chose de très utile à dire. Il est essentiel que vous écoutiez et compreniez la personne difficile sans penser à mal. Le défaut de communication est souvent à la base du désaccord, mais il peut parfois être éliminé avec beaucoup de patience. Essayez de garder cette communication détendue et cordiale et ne tombez pas dans le piège d’envenimer les choses. Après une période raisonnable passée à essayer de comprendre, prenez une décision.

Ne laissez pas un petit dur vous forcer à faire quelque chose avec lequel vous n'êtes pas d'accord. Si vous êtes le responsable, faites ce que vous pensez être le meilleur. Ne prenez pas de décision pour des raisons personnelles et soyez prêt à expliquer les raisons de votre décision. Si vous êtes un coéquipier avec une personne difficile, ne laissez pas la décision du leader avoir un impact personnel. Si les choses de vont pas dans votre sens, faites les dans l’autre sens de tout votre cœur.

Il arrive que les personnes difficiles changent et s’améliorent. Je l'ai vu de mes propres yeux, mais c'est très rare. Cependant, tout le monde a des hauts et des bas transitoires.

L’un des défis auxquels tous les programmeurs, mais surtout les dirigeants, sont confrontés est de garder la personne difficile totalement engagée. Ces personnes sont plus enclins à ralentir le travail et à résister passivement que d’autres.

III - Intermédiaire

III-A - Compétences personnelles

III-A-1 - Comment rester motivé

Il est merveilleux et surprenant que les programmeurs soient si motivés par le désir de créer des artefacts beaux, utiles ou astucieux. Ce désir n'est pas propre aux programmeurs, ni universel, mais il est si fort et commun chez les programmeurs qu'il les distingue des autres.

Cela a des conséquences pratiques et importantes. Si on demande aux programmeurs de faire quelque chose qui n’est pas beau, utile ou astucieux, ils auront le moral en berne. Il y a beaucoup d'argent à gagner en faisant des choses laides, stupides et ennuyeuses. Mais finalement, le plaisir rapportera davantage d’argent à la société.

Il y a évidemment des industries entières organisées autour de techniques de motivation, dont certaines s'appliquent ici. Les éléments spécifiques à la programmation que je peux identifier sont :

- utiliser le meilleur langage pour le travail ;

- chercher les opportunités pour appliquer de nouvelles techniques, langages et technologies ;

- essayer d’apprendre ou d’enseigner quelque chose, aussi petite soit-elle, dans chaque projet.

Enfin, si possible, mesurez l’impact de votre travail sur quelque chose de personnellement motivant. Par exemple, lors de la correction de bogues, compter le nombre de ceux-ci que j’ai corrigés et qui ne me motivent pas du tout, car cela est indépendant du nombre de problèmes pouvant encore exister et affecte faiblement la valeur totale ajoutée pour les clients de mon entreprise. Relier chaque bogue à un client heureux est toutefois pour moi une motivation personnelle.

III-A-2 - Comment être digne de confiance

Pour être cru, vous devez être digne de confiance. Vous devez aussi être visible. Si personne ne vous connaît, aucune confiance ne vous sera faite. Avec vos proches, tels que vos coéquipiers, cela ne devrait pas être un problème. Vous établissez une relation de confiance en étant réactif et informatif envers les personnes extérieures à votre département ou à votre équipe. Parfois, quelqu'un abusera de cette confiance et demandera des faveurs déraisonnables. N'ayez pas peur de cela, expliquez simplement ce que vous devez abandonner pour rendre le service.

Ne prétendez pas savoir quelque chose que vous ne savez pas. Avec des personnes qui ne sont pas de votre équipe, vous devrez peut-être faire une distinction claire entre « ne pas savoir tout de suite » et « ne pas être capable de le comprendre, jamais ».

III-A-3 - Comment concilier temps et espace

Vous pouvez être un bon programmeur sans être allé à l’université, mais vous ne pouvez pas être un bon programmeur intermédiaire sans connaître la théorie de base de la complexité informatique. Vous n’avez pas besoin de connaître la notation « Big O » (comparaison asymptotique), mais je pense personnellement que vous devriez comprendre la différence entre « temps constant », « n log n » et «  ». Vous pourrez peut-être concilier le temps et l’espace sans cette connaissance, mais en son absence, vous ne disposerez pas d’une base solide pour communiquer avec vos collègues.

Lors de la conception ou de la compréhension d’un algorithme, le temps nécessaire à son exécution dépend parfois de la taille de l’entrée. Quand cela est vrai, nous pouvons dire que la durée d'exécution la plus défavorable, attendue, dans le meilleur des cas, d'un algorithme est « n log n » si elle est proportionnelle à la taille ($ n $) fois le logarithme de la taille. La notation et la manière de l’évoquer peuvent également être appliquées à l’espace occupé par une structure de données.

Pour moi, la théorie de la complexité informatique est belle et aussi profonde que la physique, et va un peu plus loin.

Le temps (en cycles du processeur) et l’espace (mémoire) peuvent être échangés l’un contre l’autre. L'ingénierie est un compromis, et c'est un bon exemple. Ce n’est pas toujours systématique. En général, on peut gagner de la place en encodant les choses plus finement, au détriment du temps de calcul lors du décodage. Vous pouvez gagner du temps en mettant en cache, c’est-à-dire en prenant de l’espace pour stocker une copie locale de quelque chose, au détriment de la nécessité de maintenir la cohérence de celui-ci. Vous pouvez parfois gagner du temps en conservant plus d’informations dans une structure de données. Cela coûte généralement peu d’espace, mais peut compliquer l’algorithme.

L’amélioration du compromis espace/temps peut souvent modifier l’un ou l’autre dramatiquement. Néanmoins, avant de travailler dessus, vous devriez vous demander si ce que vous améliorez est vraiment l’élément qui nécessite le plus d’amélioration. Il est amusant de travailler sur un algorithme, mais vous ne pouvez pas vous laisser aveugler par le fait que l'amélioration de quelque chose qui ne pose pas de problème ne fera aucune différence notable et créera une charge de test.

La mémoire des ordinateurs modernes semble bon marché, car contrairement au temps de traitement du processeur, vous ne pouvez pas la voir être utilisée tant que vous n’avez pas heurté le mur, mais alors l'échec est catastrophique. L’utilisation de la mémoire entraîne également d'autres coûts cachés, comme les effets sur les autres programmes qui doivent rester résidents, ainsi que le temps pour l’allouer et la désallouer. Considérez ceci avec précaution avant d’échanger de l’espace pour gagner de la vitesse.

III-A-4 - Comment faire des tests de stress

Le test de stress est amusant. Il semble en premier lieu que l’objectif est de vérifier si le système fonctionne sous une charge donnée. En réalité, il est courant que le système fonctionne sous une charge donnée, mais défaille d’une manière ou d’une autre lorsque la charge est suffisamment importante. J’appelle cela « aller dans le mur » ou « faire du bonking (1)». Il peut y avoir des exceptions, mais il y a presque toujours un « mur ». L’objectif de ces tests de stress est de cibler où se trouve le mur, puis alors de déterminer comment le repousser plus loin.

Un plan de test de stress devrait être élaboré tôt dans le projet, car cela aide souvent à clarifier les attentes. Deux secondes pour une requête de page web, est-ce un échec misérable ou un succès fracassant ? 500 utilisateurs simultanés suffisent-ils ? Cela dépend, bien entendu, mais il faut connaître la réponse lors de la conception du système qui répond à la demande. Le test de stress doit être assez conforme à la réalité pour être utile. Il n’est pas vraiment possible de simuler facilement 500 humains erratiques et imprévisibles utilisant un système simultanément, mais on peut au moins créer 500 simulations et essayer de modéliser une partie de ce que ces humains pourraient faire.

Lors d’un test de stress, commencez avec une charge légère et chargez selon certaines dimensions, comme un taux d’entrée ou une taille d’entrée, jusqu’à ce que vous « heurtiez le mur ». Si le mur est trop proche pour répondre à vos besoins, ciblez la ressource qui constitue le goulot d’étranglement (il y en a généralement une dominante). Est-ce la mémoire, le processeur, les E/S, le réseau, la bande passante, ou une contention des données ? Ensuite, déterminez comment vous pouvez déplacer le mur. Notez que le déplacement du mur, c’est-à-dire l’augmentation de la charge maximale que le système peut supporter, peut ne pas aider ou pourrait nuire aux performances d’un système peu chargé. Habituellement, la performance sous charge lourde est plus importante que la performance sous charge légère.

Vous devrez peut-être avoir de la visibilité dans différentes dimensions pour en construire un modèle mental, aucune technique n’est suffisante. Par exemple, la journalisation donne souvent une bonne idée du temps entre deux événements dans le système, mais si elle n'est pas soigneusement construite, elle ne donne aucune visibilité sur l’utilisation de la mémoire ni même la taille de la structure de données. De même, dans un système moderne, plusieurs ordinateurs et de nombreux systèmes logiciels peuvent coopérer. En particulier lorsque vous frappez le mur (c’est-à-dire que les performances ne sont pas linéaires en termes de taille de l’entrée), ces autres systèmes logiciels peuvent constituer un goulot d’étranglement. La visibilité dans ces systèmes, même si vous ne mesurez que la charge du processeur sur toutes les machines participantes, peut être très utile.

Savoir où se trouve le mur est essentiel, pas seulement pour le déplacer, mais aussi pour assurer la prévisibilité afin que le travail puisse être géré efficacement.

III-A-5 - Comment équilibrer la brièveté et l'abstraction

L’abstraction est la clé de la programmation. Vous devez choisir avec soin le degré d’abstraction dont vous avez besoin. Les programmeurs débutants, avec leur enthousiasme, créent souvent plus d’abstraction qu’il n’en est vraiment utile. Un signe de cela est si vous créez des classes qui ne contiennent pas vraiment de code et ne font vraiment rien sauf servir à abstraire quelque chose. Cette attraction est compréhensible, mais la valeur de la brièveté du code doit être comparée à la valeur de l’abstraction. De temps en temps, on constate une erreur commise par des idéalistes enthousiastes : au début du projet, de nombreuses classes sont définies, ce qui semble merveilleusement abstrait, et on peut penser qu’elles géreront toutes les éventualités qui pourraient survenir. Au fur et à mesure que le projet progresse et que la fatigue s’installe, le code lui-même devient désordonné. Les corps des fonctions deviennent plus longs qu’ils ne devraient l’être. Les classes vides sont un fardeau à documenter, ce qui est ignoré lorsqu’on est sous pression. Le résultat final aurait été meilleur si l’énergie dépensée pour l’abstraction avait été dépensée pour conserver les choses courtes et simples. C'est une forme de programmation spéculative. Je recommande fortement cet article : Succinctness is Power par Paul Graham.

Il existe un certain dogme associé à des techniques utiles comme la dissimulation de l’information et la programmation orientée objet qui sont parfois poussées trop loin. Ces techniques permettent de coder de manière abstraite et d’anticiper les changements. Cependant, je pense personnellement que vous ne devriez pas produire beaucoup de code spéculatif. Par exemple, il est un style accepté de cacher une variable de type entier sur un objet derrière des mutateurs et accesseurs, de sorte que la variable elle-même ne soit pas exposée, mais uniquement l’interface pour y accéder. Ceci permet le changement de l’implémentation de cette variable sans affecter le code d’appel, et est peut-être approprié à un programmeur de bibliothèques qui doit publier une API très stable. Mais je ne pense pas que le bénéfice de cette opération l'emporte sur le coût de la verbosité quand mon équipe détient le code d’appel et peut de ce fait recoder l’appelant aussi facilement que l’appelé. Quatre ou cinq lignes de code supplémentaires sont un lourd poids à payer pour ce bénéfice hypothétique.

La portabilité pose un problème similaire. Le code doit-il être portable sur un autre ordinateur, compilateur, système applicatif ou plate-forme, ou simplement être facilement porté ? Je pense qu’un morceau de code non portable, court et facile à porter est meilleur qu’un long code portable. Il est relativement facile et certainement une bonne idée de confiner le code non portable dans un emplacement spécifique, comme une classe qui effectue des requêtes de base de données spécifiques à un SGBD donné.

III-A-6 - Comment apprendre de nouvelles compétences

Apprendre de nouvelles compétences, en particulier non techniques, est le plus amusant de tout. La plupart des entreprises auraient une meilleure ambiance si elles comprenaient à quel point ceci motive les programmeurs.

Les humains apprennent en faisant. La lecture de livre et les cours sont utiles. Mais pourriez-vous avoir du respect pour un programmeur qui n‘avait jamais écrit un programme ? Pour apprendre une compétence, vous devez vous mettre dans une position indulgente où vous pourrez exercer cette compétence. Quand vous apprenez un nouveau langage de programmation, essayez de faire un petit projet dans ce langage avant de devoir faire un grand projet. Lorsque vous apprenez à gérer un projet logiciel, essayez d’abord d’en gérer un petit.

Un bon mentor n’est pas un substitut pour faire les choses soi-même, mais c’est beaucoup mieux qu’un livre. Que pouvez-vous offrir à un mentor potentiel en échange de son savoir ? Au minimum, vous devriez proposer d’étudier durement de sorte que son temps ne soit pas gaspillé.

Essayez de demander à votre chef de vous laisser suivre une formation formelle, mais comprenez que ce n'est souvent pas mieux que le même temps passé à jouer simplement avec la nouvelle compétence que vous voulez apprendre. Dans notre monde imparfait, il est cependant plus facile de demander une formation que du temps pour jouer, même si une quantité de formations ne sont que somnolences lors des conférences, en attendant le dîner.

Si vous dirigez des personnes, comprenez comment elles apprennent et aidez-les en leur donnant des projets de la bonne taille et qui font appel à des compétences qui les intéressent. N’oubliez pas que les compétences les plus importantes pour un programmeur ne sont pas les compétences techniques. Donnez à vos collègues une chance de jouer, de faire preuve de courage, d’honnêteté et de communiquer.

III-A-7 - Apprenez à taper au clavier

Apprenez à taper au clavier. Ceci est une compétence intermédiaire, car écrire du code est si difficile que la vitesse à laquelle vous pouvez taper n’a plus d’importance et qu’il est impossible de réduire considérablement le temps nécessaire pour écrire du code, quel que soit votre niveau. Cependant, à partir du moment où vous êtes un programmeur intermédiaire, vous passerez probablement beaucoup de temps à écrire en langage naturel à vos collègues et à d’autres. Ceci est un test amusant de votre engagement ; il faut du temps et ce n’est pas très amusant d’apprendre quelque chose comme ça. La légende veut que, lorsque Michael Tiemann était chez MCC, les gens se tenaient devant sa porte pour écouter le ronflement généré par ses frappes au clavier, qui étaient si rapides qu'il était impossible de les distinguer.

III-A-8 - Comment faire des tests d'intégration

Les tests d’intégration sont des tests de l’intégration de différents composants qui ont été testés unitairement. L’intégration est coûteuse et cela ressort des tests. Vous devez inclure du temps pour cela dans vos estimations et votre planification.

Idéalement, vous devriez organiser un projet de sorte qu’il n’y ait pas une phase à la fin où l’intégration doit explicitement avoir lieu. Il est de loin préférable d’intégrer progressivement les éléments au fur et à mesure de leur réalisation au cours du projet. Si c’est inévitable, faites une estimation avec soins.

III-A-9 - Les langages de communication

Certains langages, qui sont des systèmes syntaxiques formellement définis, ne sont pas des langages de programmation, mais des langages de communication. Ils sont spécifiquement conçus pour faciliter la communication à travers la normalisation. En 2003, les plus importants sont UML, XML et SQL. Vous devriez être familier avec eux pour pouvoir bien communiquer et décider quand les utiliser.

UML est un système formel riche pour effectuer des schémas représentant la conception. Sa beauté réside dans le fait qu’il est à la fois visuel et formel, capable de transmettre beaucoup d’informations si l’auteur et le public connaissent UML. Vous devez le connaître, car les conceptions sont parfois communiquées par son biais. Il existe des outils très utiles pour réaliser des dessins UML qui ont un aspect très professionnel. Dans de nombreuses situations, UML est trop formel, et je me retrouve à utiliser un style plus simple de cases et de flèches pour les dessins de conception. Mais je reste persuadé qu’UML est au moins aussi bon pour vous qu’étudier le latin.

XML est un standard pour définir de nouveaux standards. Ce n’est pas une solution aux problèmes d’échange de données, bien qu’il soit parfois présenté comme tel. Il s’agit plutôt d’une automatisation bienvenue de la partie la plus ennuyeuse de l’échange de données, à savoir la structuration de la représentation en une séquence linéaire et la parser dans une structure. Il fournit de bonnes vérifications de type et de correction, bien qu’à nouveau ce soit une fraction de ce dont vous aurez probablement besoin dans la pratique.

SQL est un langage de requête et de manipulation de données très puissant et riche, qui n’est pas tout à fait un langage de programmation. Il comporte de nombreuses variantes, généralement très dépendantes du produit, qui sont moins importantes que le noyau standardisé. SQL est la « lingua franca » des bases de données relationnelles. Vous pouvez travailler ou non dans n'importe quel domaine pouvant tirer parti d'une compréhension des bases de données relationnelles, mais vous devriez en avoir une compréhension de base, ainsi que de la syntaxe et du sens de SQL.

III-A-10 - Les outils importants

Au fur et à mesure que notre culture technologique progresse, la technologie logicielle passe de l’inconcevable à la recherche, puis à de nouveaux produits, et enfin à des produits standardisés, largement disponibles et bon marché. Ces outils lourds peuvent supporter des charges importantes, mais peuvent être intimidants et nécessitent un investissement important dans la compréhension. Le programmeur intermédiaire doit savoir comment les gérer et quand ils doivent être utilisés ou considérés.

à mon avis, actuellement, certains des meilleurs outils sont :

- les bases de données relationnelles ;

- les moteurs de recherche de texte intégral full-text ;

- les bibliothèques mathématiques ;

- OpenGL ;

- Les parsers XML ;

- les feuilles de calcul.

III-A-11 - Comment analyser les données

L’analyse de données est un processus présent dès le début du développement logiciel, lorsque vous examinez une activité professionnelle et déterminez les prérequis pour la convertir en une application logicielle. Il s’agit d’une définition formelle, qui peut vous amener à croire que l’analyse de données est une action que vous devriez laisser aux analystes système, tandis que vous, programmeur, devriez vous concentrer sur le codage de ce quelqu’un d’autre a conçu. Si nous suivons strictement le paradigme du génie logiciel, il se peut que ce soit correct. Les programmeurs expérimentés deviennent des concepteurs et les concepteurs les plus pointus deviennent des analystes métier, ayant ainsi le droit de réfléchir à tous les prérequis en matière de données et vous confier une tâche bien définie à réaliser. Ceci n’est pas tout à fait précis, car les données constituent la valeur fondamentale de chaque activité de programmation. Quoi que vous fassiez dans vos programmes, vous déplacez ou vous modifiez des données. L’analyste métier analyse le besoin à plus grande échelle, et le concepteur de logiciel réduit cette échelle de sorte que, lorsque le problème arrive sur votre bureau, il semble que tout ce que vous ayez à faire est d’appliquer des algorithmes intelligents et de commencer à déplacer les données existantes.

Pas tout à fait.

Qu’importe l’étape à laquelle vous commencez à les examiner, les données constituent la principale préoccupation d’une application bien conçue. Si vous regardez de près comment un analyste métier récupère les prérequis depuis les exigences des clients, vous réaliserez que les données jouent un rôle fondamental. L’analyste crée ce qu'on appelle des diagrammes de flux de données dans lesquels toutes les sources de données sont identifiées et où le flux de données est façonné. Après avoir clairement défini les données devant faire partie du système, le concepteur modélisera les sources de données, en termes de relations de bases de données, de protocoles d’échanges de données et de formats de fichier, de sorte que la tâche soit prête à être confiée au programmeur. Cependant, le processus n’est pas encore terminé, car vous (le programmeur), même après ce processus approfondi de raffinement des données, devez analyser les données pour réaliser la tâche de la meilleure manière possible. Le message principal de Niklaus Wirth, le père de plusieurs langages, est au cœur de votre tâche. « Algorithmes + Structures de données = Programmes ». Il n’y a jamais un algorithme seul, faisant quelque chose pour lui-même. Chaque algorithme est supposé faire quelque chose pour au moins une donnée.

Par conséquent, les algorithmes ne tournant pas en vase clos, vous devez analyser à la fois les données que quelqu'un d'autre a identifiées pour vous et celles qui sont nécessaires pour écrire votre code. Un exemple trivial rendra le sujet plus clair. Vous implémentez une routine de recherche pour une bibliothèque. Selon vos spécifications, l'utilisateur peut sélectionner des livres en combinant genre, auteur, titre, éditeur, année d'impression et nombre de pages. L’objectif ultime de votre routine est de produire une instruction SQL légitime pour effectuer une recherche dans la base de données principale. En fonction de ces exigences, vous avez différents choix : vérifier chaque contrôle à l’aide d’une instruction « switch », ou de plusieurs « if » ; faire un tableau de contrôle de données, en vérifiant chaque élément pour voir s’il est défini, créer (ou utiliser) un objet de contrôle abstrait à partir duquel tous vos contrôles spécifiques hériteront, et les connecter à un moteur piloté par événement. Si vos exigences incluent également le réglage des performances de la requête, en vous assurant que les éléments sont vérifiés dans un ordre spécifique, vous pouvez envisager d’utiliser une arborescence de composants pour construire votre instruction SQL. Comme vous pouvez le constater, le choix de l’algorithme dépend des données que vous décidez d’utiliser, ou de créer. De telles décisions peuvent faire toute la différence entre un algorithme efficace et un algorithme désastreux. Cependant, l’efficacité n’est pas la seule préoccupation. Vous pouvez utiliser une douzaine de variables nommées dans votre code et le rendre aussi efficace que possible. Mais un tel bout de code pourrait ne pas être facilement maintenable. Peut-être que sélectionner un container approprié pour vos variables permettrait de garder la même vitesse et par la même occasion permettre à vos collègues de mieux comprendre le code lorsqu’ils le consulteront l’année suivante. De plus, choisir une structure de données bien définie peut leur permettre d’étendre la fonctionnalité de votre code sans la réécrire. À long terme, vos choix de données déterminent la durée de vie de votre code une fois que vous l’avez terminé. Laissez-moi vous donner un autre exemple, juste un peu plus de matière à réflexion. Supposons que votre tâche consiste à rechercher dans un dictionnaire tous les mots de plus de trois anagrammes, où une anagramme doit être un autre mot du même dictionnaire. Si vous le considérez comme une tâche de calcul, vous vous retrouverez avec un effort sans fin, essayant de calculer toutes les combinaisons de chaque mot, puis en le comparant aux autres mots dans la liste. Néanmoins, si vous analysez les données à la main, vous réaliserez que chaque mot peut être représenté par un enregistrement contenant le mot lui-même et un tableau trié de ses lettres comme identifiant. Armé de ces connaissances, rechercher des anagrammes signifie simplement trier la liste d’après le champ supplémentaire et sélectionner ceux qui partagent le même identifiant. L’algorithme de force brute peut prendre plusieurs jours à s’exécuter, alors que celui intelligent ne prend que quelques secondes. Souvenez-vous de cet exemple la prochaine fois que vous rencontrerez un problème insoluble.

III-B - Compétences de l’équipe

III-B-1 - Comment gérer le temps de développement

Pour gérer le temps de développement, maintenez un plan de projet concis et à jour. Un plan de projet est une estimation, un planning, un ensemble de jalons pour marquer les avancées, et une affectation de votre équipe ou de votre temps personnel à chaque tâche de l’estimation. Il doit aussi inclure d’autres tâches à ne pas oublier, comme des réunions avec les personnes de l’assurance qualité, préparer la documentation ou commander du matériel. Si vous faites partie d’une équipe, le plan de projet devrait être un accord consensuel, du début à la fin.

Le plan de projet existe pour vous aider à prendre des décisions, et non pour montrer à quel point vous êtes organisés. Si le plan de projet est trop long ou n’est pas à jour, il sera inutile pour la prise de décision. En réalité, ces décisions concernent des personnes individuelles. Le plan et votre jugement vous permettent de décider si vous devez transférer des tâches d’une personne à une autre. Les jalons marquent vos avancées. Si vous utilisez un outil de planification de projet sophistiqué, ne vous laissez pas séduire par la création d’un BDUF (Big Design Up Front) pour le projet, mais utilisez-le pour maintenir la concision et les mises à jour.

Si vous manquez un jalon, vous devriez prendre des mesures immédiates, par exemple en informant votre patron que l'achèvement prévu de ce projet a glissé. Pour commencer, l'estimation et le calendrier ne peuvent jamais être parfaits ; cela crée l'illusion que vous pourriez peut-être rattraper les jours que vous avez manqués dans la dernière partie du projet. Vous pourriez. Mais il est tout aussi probable que vous ayez sous-estimé cette partie plus que vous l'avez surestimée. Par conséquent, l'achèvement prévu du projet a déjà glissé, que cela vous plaise ou non.

Assurez-vous que votre plan comprend du temps pour : les réunions d’équipe, les démonstrations, la documentation, les activités périodiques planifiées, les tests d’intégration, la relation avec des tiers, les maladies, les vacances, la maintenance des produits existants et la maintenance de l’environnement de développement. Le plan de projet peut servir à donner à des étrangers ou à votre patron un aperçu de ce que vous ou votre équipe faites. Pour cette raison, il devrait être court et à jour.

III-B-2 - Comment gérer les risques liés aux logiciels tiers

Un projet dépend souvent de logiciels produits par des organisations qu’on ne contrôle pas. Les logiciels tiers comportent de grands risques qui doivent être reconnus par toutes les personnes impliquées.

Jamais, jamais, ne reposez aucun espoir sur un vaporware. Le vaporware est un logiciel présumé qui a été promis, mais n'est pas encore disponible. C'est le moyen le plus sûr de faire faillite. Il est imprudent d’être simplement sceptique quant à la promesse d’une société de logiciels de publier un certain produit avec une certaine fonctionnalité à une certaine date ; il est bien plus sage de l'ignorer complètement et d'oublier que vous l'avez déjà entendu. Ne le laissez jamais être écrit dans les documents utilisés par votre entreprise.

Si les logiciels tiers ne sont pas tous des illusions, ils sont quand même risqués, mais c’est au moins un risque qui peut être mesuré. Si vous envisagez d’utiliser un logiciel tiers, vous devriez consacrer très tôt de l’énergie à son évaluation. Les gens n’aimeront peut-être pas entendre qu’il faudra deux semaines ou deux mois pour évaluer l’efficacité de chacun des trois produits, mais cela doit être fait aussi tôt que possible. Le coût de l’intégration ne peut pas être précisément estimé sans une bonne évaluation.

Comprendre la pertinence des logiciels tiers existants à un usage particulier est une connaissance très tribale. C’est très subjectif et généralement l’affaire d’experts. Vous pouvez économiser beaucoup de temps si vous pouvez trouver ces experts. Souvent, un projet dépend tellement d’un logiciel tiers que si l’intégration échoue, le projet échoue. Exprimez clairement ces risques en les écrivant dans le programme. Essayez d’avoir un plan de secours, comme un autre système pouvant être utilisé ou la possibilité d’écrire la fonctionnalité vous-même si le risque ne peut pas être éliminé plus tôt. Ne jamais laisser une planification dépendre d’illusions.

III-B-3 - Comment gérer les consultants

Utilisez des consultants, mais ne comptez pas sur eux. Ce sont des gens formidables qui méritent beaucoup de respect. Comme ils peuvent voir beaucoup de projets différents, ils en connaissent souvent plus que vous sur des technologies spécifiques et même sur les techniques de programmation. La meilleure manière de les utiliser est en tant qu’éducateurs internes capables d’enseigner par l’exemple.

Cependant, ils ne peuvent généralement pas faire partie de l'équipe de la même manière que les employés réguliers, ne serait-ce que parce que vous n'avez peut-être pas assez de temps pour apprendre leurs forces et leurs faiblesses. Leur engagement financier est beaucoup plus faible. Ils peuvent être plus facilement mobiles. Ils auront peut-être moins à gagner si l'entreprise réussit. Certains seront doués, d'autres convenables et d'autres médiocres, mais malheureusement votre sélection de consultants ne sera pas aussi soignée que votre sélection d'employés, du coup vous en obtiendrez ainsi de plus médiocres.

Si des consultants sont amenés à écrire du code, vous devez le relire attentivement au fur et à mesure. Vous ne pouvez pas arriver à la fin d’un projet avec le risque d’un gros bloc de code qui n’a pas été relu. Cela est vrai pour tous les membres de l’équipe, réellement, mais vous aurez généralement plus de connaissances sur les membres de l'équipe plus proches de vous.

III-B-4 - Comment communiquer de la bonne manière

Examinez attentivement le coût d’une réunion ; il en coûte sa durée multipliée par le nombre de participants. Les réunions sont parfois nécessaires, mais les plus courtes sont préférables. La qualité de la communication dans les petites réunions est meilleure, et moins de temps est perdu. Si une personne s’ennuie lors d’une réunion, prenez cela comme un signe que la réunion devrait être plus courte.

Tout doit être mis en œuvre pour encourager la communication informelle. Un travail plus utile est réalisé durant les déjeuners avec des collègues que pendant n’importe quel autre moment. C’est une honte qu’il n’y ait pas plus d’entreprises qui le reconnaissent ou soutiennent ce fait.

III-B-5 - Comment être en désaccord honnêtement et s'en tirer

Le désaccord est une excellente opportunité de prendre une bonne décision, mais devrait être géré délicatement. J'espère que vous sentez que vous avez bien exprimé vos idées et que vous avez été entendu avant que la décision ne soit prise. Dans ce cas il n’y a rien de plus à dire, et vous devez vous décider si vous vous en tenez à la décision même si vous n’êtes pas d’accord. Si vous pouvez appuyer cette décision même si vous n'êtes pas d'accord, dites-le. Cela montre à quel point vous êtes précieux, parce que vous êtes indépendant et que vous n'êtes pas un homme qui dit toujours oui, mais que vous êtes respectueux d'une décision et que vous êtes un vrai membre de l'équipe.

Parfois, une décision avec laquelle vous n'êtes pas d'accord sera prise lorsque les décideurs n'auront pas pleinement vu les avantages de votre opinion. Vous devriez alors évaluer s'il convient de soulever la question en fonction des avantages pour l'entreprise. Si, selon votre avis, c'est une petite erreur, cela ne vaut peut-être pas la peine de la reconsidérer. Et si c'est une grosse erreur, alors bien sûr vous devez présenter un argument.

Généralement, ce n’est pas un problème. Dans certaines situations stressantes et avec certains types de personnalité, cela peut mener à prendre les choses personnellement. Par exemple, certains très bons programmeurs manquent de la confiance nécessaire pour remettre en cause une décision, même lorsqu'ils ont de bonnes raisons de croire qu'elle est fausse. Dans les pires circonstances, le décideur n’est pas sûr de lui et le prend comme un défi personnel à son autorité. Dans de telles situations, il est bon de se souvenir que les personnes réagissent avec la partie reptilienne de leur cerveau. Vous devriez présenter votre argument en privé et essayer de montrer comment de nouvelles connaissances modifient la base sur laquelle la décision a été prise.

Que la décision soit renversée ou non, vous devez vous souvenir que vous ne pourrez jamais dire « Je te l’ai dit ! », car la décision alternative avait été pleinement explorée.

III-C - Jugement

III-C-1 - Comment concilier qualité et temps de développement

Le développement logiciel est toujours un compromis entre ce que le projet doit faire et arriver à le mener à bien. Toutefois, il peut vous être demandé de faire un compromis sur la qualité pour accélérer le déploiement d'un projet d'une manière qui heurte votre sensibilité technique ou métier. Par exemple, il peut vous être demandé de faire quelque chose qui constitue une mauvaise pratique de génie logiciel et qui entraînera de nombreux problèmes de maintenance.

Si cela se produit, votre première responsabilité consiste à informer votre équipe et à expliquer clairement le coût de la baisse de qualité. Après tout, votre compréhension devrait être bien meilleure que celle de votre patron. Expliquez clairement ce qui est perdu et ce qui est gagné, et à quel coût le terrain perdu pourra être rattrapé lors du prochain cycle. À cet égard, la visibilité fournie par un bon plan de projet devrait être utile. Si le compromis sur la qualité affecte l’effort d’assurance qualité, signalez-le (à votre patron et aux responsables de l’assurance qualité). Si le compromis sur la qualité entraîne plus de bogues signalés après la période d’assurance qualité, signalez-le.

Si le problème de qualité persiste, vous devriez essayer d’isoler la « médiocrité » en composants particuliers que vous pouvez planifier de réécrire ou d’améliorer au cours du prochain cycle. Expliquez cela à votre équipe pour qu’elle puisse se préparer.

NinjaProgrammer at Slashdot a envoyé cette gemme :

« Souvenez-vous qu’une bonne conception sera résistante aux implémentations de code médiocres. Si de bonnes interfaces et abstractions existent dans tout le code, alors les éventuelles ré-écritures seront moins douloureuses. S’il est difficile d’écrire du code propre et difficile à corriger, réfléchissez à ce qui ne va pas avec la conception principale qui en est la cause. »

III-C-2 - Comment gérer la dépendance des systèmes logiciels

Les systèmes logiciels modernes ont tendance à dépendre d’un grand nombre de composants qui ne sont pas forcément sous votre contrôle. Cela augmente la productivité grâce à la synergie et la réutilisation. Par contre, chaque composant apporte avec lui des problèmes :

- Comment corrigerez-vous les bogues dans les composants ?

- Un composant vous restreint-il à certains systèmes matériels ou logiciels ?

- Que ferez-vous si un composant dysfonctionne complètement ?

Il est toujours mieux d’encapsuler le composant de manière à ce qu’il soit isolé et qu’il puisse être remplacé. Si le composant s’avère totalement inutilisable, vous pourrez peut-être en avoir un autre, mais vous devrez peut-être écrire le vôtre. L’encapsulation n’est pas la portabilité, mais cela facilite le portage, ce qui est presque aussi bon.

Posséder le code source d’un composant diminue le risque par quatre. Avec le code source, vous pouvez l’évaluer plus facilement, le déboguer plus facilement, trouver plus facilement des solutions de contournement et faciliter les corrections. Si vous faites des correctifs, vous devriez les fournir au propriétaire du composant et les incorporer dans une version officielle. Autrement vous aurez à maintenir une version non officielle.

III-C-3 - Comment décider si un logiciel est trop immature

L’utilisation de logiciels écrits par d’autres personnes est l’un des moyens les plus efficaces pour construire rapidement un système robuste. Cela ne doit pas être décourageant, mais les risques qui y sont associés doivent être examinés. L’un des risques les plus importants est la période boguée et de quasi-inopérabilité souvent associée aux logiciels avant qu’ils ne mûrissent, par le biais de leur utilisation, en un produit exploitable. Avant d’envisager l’intégration à un système logiciel, qu’il soit créé en interne ou par un tiers, il est très important de déterminer s’il est suffisamment mature pour être utilisé. Voici dix questions que vous devriez vous poser à ce propos :

1. Est-ce un vaporware ? (Les promesses sont très immatures)

2. Est-ce qu’il existe une base de connaissances concernant le logiciel ?

3. Êtes-vous le premier utilisateur ?

4. Y a-t-il une motivation forte à poursuivre ?

5. Est-ce qu’il y a eu un effort de maintenance ?

6. Survivra-t-il à l’abandon des mainteneurs actuels ?

7. Est-ce qu’il existe une solution de rechange expérimentée au moins moitié moins bonne ?

8. Est-ce qu’il est connu de votre entreprise ?

9. Est-ce qu’il est souhaitable pour votre entreprise ?

10. Pouvez-vous embaucher des personnes pour travailler dessus même s’il est mauvais ?

Un peu de considération de ces critères démontre la grande valeur des logiciels libres et des logiciels open source bien établis pour réduire les risques pour l’entrepreneur.

III-C-4 - Comment décider d’acheter ou de fabriquer

Une entreprise entrepreneuriale ou un projet qui tente de réaliser quelque chose avec un logiciel doit constamment prendre des décisions d'achat ou de fabrication. Cette tournure de phrase est regrettable à deux égards : elle semble ignorer les logiciels libres et open sources qui ne sont pas nécessairement achetés. Plus important encore, il faudrait peut-être appeler une décision « d’acquérir et d’intégrer » ou « de fabriquer et d’intégrer », car le coût de l’intégration doit être pris en compte. Cela nécessite une excellente combinaison de compétences en affaires, en gestion et en ingénierie.

- Dans quelle mesure vos besoins correspondent-ils à ceux pour lesquels il a été conçu ?

- De quelle portion de ce que vous achetez aurez-vous besoin ?

- Quel est le coût d’évaluation de l’intégration ?

- Quel est le coût de l’intégration ?

- À long terme, les achats feront augmenter ou diminuer le coût de la maintenance ?

- Est-ce que sa fabrication vous mettra dans une position commerciale dans laquelle vous ne voulez pas être ?

Vous devriez réfléchir à deux fois avant de construire quelque chose d'assez grand pour servir de base à toute autre entreprise. De telles idées sont souvent proposées par des personnes brillantes et optimistes qui auront beaucoup à apporter à votre équipe. Si leur idée est irrésistible, vous voudrez peut-être modifier votre business plan ; mais n'investissez pas dans une solution plus grande que votre propre projet sans en avoir conscience.

Après avoir examiné ces questions, vous devriez peut-être préparer deux ébauches de plans de projet, l’un pour la construction et l’autre pour l’achat. Cela vous obligera à prendre en compte les coûts d’intégration. Vous devriez également prendre en compte les coûts de maintenance à long terme des deux solutions. Pour estimer les coûts d’intégration, vous aurez à effectuer une évaluation approfondie du logiciel avant de l’acheter. Si vous ne pouvez pas l’évaluer, vous prendrez un risque déraisonnable en l’achetant et vous devriez vous opposer à l’achat de ce produit particulier. Si plusieurs décisions d'achat sont à l'étude, il faudra dépenser de l'énergie pour toutes les évaluer.

III-C-5 - Comment grandir professionnellement

Assumez la responsabilité au-delà de votre autorité. Jouez le rôle que vous désirez. Exprimez votre appréciation pour la contribution des personnes à la réussite de l’ensemble de l’entreprise, ainsi que pour tout ce qui peut vous aider personnellement.

Si vous souhaitez devenir un chef d’équipe, suscitez la formation de consensus. Si vous souhaitez devenir un responsable, prenez en charge le planning. Vous pouvez généralement le faire confortablement tout en travaillant avec un chef ou un responsable, car cela leur libérera du temps pour prendre des responsabilités plus grandes. Si cela est trop compliqué , faites-le petit à petit.

Évaluez-vous. Si vous voulez devenir un meilleur programmeur, demandez à quelqu’un que vous admirez comment vous pouvez devenir comme lui. Vous pouvez également demander à votre patron, qui en connaît moins techniquement, mais qui aura un impact plus important sur votre carrière.

Planifiez des moyens d’acquérir de nouvelles compétences, à la fois techniques, simples, comme l’apprentissage d’un nouveau système logiciel, et sociales, plus difficiles, comme écrire correctement, en les intégrant à votre travail.

III-C-6 - Comment évaluer les candidats à l’embauche

L'évaluation des employés potentiels ne reçoit pas l'énergie qu'elle mérite. Un mauvais recrutement, comme un mauvais mariage, est terrible. Une part importante de l'énergie de chacun devrait être consacrée au recrutement, même si cela est rarement fait.

Il existe différents styles d’entretiens. Certains sont tortueux, conçus pour mettre le candidat sous beaucoup de stress. Cela sert un objectif très précieux de révéler éventuellement des défauts de caractère et des faiblesses en cas de stress. Les candidats ne sont pas plus honnêtes avec les recruteurs qu’ils ne le sont avec eux-mêmes, et la capacité humaine d'auto-illusion est étonnante.

Vous devriez au minimum donner au candidat l’équivalent d’un examen oral sur les compétences techniques pendant deux heures. Avec la pratique, vous serez en mesure de couvrir rapidement l'étendue de ce qu'ils savent et la limite de leur compétence. Les candidats respecteront cela. J’ai entendu plusieurs fois des candidats dire que la qualité de l’entretien était l’une de leurs motivations pour sélectionner une entreprise. Les bonnes personnes veulent être embauchées pour leurs compétences, pas pour leur dernier travail ou l’école qu’ils ont fait ou toute autre caractéristique superficielle.

En faisant cela, vous devriez aussi évaluer leur capacité à apprendre, ce qui est de loin plus important que ce qu’ils connaissent. Vous devez également surveiller les ondes négatives dégagées par les personnes difficiles. Vous pourriez peut-être le déterminer en comparant les notes après l’entretien, mais dans le feu de l’action, il est difficile de s’en rendre compte. La qualité de la communication et du travail des personnes est plus importante que l’utilisation du dernier langage de programmation.

Un lecteur a eu de la chance en utilisant un test « ramené à la maison ». Cela a l’avantage de pouvoir découvrir une personne interrogée qui peut présenter bien, mais ne sait pas vraiment coder, et il y en a beaucoup. Personnellement, je n'ai pas essayé cette technique, mais cela semble raisonnable.

Enfin, l’entretien est aussi un processus de vente. Vous devriez vendre votre entreprise ou votre projet au candidat. Cependant, vous parlez à un programmeur, alors n’essayez pas d’embellir la vérité. Commencez avec les mauvaises choses, puis terminez sur un point fort avec les bonnes choses.

III-C-7 - Comment apprendre quand utiliser des techniques sophistiquées de science informatique

Il y a un ensemble de connaissances sur les algorithmes, les structures de données, les mathématiques et d’autres trucs géniaux que la plupart des programmeurs connaissent, mais utilisent rarement. En pratique, ces éléments merveilleux sont trop compliqués et généralement inutiles. Par exemple, il n’y a pas de raison d’améliorer un algorithme quand la majorité du temps est passé dans des appels inefficaces à une base de données. Une grande part de la programmation consiste à amener les systèmes à communiquer entre eux et à utiliser des structures de données très simples pour créer une interface utilisateur agréable.

Quand la haute technologie est-elle la technologie appropriée ? Quand faut-il déchiffrer un livre pour obtenir autre chose qu'un algorithme au fil de l'eau ? Il est parfois utile de faire cela, mais cela doit être évalué avec soin.

Les trois points les plus importants à prendre en compte pour l’utilisation éventuelle des techniques informatiques sont :

- Sont-elles bien encapsulées de sorte que le risque pour les autres systèmes soit faible et que l'augmentation globale de la complexité et des coûts de maintenance soit faible ?

- Le bénéfice est-il surprenant (par exemple, un facteur deux dans un système mature ou un facteur dix dans un nouveau système) ?

- Serez-vous en mesure de les tester et les évaluer efficacement ?

Si un algorithme bien isolé et qui en utilise un légèrement sophistiqué peut réduire le coût matériel ou augmenter les performances par un facteur de deux sur l’ensemble du système, il serait donc criminel de ne pas l’envisager. L’un des arguments pour justifier une telle approche est de montrer que le risque est réellement faible, puisque la technologie proposée a probablement été bien étudiée. Le seul problème est le risque à l’intégration. À ce niveau, l’expérience et le jugement d’un programmeur peuvent vraiment être en synergie avec la technologie sophistiquée pour faciliter l'intégration.

III-C-8 - Comment parler aux non-ingénieurs

Les ingénieurs et les programmeurs en particulier sont généralement reconnus par la culture populaire comme étant différents des autres. Ce qui implique que les autres personnes sont différentes de nous. Cela vaut la peine d’être gardé à l’esprit, lorsque vous communiquez avec des non-ingénieurs, vous devez toujours comprendre votre public.

Les non-ingénieurs sont intelligents, mais ne sont pas aussi calés dans la création de choses techniques que nous. Nous faisons des choses. Ils vendent et manipulent des choses, comptent et gèrent des choses, mais ils ne sont pas des experts en fabrication. Ils ne travaillent pas aussi bien en équipe que les ingénieurs (il y a sans doute des exceptions). Leurs compétences sociales sont généralement aussi bonnes ou meilleures que celles des ingénieurs dans des environnements ou les gens sont autonomes, mais leur travail ne nécessite pas toujours de pratiquer la sorte de communication intime et précise et de subdivisions soigneuses des tâches que nous effectuons.

Les non-ingénieurs sont peut-être trop désireux de plaire et vous les intimiderez peut-être. Tout comme nous, ils pourraient dire « oui » sans vraiment le penser, pour vous faire plaisir ou parce que vous les intimidez un peu, puis revenir sur leurs paroles.

Les non-programmeurs peuvent comprendre des choses techniques, mais ils n’ont pas ce qui est si difficile, même pour nous : le jugement technique. Ils comprennent comment fonctionne la technologie, mais ils ne peuvent pas comprendre pourquoi une certaine approche prendrait trois mois et une autre trois jours. (Après tout, les programmeurs sont aussi horriblement anecdotiques sur ce type d’estimation). Cela représente une excellente opportunité de créer une synergie avec eux.

Lorsque vous parlez à votre équipe, vous utiliserez sans réfléchir une sorte de raccourci, un langage abrégé, qui est efficace, car vous partagez une grande expérience de la technologie en général et de votre produit en particulier. Il faut faire un effort pour ne pas utiliser ces raccourcis avec ceux qui ne partagent pas cette expérience, particulièrement lorsque des membres de votre équipe sont présents. Ce vocabulaire crée un mur entre vous et ceux qui ne le partagent pas et, même pire, leur fait perdre du temps.

Avec votre équipe, il n’est pas nécessaire de rappeler les hypothèses et les objectifs de bases, et la plupart des conversations portent sur les détails. Avec les personnes externes, il doit en être autrement. Ils peuvent ne pas comprendre les choses que vous tenez pour acquises. Puisque vous les tenez pour acquises et ne les répétez pas, vous pouvez avoir terminé une conversation avec un tiers pensant que vous vous comprenez alors qu’il y a vraiment un malentendu important. Vous devriez supposer que vous communiquerez mal et faire attention à cette mauvaise communication. Essayez de les amener à résumer ou paraphraser ce que vous dites pour être sûr qu’ils comprennent. Si vous avez l’opportunité de souvent les rencontrer, prenez un peu de temps pour vous demander si vous communiquez efficacement et comment vous pouvez faire mieux. S’il y a un problème de communication, cherchez à modifier vos propres pratiques avant de devenir frustré par les leurs.

J’adore travailler avec des non-ingénieurs. Cela apporte de grandes opportunités d’apprendre et d’enseigner. Vous pouvez souvent prêcher par l’exemple, en termes de clarté de communication. Les ingénieurs sont formés à mettre de l'ordre dans le chaos, pour clarifier les choses, et les non-ingénieurs apprécient cela. Comme nous avons un jugement technique et pouvons généralement comprendre les problèmes de l’entreprise, nous pouvons souvent trouver une solution simple à un problème.

Souvent, les non-ingénieurs proposent des solutions qui, à leur avis, nous faciliteront la tâche par bonté et désir de faire les choses bien, alors qu’il existe une bien meilleure solution globale qui ne peut être trouvée que par une synergie entre le point de vue extérieur et votre jugement technique. Personnellement, j’apprécie « l’Extreme Programming », car cela corrige cette inefficacité. En associant rapidement l'estimation à l'idée, il est plus facile de trouver l'idée qui constitue la meilleure combinaison de coûts et d'avantages.

IV - Avancé

IV-A - Jugement technique

IV-A-1 - Comment discerner le difficile de l’impossible

C’est le rôle du programmeur de faire le travail difficile et de discerner l’impossible. Du point de vue de la plupart des développeurs en activité, quelque chose est impossible si on ne peut pas le développer à partir d’un simple système ou si on ne peut pas l’estimer. Selon cette définition, ce qui est appelé « recherche » est impossible. Un gros volume de travail simple est difficile, mais pas nécessairement impossible.

La distinction n’est pas simple, car on peut très bien vous demander de faire ce qui est pratiquement impossible, d’un point de vue scientifique ou de génie logiciel. Cela devient alors votre travail d’aider l’entrepreneur à trouver une solution raisonnable, qui est simplement difficile et qui répond à la plupart de ses attentes. Une solution est simplement difficile quand elle peut être planifiée avec confiance et que les risques sont compris.

Il est impossible de satisfaire une exigence vague, telle que « Construire un système qui calculera le style et la couleur de cheveux les plus attrayants pour une personne ». Si l’exigence peut être plus poussée, elle deviendra plus difficile, comme « Construire un système qui calcule un style et une couleur de cheveux attrayants pour une personne et lui permettre une prévisualisation et d’apporter des modifications, pour obtenir la satisfaction du client, basée sur le style original, tel que nous gagnions beaucoup d’argent ». S’il n’y a pas de définition précise du succès, vous ne réussirez pas.

IV-A-2 - Comment utiliser des langages intégrés

L’intégration d’un langage de programmation dans un système suscite une fascination presque érotique chez un programmeur. C’est l’un des actes les plus créatifs qui puissent être réalisés. Cela rend le système énormément puissant. Cela vous permet d'exercer vos compétences les plus créatives et prométhéennes. Ce qui fera du système votre ami.

Les meilleurs éditeurs de texte du monde ont tous des langages intégrés. Ils sont utilisables dans la mesure où le public ciblé peut maîtriser le langage. Bien sûr, l’utilisation du langage peut être rendue optionnelle, comme dans les éditeurs de texte, afin que les initiés puissent l’utiliser et les autres n’aient pas à le faire.

De nombreux autres programmeurs et moi-même sommes tombés dans le piège de la création de langages intégrés pour des objectifs spécifiques. Je suis tombé dedans deux fois. Il existe déjà beaucoup de langages conçus spécifiquement pour être des langages intégrés. Vous devriez y réfléchir sérieusement avant d’en créer un nouveau.

La véritable question à se poser avant de rendre un langage intégrable est : est-ce que ça va dans le sens ou contre la culture de mon public ? Si votre public cible est exclusivement composé de non-programmeurs, en quoi cela l’aidera-t-il ? Si votre public cible est exclusivement composé de programmeurs, peut-être préférerait-il une interface de programmation d’application (API) ? Et quel langage utiliser ? Les programmeurs ne veulent pas apprendre un nouveau langage peu utilisé, mais si cela correspond à leur culture, ils n'auront pas à passer beaucoup de temps à l'apprendre. C’est une joie de créer un nouveau langage. Mais nous ne devrions pas laisser cela nous rendre aveugles aux besoins de l'utilisateur. À moins que vous n’ayez des idées et des besoins vraiment originaux, pourquoi ne pas utiliser un langage existant, afin de pouvoir tirer parti de la familiarité que les utilisateurs ont déjà avec lui ?

IV-A-3 - Choisir des langages

Le programmeur solitaire qui aime son travail (un bidouilleur) peut choisir le meilleur langage pour la tâche. La plupart des programmeurs qui travaillent ont très peu de contrôle sur le langage qu’ils vont utiliser. Généralement, ce problème est dicté par des chefs qui prennent une décision politique plutôt qu’une décision technologique et qui n’ont pas le courage pour promouvoir un outil non conventionnel même lorsqu’ils savent, souvent avec une connaissance de première main, que l’outil le moins accepté est le meilleur. Dans d’autres cas, le bénéfice très réel de l’unité au sein de l’équipe et dans une certaine mesure d’une communauté plus large, prévaut sur le choix d’une personne. Les managers sont souvent motivés par le besoin de pouvoir engager des programmeurs expérimentés dans un langage donné. Nul doute qu’ils servent ce qu’ils perçoivent comme étant les meilleurs intérêts du projet ou de la compagnie et ils doivent être respectés pour cela. Cependant, je crois personnellement que c’est la pratique courante la plus inutile et la plus erronée que vous êtes susceptible de rencontrer.

Mais bien entendu, les choses ne sont jamais unidimensionnelles. Même si un langage de base est retenu et hors de votre contrôle, il arrive souvent que des outils et d'autres programmes puissent et doivent être écrits dans un autre langage. Si un langage doit être intégré (et vous devriez toujours y penser), le choix de celui-ci dépendra beaucoup de la culture des utilisateurs. Vous devez en tirer avantage pour servir votre entreprise ou votre projet en utilisant le meilleur langage pour le travail et le rendre ainsi plus intéressant.

Les langages de programmation devraient vraiment s'appeler « notations », car leur apprentissage n’est pas du tout aussi difficile que l’apprentissage d’un langage naturel. Pour les débutants et autres outsiders, « apprendre un nouveau langage » semble être une tâche ardue. Mais après en avoir trois à votre actif, il ne vous reste plus qu’à vous familiariser avec les bibliothèques disponibles. On a tendance à penser qu’un grand système comportant des composants écrits en trois ou quatre langages est un grand désordre. Mais je soutiens qu’un tel système est plus puissant qu’un système écrit dans un seul langage et cela pour plusieurs raisons :

- il y a nécessairement un couplage lâche entre les composants écrits dans des notations différentes (bien que les interfaces ne soient peut-être pas propres) ;

- vous pouvez facilement évoluer vers un nouveau langage ou une nouvelle plate-forme en réécrivant chaque composant individuellement ;

- un langage peut ne pas convenir à la globalité du système. Avoir plusieurs langages pour vos modules vous permet de sélectionner le bon outil pour le travail.

Certains de ces effets peuvent être seulement psychologiques, mais la psychologie compte. Finalement, les coûts de la tyrannie des langages dépassent les avantages qu’elle procure.

IV-B - Faire des compromis judicieusement

IV-B-1 - Comment lutter contre la pression du calendrier

La pression de la date de mise sur le marché est la pression pour livrer rapidement un bon produit. C’est bien, parce que cela reflète une réalité financière et reste sain dans une certaine mesure. La pression du calendrier est la pression exercée pour livrer quelque chose plus rapidement que ce qui peut l’être, c'est ravageur, malsain et trop commun.

La pression du calendrier existe pour plusieurs raisons. Les personnes qui confient les tâches aux programmeurs n’apprécient pas vraiment notre solide éthique de travail et le plaisir que procure le fait d’être un programmeur. Peut-être parce qu’ils projettent leur propre comportement sur nous, ils pensent que demander quelque chose plus tôt nous obligera à travailler plus pour le livrer plus tôt. C’est probablement vrai, mais l’effet est très faible et les dégâts sont très importants. De plus, ils n’ont aucune visibilité sur ce qu’il faut vraiment pour produire un logiciel. Ne pouvant pas le voir et ne pouvant pas le créer eux-mêmes, la seule chose qu’ils peuvent faire est de voir la pression de la date de mise sur le marché et d'attirer l'attention des programmeurs sur ce sujet.

La clef pour lutter contre la pression du calendrier est de la transformer en une pression de date de mise sur le marché. La façon de le faire est de donner une visibilité sur la relation entre la main-d'œuvre disponible et le produit. Produire une estimation honnête, détaillée et surtout compréhensible de tout le travail nécessaire est le meilleur moyen de le faire. Il présente l’avantage supplémentaire de permettre de prendre de bonnes décisions concernant les compromis possibles en matière de fonctionnalité.

L'idée clef que l'estimation doit préciser est que le travail est un fluide presque incompressible. Vous ne pouvez pas en produire plus dans un intervalle de temps que vous ne pouvez remplir un récipient au-delà de son volume. En un sens, un programmeur ne devrait jamais dire « non », mais plutôt dire « qu’allez-vous abandonner pour obtenir ce que vous voulez ? » L’obtention d’estimations claires aura pour effet d’augmenter le respect des programmeurs. C'est comme ça que les autres professionnels se comportent. Le travail acharné des programmeurs sera visible. Fixer un calendrier irréaliste sera également douloureusement évident pour tout le monde. Les programmeurs ne peuvent pas être trompés. C'est irrespectueux et démoralisant de leur demander de faire quelque chose d'irréaliste. La programmation extrême amplifie cela et construit un processus autour de cela. J'espère que tous les lecteurs auront la chance de l'utiliser.

IV-B-2 - Comment comprendre les utilisateurs

C’est votre devoir de comprendre les utilisateurs et d’aider votre supérieur à les comprendre. Parce qu’ils ne sont pas aussi intimement impliqués que vous dans la création de votre produit, les utilisateurs se comportent un peu différemment :

- les utilisateurs prennent généralement des décisions brèves ;

- ils ont leur propre travail. Ils penseront principalement à de petites améliorations dans votre produit, pas à de grandes ;

- les utilisateurs ne peuvent pas avoir une vision qui représente l’ensemble des utilisateurs de votre produit.

Il est de votre devoir de leur donner ce qu'ils veulent vraiment, pas ce qu'ils disent vouloir. Il vaut toutefois mieux leur proposer et leur faire accepter que votre proposition est ce qu'ils veulent vraiment avant de commencer, mais ils peuvent ne pas avoir la vision pour faire cela. Votre confiance dans vos propres idées à ce sujet devrait varier. Vous devez vous protéger à la fois de l'arrogance et de la fausse modestie pour savoir ce que le client veut vraiment. Les programmeurs sont formés pour concevoir et créer. Les spécialistes du marché sont formés pour comprendre ce que veulent les gens. Ces deux types de personnes ou deux modes de pensée chez une même personne, travaillant ensemble en harmonie, offrent les meilleures chances de formuler la vision correcte.

Plus vous passerez de temps avec les utilisateurs, plus vous serez en mesure de comprendre ce qui réussira réellement. Vous devriez essayer d’éprouver vos idées avec eux autant que vous le pouvez. Vous devriez manger et boire avec eux si vous le pouvez.

Dans son ouvrage « Guy Kawasaki Rules » (les règles de Guy Kawasaky), l’auteur a souligné l’importance de regarder ce que font vos utilisateurs en plus de les écouter.

Je pense que les entrepreneurs et les consultants ont souvent beaucoup de difficultés pour clarifier ce que leurs clients veulent vraiment. Si vous avez l’intention d’être consultant, je vous suggère de choisir vos clients en fonction de leur lucidité et de leur portefeuille.

IV-B-3 - Comment obtenir une promotion

Pour être promu à un rôle, jouez ce rôle en premier.

Pour être promu à un titre, déterminez ce qui est attendu de ce titre et faites-le.

Pour obtenir une augmentation de salaire, négociez armés d'informations.

Si vous sentez que vous êtes en retard pour une promotion, parlez-en à votre patron. Demandez-lui explicitement ce que vous devez faire pour être promu et essayez de le faire. Cela semble banal, mais souvent, votre perception de ce que vous devez faire sera très différente de celle de votre patron. De plus, cela va mettre votre patron devant le fait accompli.

La plupart des programmeurs ont probablement un sens exagéré de leurs capacités relatives à certains égards. Après tout, nous ne pouvons pas tous être dans le top 10 ! Cependant, j'ai vu certaines personnes qui ont été sérieusement non appréciées à leur juste valeur. On ne peut pas s'attendre à ce que l'évaluation de chacun corresponde parfaitement à la réalité à tout moment, mais je pense que les gens sont généralement assez justes, avec une mise en garde : vous ne pouvez pas être appréciés sans qu’il y ait de visibilité dans votre travail. Parfois, en raison d'événements fortuits ou d'habitudes personnelles, une personne ne sera pas remarquée. Travailler beaucoup à la maison ou être géographiquement séparé de votre équipe et de votre chef rend la tâche particulièrement difficile.

IV-C - Servir votre équipe

IV-C-1 - Comment développer les talents

Nietschze exagérait quand il a dit : « Ce qui ne me détruit pas me rend plus fort ».

Votre plus grande responsabilité est envers votre équipe. Vous devriez bien en connaître chaque membre. Vous devriez tenter d'obtenir le maximum de votre équipe, mais ne pas la surcharger. Vous devriez généralement parler à tous les membres de la façon dont ils sont sollicités. S'ils y adhèrent, ils seront bien motivés. Dans chaque projet, essayez de les mettre à profit d’une manière qu’ils suggèrent et d’une manière qui, selon vous, leur sera bénéfique. Ne les sollicitez pas en leur donnant plus de travail, mais en leur donnant une nouvelle compétence ou, mieux encore, un nouveau rôle à jouer dans l'équipe.

Vous devez permettre aux personnes (y compris vous-même) d’échouer de temps en temps et de prévoir certains échecs dans votre programme. S'il n'y a jamais d'échec, il ne peut y avoir de sens de l'aventure. S'il n'y a pas d'échecs occasionnels, c'est que vous ne faites pas assez d'essais. Quand quelqu'un échoue, vous devriez être aussi gentil que possible avec lui sans pour autant le traiter comme s'il avait réussi.

Essayez de faire en sorte que chaque membre de l’équipe adhère et soit bien motivé. Demandez explicitement à chacun d’entre eux ce dont il a besoin pour être bien motivé s’il ne l’est pas. Vous devrez peut-être laisser certains développeurs insatisfaits, mais vous devriez savoir ce que tout le monde désire.

Vous ne pouvez pas renoncer à quelqu'un qui ne porte pas intentionnellement sa charge de travail à cause d’un moral bas ou de l'insatisfaction et le laisser simplement démotivé. Vous devez essayer de motiver vos équipiers et les rendre productifs. Tant que vous avez la patience, continuez ainsi. Lorsque votre patience est épuisée, virez-les. Vous ne pouvez pas permettre à quelqu'un qui travaille intentionnellement en dessous de son niveau de rester dans l'équipe, car ce n'est pas juste pour l'équipe.

Dites clairement aux membres forts de votre équipe que vous pensez qu’ils sont forts en le disant en public. Les louanges devraient être publiques et les critiques privées.

Les membres forts de l'équipe auront naturellement des tâches plus difficiles que les membres faibles. C’est parfaitement naturel et personne ne sera dérangé par ça tant que tout le monde travaille dur.

C’est un fait singulier, qui ne se reflète pas dans les salaires, qu’un bon programmeur est plus productif que 10 mauvais programmeurs. Cela crée une situation étrange. Il sera souvent vrai que vous pourriez aller plus vite si vos programmeurs faibles se dérobaient. Si vous agissiez ainsi, vous feriez davantage de progrès à court terme. Cependant, votre tribu perdrait certains avantages importants, à savoir la formation des membres les plus faibles, la diffusion des connaissances tribales et la capacité de se remettre de la perte des membres les plus puissants. Les forts doivent être souples à cet égard et examiner la question sous tous les angles.

Vous pouvez souvent confier aux membres les plus forts de l’équipe des tâches difficiles, mais soigneusement délimitées.

IV-C-2 - Comment choisir sur quoi travailler

Vous établissez un équilibre entre vos besoins personnels et ceux de l’équipe pour choisir l’aspect du projet à traiter. Vous devriez faire ce pour quoi vous êtes le meilleur, mais essayez de trouver un moyen de vous développer, non pas en prenant plus de travail, mais en exerçant une nouvelle compétence. Les compétences en leadership et en communication sont plus importantes que les compétences techniques. Si vous êtes très fort, prenez la tâche la plus difficile ou la plus risquée et le plus tôt possible dans le projet afin de réduire les risques.

IV-C-3 - Comment tirer le meilleur parti de vos coéquipiers

Pour tirer le meilleur parti de vos coéquipiers, développez un bon esprit d'équipe et essayez de garder chaque individu à la fois stimulé et engagé personnellement.

Pour développer l’esprit d’équipe, il est bon d’utiliser des objets insignifiants comme des vêtements et des fêtes avec un logo, mais pas autant que le respect personnel. Si tout le monde respecte les autres, personne ne voudra laisser tomber quelqu'un. L'esprit d'équipe est créé lorsque les gens font des sacrifices pour l'équipe et pensent en termes de bien de l'équipe avant leur bien personnel. En tant que dirigeant, vous ne pouvez pas demander plus que ce que vous vous donnez à cet égard.

L’une des clefs du leadership d'équipe est de faciliter le consensus afin que tout le monde ait son mot à dire. Cela signifie parfois de permettre à vos coéquipiers de se tromper. Autrement dit, si cela ne nuit pas trop au projet, vous devez laisser une partie de votre équipe agir à sa manière, sur la base d’un consensus, même si vous croyez avec une grande certitude que ce n’est pas la bonne chose à faire. Lorsque cela se produit, n'acceptez pas, désapprouvez ouvertement et acceptez le consensus. Ne semblez pas blessé ou si vous y êtes forcé, déclarez simplement que vous n'êtes pas d'accord, mais pensez que le consensus de l'équipe est plus important. Cela fera souvent revenir en arrière les personnes qui ne sont pas de votre avis. N'insistez pas pour que ceux qui font marche arrière réalisent leur plan initial.

Si une personne refuse de donner son consentement une fois que vous avez discuté des problèmes de toutes les parties concernées, indiquez simplement que vous devez prendre une décision et quelle est votre décision. S'il existe un moyen de juger si votre décision sera mauvaise ou s'il est démontré ultérieurement qu'elle est fausse, changez-la le plus rapidement possible et reconnaissez les personnes qui avaient raison.

Demandez à votre équipe, en tant que groupe et individuellement, ce qui pourrait, selon elle, créer l’esprit d’équipe et créer une équipe efficace.

Félicitez fréquemment plutôt que généreusement. Reconnaissez tout particulièrement ceux qui ne sont pas d’accord avec vous quand ils sont louables. Félicitez en public et critiquez en privé, à une exception près : parfois, l’évolution ou la correction d'une faute ne peuvent être félicitées sans attirer l'attention embarrassante sur la faute d'origine, de sorte que l’évolution devrait être félicitée en privé.

IV-C-4 - Comment diviser les problèmes

C'est amusant de diviser un projet logiciel en tâches qui seront exécutées par des individus. Cela devrait être fait au plus tôt. Parfois, les responsables aiment penser qu’une estimation peut être faite sans tenir compte des personnes qui effectueront le travail. Ceci est impossible tant la productivité des individus varie. Les personnes ayant des connaissances particulières sur un composant changent également constamment et peuvent avoir un effet sur l'ordre de grandeur des performances.

Tout comme un compositeur considère le timbre de l'instrument qui jouera un rôle ou l'entraîneur d'une équipe sportive considère les forces de chaque joueur, le chef d'équipe expérimenté ne sera généralement pas en mesure de séparer la division du projet en tâches, des membres de l'équipe auxquelles elles seront affectées. Cela fait partie de la raison pour laquelle une équipe performante ne doit pas être divisée.

Cela présente un certain danger, car les gens s'ennuieront en misant sur leurs forces, sans jamais améliorer leurs faiblesses ni acquérir de nouvelles compétences. Cependant, la spécialisation est un outil de productivité très utile quand elle n’est pas trop utilisée.

IV-C-5 - Comment gérer les tâches ennuyeuses

Parfois, il n’est pas possible d’éviter des tâches fastidieuses essentielles au succès de l’entreprise ou du projet. Ces tâches peuvent vraiment nuire au moral de ceux qui doivent les accomplir. La meilleure technique, pour y remédier, consiste à invoquer ou à promouvoir la vertu de la paresse de Larry Wall, programmeur. Essayez de trouver un moyen de charger votre ordinateur de la tâche ou d'aider vos coéquipiers à le faire. Travailler pendant une semaine sur un programme pour effectuer une tâche qui prendra une semaine à la main a le grand avantage d’être plus éducatif et parfois plus reproductible.

Si tout le reste échoue, présentez des excuses à ceux qui doivent faire la tâche ennuyeuse, mais ne leur permettez en aucun cas de le faire seul. Au minimum, affectez une équipe de deux personnes pour effectuer le travail et promouvoir un travail d'équipe sain afin d'accomplir la tâche.

IV-C-6 - Comment réunir du soutien pour un projet

Pour obtenir le soutien pour un projet, créez et communiquez une vision qui démontre une réelle valeur pour l’organisation dans son ensemble. Essayez de laisser les autres partager votre vision. Cela leur donne une raison de vous soutenir et vous fait profiter de leurs idées. Recrutez individuellement des soutiens clefs pour votre projet. Dans la mesure du possible, montrez, ne dites pas. Si possible, construisez un prototype ou une maquette pour illustrer vos idées. Un prototype est toujours puissant, mais dans le logiciel, il est de loin supérieur à toute description écrite.

IV-C-7 - Comment faire grandir un système

La graine d'un arbre contient l'idée de l'adulte, mais ne réalise pas complètement la forme et la puissance de l'adulte. L'embryon grandit. Il devient plus grand. Il ressemble plus à l'adulte et a plus d'usages. Finalement, il porte des fruits. Plus tard, il meurt et son corps nourrit d'autres organismes.

Nous avons le luxe de traiter un logiciel comme ça. Un pont n'est pas comme ça; il n'y a jamais de pont « bébé », mais simplement un pont inachevé. Les ponts sont beaucoup plus simples que les logiciels.

Il est bon de penser que les logiciels sont en croissance, car ils nous permettent de faire des progrès utiles avant d’avoir une image mentale parfaite. Nous pouvons obtenir les retours des utilisateurs et les utiliser pour corriger la croissance. L’élagage des membres faibles est une chose utile.

Le programmeur doit concevoir un système fini pouvant être livré et utilisé. Mais le programmeur avancé doit faire plus. Il doit concevoir un chemin de croissance qui se termine dans le système fini. C'est votre travail de prendre le germe d'une idée et de construire un chemin qui la transpose le plus facilement possible en un artefact utile.

Pour ce faire, vous devez visualiser le résultat final et le communiquer de manière à ce que l'équipe d'ingénieurs puisse s'enthousiasmer. Mais vous devez également communiquer aux programmeurs un chemin qui va de l’endroit où ils se trouvent à l’endroit où ils veulent être, sans grands sauts. L'arbre doit rester en vie tout le temps ; il ne peut pas être mort à un moment donné et ressusciter plus tard.

Cette approche est capturée dans le développement en spirale. Les jalons qui ne sont jamais trop éloignés sont utilisés pour marquer les progrès le long du chemin. Dans l'environnement extrêmement concurrentiel des entreprises, il est préférable que les jalons puissent être livrés et rapportent de l'argent le plus tôt possible, même s'ils sont loin d'un livrable bien conçu. L’un des travaux du programmeur consiste à trouver un équilibre entre les avantages immédiats et futurs, en choisissant judicieusement une trajectoire de croissance exprimée en étapes.

Le programmeur avancé assume la triple responsabilité de développer des logiciels, des équipes et des personnes.

Un lecteur, Rob Hafernik, a envoyé ce commentaire sur cette section que je ne saurais mieux faire que de citer intégralement :

« Je pense que vous sous-insistez sur l'importance ici. Ce ne sont pas que des systèmes, mais des algorithmes, des interfaces utilisateur, des modèles de données, etc. Lorsque vous travaillez sur un grand système, il est absolument essentiel de progresser de manière mesurable vers les objectifs intermédiaires. Rien n’est aussi grave que l’horreur particulière de s’attaquer à la fin et de découvrir que tout cela ne va tout simplement pas marcher (regardez la récente débâcle du système de nouvelles des électeurs). J'irais même plus loin et le qualifierais de loi de la nature : aucun système grand et complexe ne peut être mis en œuvre à partir de zéro, il ne peut qu’évoluer d'un système simple à un système complexe en une série d'étapes intentionnelles. »

A quoi on ne peut que répondre « Fiat lux ! »

Fiat lux est une locution latine présente au début de la Genèse. Il s'agit de la première parole de Dieu, ordre donné lorsqu'il a créé la lumière le premier jour de la création du monde, traduisible en français par « que la lumière soit ».

IV-C-8 - Comment bien communiquer

Pour bien communiquer, il faut reconnaître à quel point c'est difficile. C'est une compétence en soi. Cela est rendu plus difficile par le fait que les personnes avec lesquelles vous devez communiquer sont imparfaites. Elles ne feront pas d'effort pour vous comprendre. Elles parlent mal et écrivent mal. Elles sont souvent surchargées de travail ou dérangées et, tout du moins, concentrées sur leur propre travail plutôt que sur les problèmes plus vastes auxquels vous pourriez vous attaquer. L'un des avantages de prendre des cours, de pratiquer l'écriture et la prise de parole en public ainsi que l'écoute est que si vous devenez bon, vous pouvez plus facilement voir où sont les problèmes et comment les corriger.

Le programmeur est un animal social dont la survie dépend de la communication avec son équipe. Le programmeur avancé est un animal social dont la satisfaction dépend de la communication avec des personnes extérieures à son équipe.

Le programmeur met de l'ordre dans le chaos. Une façon intéressante de faire cela est de lancer une proposition quelconque en dehors de l’équipe. Cela peut être fait dans un format papier blanc ou simplement verbalement. Ce leadership présente l’énorme avantage de fixer les termes du débat. Cela vous expose également à la critique et, pire encore, au rejet et à la négligence. Le programmeur avancé doit être prêt à accepter cela, car il a un pouvoir unique et donc une responsabilité unique. Les entrepreneurs qui ne sont pas des programmeurs ont besoin que ceux-ci fassent preuve de leadership à certains égards. Les programmeurs sont la partie du pont entre les idées et la réalité.

Je ne maîtrise pas bien la communication, mais ce que j’essaie actuellement, c’est de la considérer comme une approche à quatre volets : une fois la mise de mes idées en ordre, une préparation parfaite, je m'essaie à l'oral, je donne un papier blanc aux gens (sur papier réel, ainsi qu'électroniquement) pour leur faire une démonstration, puis je répète patiemment ce processus. Je pense que bien souvent nous ne sommes pas assez patients dans ce type de communication difficile. Vous ne devriez pas être découragé si vos idées ne sont pas immédiatement acceptées. Si vous avez investi de l'énergie dans leur préparation, personne ne vous le reprochera.

IV-C-9 - Comment dire aux gens les choses qu’ils ne veulent pas entendre

Vous devrez souvent dire aux gens des choses qui les rendront mal à l'aise. Rappelez-vous que vous faites cela pour une raison. Même si rien ne peut être fait pour résoudre le problème, dites-leur le plus tôt possible pour qu'ils soient bien informés.

La meilleure façon de parler d'un problème à quelqu'un est de proposer une solution en même temps. Le deuxième meilleur moyen est de faire appel à eux pour aider à résoudre le problème. S'il existe un danger que vous ne soyez pas cru, vous devriez trouver des personnes ou rassembler des preuves qui étayent vos propos.

L’une des choses les plus désagréables et les plus courantes que vous aurez à dire est : « Le planning devra être revu ». Le programmeur consciencieux déteste dire cela, mais il doit le dire le plus tôt possible. Il n’y a rien de pire que de remettre une action à plus tard quand le planning glisse, même si la seule action consiste à informer tout le monde. Ce faisant, il vaut mieux le faire en équipe, au moins spirituellement, si ce n'est pas fait physiquement. Vous voudrez connaître l'opinion de votre équipe sur votre position et les solutions possibles et l’équipe devra faire face aux conséquences avec vous.

IV-C-10 - Comment gérer les mythes managériaux

Le mot mythe signifie parfois fiction. Mais il a une connotation plus profonde. Cela signifie également une histoire de signification religieuse qui explique l'univers et la relation de l'humanité avec lui. Les managers ont tendance à oublier ce qu'ils ont appris en tant que programmeurs et à croire à certains mythes. Il serait aussi impoli et infructueux d'essayer de les convaincre que ces mythes sont faux, que d'essayer de désillusionner une personne profondément dévote de ses propres croyances . Pour cette raison, vous devriez reconnaître ces croyances comme des mythes :

- plus de documentation est toujours mieux. (Ils le veulent, mais ils ne veulent pas que vous passiez du temps dessus.) ;

- des ressources peuvent être ajoutées à un projet en retard pour l'accélérer. (Le coût de la communication avec les nouvelles personnes est presque toujours plus élevé qu'utile.) ;

- il est possible d'estimer le développement de logiciels de manière fiable. (Ce n'est même pas théoriquement possible.) ;

- la productivité des programmeurs peut être mesurée à l'aide de métriques simples, telles que des lignes de code. (Si être succinct est le pouvoir, les lignes de code sont mauvaises, pas bonnes.).

Si vous avez une opportunité, vous pouvez essayer d'expliquer ces choses, mais ne vous sentez pas mal si vous ne réussissez pas et n'endommagez pas votre réputation en confrontant ces mythes de manière belliqueuse. Chacun de ces mythes renforce l'idée du responsable selon laquelle il contrôle réellement ce qui se passe. La vérité est que les gestionnaires facilitent s’ils sont bons et gênent s’ils sont mauvais.

IV-C-11 - Comment gérer le chaos organisationnel

Il y a souvent de brèves périodes de grand chaos organisationnel, telles que des relâches, des rachats, des introductions en bourse, des licenciements, de nouvelles embauches, etc. Cela dérange tout le monde, mais peut-être un peu moins le programmeur dont l'estime personnelle est fondée sur la capacité plutôt que sur la position. Le chaos organisationnel est une excellente occasion pour les programmeurs d'exercer leur pouvoir magique. Je l'ai gardé pour la fin, car c'est un secret tribal profond. Si vous n'êtes pas programmeur, arrêtez de lire maintenant.

Les ingénieurs ont le pouvoir de créer et de maintenir.

Les non-ingénieurs peuvent diriger du personnel, mais dans une entreprise de logiciels classique, rien ne peut être créé et maintenu sans les ingénieurs, tout comme les ingénieurs ne peuvent généralement pas vendre un produit ou gérer efficacement une entreprise. Ce pouvoir résiste à presque tous les problèmes liés au chaos temporaire de l’organisation. Quand vous en avez, vous devriez ignorer complètement le chaos et continuer comme si de rien n'était. Vous pouvez bien sûr vous faire virer, mais si cela se produit, vous pourrez probablement obtenir un nouvel emploi grâce au pouvoir magique. Plus généralement, une personne stressée qui n'a pas le pouvoir magique entrera dans votre cercle et vous dira de faire quelque chose de stupide. Si vous êtes vraiment sûr que c'est stupide, il est préférable de sourire et de hocher la tête jusqu'à ce qu'elle s'en aille, puis de continuer à faire ce que vous savez être le meilleur pour la société.

Si vous êtes un dirigeant, dites à votre personnel de faire la même chose et dites-leur d'ignorer ce que quelqu'un d'autre leur dit. Cette ligne de conduite est ce qu'il y a de mieux pour vous personnellement et pour votre entreprise ou votre projet.

V - Note de la Rédaction de Developpez.com

Ce guide est une traduction de How to be a Programmer: Community Version.

Nous tenons à remercier vavavoum74 et bboulch pour la traduction, Christophe pour la relecture technique et escartefigue pour la correction orthographique.

(1)Texte littéral