Як задати програмісту запитання, не отримуючи відповіді "Чому"

Ми всі мали цей досвід. Ви йдете до когось, кого ви знаєте, має відповідь на запитання, задайте цій людині питання, і вони відповідають з типовою відповіддю: "чому?" Ви пояснюєте, чому вам потрібно знати, і вони намагаються вирішити вашу проблему.

Потрібен час, скручування руки та терпіння, щоб повернути розмову до початкового питання і просто отримати цю чортову відповідь.

Чому програмісти постійно роблять це, і чому поведінка стає гіршою, чим старший програміст стає?

Як можна задати програмісту запитання найбільш ефективним способом отримання відповіді на початкове запитання?

Чому розробники запитують "чому", коли хтось запитує їх, як реалізувати рішення?

Оскільки для оцінки потрібного рішення, ніж для його реальної реалізації, потрібно більше знань.

Дуже важко комусь повірити, коли вони кажуть: "Я не знаю, як це зробити, але точно знаю, що мені потрібно робити". Програмісти постійно наполягають на більш глибокому зондуванні, оскільки люди постійно наполягають на питанні неправильних питань. Так, іноді це врешті-решт повертається до вашого первинного питання, але не завжди.

Як аналогія, уявіть, якби хтось підійшов до механіка і запитав його, як замінити автомобільний акумулятор. Зазвичай, якщо ви кваліфіковані для діагностики несправного акумулятора, ви кваліфіковані, щоб змінити його, тому механік запитає, як ви знаєте, що потрібно замінити.

Він знає, якщо він цього не робить, і виявляється, що вам не потрібен акумулятор, тоді ви будете постійно повертатися, задаючи все більше і більше питань, поки в кінцевому підсумку ви не зрозумієте, що вам потрібно вимкнути світло, коли двигун не працює. Запитуючи вас наперед, відчувається, що він витрачає ваш час, але насправді він знає з досвіду, що потенційно економить обох набагато більше часу.

Отже, якщо ви хочете уникнути лінії допитів, вам потрібно переконати його наперед, що ви знаєте, про що говорите.

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

Ви не можете, принаймні, не детерміновано. Інший програміст - це людина, а не комп'ютер і не ваш слуга. Якщо ви задаєте їм питання, вони можуть вибрати, що вони вважають найкращою відповіддю. Якщо вони думають, що їм потрібно більше контексту, вони змушують його запитати.

Ви можете спробувати заздалегідь поставити своє запитання із твердженням, що ви шукаєте лише коротку відповідь із нижнього рядка, але вони все ще вільні відповісти, як вони вважають найкращим.

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

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

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

Отже, підсумовуючи - якщо ви хочете точно відповісти на ваші запитання, вам потрібно бути впевненим, що ви:

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

Більшість людей, яких я знаю, - це просто люди, а не комп’ютери. Якщо ви просто хочете відповіді, спробуйте погуглити його.

Чому програмісти постійно роблять це, і чому поведінка стає гіршою, чим старший програміст стає?

На жаль, це далеко не загальна істина.

Така поведінка обмежена меншиною справді хороших. І вам краще теж це навчитися.

Тільки відповідь на прокляте питання, що пропускати над вишами, - це хороший спосіб загнати у прірву, швидко та впевнено.

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

Кожна відповідь тут є гарною відповіддю на питання "чому", але ніхто не дійсно відповів на питання ОП.

Як можна задати програмісту запитання найбільш ефективним способом отримання відповіді на початкове запитання?

Відповідь напрочуд проста: скажіть їм, чому це потрібно зробити, перш ніж запитати їх як.

Найкраще зробити це - включити розробників на деякі зустрічі вищого рівня навколо продукту - дайте їм детальну картину, щоб вони зрозуміли, чому саме цю справу потрібно робити. Вони можуть навіть здивувати вас, коли придумаєте, як спочатку.

Хороші програмісти не просто хочуть реалізувати якесь рішення; вони хочуть реалізувати найкраще рішення конкретного питання. Для цього потрібна інформація. Питання - це спосіб збору інформації. Не маючи всієї інформації, програміст знає, що опиняється під загрозою реалізації рішення, яке не відповідатиме усім вимогам, і він буде затримуватися робити це знову. Не ховайте інформацію від своїх програмістів. Приховування інформації витрачає час, руйнує мораль і призводить до неповноцінних рішень.

Програмісти "жорсткі", щоб вирішити проблеми.

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

Просто подавати те, що хтось просить, - це [часто] неправильна проблема.

У дні, коли автоматизація MS Office була дуже лютою, ви отримували ряд питань, як правило, протягом декількох тижнів, запитуючи, як зробити "це" в одному продукті Office, а потім "що" в якомусь іншому продукті , потім ще щось в іншому. Кожне з них швидко вирішується, але "проблема" - ще не повністю заявлена ​​- не вирішена. Вони продовжують повертатися за наступною «ланкою» у своєму ланцюжку.

Якщо ви зупините їх і запитаєте їх "Чому?" тоді їм доведеться відстежувати і пояснювати ширше, чого вони хочуть досягти, а не просто описувати проблему безпосередньо перед ними. (До речі, програмісти страждають від цього так само, як і (якщо не більше) хто-небудь інший, на які такі форуми несуть заповіт).
Користувачу ланцюжок "Отримання даних з великої Бази даних у доступ, потім у Excel, щоб трохи її помасажувати, потім поперек у Word, щоб вони могли поштою об'єднати результати та надсилати їх електронною поштою щотижня", швидко замінюється на пакетна робота, яка виконує все це, а результати - це перше, що відбувається у вхідних скриньках людей вранці в понеділок, без участі користувача вручну.

Користувачам це подобається .

Ми повинні знати, куди ви намагаєтесь дістатися, перш ніж ми зможемо запропонувати вам найкращий спосіб дістатися.

Крім того, (перефразувавши Монті Пітона): "Чи хочете 5-хвилинної відповіді або повних півгодини"?

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

Знання своєї точки зору часто може докорінно переформувати отриману відповідь.

Ваше останнє запитання - "Як можна задати програмісту запитання найбільш ефективним способом отримання відповіді на початкове запитання?"

Ви спочатку плутаєте "ефективний" та "ефективний". Щоб бути найбільш ефективним , просто напишіть "Що відповісти?" на аркуші паперу і покажіть програмісту. Це дуже ефективний спосіб задати питання. Це також дуже неефективно в отриманні відповіді.

По-друге, ви припускаєте, що розробники програмного забезпечення - відповіді на питання. Вони не є. Вони вирішують проблеми. Ваше ставлення чітко показує, що ви не розумієте вирішення проблем. Найефективніший спосіб вирішити проблему - це або зрозуміти проблему до того моменту, коли ви можете описати її до вирішувача проблеми, а потім представити її для вирішення проблеми. Інший метод - це зрозуміти проблему частково, наскільки ви можете, а потім подати своє неповне розуміння вирішувачу проблеми, який спочатку задасть вам питання, які ви боялися перетворити це на цілком зрозумілу проблему, а потім вирішити її.

Дуже неефективним способом є метод, який ви намагаєтеся: зрозуміти неповну проблему, вгадати, як можна вирішити цю проблему, і запитати вирішення проблеми, як можна досягти цього рішення. Вирішувач проблеми бачив таку поведінку раніше. 10 разів, якщо він недосвідчений, тисячу разів, якщо він досвідчений. Тож вирішувач проблеми знає, що ви відправляєтесь у абсолютно неправильний бік. І вирішувач проблеми робить те, що потрібно зробити, щоб перейти у правильний напрямок, а це задавати питання, щоб зрозуміти актуальну проблему. Перші запитання, щоб зрозуміти ваше неповне розуміння проблеми, і друге більше питань, щоб зрозуміти справжню проблему.

Почніть запитання, пояснивши, чого ви хочете досягти і який контекст ви працюєте. Якщо ви дасте достатньо контексту, ви не отримаєте "чому?" , ви отримаєте "це справді потрібно?"

Тому що, статистично , більшість пропонованих функцій смокче , і не варто клопотатись із реалізацією.

Типовим спростуванням було б "але це його робота". Його робота - написання хорошого коду , і додавання функцій зазвичай суперечить цьому, оскільки для більшості функцій потрібен перероблений робочу базу коду, і це "перероблення:"

1. займає вічно
2. додає нові помилки
3. ламає речі, які раніше працювали
4. робить технічне обслуговування непрозорим

Це не гарний код, хороший код мінімальний.