Avant même que je ne ressente quoi que ce soit, l'année était déjà en train de se terminer. Je soupire en voyant la flèche du temps filer ainsi, et ma vie décompte une année de plus. Avec le recul, je suis un singe du code depuis plus de sept ans. Même si je n'ai pas accompli grand-chose, je n'ai pas non plus complètement gaspillé ce temps. Un bref bilan semble de mise, pour ne pas perdre la trace des jours passés, et cela profitera grandement à la route à venir. Si ce billet peut vous être utile d'une manière ou d'une autre, j'en serai très heureux.


Une carrière est un marathon fait d'innombrables courses enchaînées


À l'école primaire, nous savions clairement que nous obtiendrions notre diplôme en 5 ans (je suis passé par le système quinquennal à l'époque ; il semble que certains endroits le fassent encore). Peu importait à quel point vous détestiez vos professeurs, vos camarades de classe ou l'école, vous saviez que cela se terminerait dans au plus 5 ans. Pareil au collège et au lycée : en trois ou quatre ans, ça passe vite, et toute la joie et le chagrin s'estompent bientôt. L'université l'est encore plus — dès le jour où vous posez le pied sur le campus, vous commencez le compte à rebours, sachant qu'un jour, quatre ans plus tard, vous partirez. Peu importe que vous chérissiez ou gaspilliez ce temps, le temps continue d'avancer dans une seule direction, à sa vitesse éternelle et immuable.



Mais le monde du travail ? Après 5 ans, vous travaillez toujours, et vous devez continuer à travailler. Après 10 ans, 20 ans, 30 ans, même 40 ans, nous devons encore travailler. Même si vous démissionnez, vous devrez rejoindre une autre entreprise, et le nouvel emploi n'est en substance pas différent du précédent. Une fois que vous comprenez qu'une carrière est un cycle de 40 ans, vous réalisez que c'est un marathon ultra-long — pas un sprint au collège, pas un sprint pour l'entrée à l'université, et certainement pas un « entre dans une bonne université et après tu peux te la couler douce ». À quoi bon sprinter à corps perdu ; cela ne servirait de toute façon à rien. Ce qui compte le plus, c'est l'apprentissage continu — oui, des décennies d'apprentissage continu.


La seule façon de devenir un maître, ou une grosse pointure (da niu), c'est l'apprentissage constant


Ne rêvez pas que le fait d'entrer dans une grande entreprise, de rejoindre une équipe géniale, de vous asseoir à côté d'une grosse pointure ou d'assister à plus d'événements hors ligne fera de vous une grosse pointure. Tout ça, c'est « trop jeune, trop naïf ». Pourquoi une grande entreprise voudrait-elle de vous ? Pourquoi une équipe géniale voudrait-elle de vous ? D'abord, il vous faut de vraies compétences. Quant à recevoir des conseils d'une grosse pointure — c'est une question de chance. Vous avez peut-être regardé trop de séries télévisées : vous tombez dans une vallée et rencontrez un singe blanc avec le Soutra des Neuf Yangs caché dans son ventre ? Ou vous dévalez une falaise, voyez un aigle géant et apprenez les Neuf Épées de Dugu ? Avec des millions de singes de code dans tout le pays, à votre avis, quelles sont les chances de tomber sur un maître ? Et quelle est la probabilité qu'un maître accepte de vous parler ? Vous rêvez qu'un maître vous enseigne en vous prenant par la main ? À moins que vous ne soyez leur plan cul.


Bien sûr, certaines personnes ont vraiment la chance de recevoir les conseils d'un maître. Mais je crois que pour la grande majorité, même si une grosse pointure se trouve juste à côté de vous, vous n'aurez pas assez d'occasions d'obtenir ses conseils. Les entreprises nous embauchent pour travailler, créer de la valeur, leur rapporter de l'argent. Les grosses pointures ont des charges de travail plus lourdes et plus de choses à gérer — pourquoi diable seraient-elles obligées de vous guider ?


Les grandes entreprises ont certes des ressources et des matériaux abondants, ainsi que davantage d’opportunités de formation, mais il faut quand même aller regarder, écouter et apprendre par vous-même. Quant aux divers événements en présentiel, la majorité ne sont que de la publicité. Les autres conférences ne font pour la plupart qu’effleurer la surface : impossible d’obtenir du vrai fond (« du concret »). Que peuvent-ils dire en quelques dizaines de minutes ? Et combien pouvez-vous en assimiler ? Les événements en présentiel sont donc de bonnes occasions de promotion, d’élargissement des horizons (vous pouvez y entendre beaucoup de concepts) et d’extension de votre réseau (vous pouvez effectivement y rencontrer beaucoup de personnes — des pointures et vos pairs) — mais pas pour apprendre.


En une phrase : si vous voulez devenir un maître, vous devez quand même apprendre de façon pragmatique — dévorer des livres, lire du code, écrire du code. Il n’y a pas d’autre voie. Sur ce point, vous pouvez vous référer à l’article d’une pointure (Écrire du code métier tous les jours — comment devenir une pointure technique ?), que je trouve très pertinent.


Choisissez un secteur, ou une technologie, puis approfondissez


Bien que je ne prône pas l’établissement de plans quinquennaux comme certains le font — parce que notre secteur, nos entreprises, nos projets et notre personnel changent trop vite, et que ces facteurs d’incertitude feront dérailler tous les plans, surtout les plans à long terme — nous avons tout de même besoin d’objectifs. Je crois que pour la plupart des gens, l’objectif ultime n’est rien d’autre que la liberté financière. Comment atteindre la liberté financière ? La chance joue un rôle, mais ce qui compte davantage, c’est la force réelle. Qu’est-ce que la force réelle ? C’est être capable de résoudre des problèmes que les autres ne peuvent pas résoudre. Par exemple, le patron veut développer une certaine activité, et vous connaissez les règles métier sur le bout des doigts, et vous pouvez diriger une équipe pour la concrétiser. Ou bien, quand un problème technique surgit, vous pouvez le résoudre. Sans véritable force, la simple chance ne suffira pas — même si vous avez assisté à l’essor de Taobao, vous pourriez encore ne pas être financièrement libre aujourd’hui.


D’où vient la force réelle ? Elle vient de l’accumulation. Accumuler quoi, pour devenir de plus en plus précieux ? Rien d’autre que le secteur ou la technologie.


Qu'est-ce qu'un secteur ? L'automobile est un secteur, la finance est un secteur, l'habillement est un secteur, le voyage et le transport constituent un secteur, et ainsi de suite. Et qu'est-ce que la technologie ? La sécurité, l'audio, WebKit, les graphismes, l'apprentissage profond—ce sont toutes des technologies. Dans un secteur, la technologie n'est peut-être pas compliquée ; elle peut être tout à fait ordinaire. Mais si vous parvenez à comprendre en profondeur un secteur—ses règles du jeu, ses pièges, ses politiques et réglementations, ses risques, comment obtenir un rendement maximal—ce sont des choses que vous n'apprenez qu'après avoir passé du temps dans ce secteur. La technologie est plus facile à comprendre : utiliser une technologie prête à l'emploi est facile. Par exemple, WebView est très pratique à utiliser, mais son implémentation technique sous-jacente—WebKit—est extrêmement complexe, et on ne peut pas la maîtriser en quelques années seulement.


Bien sûr, il n'est pas facile de continuer à creuser profondément dans le même domaine (que ce soit un secteur ou une technologie)—cela demande de la chance. Mais comprenez ceci : ce n'est qu'en approfondissant un secteur ou une technologie que vous pouvez maximiser votre valeur. Donc, lorsque vous avez le choix, rapprochez-vous autant que possible de votre objectif.


La responsabilité pèse plus lourd que la technologie


Le travail d'un programmeur, que ce soit dans l'internet ou le logiciel d'entreprise, relève de l'ingénierie—c'est l'application de la technologie. Dans la plupart des cas, la plupart des gens ne rencontreront pas au travail de problèmes techniquement insolubles ni de défis de classe mondiale. En d'autres termes, les problèmes que vous rencontrez au travail—même si vous ne savez pas comment les résoudre—peuvent être rapidement résolus en consultant des références, des livres, l'internet et des collègues. De plus, écrire du code propre, tester minutieusement et rendre les choses robustes n'exigent pas une technologie particulièrement profonde ou de pointe. Tant que vous y mettez du cœur, vous pouvez faire du très bon travail.


À l'inverse, ceux qui sont mauvais au travail ne sont pas forcément mauvais en technologie. L'évaluation que les gens font d'eux sera forcément "irresponsable". Comme le dit l'adage, l'attitude détermine tout, et le fruit de l'attitude est la responsabilité. Même si votre niveau technique est moyen, si votre attitude est sérieuse et que vous êtes responsable, vous êtes un excellent employé—et plus précieux pour l'entreprise. Quant à ceux qui sont techniquement forts mais ont une mauvaise attitude et fuient leurs responsabilités, ce sont les gens qui se laissent vivre en mangeant et buvant, attendant la mort—des tumeurs qu'on finira par retirer.


Devenir un singe de code professionnel


Ici, "professionnel" renvoie davantage à la forme et à la méthode—à la manière de faire les choses. Avant d'expliquer ce que signifie "professionnel", regardons quelques exemples de ce qui n'est pas professionnel :


  • Lors d'un entretien téléphonique, sans demander si votre interlocuteur vous entend clairement, vous commencez à blablabla. Au bout d'une dizaine de minutes, l'autre personne soupire et dit : "Désolé, mauvais signal, je n'ai pas bien entendu..."
  • Par exemple, lors d'un entretien téléphonique, le candidat dit : "Laissez-moi d'abord trouver un endroit convenable." Après en avoir trouvé un, il vous appelle pour dire qu'il l'a trouvé—et là, l'entretien téléphonique commence... sur l'appel sortant du candidat...
  • Par exemple, arriver en retard aux réunions, ou bavarder pendant les réunions...
  • Tirer des conclusions hâtives avant de comprendre toute la situation—surtout pour les colériques—et même se mettre à insulter les gens...

Je crois que les exemples comme ceux-ci sont trop nombreux pour être listés, et je suis aussi absolument sûr que nous, singes de code et fées du code, rencontrons ce genre de choses tout le temps dans le travail quotidien. Notre réaction habituelle à ce genre de choses est "peu professionnel"—oui, c'est exactement ce que c'est.


L'inverse est professionnel :


Avant l'entretien téléphonique, confirmez d'abord si votre interlocuteur vous entend clairement, puis bla bla ; quand le candidat vous dit « Je suis disponible maintenant, faisons l'entretien » — c'est un avis. Vous raccrochez, puis vous le rappelez ; ayez un ordre du jour clair, ne soyez pas en retard ; comprenez toute l'histoire avant de commencer à jurer... et ainsi de suite.


« Il y a un ordre dans l'apprentissage, et chaque métier a sa spécialité. » C'est tout ce qu'il y a à dire.


Le savoir est infini. Il y aura toujours des choses que vous ne savez pas, des choses que vous ne pouvez pas faire. Même si vous êtes un singe de code depuis des décennies, connu comme quelqu'un qui sait tout et surnommé « M. Je-sais-tout », il n'est pas difficile de vous mettre en échec — même un écolier possède des connaissances que vous n'avez pas. L'industrie du logiciel est divisée en de nombreux domaines. On dit que chaque métier est un monde à part, mais différents domaines au sein d'un même métier ont aussi des écarts — par exemple, côté client, backend, frontend, pilotes, moteurs de jeu, infographie et traitement d'image, sécurité, etc. Nous devons donc conserver une soif de connaissances et une attitude humble. Même si vous êtes une pointure du frontend, lorsque vous rencontrez un problème de pilote, vous êtes un débutant — vous devez apprendre humblement et demander conseil aux autres.


De plus, lors d'un entretien, en tant qu'intervieweur détenant un pouvoir de vie ou de mort, vous devez faire preuve de respect envers les candidats. Ne cherchez pas délibérément à compliquer les choses ni à « faire semblant de mener l'entretien pour votre patron alors que vous ne voulez manifestement pas de cette personne » pour des raisons non techniques comme le parcours du candidat (diplôme hors filière professionnelle ou diplôme universitaire court), son expérience (petites entreprises, sociétés de sous-traitance), son manque d'expérience (peu d'années, aucun projet marquant), ou une inadéquation (vous avez besoin de profils côté client, mais la majeure partie de son expérience est en frontend), et ne méprisez pas les candidats pour d'autres raisons (j'ai déjà rencontré quelqu'un d'une entreprise étrangère qui méprisait les gens des entreprises nationales, disant que les entreprises nationales ne font que copier les étrangères). Comme le dit le vieil adage : « Ne jamais employer quelqu'un dont on doute ; ne jamais douter de quelqu'un qu'on emploie. » En tant qu'intervieweur, vous pouvez écarter une personne — c'est votre droit — mais vous devez la respecter, même si ses capacités sont réellement insuffisantes. Tout le monde a des moments où il doit baisser la tête. Une entreprise étrangère est-elle donc si formidable ? Les entreprises étrangères en Chine ne sont-elles pas simplement des antennes de sous-traitance des sièges, qui font toutes les tâches ingrates ? Motorola était si impressionnant à l'époque — salaires excellents, embauche ultra sélective — et maintenant l'arbre est tombé et les singes se sont dispersés ! Comme le dit le vieil adage, ne fanfaronnez pas, sinon vous serez frappé par la foudre tôt ou tard !


Comment arrêter les regards troubles et apaiser le cœur agité


Chaque fois que nous nous sentons perdus, c'est parce que nous pensons trop à l'avenir et faisons trop peu dans le présent ; chaque fois que nous nous sentons agités, c'est parce que nous attendons trop et accomplissons trop peu. Peu importe ce que vous devenez ou où vous vous dirigez, l'essentiel est de partir de là où vous êtes maintenant. Vous ne pouvez pas rêver de vous y envoler directement — il n'y a ni hélicoptère ni montgolfière qui puisse vous soulever du sol. Vous ne pouvez que partir du présent, garder les pieds sur terre et avancer pas à pas.


C'est encore un peu vague, un peu du genre « soupe au poulet ». Laissez-moi parler de la façon de faire concrètement :


  • D'abord, déterminez ce que vous faites exactement. Bon, un code monkey qui ne fait qu'écrire du code. Le code de quelle couche ? Android ? Apple ? Applications ? Frameworks ? Pilotes ? Quel domaine ? Graphisme et imagerie ? WebKit ? Réseautage ? Bluetooth ? Finance ? Sécurité ? Quoi — vous n'écrivez pas de code, vous ne faites que maintenir et corriger des bugs (pas mal de gens, par exemple ceux qui travaillent sur des solutions Android clés en main, ne font que maintenir et corriger des bugs) ? C'est pareil — déterminez quelle couche, quel domaine.
  • Ensuite, une fois que vous avez déterminé ce que vous faites, c'est simple : faites bien ce que vous êtes censé faire, familiarisez-vous-en à fond, jusqu'à n'avoir besoin que d'une demi-journée pour accomplir une journée entière de travail.
    Écrire du code exige d'apprendre à écrire du code à la fois bon et rapide — c'est-à-dire être capable de répondre rapidement à des exigences spécifiées avec peu de bugs. À un niveau supérieur, cela implique aussi d'écrire du code propre et compréhensible, avec une structure raisonnable et un nommage clair. C'est le développement des compétences fondamentales, et il a longtemps été négligé, car presque aucune entreprise n'a de KPI portant sur le fait que le code soit bon ou mauvais ; au mieux, ces KPI couvrent le nombre de bugs, le taux de plantage, les performances et la stabilité. Ce sont des métriques logicielles, pas de la qualité de code. La meilleure façon de mesurer la qualité du code est de voir la réaction de la personne qui reprend votre code — de voir combien de fois elle vous maudit. Pour améliorer vos compétences en programmation, vous pouvez lire des livres comme « Code Complete » et « Clean Code », mais plus important encore, lisez de l'excellent code open source.
  • Une autre consiste à vous familiariser avec la base de code existante, en vous efforçant de savoir quelles classes doivent être modifiées et où ajouter du nouveau code chaque fois qu'une nouvelle exigence arrive. Lorsque vous corrigez des bugs, vous devez être capable de réfléchir et de savoir approximativement où se trouve le bug, quelle classe ou méthode cause le problème.
  • De plus, familiarisez-vous avec la logique métier. Tout logiciel est créé pour mettre en œuvre une activité. Pour comprendre la logique métier, comprenez d'abord la logique du petit module dont vous êtes responsable, puis la logique métier de l'ensemble du logiciel. C'est très bénéfique pour évaluer de nouvelles exigences et résoudre des bugs, car vous réfléchirez dans une perspective globale. Il existe des indicateurs spécifiques, comme l'organisation des documents d'exigences, à partir desquels vous pouvez générer divers cas de test et scénarios, ce qui vous aide à vérifier l'exactitude de votre code.
  • Ensuite, préparez et sauvegardez les environnements de test, les données de test et les cas de test courants. Après de nouvelles exigences et des corrections de bugs, vous devez également les organiser et les ajouter au référentiel de tests pour l'auto-test et la régression. Bien que l'assurance qualité (QA) garantisse la qualité logicielle, notre logiciel doit au moins fonctionner et répondre aux exigences avant d'être transmis à l'assurance qualité. En bref, les programmeurs professionnels doivent effectuer eux-mêmes suffisamment de tests. Cependant, les tests ne sont parfois pas si pratiques. Par exemple, côté client, il arrive souvent que les données du backend ne soient pas prêtes, vous devez donc simuler des données ; certaines données n'apparaissent que dans des scénarios rares, et vous devez également les simuler pour les tester ; avant la publication, vous devez tester dans l'environnement de test avec un serveur de test ; etc. Cela signifie que si vous avez fréquemment besoin de ces éléments—comme des données simulées, des proxys, etc.—vous devriez investir un peu d'effort pour les organiser et les sauvegarder, et même trouver des moyens—que ce soit en écrivant du code ou en utilisant des bibliothèques open source—de mettre en place un environnement de test pratique. C'est très utile pour le développement. Vous vous souviendrez peut-être qu'un bug peut être facile à corriger mais difficile à vérifier, nécessitant des proxys, des données simulées, la simulation de scénarios particuliers, l'ajustement d'environnements réseau, etc.
  • Sauvegardez également les configurations d'environnement courantes. Par exemple, si votre code comporte des personnalisations différentes pour différents scénarios, la meilleure approche consiste à faire une copie pour chaque scénario, chacune entièrement configurée, plutôt que d'utiliser différentes branches, même si cela est également possible. Il y a deux raisons :
    Après quelques années dans le secteur, nous savons bien que la configuration d'environnement fait aussi partie du développement, et qu'elle est généralement très pénible. Elle peut transformer quelque chose qui ressemble à un travail de dix minutes en deux jours de travail, et ce n'est peut-être toujours pas terminé. Le code d'aujourd'hui est très complexe, et la complexité ne réside pas dans le code lui-même, mais dans les dépendances extrêmement complexes. Les personnes qui bricolent souvent avec des logiciels open source devraient savoir qu'une bibliothèque en elle-même peut ne pas être complexe, mais que pour l'utiliser, il faut installer et configurer tout un tas de dépendances. Imaginez, si vous n'utilisez pas de gestionnaire de paquets (comme apt-get, brew, pip, etc.), essayez d'installer OpenCV manuellement, ou de compiler directement son code source.
    • Bien que les branches de code puissent distinguer différents codes, les configurations de dépendances d'environnement ne figurent souvent pas dans le dépôt. Cela signifie qu'après avoir changé de branche, vous devez encore gérer la configuration d'environnement et les dépendances.
    • Une autre raison est la question du parallélisme. Supposons que vous développiez une nouvelle fonctionnalité sur la branche de la version A, et qu'à ce moment-là la version B (supposons que A et B concernent des clients différents, et que les deux branches diffèrent) nécessite une correction de bug. Pensez-vous qu'il soit plus pratique de changer de branche, ou de travailler dans un autre répertoire ? Je pense que l'approche d'isolation physique est meilleure.
  • Après avoir accompli tout ce qui précède, je pense que les tâches qui relèvent de votre responsabilité ne seront plus un problème pour vous. À ce stade, vous devez étudier en profondeur et comprendre les éléments dont vous dépendez. Par exemple, vous utilisez des bibliothèques réseau comme OkHttp et Retrofit — pourquoi sont-elles meilleures que celles natives ? Quels sont leurs principes fondamentaux ? Quelle est leur philosophie d'encapsulation ? De même, pour les bibliothèques de chargement d'images comme UIL et Picasso, quels sont leurs principes ? Les bibliothèques sous-jacentes dont elles dépendent sont très bien encapsulées et faciles à utiliser. Plus ces bibliothèques sont nombreuses, si vous ne savez que les utiliser, alors vous êtes fichu. Parce que même quelqu'un qui ne les a jamais utilisées peut comprendre comment les utiliser après avoir lu un tutoriel pendant quelques minutes. Ce n'est qu'en comprenant profondément les détails d'implémentation et en apprenant les usages avancés que vous pourrez véritablement dire que vous n'avez pas utilisé ces excellentes bibliothèques en vain.
  • De plus, dans n'importe quel domaine et à n'importe quel niveau, l'optimisation des performances est la marque d'un expert. Le travail d'optimisation des performances sur un projet est généralement confié à des experts. Donc, si vous avez étudié et pratiqué l'optimisation des performances, c'est sans aucun doute un énorme atout pour vos compétences, et ce sera un gros plus lors des entretiens.
  • Enfin, soyez dévoué et prenez votre travail au sérieux. Prenez chaque ligne de code et chaque bug au sérieux. Même si vous n'aimez pas votre travail actuel, même si vous sentez que vous perdez votre temps et votre vie, à corriger des bugs tous les jours sans joie, vous devez quand même le prendre au sérieux et bien faire votre travail. Comme dit le proverbe, « Prends l'argent et écarte les malheurs pour les autres. » Puisque vous recevez un salaire de l'entreprise, vous devez bien faire votre travail. Si vous pouvez décrocher un meilleur travail à l'avenir, c'est une autre histoire, quelque chose pour plus tard. Aujourd'hui, tant que vous êtes ici, vous devez faire ce qui doit être fait. Si vous êtes trop impétueux, avez de grandes ambitions mais peu de capacités, et bâclez toujours, pensez-vous pouvoir obtenir un meilleur travail ? Le patron vous confierait-il des tâches plus importantes ? Bien que le monde soit un endroit étrange et qu'en effet certaines personnes obtiennent des salaires plus élevés et de meilleurs emplois non pas grâce à leurs compétences, je crois que dans la plupart des cas, c'est proportionnel. Les personnes mieux traitées que vous ont des raisons légitimes. Si vous ne l'acceptez pas, alors vous devriez travailler encore plus dur. Quand vous décrocherez un meilleur travail à l'avenir, prouvez aux autres : « Je suis meilleur que vous tous ! »

Si vous pouvez faire les quelques choses suggérées ci-dessus et persévérer un peu, d'ici six mois vous verrez certainement un changement qualitatif.


Nique la planification de carrière et les plans à long terme.


La planification de carrière est un truc méthodologique, encore moins fiable que les putains de design patterns. Les plans à long terme sont encore plus nuisibles. Les plans dépassant un an, ou même six mois, sont des conneries. Va demander à ces grosses pointures—peu d'entre elles ont des putains de plans de carrière et de plans à long terme clairs. Leurs traits communs sont : ils savent creuser en profondeur, peuvent dévorer des livres, savent lire du code, ont une pensée active, une logique claire, et lorsqu'ils résolvent des problèmes, leur approche est plus élégante que la vôtre.


Pourquoi ces choses sont-elles inutiles ? Parce que dans la vraie vie, les choses changent très vite. Les projets peuvent être abandonnés après quelques mois. Quant aux personnes, Zhang San démissionne aujourd'hui et Li Si est muté à un autre poste demain. Avant que vous ayez terminé, les exigences changent, ou cette activité opérationnelle est annulée parce que le patron ne va pas approuver le budget...


Laissez-moi donner un exemple précis de mon entourage : l'année dernière, un nouveau stagiaire a rejoint l'équipe. Il a été recruté comme développeur client Android. Après son arrivée, il a reçu des tâches Android la première semaine. La deuxième semaine, une nouvelle exigence majeure est apparue, nécessitant du H5 (Mobile HTML5), donc ce gamin a dû faire du H5 (il a dû apprendre JavaScript à partir de zéro). Au bout d'environ trois mois, la politique de l'entreprise a changé, et ils ne pouvaient plus utiliser autant de stagiaires, donc le gamin a dû retourner à l'école. Si vous étiez ce gamin, vous ne pourriez même pas accomplir un plan d'étude d'un mois, parce que vous ne savez pas ce qui se passera la semaine prochaine, ni même demain.


Pour obtenir un meilleur environnement de croissance et d'apprentissage, vous devez aller dans une grande entreprise.


Qu'il s'agisse d'aller dans une grande entreprise ou une petite entreprise, cela peut être listé comme un sujet immortel au même titre que le débat C vs. C++, le débat GNOME vs. KDE et le débat Vim vs. Emacs. Je crois que lorsque vous êtes au début de votre carrière, par exemple juste après l'obtention de votre diplôme ou dans les deux ou trois ans suivant l'obtention du diplôme, une grande entreprise est sans aucun doute un très bon choix. Ici, « grande entreprise » inclut les meilleures entreprises nationales telles que BAT, NetEase et d'autres grandes entreprises nationales bien connues, ainsi que de grandes entreprises étrangères comme Intel, Microsoft, Facebook, Google, etc.


Ensuite, permettez-moi de parler des raisons. Les entreprises nous embauchent pour que le travail soit fait, pour créer de la valeur et pour aider l’entreprise à gagner de l’argent. Elles ne vous embauchent pas pour apprendre, pour élargir vos horizons, pour vous rapprocher de grands noms ou pour discuter de problèmes. Une grande entreprise, parce qu’elle est grande, dispose d’une source stable de revenus et de rentabilité, donc son rythme est régulier et relativement détendu. Ses projets sont soit matures et stables, soit ne sont pas menés pour un profit à court terme. Par conséquent, elle agit avec réflexion dans le développement des talents. Autrement dit, elle peut tolérer que vous appreniez, ou même que vous ralentissiez légèrement vos tâches professionnelles (je veux dire légèrement ralentir), parce que l’entreprise s’attend aussi à ce que vous appreniez et amélioriez vos compétences et capacités. L’entreprise aura l’espace pour accueillir une meilleure version de vous. Pour le dire clairement, il y a suffisamment de place pour que vous vous amélioriez et progressiez, et il y a le temps et la patience de vous laisser mener ce processus à bien. Une petite entreprise peut-elle avoir un tel espace ? Peut-elle vous permettre de dire : « Je vais d’abord étudier pendant quelques mois » ? Il est possible que quelques mois plus tard, lorsque vous reviendrez de vos études, l’entreprise ait fait faillite.


De plus, les grandes entreprises comptent beaucoup de gens — plus de bonnes personnes, plus d’experts, mais aussi certaines mauvaises personnes et pas mal d’incompétents. Vous pouvez rencontrer plus de gens, apprendre comment fonctionne une grande entreprise, ce qui lui a permis de devenir si grande et comment elle continue de fonctionner sans décliner. Dans une grande entreprise, vous pouvez avoir le temps et l’espace pour apprendre, élargir vos horizons et développer votre réseau. Ce sont des choses qu’une petite entreprise ne peut pas offrir.


En un mot, lorsque vous êtes dans la phase d'apprentissage rapide de votre carrière, une grande entreprise est le meilleur choix. Quand vous estimez avoir suffisamment appris ou avoir atteint un nouveau goulot d'étranglement, une petite entreprise est un excellent endroit pour utiliser pleinement vos compétences. Vous voyez donc, les personnes issues de BAT, qu'elles créent leur propre entreprise ou rejoignent une startup, obtiennent de très bons résultats. C'est gagnant-gagnant. Pour nous, une petite entreprise offre plus d'espace, moins de personnes mais plus de choses à faire, et constitue une grande scène pour montrer vos capacités. Et les petites entreprises ont précisément besoin de ces personnes polyvalentes capables de faire le travail de dix, à la fois CTO et singe de code, à la fois développeur et opérations.


La communication et la maintenabilité du code dépendent du fait que l'auteur tient compte des autres.


Si une personne est prête à prendre les autres en considération et à se mettre à leur place, je crois que ses compétences en communication ne seront pas mauvaises, et que la lisibilité du code qu'elle écrit ne sera pas trop mauvaise non plus. Si vous ne vous souciez pas des autres, ne parlez que pour votre propre intérêt et oubliez tout après avoir dit ce que vous aviez à dire, alors quelle que soit votre manière de communiquer, cela ne fonctionnera pas. Si vous ne tenez pas compte du fait que d'autres devront maintenir votre code, et ne tenez même pas compte du fait que vous devrez vous-même relire le code que vous écrivez maintenant (voyez, vous ne tenez même pas compte de vous-même), alors si un tel code est maintenable, c'est que j'aurai vécu pour rien.


Pour résister à l'agression étrangère, il faut d'abord stabiliser l'intérieur.


La maxime du Généralissime est assez profonde et significative, et elle a aussi une valeur de guide. Ma compréhension de cette maxime est que, des individus, des équipes et des services jusqu'aux entreprises et aux pays, vous ne pouvez pas mener deux ou plusieurs choses majeures en même temps. Ce n'est qu'après en avoir terminé une que vous pouvez passer aux autres. C'est un peu difficile à comprendre ; laissez-moi expliquer lentement.


Comme le dit le proverbe, « Quand on est bien nourri et au chaud, des pensées lubriques surgissent. » Quand tu n'as même pas de quoi prendre ton prochain repas, comment peux-tu penser à draguer des filles ? Quand tu n'as même pas appris à fond une compétence, un langage de programmation ou une plateforme, pourquoi penser au développement multiplateforme ou à l'étendue des technologies ? Ce ne sont que des conneries. Si tu creuses des puits partout, aucun ne sera profond, et au final tu ne trouveras jamais d'eau de toute ta vie. C'est comme dire que dix 10 % ne valent pas un 100 %.


Un autre exemple est l'équipe — chaque version tourne au chaos. Comment peux-tu parler de XP ou d'innovation technique dans ces conditions ? Fais le travail de te familiariser avec les technologies dont ton activité a réellement besoin, et maîtrise-les à fond. D'abord, fais bien ton propre travail, et fais-le avec aisance. Quand tu peux gérer chaque version sans effort, ou même quand le travail de 10 personnes peut être pris en charge par 5, c'est alors — et seulement alors — qu'il est temps de se consacrer à l'innovation technique, aux tests unitaires, à XP, à une culture pilotée par la technologie ou à une culture centrée sur les ingénieurs.


Au niveau de l'entreprise, lorsque vous n'avez même pas encore sécurisé une part de marché stable dans votre domaine actuel, vous copiez les grandes stratégies des autres : ils se lancent dans la finance, vous aussi ; ils se lancent dans l'automobile, vous aussi ; ils se lancent dans le cinéma, vous aussi. Cela finira tôt ou tard par vous tuer. Prenez M. Jia (Jia Yueting) aujourd'hui : parmi les divisions TV, téléphones et sportives de LeEco, laquelle a une part de marché stable ? Laquelle peut assumer la responsabilité de faire vivre la famille ? Pourtant, il s'en va jouer à des jeux de stratégie et construire des voitures ? C'est ce qu'on appelle « No zuo, no die. » M. Ma (Jack Ma) est bon en matière d'agencement stratégique, mais il ne l'a fait que lorsqu'il avait un monopole dans un domaine : lorsqu'il a lancé Taobao, c'était parce que B2B avait acquis une base solide et pouvait faire vivre la famille. En d'autres termes, B2B était déjà bien établi, détenait la majorité de la part de marché et était rentable, donc même si Taobao échouait et perdait de l'argent, ce n'était pas grave. Plus tard, il a lancé Alibaba Cloud, et maintenant la division cinéma, Cainiao, Double H — tous ces éléments nécessitent des injections de trésorerie continues. Pourquoi ? Parce que Taobao et Tmall peuvent soutenir l'ensemble d'Alibaba, et même si tous perdent de l'argent, il peut supporter les pertes.


Il en va de même au niveau national : quand les gens n'ont pas encore de quoi manger à leur faim ni de quoi se vêtir, comment parler de civilisation spirituelle ou d'innovation technologique ? Par exemple, la Chine des années 1970 et 1980, ou l'Asie du Sud-Est il y a une dizaine d'années (les pays plus faibles, pas les Quatre Tigres), et la protection de l'environnement : quand l'humanité doit choisir entre sa propre survie et la protection de l'environnement, elle ne peut choisir que la première. Ainsi, lorsqu'un pays moins développé progresse vers le statut de pays modérément développé, le développement économique passe toujours en premier. Le processus de développement humain est partout le même : polluer d'abord, poursuivre le développement, puis nettoyer.


À ce stade, je pense que vous comprenez ce que je veux dire.


Améliorer la compétitivité pour créer de la valeur.


Qu'est-ce que la compétitivité ? Je pense qu'elle signifie cultiver la capacité de résoudre des problèmes qui ne peuvent pas être résolus par de simples recherches Google. En termes simples, c'est un système de connaissances. Un problème que Google peut résoudre est nécessairement ponctuel. Qu'il s'agisse de StackOverflow ou d'un article de blog, ils traitent toujours un problème ponctuel — il ne peut pas être trop vaste, car sinon, comment un seul article pourrait-il l'expliquer clairement ? Plusieurs points, reliés au fil du temps, forment un système. Cela vient de recherches Google répétées sur une longue période, plus de réflexion et de synthèse. C'est ça, la compétitivité. C'est aussi la valeur d'un vétéran expérimenté.


Beaucoup de gens débattent : faut-il continuer à écrire du code après 30 ans ? Que fait-on après 40 ans ? Il est vrai qu'avec l'âge, le corps et l'énergie déclinent, et l'on ne peut plus passer des nuits blanches comme dans sa jeunesse. La situation des travailleurs de première ligne dans la trentaine est donc assez difficile. Les premières années après l'obtention du diplôme sont une période de croissance rapide — tant que l'on est prêt à étudier dur, ses compétences et ses revenus augmentent en ligne droite. Mais pour les codeurs de première ligne approchant la trentaine, obtenir des progressions linéaires à la fois en compétences et en revenus devient assez difficile. La famille, la vie et l'état physique laissent moins de temps pour étudier. À ce stade, les choses que l'on peut faire sont celles que des personnes sorties de l'école depuis seulement un ou deux ans peuvent aussi faire — et elles ont plus d'énergie et une meilleure santé. Ainsi, beaucoup de gens passent soit au management, soit changent complètement de carrière, et ceux qui restent réfléchissent toujours au moment de faire le changement.


À mon avis, la raison la plus importante de cette situation délicate est l'échec à continuer d'apprendre et à accumuler suffisamment de compétitivité. Même si vous ne devenez pas manager ou expert de premier plan (dans la vie réelle, il est impossible que toutes les personnes de plus de 30 ans deviennent manager ou maître), si vous continuez d'apprendre et améliorez continuellement votre compétitivité, votre valeur ne fera qu'augmenter — même si l'entreprise ne vous accorde que les augmentations annuelles standard.


En matière de salaire, nous devrions le calculer par unité de temps. Supposons que votre salaire mensuel soit de 2,150 yuan ; cela découle de 21.5 × 100. Si vous prenez un jour de congé, 100 yuan sont déduits. En poursuivant la conversion : 8 × 12.5 = 100, ce qui signifie que votre salaire horaire est de 12.5 yuan. Imaginons deux personnes ayant toutes les deux un salaire mensuel de 2,150, mais l'une a un niveau de compétence plus élevé : le travail d'une journée est fait en 2 heures, et le travail d'un mois en une semaine. L'autre doit faire des heures supplémentaires chaque jour rien que pour terminer. Qui a le salaire le plus élevé ? Bien sûr, il s'agit d'un scénario simplifié ; la vie réelle est plus complexe. Bien que tout le monde ait une période de croissance rapide, et que les entreprises aient aussi des périodes d'expansion rapide, tout finit par atteindre un état stable. La stabilité signifie atteindre un goulot d'étranglement. Prenons la plupart des gens dans les grandes entreprises comme BAT, par exemple—en prenant Alibaba comme exemple, la grande majorité des gens s'arrêtent après avoir atteint P7. Être promu P8 sans être manager est très difficile, et cela ne fait qu'empirer. Donc ces personnes ne peuvent obtenir que des augmentations annuelles standard. Pour élever leur niveau de revenu, elles ne peuvent augmenter leur valeur qu'en améliorant leur propre efficacité au travail.


Certains diront que ce n'est pas réaliste—le travail n'est pas nécessairement réparti équitablement, et les anciens peuvent se voir confier plus de tâches. En fait, cette décision vous appartient. Si vous êtes déjà un ancien sans espoir d'avancement, pourquoi en faire plus ? C'est une époque où l'arrière décide de la tête—c'est-à-dire une époque où le salaire décide de la responsabilité. L'effort que les employés fournissent dépend de combien ils sont payés. Pour le dire franchement : ils paient le salaire d'un jeune diplômé, mais s'attendent à ce que vous fassiez le travail d'un architecte et portiez la responsabilité d'un CTO. Les gens ne font cela que pendant la première phase de carrière, lorsqu'ils apprennent et progressent rapidement—et une fois qu'ils estiment avoir assez appris, ils sautent immédiatement vers un meilleur poste.


En bref, ce n'est qu'en apprenant et en résumant continuellement, et en cultivant davantage de compétitivité, que vous prendrez de la valeur avec l'âge.


Les choses importantes ne doivent pas nécessairement être traitées en premier.


Lorsque vous avez plusieurs grandes tâches à traiter—par exemple, une nouvelle fonctionnalité, plusieurs bugs dans la version déjà publiée, et une proposition technique pour la campagne opérationnelle du mois prochain—lorsque ces trois tâches sont sur la table, vous ne pouvez choisir que la plus importante à faire en premier. Cela exige effectivement d'appliquer le principe des choses importantes d'abord.


Mais supposez qu'il y ait aussi d'autres petites tâches à faire : par exemple, recharger votre forfait téléphonique ; acheter quelque chose en ligne ; mettre à jour un logiciel. Ces petites tâches qui peuvent être faites en 10 minutes, il vaut mieux les faire en premier. Ainsi, vous avez l'esprit clair et vous n'arrêterez pas de penser : « Pense à recharger ton forfait téléphonique. » Ces petites choses sont naturellement faciles à oublier, donc votre cerveau vous les rappelle inconsciemment. Cela perturbe la réflexion normale du travail et affecte la concentration mentale, réduisant ainsi l'efficacité sur les choses importantes. De plus, suivre « les choses importantes d'abord » peut faire que ces petites tâches ne soient pas terminées le soir et soient reportées au lendemain.


Le principe distinctif est le suivant : si une petite tâche peut être faite en 10 minutes, alors faites-la immédiatement. Comprenez que plus votre liste de tâches est courte, mieux c'est. Quant aux tâches qui prennent une demi-journée ou une journée entière, elles doivent bien sûr toujours être traitées selon le principe des choses importantes d'abord.


Ne faites pas d'heures supplémentaires acharnées sur les tâches professionnelles ; faites plutôt des heures supplémentaires pour étudier.


Les heures supplémentaires sont inévitables dans l'industrie du logiciel, en particulier dans l'industrie internet. À l'ère actuelle de l'internet mobile, le 996 est un phénomène courant. Vous pouvez vous sentir épanoui, ressentir un sentiment d'accomplissement, ou vous sentir fatigué. Mais faire des tâches métier en heures supplémentaires chaque jour comme un bœuf est, au minimum, la chose la plus fatale pour le développement personnel. Maintenant que c'est la fin de l'année, regardez en arrière et réfléchissez : qu'avez-vous fait cette année ? Comment avez-vous progressé ? Vous constaterez que vous avez fait beaucoup de choses, mais que vous avez très peu progressé. Lorsque vous rencontrez quelque chose que vous ne connaissez pas, vous cherchez en ligne, vous copiez, et c'est tout. Vous avez fait tant de travail métier — ressentez-vous un sentiment d'accomplissement ? Le sentiment d'accomplissement d'un programmeur vient davantage du développement personnel, de la capacité à faire des choses auparavant impossibles, et non du fait de déplacer des briques chaque jour.


Par exemple, vous savez construire des maisons. Mais si vous avez passé toute l'année à construire des maisons aux spécifications à peu près identiques, quel progrès avez-vous accompli ? Quand un projet de construction d'un beau château se présente, pouvez-vous le gérer ? L'entreprise nous paie pour créer de la valeur. Pour l'entreprise, les maisons sont la valeur. Tant que vous pouvez produire plus de maisons, vous valez le salaire qu'elle vous verse. Le jour où vous vieillirez ou tomberez malade et ne pourrez plus construire de maisons, elle trouvera immédiatement une personne plus jeune et plus forte pour vous remplacer. Mais la façon dont vous évoluez pour devenir quelqu'un qui construit des châteaux — l'entreprise ne s'en soucie pas du tout.


Donc, si vous avez l'impression de déplacer des briques tous les jours—plusieurs mois, voire un semestre, sans progrès, sans nouvelles connaissances acquises et sans réelle compréhension des problèmes rencontrés—alors il est temps de faire attention. Ralentissez le rythme de déplacement des briques. Même si cela signifie sacrifier votre KPI, arrêtez-vous pour étudier, résumer et réfléchir à la manière de faire mieux. Par exemple, pour les tâches répétitives, pouvez-vous utiliser des scripts pour des choses comme l'empaquetage et la publication ? Pour les exigences venant du produit et des opérations, pouvez-vous les refuser raisonnablement ? Pour les campagnes opérationnelles répétitives, pouvez-vous créer des modèles de configuration, et ainsi de suite ?


Travailler en heures supplémentaires sur des tâches métier chaque jour ne mènera pas au progrès. Pour progresser, vous ne pouvez qu'étudier.


Apprenez à travailler intelligemment.


Lors d'un examen, quelle est la meilleure méthode ? Ne pas deviner au hasard, ne pas résoudre soi-même, mais copier la bonne réponse. Quand une tâche vous est assignée, quelle est la meilleure façon ? Ne pas la faire soi-même—même si vous la maîtrisez déjà parfaitement—mais la faire faire par quelqu'un d'autre. La façon la plus économe en efforts et la plus simple d'accomplir quelque chose est de la faire faire par quelqu'un d'autre. Il y a de nombreuses façons d'accomplir quelque chose ; nous devrions choisir l'approche la moins coûteuse.


Il ne s'agit pas d'encourager tout le monde à être opportuniste et à refiler ses propres tâches aux autres—bien sûr, si vous avez la capacité de refiler des tâches et que l'autre personne est prête à les prendre, c'est très bien aussi. Il s'agit plutôt de travailler intelligemment et de ne pas épuiser votre énergie sur des choses qui devraient être la responsabilité de quelqu'un d'autre. Par exemple, les dépendances logicielles sont assez complexes de nos jours, et les problèmes apparaissent généralement à la couche supérieure. Si vous découvrez que le problème est causé par la couche sous-jacente, alors ne creusez pas (à moins d'avoir amplement de temps pour étudier et rechercher)—laissez plutôt la personne responsable l'examiner. Elle connaît mieux le sujet. Ce qui pourrait vous prendre une journée entière à comprendre, elle peut le résoudre en un coup d'œil.


De plus, pour les opérations manuelles fastidieuses et les tâches répétitives, écrivez des scripts pour les accomplir. Le plus grand avantage de l'ordinateur est sa capacité à accomplir des tâches de manière répétée sans faire d'erreurs. Son plus grand atout réside dans la répétition : les humains ne sont pas aussi doués que les ordinateurs pour la répétition, et ils font des erreurs, comme des fautes de frappe. Beaucoup de choses, comme l'empaquetage, la publication, etc., peuvent toutes être accomplies avec des scripts.


Apprenez à tirer parti des avantages d'être programmeur.


Le logiciel n'est plus cette chose mystérieuse et difficile à comprendre des laboratoires universitaires. Il fait désormais partie intégrante de la vie des gens — même les seniors qui dansent sur la place utilisent des smartphones, WeChat et Taobao. Je crois que de moins en moins de personnes demanderont à des ingénieurs logiciels de réparer leur ordinateur. Cela signifie que nous côtoyons des logiciels tous les jours et que nous ne pouvons pas vivre sans eux. En tant que personnes qui savent écrire des logiciels, nous devrions bien tirer parti de nos avantages. Laissez-moi illustrer cela avec quelques exemples :


  • Sachez identifier toutes sortes de SMS d'hameçonnage et d'appels/textos frauduleux. Si un programmeur se fait arnaquer par une fraude téléphonique, il faudrait dire que ce programmeur est un raté colossal.
  • Pour divers logiciels, sachez identifier lequel est authentique, lequel est une contrefaçon, lequel est faux, lequel pourrait porter un virus et lequel pourrait contenir un cheval de Troie. Plus important encore, ayez une conscience de la sécurité. Les fuites de données personnelles dans les applications mobiles et les sites web sont très graves de nos jours, alors faites particulièrement attention à gérer les autorisations des applications, et inscrivez-vous sur le moins de sites possible. En plus de veiller à votre propre sécurité de l'information, vous devriez aussi le rappeler aux personnes autour de vous.
  • Autre exemple : les gens ordinaires obtiennent des informations en visitant des sites web et en utilisant des moteurs de recherche, mais les programmeurs (猿媛) ne devraient-ils pas utiliser des robots d'exploration ?
  • Un autre exemple est de saisir des enveloppes rouges, d'attraper des billets, des ventes flash (ne visez pas les gâteaux de lune haha), de booster des votes, de booster des commentaires, etc. Les gens ordinaires comptent sur l'effort manuel, le travail manuel et la publication sur leur Moments. En tant que programmeurs, nous devons absolument compter sur la technologie—écrire un script, écrire un morceau de code pour nous aider à faire ces choses. C'est aussi un avantage qui vient avec notre profession.

De : Ciel étoilé du vagabond
Auteur : alexhilton
Lien : http://blog.csdn.net/hitlion2008/article/details/54089376