Comment poser une question à un programmeur sans obtenir «Pourquoi» comme réponse

Nous avons tous vécu cette expérience. Vous allez à quelqu'un que vous connaissez a la réponse à une question, posez-lui la question et ils répondent avec la réponse typique: "pourquoi?" Vous expliquez pourquoi vous avez besoin de savoir et ils essaient de résoudre votre problème.

Il faut du temps, des torsions de bras et de la patience pour ramener la conversation à la question d'origine et obtenir cette réponse sacrément juste.

Pourquoi les programmeurs font-ils constamment cela, et pourquoi le comportement empire-t-il plus le programmeur devient senior?

Comment pouvez-vous poser une question à un programmeur de la manière la plus efficace pour extraire la réponse à la question d'origine?

Pourquoi les développeurs demandent-ils "pourquoi" quand quelqu'un leur demande comment implémenter une solution?

Parce qu'il faut plus de connaissances pour évaluer si une solution est appropriée que pour l'implémenter réellement.

Il est très difficile de croire quelqu'un quand il dit: "Je ne sais pas comment faire, mais je sais que c'est ce que je dois faire." Les programmeurs insistent constamment pour approfondir parce que les gens insistent constamment pour poser les mauvaises questions. Oui, parfois, cela revient finalement à votre question d'origine, mais pas toujours.

Par analogie, imaginez si quelqu'un s'approchait d'un mécanicien et lui demandait comment remplacer une batterie de voiture. Habituellement, si vous êtes qualifié pour diagnostiquer une batterie défectueuse, vous êtes qualifié pour en changer une, donc le mécanicien vous demandera comment vous savez qu'elle doit être remplacée.

Il sait que s'il ne fait pas cela, et il s'avère que vous n'avez pas besoin d'une batterie, alors vous continuerez à revenir en posant de plus en plus de questions jusqu'à ce que vous finissiez par comprendre que vous devez éteindre les lumières lorsque le moteur est ne pas courrir. En vous le demandant, vous avez l'impression de perdre votre temps, mais il sait vraiment par expérience qu'il peut potentiellement vous faire gagner beaucoup plus de temps.

Donc, si vous voulez éviter la ligne de questionnement, vous devez le convaincre dès le départ que vous savez de quoi vous parlez.

"La question est précisément de savoir comment on peut dialoguer avec un autre programmeur pour poser une question, où l'autre a la réponse et éviter le débat sur la raison pour laquelle la question est posée."

Vous ne pouvez pas, du moins pas de manière déterministe. L'autre programmeur est une personne, pas un ordinateur et pas votre serviteur. Si vous leur posez une question, ils choisissent ce qu'ils pensent être la meilleure réponse. S'ils pensent avoir besoin de plus de contexte, ils peuvent le demander.

Vous pouvez essayer de préfacer votre question avec une déclaration selon laquelle vous ne cherchez qu'une réponse courte et nette, mais ils sont toujours libres de répondre comme ils le pensent le mieux.

La question est précisément de savoir comment l'un s'engage avec un autre programmeur pour poser une question, où l'autre a la réponse et éviter le débat sur la raison pour laquelle la question est posée.

Tu ne peux pas. Les programmeurs, surtout les bons, sont câblés pour résoudre les problèmes et être efficaces . Lorsqu'un client ou un collègue programmeur vient à la recherche d'une réponse, il s'assurera de connaître le problème qu'il résout avant de présenter une solution. De cette façon, ils sont efficaces (ils ne perdent pas votre temps et votre temps en donnant une réponse qui ne résoudra pas votre problème) et ils résolvent de vrais problèmes (en vous donnant des solutions / réponses aux questions que vous devriez poser).

Exemple - lorsqu'un client vient à vous et dit qu'il veut une fonctionnalité X implémentée. Parfois, le client a vraiment besoin d'une fonctionnalité X et parfois vous devez vraiment creuser et interroger le client juste pour découvrir qu'il ne veut pas X mais quelque chose de complètement différent. Plus les programmeurs sont âgés et expérimentés, plus il est probable qu'ils aient été brûlés par le passé en ne allant pas au cœur du problème avant de présenter une solution.

Donc, pour résumer - si vous voulez que vos questions répondent précisément, vous devez être sûr que vous êtes:

• poser les bonnes questions (vous devez donc rechercher le problème à l'avance)
• fournir le contexte du problème
• partager certains de vos recherches pour les diriger plus rapidement vers le problème

La plupart des humains que je connais ne sont que des humains et non des ordinateurs. Si vous voulez juste des réponses, essayez de le googler.

Pourquoi les programmeurs font-ils constamment cela, et pourquoi le comportement empire-t-il plus le programmeur devient senior?

Malheureusement, c'est loin de la vérité générale.

Ce comportement est limité à la minorité des très bons. Et vous feriez mieux de l'apprendre aussi.

Répondre à la maudite question en sautant le pourquoi est un bon moyen d'entrer dans un gouffre, rapidement et sûrement.

Si vous voulez vraiment sauter la partie instruite, vous pouvez préfixer votre question avec quelques phrases sur les limitations et votre désir de sauter des questions - vous pouvez obtenir une réponse ou simplement être envoyé. Présenter un résumé de vos propres recherches est une meilleure idée.

Chaque réponse ici est une bonne réponse à la question «pourquoi», mais personne n'a vraiment répondu à la question OP.

Comment pouvez-vous poser une question à un programmeur de la manière la plus efficace pour extraire la réponse à la question d'origine?

La réponse est étonnamment simple: dites-leur pourquoi cela doit être fait avant de leur demander comment.

La meilleure chose à faire est d'inclure les développeurs dans certaines réunions de niveau supérieur autour d'un produit - leur donner une vue d'ensemble afin qu'ils puissent voir pourquoi cette chose particulière doit être faite. Ils peuvent même vous surprendre en trouvant le premier.

Les bons programmeurs ne veulent pas simplement implémenter une solution; ils veulent mettre en œuvre la meilleure solution pour le problème spécifique. Cela nécessite des informations. Les questions sont le moyen de recueillir des informations. Sans toutes les informations, le programmeur sait qu'il est en danger d'implémenter une solution qui ne répondra pas à toutes les exigences et sera bloqué à nouveau. Ne cachez pas les informations de vos programmeurs. Cacher des informations fait perdre du temps, détruit le moral et conduit à des solutions inférieures.

Les programmeurs sont "câblés" pour résoudre les problèmes.

Les bons programmeurs essaieront de résoudre les "bons" problèmes.

Fournir simplement ce que quelqu'un demande est [souvent] le mauvais problème à résoudre.

À l'époque où l'automatisation de MS Office faisait fureur, vous receviez une série de questions, généralement au cours de quelques semaines, demandant comment faire «ceci» dans un produit Office, puis «cela» dans un autre produit , puis autre chose dans un autre. Chacun de ces éléments est rapidement traité, mais le «problème» - pas encore entièrement énoncé - n'est pas résolu. Ils reviennent sans cesse pour le prochain "maillon" de leur chaîne.

Si vous les arrêtez et leur demandez "Pourquoi?" ils doivent ensuite revenir en arrière et expliquer plus largement ce qu'ils veulent réaliser et non pas simplement décrire le problème immédiatement devant eux. (BTW, les programmeurs en souffrent autant (sinon plus) que n'importe qui d'autre, ce dont témoignent des forums comme ceux-ci).
La chaîne de l'utilisateur "Obtenir les données de la grande base de données dans Access, puis dans Excel pour les masser un peu, puis dans Word pour qu'ils puissent fusionner les résultats par courrier électronique et les envoyer par courrier électronique aux personnes chaque semaine" est rapidement remplacée par un travail par lots qui fait tout cela, avec les résultats assis dans les boîtes de réception des gens le lundi matin, sans aucune intervention manuelle de l'utilisateur.

Les utilisateurs aiment ça.

Nous devons savoir où vous essayez d'arriver, avant de pouvoir vous proposer le meilleur moyen d'y arriver.

Alternativement, (pour paraphraser Monty Python): "Voulez-vous la réponse de 5 minutes ou la demi-heure complète"?

Il est inutile que le programmeur agite toutes les minuties d'une fonction particulière lorsque vous voulez seulement savoir si elle fonctionnera si vous lui fournissez un nombre avec trois trois décimales.

Connaître votre point de vue peut souvent remodeler radicalement la réponse que vous obtenez.

Votre dernière question est "Comment pouvez-vous poser une question à un programmeur de la manière la plus efficace pour extraire la réponse à la question d'origine?"

Vous confondez d'abord «efficace» et «efficace». Pour être plus efficace , écrivez simplement "Quelle est la réponse?" sur un morceau de papier et montrez-le au programmeur. C'est une façon très efficace de poser une question. Il est également très inefficace d'obtenir une réponse.

Et deuxièmement, vous supposez que les développeurs de logiciels sont des répondeurs aux questions. Ils ne sont pas. Ce sont des résolveurs de problèmes. Votre attitude montre clairement que vous ne comprenez pas la résolution de problèmes. Le moyen le plus efficace de résoudre un problème est de comprendre le problème au point où vous pouvez le décrire à un résolveur de problème, puis de le présenter à un résolveur de problème. L'autre méthode consiste à comprendre le problème partiellement dans la mesure du possible, puis à présenter votre compréhension incomplète à un résolveur de problème, qui vous posera d'abord les questions que vous redoutez pour en faire un problème entièrement compris, puis le résoudre.

La méthode que vous essayez est très inefficace: obtenez une compréhension incomplète du problème, devinez comment ce problème pourrait être résolu et demandez à un résolveur de problème comment cette solution peut être trouvée. Le résolveur de problèmes a déjà vu ce comportement. 10 fois s'il n'a pas d'expérience, mille fois s'il est expérimenté. Le résolveur de problèmes sait donc que vous vous dirigez dans une direction complètement erronée. Et le résolveur de problèmes fait ce qui doit être fait pour aller dans la bonne direction, c'est-à-dire poser des questions pour comprendre le problème réel. Premières questions pour comprendre votre compréhension incomplète du problème, et deuxièmes autres questions pour comprendre le vrai problème.

Commencez la question en expliquant ce que vous voulez réaliser et quel est le contexte dans lequel vous travaillez. Si vous donnez suffisamment de contexte, vous n'obtiendrez pas un «pourquoi». , vous obtiendrez un "est-ce vraiment nécessaire?"

Parce que, statistiquement , la plupart des fonctionnalités proposées sont nulles et ne valent pas la peine d'être implémentées.

Une réfutation typique serait «mais c'est son travail». Son travail consiste à écrire du bon code , et l'ajout de fonctionnalités va généralement à l'encontre de cela, car la plupart des fonctionnalités nécessitent une refonte de la base de code de travail et cette "chose de refonte:"

1. prend pour toujours
2. ajoute de nouveaux bugs
3. casse des choses qui fonctionnaient
4. rend la maintenance imperméable

Ce n'est pas du bon code, un bon code est minime.