Nous avons tous Google, tout le temps

Peu importe leur expérience, ou la technologie en question, tout le monde googles, tout le temps.

Pourquoi nous Google

Parfois, nous ne savons pas

Parfois, on ne sait pas. Lorsque j'ai créé mon premier plug-in Salesforce CLI, je n'avais jamais utilisé TypeScript auparavant. J'aurais pu essayer de comprendre cela à partir de l'exemple de code de plug-in, mais il semblait improbable que j'apprenne les bases de cette façon. J'ai donc cherché un «tutoriel dactylographié» sur Google et appris juste assez pour commencer. Au fur et à mesure du développement, j'ai probablement googlé 20 autres fois pour des fonctionnalités spécifiques. Je ne m'en souviendrai pas la plupart du temps la prochaine fois. Je vais donc lancer à nouveau des requêtes similaires. Même si je m'en souviens, je le repasserai encore.

Nous ne voulons pas demander de l'aide trop tôt

Je suis un grand fan de la règle des 15 minutes - si vous êtes coincé avec un problème, vous devez essayer de le résoudre vous-même pendant 15 minutes avant de demander de l'aide, mais si vous ne l'avez pas résolu au bout de 15 minutes, vous avez demander de l'aide. La durée réelle est sans importance, il s'agit davantage d'encourager les développeurs à être autonomes et à enquêter sur les problèmes qu'ils rencontrent, mais également de ne pas perdre trop de temps s'ils sont vraiment bloqués. Je parie qu’une bonne partie de toute enquête de 15 minutes sera consacrée à la saisie des termes dans Google.

De plus, l'instauration d'une règle de 15 minutes peut être une véritable révélation. Vous serez surpris par le nombre de personnes qui:

  • distraire quelqu'un, n'importe qui, plutôt que de passer un moment à réfléchir au problème
  • passez des journées entières à lutter contre le problème, persuadés qu'ils vont le résoudre d'ici une heure environ, malgré toutes les preuves

Nous ne pouvons pas tout suivre

Dans un monde idéal, je n’aurais pas besoin de Google car je lisais et assimilais tous les articles de blog et articles pertinents. Dans le monde réel, cela signifierait (a) que je ne ferais rien d’autre et (b) que je ne lirais toujours pas tout, car la quantité d’informations pertinentes augmente de façon exponentielle. Je n’ai pas tout lu après Googling non plus, mais l’algorithme de classement des pages semble permettre assez bien d’identifier les hits les plus pertinents. Bien sûr, je ne vérifie jamais cela, alors il est possible que je manque de bons articles, mais à un moment donné, vous devez faire confiance à quelque chose (comme je l’aime trop, Quis custodiet ipsos custodes?)

La seule constante est le changement

Même si c’est un domaine que je connais très bien et un scénario que j’ai codé plusieurs fois auparavant, je jouerai quand même un provisoire (tiré de Golf Monthly):

Si, après avoir joué un coup, vous pensez que votre balle peut être perdue (en dehors d'un obstacle d'eau) ou en dehors des limites, vous devez jouer une balle provisoire. Le but de la règle est de gagner du temps.

J'ai mon approche existante, et je l'utiliserai si c'est toujours la meilleure façon. Ce que je ne ferai pas, c’est de supposer que la façon dont je l’ai fait la dernière fois reste la meilleure (c’est un exemple de The One True Way, un trait Rogue High Performer). Si le scénario implique des composants de la foudre, il est fort probable qu’il existe une nouvelle approche ou, si une fenêtre de publication de Salesforce est déjà passée, une multitude de nouveaux composants standard que je peux utiliser. Si le scénario implique JavaScript, il y aura probablement deux autres versions du langage et une douzaine de nouveaux cadres pour choisir entre! Quoi que je fasse, je vais prendre le temps de vérifier auprès de Google s'il manque des astuces.

Tout comme pour la balle provisoire, le but est de gagner du temps. Je vais mettre un peu plus de temps à effectuer le travail initial, mais la quantité de travail à venir sera réduite.

Nous ne nous sentons pas mal à ce sujet

Mais les nouveaux développeurs le font parfois, ce qui est fou. Dans un monde sans moteurs de recherche, ce serait comme avoir accès à la meilleure bibliothèque de référence au monde, mais ne jamais l'utiliser parce que vous étiez gêné de voir quelqu'un qui avait déjà lu le livre vous voir chercher quelque chose!

Je suis mieux connu dans la communauté Salesforce sous le nom de Bob Buzzard - Umpteen Certifications, y compris un architecte technique, 6 x MVP et CTO de BrightGen, un partenaire de Platinum Cloud Alliance au Royaume-Uni qui recrute actuellement.

Vous pouvez trouver mes pensées (généralement) plus techniques sur le blog de Bob Buzzard