Les programmeurs ont des dictons différents sur les problèmes difficiles. Probablement mon option préférée : "Il y a deux problèmes difficiles en informatique: l'invalidation du cache, le nommage et l'erreur par unité."

J'écris des logiciels depuis assez longtemps pour faire face à chacun de ces problèmes. En même temps, je parle du côté des affaires et explique aux clients la partie technique de notre produit, donc je rencontre constamment des non-programmeurs. La chose la plus importante est de transmettre correctement l'idée ou le concept de telle manière que les autres le comprennent.

Et c'est très difficile.

Comme dans tous les domaines professionnels, les programmeurs ont développé leur propre jargon pour transférer rapidement des concepts.

Technolepet

Le jargon est très important. Si mon collègue et moi choisissons un algorithme pour résoudre un problème spécifique, nous pouvons dire que «la première option O(n^2)avec une surcharge minimale dès le départ et la seconde est dépréciée O(n log n), mais avec une installation et une configuration coûteuses» .

Cette seule phrase en dit long, pour quels scénarios l'algorithme doit être utilisé et comment ils sont mis en œuvre sous le capot:

L'option A est idéale pour un système avec une petite quantité d'entrée.
L'option B est idéale pour travailler avec une très grande quantité de données d'entrée, où les coûts élevés d'installation et de configuration du système seront compensés par de meilleures performances dans le processus.
Si vous avez l'intention d'utiliser l'algorithme en boucle, vous devez choisir la première option pour éviter le code d'installation et de configuration coûteux.
Nous pouvons peut-être réduire le coût d'installation de l'option B à l'aide de la mise en cache.
Probablement, dans l'option A, chaque élément des données d'entrée est comparé à tous les autres (par exemple, for x in inputs { for y in inputs { if some_condition(x, y) { ... }}}).
Probablement, l'option B crée d'abord un arbre, puis effectue une recherche linéaire, suivie d'une recherche dans cet arbre.

Comme vous pouvez le voir, nous avons pu transmettre plusieurs paragraphes d'informations en une seule phrase, en utilisant simplement les bons termes.

Dans ce cas, je voulais dire des algorithmes pour détecter les collisions, c'est-à-dire les intersections entre deux ou plusieurs objets. Le premier vérifie toutes les combinaisons possibles de données d'entrée, tandis que le second utilise un arbre quadrant ou une partition d'espace binaire pour vérifier uniquement les éléments fermés.

Mais si vous rencontrez des personnes extérieures au monde de la programmation (par exemple, ingénieurs en mécanique ou en électricité, gestionnaires, spécialistes du marketing), ce jargon technique ne fera qu'insulter et dérouter les gens, sans transmettre presque aucune information précieuse.

C'est ce que j'appelle technoleth, le marmonnement d'un programmeur.

Franchement, ces détails et conditions ne sont généralement pas nécessaires aux personnes d'autres régions, et ils s'en moquent vraiment.

Par exemple, vous expliquez une nouvelle fonction étonnante qui trouve le chemin le plus court de A à B, générant une grille de navigation et appliquant la recherche A * .

En aucun cas, vous n'avez besoin de décrire la nouvelle fonction comme dans la phrase précédente. Au lieu de cela, dites quelque chose comme ceci:"Nous calculons un tas de chemins possibles, puis appliquons les algorithmes intelligents qui sont utilisés dans l'industrie du jeu pour trouver le meilleur itinéraire . "

Peu importe que nous utilisions la recherche A * ici (contrairement à l'algorithme de Dijkstra ou à la recherche de largeur). Peu importe que dans les jeux, la recherche A * soit utilisée non seulement pour déplacer des personnages. Il suffit que l'interlocuteur sache que vous pouvez trouver un bon chemin de A à B et que nous utilisons des outils fiables qui ont déjà été testés dans d'autres domaines.

Cela ne fait pas de mal de montrer l'illustration de ce que vous voulez dire ...

Il m'est arrivé de voir comment des programmeurs plus expérimentés utilisent le jargon technologique pour démontrer leur supériorité, pour montrer leur incroyable intelligence et établir leur domination. C'est vraiment ennuyeux.

Ne vous méprenez pas, il y a parfois des situations où un interlocuteur suffisamment compétent demande: "C'est très difficile, pourquoi ne pas simplement faire X?" - et vous devez montrer que vous êtes un expert ici, mais il ne sait pas de quoi il parle ... mais vous pouvez toujours le faire de différentes manières.

N'essayez pas d'utiliser le technolepet pour satisfaire votre ego, il ostracise les gens et déshonore notre profession.

Le respect

Nous passons donc progressivement au point suivant ... n'oubliez pas le respect.

Beaucoup de gens avec qui je travaille sont vraiment intelligents et experts dans leurs domaines, mais pas nécessairement ils ont suffisamment de connaissances et d'expérience dans la création de systèmes d'information.

Pour expliquer un problème complexe, il est souvent préférable de simplifier les concepts. Mais essayez de ne pas être condescendant.

L'ingénieur logiciel dont j'ai parlé a souvent répondu: «C'est ... compliqué» quand une personne «normale» demande comment fonctionne telle ou telle fonction. C'est comme si le code était si sophistiqué que sans 20 ans d'expérience en programmation, vous ne pouvez pas le comprendre.

Ne fais pas ça.

La meilleure réponse:"Si vous simplifiez un peu les choses, alors d'abord nous faisons X, puis nous faisons Y, et enfin nous faisons Z, mais vous devez garder à l'esprit une douzaine de situations frontalières (peut-être expliquer une ou deux), mais l'essentiel est le suivant . " Vos collègues sont intelligents et sans techno-jargon sont tout à fait capables de vous comprendre.

Une autre astuce vraiment utile consiste à utiliser un non-programmeur comme plate-forme, comme un canard en caoutchouc. Si vous travaillez sur un problème complexe, expliquez-lui en termes simples votre solution et demandez si vous pouvez trouver une meilleure option.

Notre entreprise travaille dans le domaine de la CNC, c'est-à-dire qu'elle a quelque chose à voir avec le monde réel (par exemple, lorsque vous essayez de mettre en œuvre une compensation pour la largeur de la coupe ). Les ingénieurs savent très bien analyser les problèmes liés à la physique et à la géométrie.

Personnification, exagération et analogie

Les gens sont des êtres sociaux. Nous sommes programmés pour comprendre les relations et aimer les analogies pour relier les nouveaux concepts aux concepts existants. Lorsque vous parlez à quelqu'un, vous pouvez utiliser ces astuces pour vous aider à comprendre des sujets complexes.

Supposons que votre entreprise dispose d'un système d'approvisionnement en ligne. Le marketeur souhaite comprendre toute la chaîne de la commande en ligne à la livraison du colis afin de mieux répondre aux questions des clients. Je pourrais dire quelque chose comme ça:

, . www.example.com, «» ( -, ).

(-). , () . , , , (, ).

( ), , . , , ( — , ), .

( ) . , , .

Tout cela semble un peu comique, et l'exemple est plus que farfelu, mais je peux garantir que c'est une explication plus compréhensible qu'un grand schéma de réseau avec les termes «serveur Web», «architecture d'événements» et «Apache Kafka» (voir la section sur technolepte )

Un autre exemple. Si vous essayez d'expliquer à un étranger comment fonctionne l'algorithme de recherche de chemin, vous ne dites pas «les chemins visités ont plus de poids», vous dites «l'algorithme ne veut vraiment pas suivre les chemins où il est déjà allé».

C'est une différence subtile, mais nous faisons la personnification de l'algorithme. Nous disons qu'il «veut vraiment faire X» ou «essayer très fort d'éviter Y». Souvent, cela aide les gens à comprendre .

Analogies utiles avec des exemples (le cas échéant). Vous avez probablement déjà remarqué que cet article regorge d'exemples. Au lieu d'une explication abstraite, je raconte des histoires spécifiques qui aident à expliquer la thèse. Ce n'est pas un accident.

Dessinez de belles images

Cela semble ringard, mais parfois une image vaut vraiment mille mots.

Il y a quelques mois, je lisais un cours à la radio, et la fille à proximité ne pouvait pas se rappeler quels boutons appuyer sur le menu de ce petit écran LCD 16 × 2.

J'ai demandé si elle pouvait dessiner un diagramme.

Elle a pensé que j'étais un gars intelligent et s'est moquée d'elle.

Mais je ne plaisantais pas.

Au lieu de cela, j'ai trouvé un morceau de papier, et ensemble, nous avons fait quelque chose comme ceci:

Le programmeur reconnaît immédiatement le diagramme d'état de la théorie des automates. À l'insu d'une fille, j'ai introduit la technique informatique fondamentale dans son cerveau et comment l'interface de cette radio est programmée sous le capot.

Mais elle (et tout le monde à ce stade) ne se soucie pas de la science. Ils ont obtenu une carte qu'ils peuvent utiliser pour naviguer dans l'interface utilisateur.

Il y a un étrange plaisir à adapter un concept complexe pour quelqu'un d'une autre région. Surtout quand ils peuvent déterminer que la carte est vraiment un bug: vous devez appuyer sur le bouton Annuler et le maintenir enfoncé pour revenir à l'état inactif, car appuyer sur ce bouton vous ramène normalement au "Menu principal".

J'ai toujours un grand cahier avec des draps vierges sur mon bureau. Habituellement, j'écris une liste de choses à faire ou quelques dessins pendant la réflexion, mais cela aide souvent à expliquer. La capacité de dessiner quelque chose lors d'une conversation permet de vérifier le cours et de s'assurer que vous êtes sur la même longueur d'onde (jeu de mots voulu) que vous avez la même idée.

J'ai décuplé $ FEATURE

Supposons que vous ayez effectué quelques ajustements de performances et qu'un certain morceau de code fonctionne désormais beaucoup plus rapidement. Comment expliquer cela à un non-programmeur ou à quelqu'un qui ne voit pas le code source?

D'une part, à la question de ce que vous avez fait la semaine dernière, vous pouvez dire la vérité à la personne: "J'ai ajouté la mise en cache à lookup_something ()pour accélérer la recherche générale et traduire l'algorithme de detect_collisions()c O(n^2)à O(n log n)" , mais avec une forte probabilité qu'ils ne comprendront rien (voir technolept ) .

Vous pouvez également dire que vous «optimisez la productivité» , mais cela ressemble à une excuse, et le gestionnaire réfléchira aux raisons pour lesquelles il vous a embauché.

Souvent, les développeurs disent: "J'ai décuplé $ FEATURE."(ou un autre nombre arbitraire) et cela est limité. Une telle phrase vous permet de profiter d'un tas de félicitations des citadins, mais souvent c'est un peu ... trompeur.

Dans la plupart des cas, vous avez réellement amélioré les performances de plusieurs fonctions, mais si ces fonctions n'étaient pas un goulot d'étranglement, alors avec une forte probabilité, personne ne verra de différence.

Remarque. Si vous connaissez la loi d'Amdahl, augmenter les performances d'une fonction qui n'est pas un goulot d'étranglement revient à utiliser davantage de cœurs de processeur pour une tâche essentiellement cohérente.

La question se pose également: qu'avez-vous fait pour décupler la productivité? Est-ce un nombre étonnamment spécifique, votre code source a-t-il répété plusieurs fois un travail? Ou a-t-il demandé des données (disons, à partir de matériel ou d'un site tiers) dix fois plus lentement qu'il ne le devrait? Même cela me fait douter de vos capacités, car vous avez soit (mal) deviné la vitesse de polling initiale, soit vous sacrifiez toujours les performances en utilisant le polling au lieu d'une architecture d'événement plus efficace.

Il me semble qu'il vaut mieux essayer de trouver un juste milieu entre précision et compréhensibilité. Si vous avez apporté une modification qui améliore la complexité algorithmique d'un fragment de code (par exemple, une fonction detect_collisions()passée de O(n^2)à O(n log n)), vous pouvez dire:«La fonction X peut désormais s'adapter à une grande quantité d'entrée dans un délai raisonnable, mais ne le pouvait pas auparavant . »

Il est normal de dire "je ne sais pas" ...

... et continuez comme ceci: "... mais si vous me donnez cinq minutes, je peux vous le dire" .

Je le vois souvent. Les gens ont peur de montrer leur ignorance, donc ils sont silencieux, tourmentés ou inventent quelque chose.

Par exemple, si un responsable vient vers vous et vous demande: «Le client a demandé la fonction X, est-ce possible? Et combien de temps cela prendra-t-il? "

Dans neuf cas sur dix, la réponse honnête est «je ne sais pas», mais cela n'aide pas vraiment le gestionnaire à décider du moment. Il s'est tourné vers vous parce que vous êtes un expert dans le domaine concerné et que vous êtes mieux préparé à donner une réponse.

Certains essaient de deviner ou de tricher (par exemple, "Oui, nous le ferons dans deux à trois semaines"), mais cette approche ne fonctionne généralement pas à long terme. Dans le meilleur des cas, vous serez retardé de quelques semaines et, dans le pire des cas, passerez des mois à travailler juste pour découvrir que cette fonction ne peut pas fonctionner avec l'architecture d'application actuelle.

C'est un excellent moyen de perdre le respect des collègues et des supérieurs.

D'un autre côté, les mots «Pas sûr, mais donnez 5 à 10 minutes, et j'aurai une réponse» montre plusieurs choses à la fois:

Vous êtes prêt à admettre que vous ne savez pas tout (c'est-à-dire pas un égoïste narcissique).
Vous êtes responsable de vos propos et ne souhaitez pas donner de réponse inexacte.
Vous respectez suffisamment la personne pour passer une partie de votre temps à répondre à sa question.
Tu es un bon gars :).

(Et vous avez suffisamment de temps pour le comprendre).

Cela ressemble à une vieille parabole :

D'autres personnes (généralement) ne s'attendent pas à ce que vous sachiez tout dans leur domaine. Au lieu de cela, ils s'attendent à ce que vous disposiez d'outils pour rechercher la question et traduire la réponse en termes qu'ils peuvent comprendre.

Le vieil ingénieur a pris sa retraite et, après quelques semaines, la Big Machine est tombée en panne, ce qui est très important pour les revenus de l'entreprise. Le directeur n'a pas été en mesure de remettre la machine en marche. L'entreprise a donc invité l'ancien ingénieur en tant que consultant indépendant.

Il a accepté. Arrivé à l'usine, il regarda la Big Machine, prit un marteau et le frappa une fois. Après cela, la voiture a commencé à fonctionner. Le vieil ingénieur est parti et l'entreprise a recommencé à gagner de l'argent.

Le lendemain, le gestionnaire reçoit une facture de l'ancien ingénieur de 5 000 $. Le manager est furieux et refuse de payer. Le vieil ingénieur assure que c'est un prix équitable. Le gestionnaire rétorque que si c'est un prix équitable, vous pouvez demander des détails sur le compte.

Un nouveau compte détaillé ressemble à ceci ...

Marteau: 5 $

Savoir où la voiture a frappé avec un marteau: 4995 $

Tout le monde peut google n'importe quelle question. Mais seul un ingénieur logiciel sait quels mots clés utiliser et comment interpréter les résultats.

résultats

Habituellement, sur mon blog, je publie des articles purement techniques avec des tonnes de code, mais il est parfois utile de se rappeler qu’il y a autre chose dans ce monde que le code.

Les programmeurs (non sans raison) sont perçus comme des personnes ayant de faibles compétences sociales et de communication. Mais une partie importante de notre travail nécessite une communication efficace. J'espère que mon expérience vous aidera avec quelque chose.

Certains peuvent considérer qu'il s'agit de «politique de bureau» et de manipulation des opinions d'autrui. Voici ce que je vais répondre:

Hé bien oui. Mais cela ne s'applique-t-il pas à la plupart des interactions interpersonnelles?

La psychologie aide simplement les programmeurs à parler le même langage avec des non-programmeurs et à travailler ensemble pour atteindre un objectif commun.

Parler est difficile. Essais sur la communication avec les non-programmeurs