Apprendre comment devenir un bon programmeur

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.

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

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 « kitxmlcodeinlinelatexdvpn^2finkitxmlcodeinlinelatexdvp ». 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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.