Pourquoi le codage est-il si difficile ? | Partie 1

Ce billet porte sur un sujet technique : le codage. Mais pour être clair, je n’ai pas de formation technique.

Je suis le fier fils d’un artiste qui m’a appris à utiliser mes émotions comme boussole pour naviguer dans la vie, plutôt que la logique. L’argile, le graphite, l’encre, la peinture, la toile, le papier et l’adhésif coulent dans mes veines.

J’ai eu du mal à l’école pour de nombreuses raisons – parmi elles, deux difficultés d’apprentissage : des lésions nerveuses cérébrales dues à des complications à la naissance et une dyslexie et qui ne serait pas diagnostiquée jusqu’à la fin de ma vingtaine. Mes meilleurs résultats aux tests étaient si mauvais que j’ai failli ne pas entrer à l’université.

J’ai étudié les sciences politiques à l’école et mes premières tentatives ratées de carrière étaient dans le cinéma et le design graphique.

J’ai appris moi-même à coder – c’est l’une des choses les plus difficiles que j’ai jamais faites. J’ai également enseigné le code dans un bootcamp ici à D.C. pendant environ 5 ans et j’ai fait du mentorat avec des amis de temps en temps.

Bien que ce soit difficile, ce n’est pas impossible. Lorsque vous êtes autodidacte, vous apprenez des bribes et des morceaux. Parfois, quelque chose fait sens immédiatement, tandis que d’autres feront tilt dans des années. Le chemin de l’explication est bien tracé mais j’ai constaté que vos expériences de vie, vos dispositions et votre éducation font que la moitié de votre bataille consiste à trouver les bonnes ressources d’apprentissage.

Deux choses avant de commencer :

  1. Si je peux le faire, vous le pouvez aussi.
  2. Vous n’êtes pas seul.

Nouveau vocabulaire, nouveaux concepts, nouveau… tout

L’un des obstacles délicats à l’apprentissage du code est que les termes utilisés pour décrire quoi que ce soit en « langage de code » peuvent souvent signifier quelque chose d’entièrement différent en anglais ordinaire. Mon exemple préféré est le mot « classe ».

Contrairement aux connotations académiques ou sociologiques auxquelles nous sommes habitués, une classe en langage de programmation est différente selon le langage de programmation que vous utilisez. Encore plus déroutant dans ces différents langages de programmation, une Classe est à la fois assez liée conceptuellement pour établir des parallèles de ressemblance quant à savoir pourquoi ses auteurs originaux ont choisi de l’appeler une Classe, mais l’utilisation réelle est assez différente vraiment quelque chose de tout à fait différent. (Plus précisément, les classes CSS par rapport aux classes orientées objet)

Parler code s’apparente presque à de l’argot, ce qui, comme tout parent le sait, est frustrant. Il peut être difficile au début de signaler ce qui est un mot anglais normal et ce qui est un terme de « code ».

De plus, vous les entendez souvent en succession rapide, donc une phrase complète de code-speak sera grammaticalement correcte et vous connaîtrez chacun des mots séparément, mais pas lorsqu’ils sont disposés de cette façon.

« Après avoir vidé à la fois le cache du navigateur sur local et demandé à John de vider les caches du serveur sur staging, pensant que cela devait être une sorte de mémoire persistante ou un problème d’état, il s’est avéré qu’une collision de nommage écrasait les invocations définies plus tôt dans la racine. Je vais faire un ticket pour ajouter des cartes de source afin que nous puissions suivre les instanciations plus facilement au lieu de parcourir le repo. » -Phrase réelle que j’ai dite à mon patron, qui a hoché la tête d’un air approbateur.

Non seulement partir de zéro, définir ce qu’est le zéro

En plus de cela, il y a des concepts que vous n’avez jamais eu à rencontrer auparavant, et encore moins à combattre.

Un exemple que j’aime utiliser avec mes étudiants est:
Disons que vous voulez programmer votre ordinateur pour vous faire une tasse de café. Simple non ?

Vous : Hé Ordinateur : fais-moi une tasse de café.

Ordinateur : BEEP BOOP : BIEN SÛR PAT. QU’EST-CE QUE LE CAFÉ ET QU’EST-CE QUE L’ON FAIT ?

Imaginez toutes les façons dont vous pourriez faire du café… puis imaginez le processus pour obtenir le grain de café de l’arbre sur lequel il a poussé, dans une forme que vous pouvez utiliser dans ce processus… yikes.

Nous partons souvent de zéro, et même les petites choses simples pour nous sont en fait souvent étonnamment complexes à accomplir avec du code.

Vous ne devez pas seulement programmer les choses, vous devez définir ce qu’elles sont en premier lieu. Ensuite, vous devez renforcer votre code pour gérer toutes les façons possibles qu’il pourrait aller mal. Les tâches simples deviennent des cathédrales étonnantes honorant les dieux de l’explicite.

« Just Google it »

Peut-être que le conseil qui m’exaspère le plus de la part de mes pairs aux nouveaux développeurs est de « Google it ».

Toute personne qui a été la poitrine profonde dans la boue sait à quel point cela n’est pas utile.

A. Vous ne savez pas comment diagnostiquer ce qui ne va pas, donc vous ne savez même pas par où commencer. (Si vous le saviez, vous ne demanderiez pas).
B. Même si vous le faisiez, vous ne savez pas quels termes sont associés au problème.
C. Et même si vous le faisiez, les résultats sont souvent si déconcertants que vous ne le sauriez pas s’il vous regardait droit dans les yeux. (Ou comme le disait mon grand-père, vous ne seriez pas capable de verser de l’eau d’une botte s’il y avait des instructions au fond.)

Le codage est comme une langue étrangère

Il y a des parallèles frappants entre l’apprentissage du code et l’apprentissage d’une langue étrangère. J’ai constaté que les étudiants en langue, anglaise ou autre, ont tendance à assimiler les syntaxes plus rapidement.

Oui, il y a des modèles et une logique dans les systèmes.

Oui, certaines choses sont idiosyncratiques et ne peuvent pas être transmises succinctement dans leur équivalent anglais.

Oui, il y a des exceptions aux 2 points ci-dessus qui contredisent ou n’ont pas de sens, mais c’est comme ça, donc vous devez le mémoriser.

Mi-pasteur / mi-scientifique

Peut-être que la contradiction la plus exaspérante qu’un programmeur doit remplir est que vous êtes chargé à la fois de savoir comment tout cela fonctionne, et de mettre une bonne majorité à la craie de la foi.

Pour programmer, vous devez utiliser la logique, la raison et l’inférence. Le débogage est un processus déductif. Un bon code est bien structuré, délibérément logique et bien organisé.

D’autre part, nous utilisons des roches que nous avons trompées pour penser (les ordinateurs). Nous nous appuyons sur des frameworks, des bibliothèques et des snippets écrits par d’autres personnes que nous ne comprenons pas à cause du temps ou que nous prenons purement sur la foi. Il se passe tellement de choses dans chaque ligne de code que nous ne pourrions jamais terminer la fonction si nous devions nous arrêter et réfléchir à ce que tout cela fait.

Pour être un programmeur, vous devez être à la fois en partie prêtre/prêtresse basé sur la foi et logicien Spock froid comme la pierre.

Image via Paramount Pictures.

Conclusion

Donc, comme vous pouvez le voir, nous avons du pain sur la planche. Mais tout comme nous ne sommes pas venus au monde en sachant comment parler, ou écrire, ou accomplir n’importe laquelle des tâches que nous trouvons aujourd’hui routinières, mais pour lesquelles nous nous battions autrefois : nous pouvons le faire.

La vérité profonde derrière le codage est qu’il est le produit, le niveau meilleurs efforts – les bonnes intentions – le cadeau honnête de certaines personnes très intelligentes pour rendre la vie plus facile. Une personne intelligente, quelque part, a dit : « Ça craint. Il doit y avoir un meilleur moyen que ça. »

Et le code a pris son premier souffle.

Dans la prochaine section, je vous donnerai quelques stratégies pour faciliter ce processus et vous faire avancer vers vos objectifs. Le code est là pour rester, il est là pour aider, et si rien d’autre, vous pourriez juste avoir un peu de plaisir.

Leave a Reply

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.