Article original : These are the key non-coding skills all programmers should have

Par karntrehan

En tant que programmeurs, nous faisons bien plus chaque jour que simplement écrire du code incroyable.

Oui, coder est ce que la majorité d'entre nous aime faire le plus et ce avec quoi les gens nous associent le plus. Mais il existe diverses autres compétences impliquées dans le fait d'être un grand programmeur.

Voici quelques-unes de ces compétences que je pense que nous ne reconnaissons parfois pas à leur juste valeur. Elles valent la peine d'être cultivées davantage pour devenir un meilleur programmeur et aussi une meilleure personne.

Lecture

Nous lisons quotidiennement.

Que ce soit le code d'un autre programmeur, des documentations (parfois déconcertantes), des blogs, des forums ou des faits sur Jon Skeet sur StackOverflow, nous lisons constamment.

Plus nous lisons, plus nous en savons sur une technologie, un framework, ou les opinions et expériences des autres concernant ces technologies et frameworks.

Le jour où nous arrêtons de lire, nous risquons de devenir obsolètes. C'est à quelle vitesse le domaine de la technologie évolue. La meilleure façon de faire quelque chose aujourd'hui peut ne pas être la meilleure demain.

Par conséquent, plus nous lisons, meilleurs nous devenons.

Il est vraiment important pour moi de lire le code des autres et d'avoir un avis à ce sujet afin de comprendre à quoi ressemble un bon code. C'est ainsi que je peux écrire un meilleur code ou suggérer des améliorations au code que j'hérite.

Écriture

Nous écrivons beaucoup de contenu non codé dans nos projets. Cela inclut une belle documentation, des commentaires et des messages de commit. Certains d'entre nous aiment passer leur temps à écrire des blogs.

Avoir de bonnes compétences en écriture dans notre documentation et nos commentaires rend notre code plus facile à comprendre, à déboguer et à maintenir. Un bon message de commit peut aider à économiser des heures à l'avenir lorsque vous souhaitez identifier ce qui a exactement changé dans votre base de code.

Écrire du contenu non codé ne vient pas naturellement à nous tous. Les retours et la motivation des pairs aident beaucoup.

Nous demandons des retours, nous travaillons dessus, et nous nous améliorons. Et si nous ne demandons pas toujours, allez-y et donnez-nous des retours avec compassion de toute façon, nous les apprécierons le plus.

Je pense que lorsque vous écrivez des blogs, vous voulez que ce soit parfait parce qu'un grand public va le lire, donc vous apprenez de plus en plus. Also second thing is I always believe writing things down helps you never forget them.

Écoute

Nous écoutons et traduisons constamment. Nous convertissons constamment des exigences de fonctionnalités non techniques en solutions techniques.

Lorsque nous entendons « Ajoutez un bouton pour faire X », nous pensons aux diverses implications que ce changement pourrait avoir, au code impliqué, aux choses qu'il pourrait casser ainsi qu'à l'expérience utilisateur.

Nous nous soucions de nos utilisateurs autant que tout le monde dans l'équipe.

Une exigence apparemment simple pourrait nous faire réfléchir pendant des heures. Nous écoutons et posons des questions. Nous débattons de la valeur d'une fonctionnalité. Nous ne voulons pas manquer de détails, car corriger les exigences manquantes plus tard devient très frustrant et coûteux pour nous.

L'écoute est une compétence très basique et l'une des plus importantes qu'un développeur devrait avoir. La manière la plus simple de comprendre les exigences est par « l'empathie ». Mettez-vous à la place du client ou des utilisateurs finaux et regardez les choses de leur perspective. Posez-vous des questions comme :
• Comment cela résout-il le problème ?
• Est-ce suffisamment intuitif ?

Communication

À mon avis, la facilité de communication définit le succès d'une organisation. La facilité avec laquelle différentes parties prenantes d'une équipe peuvent communiquer entre elles dicte nos chances d'atteindre nos objectifs avec succès.

Nous avons des idées. Nous aimons les partager. Plus les canaux de communication sont faciles, plus il est facile de partager des idées, de savoir ce que l'on attend de nous et de contribuer à l'objectif commun aligné.

Si la communication est difficile autour de nous, cela devient un signal d'alarme et rend les choses difficiles pour beaucoup d'entre nous.

En tant que développeur, il est important de communiquer avec compassion avec votre équipe de conception. Une fois que vous recevez les designs et que vous avez des retours, demandez aux designers « Quelle était l'idée derrière cela ? », « Est-ce ce que l'utilisateur veut ? ». Demander pourquoi plutôt que de dire « ... cela pourrait être mieux », aide à établir une communication efficace et garantit que vos retours sont bien reçus.

Priorisation

Nous attribuons constamment des scores de priorité aux tâches.

Dois-je travailler sur cette fonctionnalité ou sur celle-là ? Qu'est-ce qui m'aiderait ? Qu'est-ce qui aiderait mon équipe ? Qu'est-ce qui aiderait les utilisateurs ? Quelqu'un d'autre écrirait-il cela mieux ? Dois-je essayer d'écrire une solution parfaite dès le départ ou écrire quelque chose qui fonctionne maintenant et ensuite le refactoriser pour l'améliorer avant de le livrer ?

Prioriser les tâches peut nous aider à livrer mieux et à réduire les efforts gaspillés sur des tâches redondantes.

La priorité est importante car il y a toujours de la place pour l'amélioration dans le développement et il y a de nombreuses fonctionnalités à ajouter et de nombreux problèmes à résoudre. Si nous ne priorisons pas, le projet ne sera jamais terminé. Je priorise généralement les choses en fonction du « temps pris, impact, résultat final, effort, valeur pour l'utilisateur, valeur pour l'entreprise ».

Camaraderie

Nous sommes de grands joueurs d'équipe.

Le logiciel implique généralement un grand nombre de personnes issues de différentes équipes. Chaque version implique des efforts de la part des équipes backend, frontend, API, des designers, des chefs de produit et des testeurs, entre autres. Un bug dans le système backend n'est pas une erreur backend, mais un bug d'équipe. Nous assumons tous une responsabilité collective pour cela et aidons à le résoudre.

Plus nous pensons et travaillons en équipe, plus nous sommes individuellement réussis.

Au sein d'une équipe, le travail d'équipe aide à accomplir le travail plus rapidement car nous sommes conscients des forces et des faiblesses de chaque membre. Tout comme dans un match de cricket, connaître les forces de vos joueurs aide à identifier quel lanceur devrait lancer à quel batteur, ce qui augmente vos chances de gagner le match.

Mentorat

Beaucoup d'entre nous sont autodidactes et apprennent constamment.

Nous ne connaissons peut-être pas la meilleure façon de faire quelque chose dès le premier jour. Nous cherchons donc des mentors. Les mentors nous aident à identifier les erreurs tôt, à cultiver le bon état d'esprit et à devenir plus confiants.

À mesure que notre confiance grandit, nous commençons à essayer de nouvelles choses. Nous faisons parfois des erreurs, apprenons d'elles et partageons nos apprentissages avec le monde. C'est à ce moment-là que nous commençons à être des mentors pour quelqu'un d'autre.

Le mentorat, à mon avis, ressemble plus à BitTorrent. Vous avez des morceaux du tout, aucune personne ne possède tout, et vous partagez toujours ce que vous avez avec les autres qui ne l'ont pas, même si vous avez 1% du fichier.

Contributions communautaires

À mesure que nous grandissons, nous commençons à comprendre le rôle extrêmement important que joue la communauté dans notre croissance et commençons à contribuer à la communauté avec un cœur ouvert.

Nous commençons à chercher des rencontres locales, des conférences et des projets open source auxquels nous pouvons contribuer. Nous offrons notre talent le plus important gratuitement, pour la croissance de la communauté. Que ce soit en donnant des conférences, en assistant à des conférences, en soutenant les intervenants, en organisant des rencontres, en écrivant des blogs, en open sourçant des choses, en améliorant des projets open source existants, etc., nous faisons notre part dans la communauté.

Nous sommes la communauté et jouons un rôle vital dans sa croissance.

Ai-je oublié une compétence ? Souhaitez-vous discuter de l'une des compétences plus en détail ? Souhaitez-vous partager une histoire personnelle liée à l'une de ces compétences ? Cela devrait-il faire partie d'un programme éducatif ? Commentez ci-dessous ou connectez-vous avec moi sur Twitter !