Trois mauvaises habitudes à éviter pour un développeur

dimanche 1er novembre 2020 par SocraticDev

Adopter des habitudes positives et productives est absolument nécessaire pour avoir une carrière fructueuse.

David Xiang, leader technique chez Squarespace à New York et auteur du livre "Software Developer Life" discute de trois habitudes à se défaire en tant que développeur. Ce sont des pièges dans lesquels la plupart d'entre nous sommes tombés. À différents degrés. Il propose des solutions simples et proactives à ces trois mauvaises habitudes.

S'embourber dans un terrier de lapin (rabbit hole)

S'embourber dans un terrier de lapin signifie, pour un développeur, de prendre beaucoup plus de temps prévu sur une tâche sans informer son équipe qu'il est bloqué. Le développeur devrait être en tout temps en mesure de communiquer le statut de son travail. Surtout s'ils n'ont pas encore terminé une tâche qui devrait l'être.

Beaucoup de programmeurs croient qu'ils devraient être en mesure de tout régler par eux-mêmes sans l'aide de leurs collègues. Ils croient même qu'avouer être bloqué pourrait leur donner une mauvaise réputation. Or, c'est tout à fait le contraire. Un programmeur embourbé qui modifie des fichiers à gauche et à droite et n'est pas en mesure de donner l'heure juste à son équipe est très dangeureux. Il peut causer des bogues et d'autres dommages.

Vous gagnerez beaucoup plus de respect et de confiance si vous êtes en mesure d'informer votre équipe de vos difficultés. Même les programmeurs les plus expériementés frappent des problèmes difficiles à régler. Dès qu'on constate que ça n'avance pas comme prévu, qu'on commence à tourner en rond, il faut lever la main et informer l'équipe qu'on est bloqué.

Ne pas être autonome : poser plusieurs fois les mêmes questions

En arrivant dans une nouvelle équipe, tout est nouveau et vous poserez beaucoup de questions. C'est très bien!

On vous montrera comment l'équipe gère les tâches, où trouver la documentation, comment mettre en place votre environnement de développement, etc. Prenez l'habitude de tout prendre en note. Si on vous explique des processus, c'est votre responsabilité de les apprendre.

Personnellement, je centralise et classifie toute information non-sensible dans l'application OneNote de Microsoft. Ce n'est pas tant de noter l'information elle-même, mais savoir où se trouve l'information et comment la retrouver. C'est une marque de compétence de comprendre et être autonome dans son environnement de développement et le domaine d'affaires où on ajoute de la valeur, non ?

Effectuer des tâches sans comprendre le contexte entourant le code

Beaucoup de développeurs se donnent pour objectif de régler des bogues le plus rapidemment possible. Or ce n'est habituellement pas ce que le leader technique désire. En assignant un bogue à un nouveau développeur, le leader technique ne l'invite pas tant à corriger bêtement le bogue qu'à comprendre le système où il se produit. Il y aura toujours une façon bête et méchante de corriger un bogue. La plupart du temps ça ne fait que déplacer le problème un peu plus loin. Un bon développeur prendra le temps de comprendre le sous-système entourant le bogue afin de se familiariser avec l'application sur laquelle il travaille.

Au final, pour une carrière heureuse en développement logiciel, on adoptera certaines habitudes pouvant contredire nos préconceptions :

  1. Un programmeur pouvant communiquer ses problèmes et son statut est beaucoup plus apprécié qu'un programmeur perdu qui ne communique pas;

  2. Un programmeur autonome et compétent est un programmeur qui absorbe l'information comme une éponge et qui connaît son environnement de développement et les processus d'affaires qu'il développe;

  3. Régler des bogues en un temps record n'est pas ce que recherche une bonne organisation. Une bonne organisation donne des opportunités au développeur d'apprendre les processus d'affaire, le contexte et les particularités des sous-systèmes sur lesquels il est appelé à intervenir.

Bref, un développeur compétent est beaucoup plus qu'un "code monkey". C'est un participant essentiel au processus de développement de logiciel. Et cela demande beaucoup d'humilité, d'initiative et des bonnes habitudes de travail.

Source

3 Common Software Development Mistakes To Avoid