Как задать вопрос программисту, не получая «почему» в качестве ответа

У всех нас был этот опыт. Вы идете к человеку, у которого, как вы знаете, есть ответ на вопрос, задаете этому человеку вопрос, и он отвечает типичным ответом: «почему?» Вы объясняете, почему вам нужно знать, и они пытаются решить вашу проблему.

Требуется время, скручивание рук и терпение, чтобы вернуть разговор к исходному вопросу и получить этот чертов ответ.

Почему программисты постоянно делают это, и почему поведение тем хуже, чем старше становится программист?

Как вы можете задать программисту вопрос наиболее эффективным способом извлечения ответа на исходный вопрос?

Почему разработчики спрашивают «почему», когда кто-то спрашивает их, как реализовать решение?

Потому что для оценки соответствия решения требуется больше знаний, чем для его реализации.

Очень трудно поверить кому-то, когда они говорят: «Я не знаю, как это сделать, но я точно знаю, что это то, что мне нужно сделать». Программисты постоянно настаивают на более глубоком исследовании, потому что люди постоянно настаивают на том, чтобы задавать неправильные вопросы. Да, иногда это в конечном итоге возвращается к вашему первоначальному вопросу, но не всегда.

В качестве аналогии представьте, если кто-то подошел к механику и спросил его, как заменить автомобильный аккумулятор. Обычно, если вы квалифицированы для диагностики неисправной батареи, вы можете заменить ее, поэтому механик спросит, откуда вы знаете, что она нуждается в замене.

Он знает, что если он этого не делает, и оказывается, что вам не нужна батарея, тогда вы будете возвращаться, задавая все новые и новые вопросы, пока в конце концов не поймете, что должны выключить свет, когда двигатель не бегать. Когда вы спрашиваете об этом заранее, создается впечатление, что он тратит ваше время, но на самом деле он знает по опыту, что потенциально может сэкономить вам обоим гораздо больше времени.

Итак, если вы хотите избежать линии допроса, вам нужно убедить его заранее, что вы знаете, о чем говорите.

«Вопрос, в частности, заключается в том, как один взаимодействует с другим программистом, чтобы задать вопрос, где другой имеет ответ и пропускает дискуссию о том, почему задается вопрос».

Вы не можете, по крайней мере, не детерминистически. Другой программист - это человек, а не компьютер и не ваш слуга. Если вы зададите им вопрос, они получат возможность выбрать лучший ответ. Если они думают, что им нужно больше контекста, они просят об этом.

Вы можете попытаться предвосхитить свой вопрос с помощью заявления о том, что вы ищете только короткий, итоговый ответ, но они все еще могут ответить так, как считают нужным.

Вопрос, в частности, заключается в том, как один из них взаимодействует с другим программистом, чтобы задать вопрос, где другой имеет ответ и пропускает дискуссию о том, почему задается вопрос.

Ты не можешь Программисты, особенно хорошие, готовы решать проблемы и быть эффективными . Когда клиент или коллега-программист приходит за ответом, он обязательно узнает о проблеме, которую решает, прежде чем представить решение. Таким образом, они эффективны (они не тратят ваше и свое время, давая ответ, который не решит вашу проблему), и они решают реальные проблемы (давая вам решения / ответы на вопросы, которые вы должны задавать).

Пример - когда клиент приходит к вам и говорит, что хочет реализовать функцию X. Иногда клиенту действительно нужна функция X, а иногда вам действительно нужно покопаться и опросить клиента, чтобы узнать, что он не хочет X, а что-то совершенно другое. Чем старше и опытнее программисты, тем больше вероятность того, что они сгорели в прошлом из-за того, что не добрались до сути проблемы, прежде чем предлагать решение.

Итак, подведем итог - если вы хотите, чтобы ваши вопросы точно отвечали, вы должны быть уверены, что вы:

• задавать правильные вопросы (таким образом, вам нужно изучить проблему заранее)
• обеспечение контекста для проблемы
• поделиться некоторыми из ваших исследований, чтобы направить их быстрее к проблеме

Большинство людей, которых я знаю, просто люди, а не компьютеры. Если вы просто хотите получить ответы, попробуйте найти их.

Почему программисты постоянно делают это, и почему поведение тем хуже, чем старше становится программист?

К сожалению, это так же далеко от общей правды, как это получается.

Такое поведение ограничено меньшинством действительно хороших. И тебе лучше это тоже выучить.

Просто отвечая на проклятый вопрос, пропуская все это, можно быстро и уверенно войти в пропасть.

Если вы действительно хотите пропустить обученную часть, вы можете добавить в свой вопрос несколько предложений об ограничениях и свое желание пропустить вопросы - вы можете получить какой-то ответ или просто отослать его. Представление резюме ваших собственных исследований - лучшая идея.

Каждый ответ здесь является хорошим ответом на вопрос «почему», но на самом деле никто не ответил на вопрос ОП.

Как вы можете задать программисту вопрос наиболее эффективным способом извлечения ответа на исходный вопрос?

Ответ на удивление прост: скажите им, почему это нужно сделать, прежде чем спросить их, как это сделать.

Лучшее, что можно сделать, это включить разработчиков в некоторые встречи более высокого уровня, посвященные продукту, - дать им некоторую общую картину, чтобы они могли понять, почему эту конкретную вещь необходимо выполнить. Они могут даже удивить вас, придумав, как сначала.

Хорошие программисты не просто хотят реализовать какое-либо решение; они хотят реализовать лучшее решение для конкретной проблемы. Это требует информации. Вопросы - это способ сбора информации. Без всей информации программист знает, что он рискует реализовать решение, которое не будет соответствовать всем требованиям, и будет застревать, делая это снова. Не скрывайте информацию от своих программистов. Сокрытие информации тратит время, разрушает моральный дух и приводит к неполноценным решениям.

Программисты "запрограммированы" решать проблемы.

Хорошие программисты постараются решить «правильные» проблемы.

Просто предоставить то, что кто-то просит, - [часто] неправильная проблема, которую нужно решить.

В те дни, когда автоматизация MS Office была в моде, вы получите ряд вопросов, обычно в течение нескольких недель, с вопросом, как сделать «это» в одном продукте Office, а затем «это» в каком-то другом продукте. затем снова что-то еще в другом. Каждый из них быстро решается, но «проблема» - еще не полностью сформулированная - не решена. Они продолжают возвращаться к следующему «звену» в своей цепи.

Если вы остановите их и спросите их "Почему?" затем они должны отследить и объяснить более широко, чего они хотят достичь, а не просто описать проблему непосредственно перед ними. (Кстати, программисты страдают от этого так же, как (если не больше, чем) кто-либо еще, кому нравятся эти заветы медведя).
Цепочка пользователя «Получение данных из большой базы данных в Access, затем в Excel, чтобы немного помассировать их, затем в Word, чтобы они могли объединять результаты по почте и отправлять их по электронной почте людям каждую неделю», быстро заменяется пакетная работа, которая делает все это, с результатами, находящимися в почтовых ящиках людей первым делом в понедельник утром, без какого-либо ручного участия пользователя вообще.

Пользователям это нравится .

Нам нужно знать, куда вы пытаетесь добраться, прежде чем мы сможем предложить вам лучший способ добраться туда.

Или (перефразируя Монти Пайтона): «Вы хотите 5-минутный ответ или полчаса»?

Нет смысла программисту отбрасывать все мелочи конкретной функции, когда вы хотите знать, справится ли она, если вы передадите ей число с тремя тремя десятичными знаками.

Знание своей перспективы часто может радикально изменить ответ, который вы получите.

Ваш последний вопрос: «Как вы можете задать вопрос программисту так, чтобы наиболее эффективно извлечь ответ на исходный вопрос?»

Вы сначала путаете «эффективный» и «эффективный». Чтобы быть наиболее эффективным , просто напишите "Каков ответ?" на листе бумаги и показать его программисту. Это очень эффективный способ задать вопрос. Это также очень неэффективно при получении ответа.

И во-вторых, вы предполагаете, что разработчики программного обеспечения отвечают на вопросы. Они не. Они решают проблемы. Ваше отношение ясно показывает, что вы не понимаете решения проблем. Наиболее эффективный способ решения проблемы - это либо понять проблему до такой степени, чтобы вы могли описать ее для решателя проблем, а затем представить ее для решателя проблем. Другой метод состоит в том, чтобы частично понять проблему настолько, насколько вы можете, а затем представить свое неполное понимание специалисту по решению проблем, который сначала задаст вам вопросы, которых вы боитесь превратить в полностью понятую проблему, а затем решите ее.

Очень неэффективный способ - это метод, который вы пытаетесь: получить неполное понимание проблемы, угадать, как эта проблема может быть решена, и спросить решателя проблемы, как это решение может быть достигнуто. Решатель проблем видел такое поведение раньше. 10 раз, если он неопытный, тысячу раз, если он испытан. Таким образом, решающий проблему знает, что вы движетесь в совершенно неверном направлении. И решение проблем делает то, что нужно сделать, чтобы идти в правильном направлении, который задает вопросы, чтобы понять реальную проблему. Первые вопросы, чтобы понять ваше неполное понимание проблемы, а вторые вопросы, чтобы понять реальную проблему.

Начните вопрос, объяснив, чего вы хотите достичь и в каком контексте вы работаете. Если вы предоставите достаточно контекста, вы не получите «почему?» , вы получите "это действительно необходимо?"

Поскольку, по статистике , большинство предлагаемых функций отстой , и не стоит хлопот в реализации.

Типичным опровержением было бы «но это его работа». Его работа заключается в написании хорошего кода , и добавление функций обычно идет вразрез с этим, потому что большинство функций требуют переделки рабочей базы кода и этой «вещи редизайна»:

1. берет навсегда
2. добавляет новые ошибки
3. ломает вещи, которые раньше работали
4. делает обслуживание непроницаемым

Это не хороший код, хороший код минимален.