Un peu comme le syndrome de la page blanche pour un écrivain, le projet non-démarré est une plaie connue de tous les développeurs. Souvent, nous avons tendance à vouloir élaborer un projet parfait. La plupart du temps, nos idées meurent dans l'oeuf. Avec la disponibilité de ressources puissantes et souvent gratuites, nous n'avons aucune excuse pour ne rien avoir concret à ajouter à notre portefolio.

Pour les projets personnels, ma suggestion est simple : tout est bien. Pas de tests unitaires? plus tard! Vous utilisez des ressources disponibles dans des librairies open-source au lieu de tout coder vous-mêmes? Bonne idée!

L'important est d'avoir donné naissance à un projet et l'avoir rendu disponible au public. Non?

Au boulot, cuillez toujours les fruits à portée de la main

Si quelqu'un vous paye pour faire un travail : donnez-lui en pour son argent. Surtout, ne gaspillez pas vos efforts pour satisfaire vos idéaux de clean code et de respect des standards de l'industrie. Votre client s'en fout fort probablement.

La première chose à faire pour un développeur engagé par un client : se poser les questions suivantes

• Pourquoi mon client a-t-il besoin de ce système informatisé?

• Selon quels critères mon travail de développeur est-il jugé?

Hélas vous n'y échapperez pas : vous devez absolument savoir pourquoi votre client a besoin du système informatisé sur lequel vous êtes appelé à travailler. Que vous travailliez pour un organisme public, une compagnie d'assurance ou une boîte de jeu vidéo, comprendre les besoins du client est primordial.

En comprenant le domaine d'affaires, vous allez être en mesure de :

• Communiquer efficacement avec votre client;

• Prendre des décisions de façon éclairée;

• Offrir des conseils précieux.

Cette connaissance du domaine d'affaires et des priorités de votre client vous permettra aussi de déterminer les critères selon lequel votre travail sera jugé. Est-ce une ruse? Oui et non. Non, car il n'y a absolument rien de répréhensible à axer son travail en vue de répondre à ces critères. Oui, c'est une ruse car connaître les besoins du client vous permettra d'obtenir un succès avec un effort moindre qu'en travaillant à l'aveuglette ; en vous fiant à des a priori hypothétiques.

Certains développeurs croient à tort que leur employeur désire une productivité incroyable. Ils croient qu'en fermant un nombre important de tickets à chaque jour, ils font un bon travail. Or, c'est rarement le cas. La plupart du temps, ces développeurs produisent un code de qualité inférieure, ne testent pas bien leurs modifications et ralentissent même le processus en devant retravailler un correctif refusé par le contrôle de qualité.

D'autres développeurs se découvrent une passion pour le clean code, les principes SOLID et les bonnes pratiques. Pour le même résultat perçu par le client, ils travailleront davantage et, parfois, pour rien car la fonctionnalité sera rapidement abandonnée ou grandement modifiée dans une itération suivante. Somme toute, il est rare qu'un client valorise les prouesses techniques aux dépends d'un système fonctionnel et utile.

Des fruits à portée de la main?

Connaître le domaine d'affaires, les besoins du client ainsi que ses attentes vous permettront d'identifier ces tâches aisées qui auront un impact significatif pour votre client.

Voici quelques idées que j'ai rencontré dans mon quotidien :

• Être en mesure de tester ses corrections efficacement avant de fermer un ticket;

• Considérer comme prioritaire toute difficulté qui bloque un membre de l'équipe et offrir son aide;

• Être familier avec le code, le modèle de données et le pipeline de déploiement afin d'informer le client du risque ou de l'ampleur du travail prévu;

• Ne pas être trop critique envers le code : garder votre code propre et refactorer au besoin afin de toujours être en mesure de livrer les fonctionnalités répondant au besoin du client.

Comme chacun de vos clients vivent une réalité différente, on doit s'attendre à ce que ces tâches diffèrent d'un milieu à l'autre. La notion de "low-hanging fruit" est primordiale en développement. Faire moins d'effort pour obtenir les résultats ayant le plus grand impact.

Malgré tout, certaines tâches ardues demeurent inévitables. Toutefois en prenant le temps de comprendre le contexte de votre intervention, vous allez économiser beaucoup d'efforts tout en répondant efficacement aux besoins de votre client.