Récemment, j'ai lu beaucoup d'articles de Steve Yegge. L'un d'eux, intitulé « Practicing Programming » (s'exercer à la programmation), a été écrit en 2005, et après l'avoir lu, j'ai été stupéfait :

Contrairement à ce que vous croyez, le simple fait de vous plonger dans le travail chaque jour n'est pas une véritable pratique : assister à des réunions n'exerce pas vos compétences relationnelles ; répondre à des e-mails n'améliore pas votre vitesse de frappe. Vous devez régulièrement vous ménager du temps pour une pratique ciblée afin de faire mieux les choses.
Je connais de nombreux programmeurs exceptionnels — c'est l'un des meilleurs « avantages » supplémentaires de travailler chez Amazon. Si vous les observez attentivement, vous constaterez qu'ils s'exercent toujours. Ils sont déjà excellents, mais ils continuent de s'exercer. Leurs façons de s'exercer sont variées, et je n'en présenterai que quelques-unes dans cet article.
D'après ce que je comprends, la raison pour laquelle ces programmeurs exceptionnels réussissent si bien est qu'ils n'ont cessé de s'exercer. Un corps parfait ne s'obtient que par un exercice régulier, et vous devez continuer à faire de l'exercice pour le maintenir, sinon il perdra la forme. Il en va de même pour la programmation et le génie logiciel.

C'est une distinction importante — je conduis pour aller au travail chaque jour, mais mon niveau de conduite est bien inférieur à celui d'un conducteur professionnel ; de même, programmer chaque jour peut ne pas suffire à faire de vous un programmeur professionnel. Alors, qu'est-ce qui peut transformer une personne ordinaire en conducteur professionnel ou en programmeur professionnel ? Que devez-vous pratiquer ?
La réponse se trouve dans un article de Scientific American intitulé « The Expert Mind » (l'esprit expert) :

Ericsson a proposé que ce qui compte n’est pas l’expérience elle-même, mais la « pratique délibérée », c’est-à-dire le fait de se confronter constamment à des choses qui dépassent vos capacités actuelles. Certains amateurs enthousiastes passent beaucoup de temps à jouer aux échecs, au golf ou à un instrument de musique, mais ils peuvent rester à un niveau amateur, et c’est pourquoi un étudiant bien entraîné peut les surpasser en relativement peu de temps. Notamment, en ce qui concerne l’amélioration de votre niveau, une grande quantité de temps passée à jouer aux échecs (même dans diverses compétitions) semble encore moins efficace qu’un entraînement dédié. La valeur principale de l’entraînement est de découvrir ses faiblesses et de les améliorer de manière ciblée.

La « pratique délibérée » signifie souvent traiter des problèmes qui se situent juste à la limite de vos capacités, c’est-à-dire des choses où vous avez une forte probabilité d’échouer. Si vous ne rencontrez pas un certain échec, vous ne progresserez peut-être pas. Vous devez constamment vous lancer des défis et dépasser vos limites.

De tels défis surviennent parfois au travail, mais pas nécessairement. Séparer la pratique du travail professionnel est souvent appelé « Code Kata » dans le domaine de la programmation.

Le concept de Code Kata a été proposé par David Thomas, l’un des auteurs de The Pragmatic Programmer: From Journeyman to Master. Ce concept désigne principalement une pratique répétée sur une technique ou une compétence particulière afin de la maîtriser. — Note du traducteur.


Ce que l’on appelle un kata est une série de mouvements. Ce concept est emprunté aux arts martiaux.

Si vous voulez voir quelques exemples de code katas (c’est-à-dire des façons d’étudier assidûment et de perfectionner ses compétences en programmation), l’article de Steve Yegge offre effectivement de bonnes suggestions. Il les appelle « exercices d’entraînement » :

1. Rédigez votre propre CV. Listez toutes vos compétences pertinentes, puis marquez celles qui seront encore utiles dans 100 ans. Attribuez à chaque compétence une note sur 10.

2. Dressez la liste des programmeurs que vous admirez. Essayez d’y inclure ceux avec qui vous travaillez, car vous acquerrez certaines compétences grâce à eux au travail. Notez 1–2 points forts de chacun d’eux, c’est-à-dire les aspects que vous souhaitez améliorer chez vous.

3. Consultez la section « Informatique » sur Wikipédia, trouvez la catégorie « Pionniers de l’informatique », choisissez une personne dans la liste, lisez son histoire et ouvrez tous les liens qui vous intéressent pendant votre lecture.

4. Passez 20 minutes à lire le code de quelqu’un d’autre. Lire du code excellent et lire du code médiocre sont tous deux bénéfiques ; alternez entre les deux. Si vous ne parvenez pas à faire la différence entre eux, demandez à un programmeur que vous respectez de vous montrer à quoi ressemblent du code excellent et du code médiocre. Montrez aux autres le code que vous avez lu et demandez leur avis.

5. Dressez la liste de vos 10 outils de programmation préférés — ceux que vous estimez utiliser le plus et dont vous ne pouvez pas vous passer. Choisissez-en un au hasard et passez une heure à lire sa documentation. Pendant cette heure, essayez d’apprendre une fonctionnalité de cet outil dont vous ignoriez l’existence, ou découvrez une nouvelle façon de l’utiliser.

6. Réfléchissez à ce dans quoi vous êtes le meilleur, en dehors de la programmation. Pensez ensuite au type de pratique qui vous a rendu si compétent et professionnel. Quelle inspiration cela apporte-t-il à votre travail de programmation ? (Comment pouvez-vous appliquer ces expériences à la programmation ?)

7. Prenez une pile de CV et passez une heure dans une salle avec un groupe d’intervieweurs. Assurez-vous que chaque CV est lu par au moins 3 intervieweurs et se voit attribuer une note de 1 à 3. Discutez des CV qui ont reçu des notes très différentes d’un intervieweur à l’autre.

8. Participez à un entretien téléphonique. Ensuite, notez votre retour, partagez vos opinions, puis parlez à la personne qui a mené l’entretien téléphonique pour voir si vous êtes d’accord sur une conclusion.

9. Menez un entretien technique, et le candidat doit être un expert dans un domaine que vous connaissez peu. Demandez-lui de supposer que le public ne connaît rien à ce domaine, alors faites-lui commencer par les bases. Essayez de comprendre ce qu'il dit, et posez des questions lorsque c'est nécessaire.

10. Saisissez l'occasion d'assister à l'entretien technique de quelqu'un d'autre. Pendant le processus, contentez-vous d'écouter attentivement et d'apprendre. Pendant que le candidat travaille dur pour résoudre des problèmes techniques, essayez aussi de résoudre ces problèmes dans votre tête.

11. Trouvez une personne avec qui vous pouvez échanger des problèmes pratiques, et partagez des problèmes de programmation entre vous toutes les deux semaines. Passez 10–15 minutes à essayer de les résoudre, puis 10–15 minutes à en discuter (qu'ils soient résolus ou non).

12. Lorsque vous entendez une question d'entretien que vous ne pouvez pas résoudre immédiatement, retournez rapidement à votre place et envoyez-vous la question par courriel comme rappel pour plus tard. Trouvez un moment dans la semaine pour la résoudre avec votre langage de programmation préféré.

La raison pour laquelle j'aime la liste de Steve, c'est qu'elle semble exhaustive. Certains programmeurs considèrent la « pratique » comme de simples casse-têtes de programmation difficiles. Mais selon moi,la programmation concerne davantage les personnes que le code.Par conséquent, en résolvant toutes les questions obscures d'entretiens de programmation du monde, cette approche a une capacité limitée à améliorer vos compétences personnelles.

En ce qui concerne la « pratique délibérée », j'aime aussi les« Teach Yourself Programming in Ten Years » de Peter Norvig (apprendre la programmation en dix ans par soi-même)nombreuses suggestions formulées dans l'article :

1. Communiquez avec d'autres programmeurs. Lisez le code des autres. C'est plus important que n'importe quel livre ou cours de formation.

2. Écrivez vous-même des programmes ! La meilleure façon d'apprendre est d'apprendre en faisant.

3. Suivez des cours de programmation dans le cadre d'un premier ou d'un deuxième cycle universitaire.

4. Trouvez quelques projets à réaliser et formez une équipe avec d'autres programmeurs. Pendant le projet, apprenez à distinguer les meilleurs programmeurs des pires.

5. Travaillez avec d'autres programmeurs sur des projets, apprenez à maintenir du code que vous n'avez pas écrit et apprenez à écrire du code facile à maintenir pour les autres.

6. Apprenez de nombreux langages de programmation différents, en particulier ceux qui ont une vision du monde et un modèle de programmation différents de ceux des langages que vous connaissez actuellement.

7. Comprenez l'impact du matériel sur le logiciel. Sachez combien de temps il faut à votre ordinateur pour exécuter une instruction, combien de temps il faut pour récupérer un mot depuis la mémoire (avec ou sans cache), combien de temps il faut pour transférer des données sur Ethernet (ou sur Internet), combien de temps il faut pour lire des données séquentielles depuis un disque ou se déplacer vers un autre emplacement sur un disque, etc.

Vous pouvez également vous inspirer des 21 katas de code pratiques de Dave Thomas (CodeKata.com), ou vous préférerez peut-être rejoindre un « dojo de programmation » local (CodingDojo.org).

Pour la « pratique délibérée », je ne peux pas fournir une longue liste de suggestions comme Steve, Peter ou Dave. Je suis bien moins patient qu'eux. En fait, à mon avis, le « kata de code » ne nécessite que deux mouvements :

1. Écrivez un blog. J'ai fondé le blog CodingHorror.com au début de 2004 comme une forme de ma propre pratique délibérée. Il était très peu connu au début, mais il est ensuite devenu la chose la plus importante que j'aie faite dans ma carrière. Vous devriez donc écrire un blog, vous aussi. Ceux qui finissent par « se faire connaître du monde » sont souvent ceux qui savent écrire et communiquer efficacement. Leurs voix sont les plus fortes ; ce sont eux qui établissent les règles et orientent les tendances mondiales.

2. Participez activement à des projets open source célèbres. Tous les grands discours sonnent bien, mais êtes-vous un beau parleur ou quelqu'un qui agit ? Ne vous contentez pas de parler sans agir. C'est très important, car les gens vous jugeront sur vos actes, pas sur vos paroles. Efforcez-vous de laisser quelque chose de réel et d'utile dans le domaine public, puis vous pourrez dire : « J'ai contribué à ce projet. »

Lorsque vous pourrez écrire un code brillant et expliquer ce code au monde avec des mots brillants, alors je considérerai que vous maîtrisez le kata de programmation le plus badass !

Source : http://www.topthink.com/topic/11711.html