C'est une histoire vraie, à propos de moi-même. Comment un être vivant rationnel a-t-il pu sombrer progressivement dans la folie ?

J'étais assis dans mon bureau en costume, avec une vague idée de startup flottant dans ma tête. Puis, j'ai décidé d'apprendre la programmation. J'avais entendu par hasard quelques personnes se vanter d'utiliser un langage appelé Ruby pour automatiser facilement le travail de bureau. J'ai pensé : « Ha, Ruby. » Je suis rentré chez moi et j'ai googlé Ruby. Quinze secondes plus tard, j'ai choisi au hasard un tutoriel Ruby et j'ai commencé à apprendre.

Une semaine plus tard, j'ai assisté à ma première rencontre de hackers de ma vie. Tout le monde là-bas discutait de Scala, Clojure et Go. J'ai pensé qu'ils en savaient vraiment beaucoup. Je me suis retourné et j'ai emprunté trois livres O'Reilly, en lisant environ 50 pages de chacun.

Quoi ? Vous demandez pourquoi je n'ai pas terminé un seul livre ? C'est parce que chaque livre commence de manière simple et facile à comprendre, puis commence à faire des suppositions—en supposant que vous avez certaines connaissances, en supposant que vous savez utiliser certains outils—mais je ne savais rien de tout ça, d'accord ?

Un de mes amis m'a dit que je devrais apprendre Emacs, et m'a donné son fichier de configuration. J'ai passé plusieurs heures de plus à apprendre la syntaxe de base de Lisp afin de pouvoir créer mon propre fichier de configuration.

Puis quelqu'un est passé à côté de moi, m'a vu utiliser Emacs et a demandé : « Pourquoi utilises-tu encore Emacs (imaginez l'expression de son visage), ne sais-tu pas que Vim est meilleur ? » J'ai pensé : « Ha, Vim », et j'ai donc commencé à mémoriser les interminables raccourcis clavier de Vim.

Les ingénieurs discutent souvent pour savoir quel éditeur de texte est le meilleur. De plus, les ingénieurs traitent ce sujet comme une guerre de religion : les critères de jugement ne reposent pas sur des normes objectives, mais sur des clivages historiques.

À l’époque, je croyais que plus je tapais vite, plus je pouvais programmer vite. J’ai donc abandonné la disposition de clavier traditionnelle et je suis passé à la disposition Dvorak indispensable aux programmeurs (exactement comme celle ci-dessous). Objectivement parlant, pour les programmeurs, c’est la disposition de clavier la plus efficace.

En regardant la disposition de clavier ci-dessus, pouvez-vous me dire combien de touches de lettres, de touches de chiffres et de touches de caractères spéciaux sont restées à leur emplacement d’origine ? La réponse tient en un seul chiffre.

Au moment où j’ai réussi à démarrer Linux et à taper dix mots par minute, j’ai commencé à apprendre Python grâce à des livres et à des cours Udacity.

Après sept mois de lutte acharnée, j’ai décroché mon premier emploi d’ingénieur logiciel.

Lorsque le CTO m’a fait passer l’entretien, je lui ai parlé de tous les outils que j’avais appris et des fichiers de configuration sophistiqués que j’utilisais. Le CTO m’a écouté poliment, hochant la tête de temps en temps. Après que j’ai fini de me vanter de mes vastes connaissances, il m’a regardé et a dit : « En fait, il existe de nombreuses façons de résoudre la plupart des problèmes, mais seule une infime partie d’entre elles a du sens. »

Il y a quatre ans, l'entreprise où je travaillais a décidé de construire son produit avec Ruby on Rails. Aucun des ingénieurs n'avait d'objection au choix du langage, et aujourd'hui encore, une grande partie de leur code d'origine est toujours en fonctionnement. Tous les ingénieurs utilisent des MacBooks, non seulement parce que les MacBooks sont fiables, mais aussi parce qu'ils sont très similaires aux serveurs Ubuntu Linux utilisés dans leur produit. Les ingénieurs ici ne se disputent pas pour savoir si Vim ou Emacs est meilleur — tout le monde utilise RubyMine, un puissant environnement de développement intégré avec d'excellentes configurations par défaut. Chaque ingénieur ici utilise exactement les mêmes outils, ce qui signifie que n'importe qui peut choisir n'importe quelle place et commencer immédiatement la programmation en binôme avec le collègue à sa gauche ou à sa droite, sans se soucier de la configuration de l'environnement. L'utilisation de configurations identiques facilite grandement la collaboration entre deux développeurs.

Même si je ne connaissais pas Ruby on Rails, l'entreprise pensait que j'étais qualifié pour le poste. Comme je connaissais Python et Django, et que j'avais gagné un hackathon, l'entreprise estimait que c'était suffisant pour démontrer mes compétences.

Les premières semaines ont été difficiles. La difficulté ne venait pas seulement du fait de rejoindre une nouvelle équipe, d'utiliser un nouveau langage, un nouveau framework et une nouvelle base de code, mais aussi parce que j'ai réalisé que les personnes autour de moi apprenaient la programmation avec une attitude autodestructrice.

J'ai passé des mois assis seul dans des bibliothèques et des cafés, installant aveuglément divers outils en ligne de commande, déboguant des pilotes Linux et résolvant des problèmes triviaux comme des parenthèses mal appariées. J'ai touché à tous les cours en ligne imaginables et je me suis inscrit à d'innombrables MOOCs. Je pense que je n'ai rien appris vraiment jusqu'à ce que, lors d'une évaluation mensuelle, je sois passé à la cinquième place. Ces expériences m'ont donné l'impression que la programmation est une bataille qu'on ne peut jamais gagner. J'ai commencé à comprendre à quel point le passé de ces programmeurs apparemment normaux était sombre : ils avaient tant traversé et tant réprimé pendant si longtemps. Je dois dire qu'apprendre la programmation est pratiquement une activité antisociale.

Le premier week-end après avoir quitté mon précédent emploi, j'ai publié ce selfie. Ce jour-là, je me suis levé tôt et j'ai enfilé un costume correct. Je portais ce costume pour me rappeler : je suis une personne sur le point d'apprendre la programmation. La légende Facebook disait : « Mon nouveau bureau, la table à manger. Je vis une vie de 8 h à 18 h chaque jour, ne me reposant que lorsque c'est absolument nécessaire. » Dans la vie, je parlais comme un programmeur et je pensais comme un. À présent, je me suis habitué à ce mot.

Mes collègues ne rencontrent presque jamais d'erreurs de syntaxe parce que leur IDE gère ce problème pour eux. Et quand ils tombent sur un message d'erreur, s'ils ne peuvent pas le résoudre en quelques minutes, ils envoient un message instantané à un autre collègue pour demander de l'aide. Ils passent librement au bureau de quelqu'un et commencent à programmer en binôme. Les programmeurs ici ne sont pas trop égocentriques, et ils ne se considèrent pas comme des élites. Ils ne voient pas non plus la programmation comme une entreprise douloureuse. C'est juste une conversation constructive entre amis adultes.

Les outils utilisés par les membres d'une équipe sont très homogènes. Dans les projets passionnels et les hackathons, les développeurs peuvent utiliser des frameworks JavaScript plus récents comme Angular.js. Mais dans une véritable équipe, les membres concentrent leur énergie sur l'amélioration du produit avec les technologies existantes. De ce point de vue, ils sont conservateurs.

Vous verrez quelque chose de similaire chez ThoughtBot. Chez ThoughtBot, tout le monde s'en tient à un ensemble d'outils restreint et efficace (Rails, Vim, Postgres et Redis). Comme l'ensemble d'outils est restreint, les ingénieurs peuvent facilement devenir experts dans ce domaine, et comme tout le monde utilise le même ensemble d'outils, l'interopérabilité entre eux devient facile.

Donc la vraie question est : si les équipes efficaces sont plus productives lorsqu'elles utilisent un ensemble restreint et fixe d'outils, alors peut-être qu'il est également préférable pour les personnes apprenant la programmation d'utiliser un ensemble restreint et fixe d'outils. Les cours de programmation en ligne et les bootcamps de codage le pensent clairement.

Mais en tant qu'individu, il y a tellement d'outils parmi lesquels choisir qu'il est vraiment difficile de décider quelle voie suivre. Je le sais parce que je suis passé par là. L'ensemble des compétences d'un bon programmeur peut être représenté par une forme en T — connaître un peu de nombreux domaines, mais ne maîtriser réellement que quelques-uns. Cependant, au fil des années d'accumulation, la forme en T se transformera progressivement en forme de soulignement.

J'ai rencontré beaucoup de personnes apprenant la programmation qui, dès le début, veulent tout apprendre et tout maîtriser. Au final, elles échouent toutes et abandonnent leur rêve de devenir programmeur. Je ne veux pas que cela vous arrive aussi.

Vous devez vous concentrer sur moins de choses

Sans plus attendre, voici quelques grandes erreurs que les débutants ont tendance à commettre :

• Passer d'un langage à un autre, sauter d'un framework à l'autre, ou se leurrer en pensant pouvoir maîtriser chaque langage ou framework.
• Utiliser des outils de niche pour construire votre environnement de développement au lieu de choisir des outils traditionnels et fiables.
• Apprendre des outils comme Docker et Famo.us simplement parce qu'ils sont nouveaux et à la mode, alors que vous n'avez même pas encore maîtrisé des technologies plus fondamentales.

Si je devais résumer mon conseil en un seul mot, je dirais : concentration.

Permettez-moi de vous demander—utiliseriez-vous le mot « focus » pour décrire votre plan d'étude de programmation ? Si vous pensez que votre plan est suffisamment ciblé, très bien. Vous pouvez arrêter de lire maintenant et retourner à votre plan pour commencer à apprendre, car je ne veux rien dire qui pourrait vous faire perdre votre concentration.

Si votre plan n'est pas suffisamment ciblé, vous avez aussi de la chance—faites ce que je dis et vous pourrez vous concentrer, mais cela vous prendra quelques minutes pour prendre quelques décisions difficiles. Attendez, ne partez pas !

Très bien, vous êtes encore là. Voici les décisions difficiles que vous devez prendre.

1. Choisissez un type de logiciel : cela peut être une application web, une application mobile, un jeu ou un système embarqué. Je recommande les applications web parce qu'elles sont flexibles. Il y a beaucoup de ressources d'apprentissage et d'innombrables débouchés professionnels. Si votre intérêt ne se porte pas sur les applications web, fermez cette page, tapez « débuter en développement _____ » dans le champ de recherche Google, et cliquez sur les résultats un par un.
2. Choisissez un langage de programmation : JavaScript, Ruby ou Python. Chaque langage a ses points forts, et chacun a un outil correspondant pour construire des applications web (Node.js, Rails et Django, respectivement). À moins de savoir clairement quel langage vous devriez apprendre, je recommande JavaScript parce que c'est le plus largement utilisé.
3. Choisissez un cours en ligne. Voici quelques options : si JavaScript vous intéresse, consultez FreeCodeCamp.com ou NodeSchool.io ; si Ruby vous intéresse, consultez TheOdinProject.com ou TeamTreehouse.com ; si Python vous intéresse, consultez Udacity.com. Faites confiance à la sagesse des formateurs qui ont conçu ces cours, terminez le cours dans l'ordre suggéré et ne sautez pas d'une partie à l'autre.
4. Achetez un MacBook neuf ou d'occasion, ou installez Ubuntu Linux sur votre ordinateur actuel. Quant aux autres outils dont vous pourriez avoir besoin, installez simplement ce que le cours en ligne recommande.

Une fois ces décisions prises, le reste du chemin est simple. Gardez la tête froide et ne vous laissez pas distraire par les nouveaux outils qui vous entourent. Consacrez un peu de temps à votre cours en ligne chaque jour, sept jours sur sept—même seulement une demi-heure à la fois. Faites confiance aux décisions que vous prenez aujourd'hui. Enfin, souvenez-vous : avec de la patience, toute personne compétente peut devenir un codeur exceptionnel—et cela vous inclut absolument.

Source : http://code.csdn.net/news/2822796