Je suis en quelque sorte arrivé à la porte de la programmation par un mélange de ruses et de tromperies, puis j'ai continué à foncer à toute vitesse. Avant l'âge de 26 ans, je n'avais presque aucune expérience en écriture de code, et pourtant, après avoir obtenu un master, j'ai choisi de façon inattendue une startup qui ne pouvait en aucun cas offrir de formation. J'ai lutté à contre-courant sous la triple pression des inquiétudes quotidiennes liées à la faillite de l'entreprise, de la peur d'être licencié et des regards froids de mes collègues. Un an et demi plus tard, lorsque je suis parti, j'étais déjà l'ingénieur backend principal d'un produit comptant 5 millions d'utilisateurs. Autrefois, je craignais l'informatique, croyant que les maîtres de la technique devaient être enveloppés de la lumière de Bouddha, tapant jour et nuit sans repos, produisant des dizaines de milliers de lignes de code par jour. Maintenant que j'ai un peu plus vu le monde, quand je repense à ce processus aussi inconfortable qu'une première nuit, je ne le trouve pas du tout inspirant, mais je le considère plutôt comme une évidence. Un programmeur idéal n'est pas différent d'un architecte idéal, d'un comptable idéal ou d'un masseur idéal ; ce sont essentiellement tous des artisans. Je crois que n'importe qui peut devenir un programmeur idéal.

Ces trois dernières années, j'ai traîné dans le cercle Internet. J'ai rencontré des programmeurs, travaillé avec certains, dirigé certains et en ai interrogé certains. Ils ont des parcours éducatifs différents — certains de l'Université de Pékin, certains d'établissements de formation, certains titulaires d'un doctorat, certains décrocheurs du lycée ; ils ont aussi des références différentes — certains de BAT, certains d'une société de fonds en faillite (et étaient même vendeurs). Leur expérience varie de 0 à 15 ans. Mais je pense que les programmeurs n'ont besoin d'être divisés qu'en trois catégories : les programmeurs géniaux, les programmeurs idéaux et les programmeurs médiocres. Quant aux programmeurs géniaux, j'ose dire que je n'en ai rencontré que trois. C'est le destin. Sept points sont décidés quand tu es un spermatozoïde : posséder un excellent talent mathématique, une logique calme et méticuleuse, et une passion pour la technologie qui se délecte de rester éveillé toute la nuit pour résoudre des problèmes difficiles. Trois points viennent du fait de commencer tôt, tôt, tôt — en souhaitant que, pendant que tes pairs jouent dans la boue, tu commences à jouer avec des ordinateurs, et que tu franchisses la règle des 10 000 heures avant d'obtenir ton diplôme universitaire. Après cela, c'est déjà un jeu de la vie.

Les programmeurs de génie sont rares à trouver, et encore plus difficiles à garder en abondance. Les 90 % que je vois sont encore des programmeurs médiocres. L'expansion de l'ère informatique a rendu les programmeurs aussi communs que les imprimeurs à la Renaissance. La plupart des personnes qui entrent dans ce domaine le font uniquement pour un plus grand bol de riz, un salaire plus élevé et de meilleures conditions de vie. Les programmeurs médiocres écrivent du code pourri, sans normes ni cohérence, s'accrochant aux langages de l'ancien monde, mais ils adorent parler de grande architecture et de performance. Leurs paroles sont plus belles que leurs actes. Et sans exception, ils croient que la technologie n'a pas d'avenir, et que le produit, le marketing et le management sont des métiers plus nobles. Quant à 99 % d'entre eux, ils révéleront naturellement qu'ils ont justement du talent dans ces domaines, tout en dédaignant de comprendre des problèmes triviaux comme pourquoi un processus a planté.

Mais ce que je préfère, c'est d'être avec des programmeurs idéaux. J'aimerais pouvoir manger et vivre avec eux. Si cela m'était permis, j'espère que mon équipe serait remplie de leurs bannières. Les programmeurs idéaux ont bon cœur (ils ne sont jamais les chouchous des intrigues de bureau ; ils forment un groupe d'artisans innocents, brillants et joyeux), ont une curiosité naïve (leurs yeux pétillent souvent d'un « Waouh, comment est-ce fait ! »), recherchent toujours l'excellence (leur phrase fétiche est « Laisse-moi étudier cela un peu plus »), et sont prêts à partager (ils sont actifs sur GitHub, dans les communautés de questions-réponses, et autour de vous, prêts à consacrer un temps précieux à aider les novices). Oui, ils n'ont pas besoin d'être encadrés. Donnez-leur simplement une direction générale, et ils reviendront toujours avec des résultats inattendus.

Le programmeur idéal et le programmeur médiocre ne sont séparés que par un seul mur. La différence entre les deux ne tient qu'à six petits bits, et c'est précisément dans ces petits bits accumulés au fil du temps que l'écart entre les personnes se creuse à jamais. Fait intéressant, j'ai découvert que ces six petits bits sont tous liés à la conscience. Autrement dit, les programmeurs, comme toutes les autres professions des industries émergentes, peuvent atteindre le stade idéal tant qu'ils ont la conscience plus le temps qui forge. Un programmeur idéal est nécessairement aussi un excellent résolveur de problèmes.

Le premier petit bit : se concentrer sur le présent

J'ai vu trop de programmeurs à l'esprit agité, je dois donc faire de « se concentrer sur le présent » la première règle. Ils ont souvent toutes sortes de petits rêves, comme devenir petit producteur de thé, petit vendeur d'oies, faire du produit, de la vente ou de l'investissement, mais ils sont « retenus » par le salaire élevé des programmeurs ou par le manque de courage de changer de carrière. À cause de leur manque de concentration, ils ne se soucient pas de bien faire leur propre travail, ne se soucient pas de perfectionner leurs compétences et ne se soucient pas d'apprendre les technologies émergentes. Certes, ce monde compte de grands profils produit (comme Jobs), de grands vendeurs (comme Ellison) et de grands investisseurs (comme Peterffy), et ils ont tous été programmeurs à un moment donné, sans exception. Mais avez-vous entendu le commentaire de Buffett sur Gates ? Si Bill Gates changeait de carrière pour vendre des chiens, il serait le plus grand marchand de chiens du monde. Je crois fermement qu'à l'exception de quelques génies, les mortels ordinaires peuvent réussir dans plusieurs domaines tant qu'ils conservent une concentration suffisante. Et même si vous voulez vendre des chiens l'année prochaine, votre expérience de programmeur peut encore vous entraîner à une logique solide, à la prudence et à la patience, qui sont des avantages concurrentiels considérables dans n'importe quel secteur.

Le deuxième petit bit : capacité de réflexion et force motrice

Je crois que la gestion d'événements inattendus tels que les bugs, les plantages, le tuning et les intrusions reflète mieux l'écart entre les programmeurs médiocres et les programmeurs idéaux que la programmation elle-même. Face à un problème inconnu, comment localiser le problème central dans des conditions complexes, comment décortiquer les couches pour analyser les causes sous-jacentes, comment éliminer les interférences et rétablir un scénario minimal vérifiable, et comment saisir les données clés pour vérifier ses hypothèses et ses expériences — ce sont les meilleurs scénarios pour démontrer la capacité de réflexion d'un programmeur. Oui, lorsqu'on mesure le standard d'un programmeur idéal, la capacité de réflexion est plus importante que l'expérience.

Parfois, un copain débarque et me demande : « Une tâche soumise est bloquée ; que dois-je faire ? » J'ai toujours l'impression qu'il pourrait faire mieux. Par exemple, il pourrait vérifier ou tester d'autres tâches pour exclure le code lui-même ; il pourrait vérifier les exceptions via l'interface Web (s'il n'a pas de compte, il peut me demander de lui en fournir un) ; il pourrait inspecter les logs de l'hôte ou vider les caches. Au minimum, il devrait me fournir l'ID de la tâche et les logs de la console. Les programmeurs idéaux n'attendent jamais que les choses avancent ; ils utilisent toutes les méthodes possibles pour faire avancer les choses.

Le troisième petit point : ne jamais dire non

Je me souviens qu'avant de quitter mon ancienne entreprise, j'ai eu une conversation avec mon patron. Il a dit que ma plus grande force était que je ne lui disais jamais qu'une chose ne pouvait pas être faite. Plus tard, j'ai découvert que dans de nombreuses équipes, il existe une opposition entre la technique et le produit. Les programmeurs utilisent souvent « techniquement impossible » pour bloquer les exigences produit, tandis que les gens du produit utilisent souvent « Pourquoi Facebook peut le faire et pas nous ? » pour railler les programmeurs. Ces deux phrases devraient être des mots interdits. Fondamentalement, elles ne favorisent pas l'affection mutuelle entre les singes programmeurs et les chiens produit.

L’expression « techniquement impossible » est facile à dire, mais combien de personnes sont sûres à 100% dans leur for intérieur lorsqu’elles le disent ? Si vous n’êtes pas sûr, pourquoi ne pas retourner faire une recherche Google avant de répondre ? Je pensais au départ que les programmeurs débordaient d’imagination ; c’est grâce à l’imagination que tant de produits logiciels et internet qui changent nos vies sont nés. Ayant vu davantage de choses, je comprends que la plupart des programmeurs sont devenus conservateurs dans leur lutte contre les bugs et peu enclins à prendre des risques, tandis que de nombreuses équipes ne sont pas non plus disposées à tolérer l’échec. Ainsi, « dire non » devient une résistance habituelle. Vous souvenez-vous encore pourquoi Zeng Guofan a dissous l’armée du Hunan ? Il disait que cette armée avait « un esprit du soir profondément accumulé » et ne pouvait plus combattre. Pour être un programmeur idéal, vous ne devez pas vous donner l’occasion de laisser se développer cet esprit du soir. Si vous faites face à des exigences déraisonnables, vous pouvez exposer le coût en temps et présenter un plan de sauvetage détourné. Dire simplement « non » de but en blanc n’est pas conseillé.

Le quatrième petit point : Investir dans l’avenir

Être programmeur est un métier très cruel. Les langages, frameworks et patrons que vous apprenez et utilisez peuvent devenir des fleurs d'hier en quelques années ; l'autre groupe de programmeurs que vous moquez aujourd'hui pourrait bientôt se retourner et se moquer de vous. Ainsi, les programmeurs idéaux, en plus de bien faire leur propre travail, doivent consacrer du temps à investir dans l'avenir. Qu'est-ce que « l'investissement » ? L'investissement signifie que le temps que vous y consacrez maintenant vous reviendra à l'avenir sous forme de plus de temps ou d'argent (regardez les salaires actuels des programmeurs qui ont appris iOS il y a quelques années !). Prenons mon propre domaine — l'exploration de données — comme exemple. Vers 2008, Hadoop a commencé à monter en puissance, et le concept de « big data » est devenu très en vogue ; les ingénieurs Hadoop étaient introuvables même à prix d'or, et les entreprises internet ont transféré leurs activités de statistiques de données, d'analyse de données et d'exploration de données vers des plateformes distribuées. Ces dernières années, pendant que Hadoop continue d'itérer, Spark a soudainement émergé comme une nouvelle force, battant le record de tri de Hadoop. Son avantage de performance dû au stockage des données intermédiaires en mémoire et ses riches structures de données font que les gens en tombent amoureux sans fin, tandis que divers petits bugs étranges et la courbe d'apprentissage abrupte donnent envie de renoncer. Ainsi, toute personne lucide sait que Spark est la tendance future (la mémoire deviendra de moins en moins chère). À condition que l'activité principale reste sur Hadoop, vous pouvez basculer de manière appropriée certains petits modules vers Spark tout en prêtant attention au développement de la communauté Spark. Bientôt, les gains de performance obtenus grâce à Spark auront remboursé le temps d'apprentissage investi auparavant.

Le cinquième petit point : bien utiliser les outils

Bien utiliser les outils peut se diviser en quatre niveaux :

• Moteur de recherche
• Ne croyez pas en la répétition
• Extraits de code
• Automatisation

Lorsque je suis entré pour la première fois dans ce secteur, un ami qui avait fait des études d'informatique mais est devenu fonctionnaire m'a demandé : « Tu n'as jamais appris la programmation du tout ? Comment écris-tu habituellement du code ? » J'ai répondu Google, et j'ai été impitoyablement raillé, à tel point que mes noms de compte partout sont 2shou, me disant que je suis un programmeur de seconde main sans honte. C'est une blague, mais si on me posait la question maintenant, je répondrais encore Google. La croissance d'un programmeur est comme un cercle en expansion. À l'extérieur se trouve une mer sans limites ; plus le cercle est grand, plus la surface en contact avec la mer est grande. Plus on en sait, plus on en ignore. L'informatique est aussi une discipline qui subit des changements générationnels extrêmement rapides, et c'est la discipline qui bénéficie des meilleures connaissances en ligne. Il est difficile d'utiliser des méthodes d'enseignement formel traditionnelles avec instruction et apprentissage ; au contraire, il est facile d'obtenir les connaissances les plus récentes grâce aux moteurs de recherche.

Ne croyez pas en la répétition. Les maîtres l'appellent le principe DRY (Don't repeat yourself). Après avoir écrit beaucoup de code, on acquiert un jugement intuitif du bon et du mauvais code. Mes critères sont la concision et la normalisation. La concision n'est pas un critère de beauté esthétique. Moins il y a de répétition, moins vous avez de chances de faire des erreurs, et plus le coût de la maintenance ultérieure est faible.

Si vous perdez malheureusement du code datant de trois semaines, vous pourrez peut-être reproduire les fragments qui persistent dans votre esprit grâce à une mémoire exceptionnelle, mais s'il s'agit de code datant de trois mois, vous n'aurez probablement pas autant de chance. Un programmeur idéal mettra tout en œuvre pour trouver des moyens efficaces de stocker l'information, en conservant de courts fragments tels que du code, des scripts, des configurations et des expériences notées sous le coup de l'inspiration au travail, afin de pouvoir les consulter à tout moment.

Un programmeur idéal doit être paresseux. Pour lui, les étapes répétitives sont aussi laides que le code répétitif. S'il se rend compte qu'une tâche risque de se répéter sur le long terme, plus vite elle est automatisée, mieux c'est.

Le sixième petit point : Gérer son temps

La gestion du temps est particulièrement importante dans le métier de programmeur, car lorsqu'on accomplit des tâches, on doit avancer seul comme un loup dans la nature sauvage. Si vous pouvez vous maîtriser avec constance sans contrainte extérieure et garantir un travail et des études efficaces, alors avec le temps, vous deviendrez certainement plus compétent que la personne moyenne.

Les programmeurs font un travail intellectuel de haute intensité. En général, 4-5 heures de concentration sur le travail principal chaque jour suffisent, mais en dehors du travail, vous devez prévoir du temps pour apprendre. Outre l'étude, il faut aussi laisser un peu de temps pour se vider l'esprit. Profitez des pauses pour préparer du thé ou boire du café afin de garder ce temps précieux pour vous, en réfléchissant à l'avenir et en revisitant le passé — pour obtenir deux fois le résultat avec la moitié de l'effort.

Après avoir dit tout cela, certains pourraient demander : à quoi bon se donner tant de mal pour devenir un programmeur idéal ? Est-ce que cela apportera un salaire élevé ? Non. Est-ce que cela peut mener à une promotion ? Pas nécessairement. Épouser une femme à la peau claire, riche et belle ? Mieux vaut aller vendre des chiens à la place.

Kazuo Inamori a raconté un jour une histoire : des artisans de l'ère Meiji furent convoqués par l'empereur. Bien qu'ils fussent des gens de la campagne sans instruction, ils consacraient toute leur vie à un seul métier, portant naturellement un tempérament noble. Un programmeur idéal, peut-être, est quelqu'un qui marche sur les traces de cet esprit noble.

Auteur : Sandy
Lien original : http://mdsa.51cto.com/art/201511/496267.htm#topx