Почему умение задавать правильные вопросы - один из лучших навыков в карьере разработчика
Программировать сложно.
К сожалению, я не вижу в обозримом будущем, когда разработчик сможет автоматически вызывать в воображении решение сложного требования без необходимости консультироваться с Google или тратить много времени на постоянный поиск правильного способа что-то сделать.
Библиотека того, что нужно знать о любом конкретном языке программирования и его возможном использовании, слишком велика, чтобы ее можно было сразу запомнить и адаптировать. Если вам это удастся, то вам спасибо. Вы легенда и ученый, и я хвалю вас.
Но для нас, простых людей, я обнаружил, что для того, чтобы найти решение любой проблемы, вы должны сначала знать, какие вопросы задавать - будь то простая цель - перевернуть связанный список или запустить крупномасштабное, интеграция в реальном времени с конкретным API, которая требует дальнейшей алгоритмической обработки извлеченных данных.
Альберт Эйнштейн даже сказал о приближающихся проблемах:
«Если бы у меня был час на решение проблемы, и моя жизнь зависела от решения, я бы потратил первые 55 минут на определение правильного вопроса, который нужно задать, потому что, как только я знаю правильный вопрос, я мог бы решить проблему менее чем за пять минут. . »
Излишне говорить, что умение задавать правильные вопросы необходимо для развития.
Эта концепция коренным образом изменила мой подход к программированию, и я знаю, что никогда не променяю эту философию ни на что другое.
Это именно то, что позволило мне реализовать такие крупномасштабные интеграции за считанные дни, выполнять задачи, которые у меня раньше не было опыта, скрупулезно, а также достигать и узнавать больше, чем когда-либо прежде, с относительной легкостью и эффективностью.
Настоящий вопрос заключается в следующем: как вы задаете правильные вопросы, которые устранят разрыв между вами и решением?
Потратьте время на размышления и точный анализ того, чего вы хотите достичь
Вы не хотите слепо подходить к какой-либо задаче. Вам это может показаться очевидным, но чаще всего мы стремимся сразу приступить к делу, не понимая, какую задачу мы пытаемся решить.
Это может привести к тому, что вы будете делать больше, делать меньше или полностью отклоняться от того, что ожидалось реализовать.
Что может быть лучше для определения цели, чем спросить своего менеджера или технического руководителя о точных деталях того, что вы пытаетесь достичь?
Все это сделано для того, чтобы попытаться понять требования, которые вы получаете.
Я знаю, что регулярно чувствую, что получаю задачу, в которой не хватает деталей, - я чувствую, что не одинок в этом. Вместо того, чтобы сразу приступить к делу, пытаясь собрать воедино недостающие детали, просто попросите распределителя задач заполнить эти пробелы.
Несколько примеров вопросов могут выглядеть так:
- Где вы хотите, чтобы это было в пользовательском интерфейсе?
- Как вы собираетесь вписать эту особенность в нашу текущую реализацию?
- Есть ли конкретная функциональность, которой я должен стремиться?
- Как вы представляете, как пользователь взаимодействует с этим конкретным компонентом?
Опять же, это не более чем сбор требований. И как только вы поймете это требование, вы сможете адекватно сформировать четкий путь того, как вы собираетесь выполнить это требование.
Таким образом, у вас будет четкая цель, к которой нужно стремиться.
Когда требование кажется слишком большим, разбейте его на части
Это самый важный навык во всей разработке программного обеспечения.
Но не верьте мне на слово.
Во время Разговора в Google о философии разработки программного обеспечения профессор Стэнфордского университета компьютерных наук Джон Остерхаут подчеркнул, что декомпозиция задач - это самая важная вещь во всей компьютерной науке.
Я не мог с этим согласиться.
Когда вам поручают задачу, чаще всего это что-то довольно масштабное, из-за чего трудно понять, с чего именно вам следует начать и в каком направлении двигаться.
Вот почему вам нужно спросить себя, как можно разбить проблему на более мелкие и более достижимые компоненты. Когда задача разделена на более мелкие микрозадачи, вы можете подходить к цели большой задачи, как вехи, - получать прекрасные дозы дофамина каждый раз, когда вы выполняете указанную микрозадачу.
Итак, задайте вопрос: как решить эту проблему и уменьшить ее? Как именно можно препарировать этого зверя?
Это сделано для того, чтобы сделать вашу жизнь проще и менее напряженной.
Например, когда я приступил к созданию своей первой интеграции в реальном времени между Salesforce и другой CRM, мне нужно было сначала понять каждый крошечный проект, который существовал в этом более крупном проекте. Какие шаги мне нужно было предпринять, чтобы сделать это проще? Это побудило меня задать несколько из следующих вопросов:
- Как структурирован ответ API и JSON и как это узнать? Изучите документацию по API другой CRM, напишите имитационные выноски, которые отправят мне по электронной почте с ответом из другой системы.
- Как Salesforce будет получать изменения, внесенные в другую CRM, и обновлять их в реальном времени? Отдых веб-службы с помощью HTTP Post, публичный доступ к веб-службе, добавление службы в качестве веб-перехватчика в другой системе.
- Как я буду отображать и обрабатывать эту информацию в Salesforce и обновлять другую систему с учетом изменений, внесенных в Salesforce? Создайте класс, который действует как объект для анализа ответа JSON и хранения переменных в классе, используйте запросы GET, POST и PATCH к другой CRM, поймите, как пост-запрос структурирован в JSON.
- И этот список можно продолжать и продолжать.
Когда вы смотрите на вопросы, которые я задавал, и ответы, которые я затем придумал, когда приближался к этой проблеме, становится очевидным то, что мне нужно было сосредоточить на каждом этапе пути, чтобы максимизировать мою продуктивность при выполнении этого требования.
Вот почему вам нужно делать то же самое, задавая очень конкретные вопросы, чтобы определить точный путь и план, по которому вам нужно следовать для достижения задачи.
Инструмент №1 для последовательного прогресса: вопросы «Как?»
Ага.
Задавать вопросы «как» - это основа любого запроса, который программист вводит в поисковую систему Google, чтобы найти ответ на свои насущные технические потребности. Обычно вы можете попасть на какой-нибудь форум программирования, например, на Stack Overflow.
Как вы видите из приведенных выше примеров, ясно, что вопрос «как» используется не только для ответа на технические вопросы, но, скорее, как инструмент для перехода от начального требования к ожидаемому решению.
Но, честно говоря, это не всегда так просто, как просто задать очень прямой вопрос - хотя это потрясающее чувство, когда ты находишь ответ сразу.
Если вопрос слишком общий, вы можете не найти именно то, что ищете. Или, если вопрос, который вы задаете, слишком специфичен для конкретной проблемы, вы, вероятно, тоже не найдете там ответа.
Но все мы это знаем. Я предполагаю, что вы знаете, как правильно попросить Google перевернуть связанный список, реализовать определенный шаблон проектирования или как правильно создать функциональную кнопку в JavaScript, которая вызывает код на стороне сервера.
Это простые и понятные вопросы, которые мы задаем каждый день в программировании, но что делать, когда проблема становится слишком сложной, и вещи внезапно перестают быть очевидными?
Вопросы «Как» стимулируют развитие посредством конкретных целенаправленных действий, но когда все становится трудным, вы должны понимать тонкое искусство, которое окружает эти сложности, поскольку простой вопрос не всегда может дать прямой ответ.
Когда на вопрос «Как?» Нельзя ответить, примените силу мета-вопроса
Я уверен, что вам приходилось сталкиваться с подобным сценарием много раз: вы не умеете что-то делать и спрашиваете об этом в Google. Не повезло с первого раза, поэтому вы пытаетесь снова, снова и снова. Вы продолжаете продолжать, пока не исчерпаете все свои возможности и не измените структуру своего вопроса так, что в конечном итоге вы просто бьете головой по клавиатуре, крепко сжимая руками фолликулы ваших волос, готовясь просто вырвать все это. Вы убедили себя, что застряли.
Я бывал там много раз и уверен, что лично никогда не перестану испытывать это чувство, пока сохраню свое место в качестве разработчика.
Но, возможно, вы просто испытываете это из-за того, что задаете неправильные вопросы.
Поскольку программирование - это ремесло, требующее немало критического мышления, вы должны понимать, что вы не можете найти все, что ищете, с помощью простого поиска.
Вы должны задавать правильные вопросы.
Вопросы, которые окружают наиболее очевидные и конкретные вопросы «как делать». Я люблю называть эти вопросы мета-вопросами. Вопросы, которые проявляются как результат упражнений на стратегическое критическое мышление, которые окружают первоначальный очевидный вопрос - вопросы внутри вопроса.
Это может быть трудно осмыслить, но подумайте об этом: это в значительной степени совпадает с идеей декомпозиции проблемы, о которой я говорил ранее.
Представьте, что вам было предложено заполнить онлайн-форму, которая должна автоматически генерировать эту информацию при отправке в шаблонный PDF-файл и сохранять ее в виде файла в облачной базе данных.
Ваш первый инстинкт, вероятно, состоит в том, чтобы прямо спросить, как создать PDF-файл из информации, хранящейся в онлайн-форме. Скорее всего, вы получите информацию о том, как отображается PDF-файл, но ничего конкретного о том, как добиться уникальности вашей задачи.
В этой ситуации лучше всего подумать о том, какая информация вам понадобится, чтобы окружать этот огурец, в котором вы находитесь.
Итак, что вам следует сделать, это спросить:
- Как в первую очередь создается и форматируется PDF-файл? Это приведет вас к тому, как именно вы должны создать шаблон PDF-файла и передать правильные заголовки.
- Как передать эту конкретную информацию из формы в шаблон PDF-файла? Это может привести вас к идее сделать PDF-файл веб-страницей, которая получает информацию из параметров в URL-адресе, чтобы можно было делать правильные запросы для этой информации формы.
- Как сохранить страницу PDF в виде файла без перенаправления с текущей страницы формы? Это может привести вас к необходимости хранить сгенерированные двоичные данные из PDF в типе данных blob (большой двоичный объект), который затем можно вставить в виде файла при сохранении формы.
Это проблема, с которой мне действительно пришлось столкнуться, пытаясь обойти ограничения облачной разработки Salesforce, и именно эти вопросы, которые я задал, в конечном итоге привели меня к решению.
Что вам нужно знать, так это то, что большинство задач по программированию не являются прямым путем к завершению. Вам нужно будет подумать о структурах, которые окружают конкретную проблему, и постараться ответить на те основополагающие вопросы, которые позволят вам построить материал, чтобы сформировать более широкое решение, которое вам нужно достичь.
Это отнюдь не простая задача, но она эффективна и позволяет вам лучше понять язык и системы, с которыми вы работаете.
Обобщенные шаги (TL; DR)
Помните, как важно задавать взвешенные и целенаправленные вопросы всякий раз, когда вы приближаетесь к новой задаче.
Именно эти типы вопросов позволяют вам деконструировать проблему, чтобы сделать ее более достижимой и понятной. Если вы так думаете, вряд ли какая-либо задача, которую вы поставили, вызовет серьезные препятствия на пути прогресса.
- Определите цель и цель задачи, собрав более подробную информацию о переданном вам требовании.
- Разбейте задачу на микрозадачи, задав внутренние вопросы о том, как вы представляете крошечные структуры, составляющие эту задачу.
- Сначала задайте простые вопросы, чтобы найти ответы на проблемы, с которыми другие люди сталкивались раньше.
- Когда простые вопросы не работают, подумайте обо всем, что связано с задачей, что может сделать ее возможной. Это вопросы внутри вопросов, и они идут рука об руку с пониманием структур, составляющих микрозадачу.
