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 dansune 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 !

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.

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.

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.

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.

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.

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.