При обучении кодированию или кодированию более эффективно одной из самых важных тем является то, как задавать технические вопросы. В своем Докладе на PyCon 2015 Саша Прачечная поднимает этот сложный вопрос, а также параллель с тем, как отвечать на технические вопросы. Разработчики постоянно учатся, стремясь расширить границы своих знаний, чтобы писать лучшие приложения. На этом этапе моего пути к программированию я сосредоточусь на том, как эффективно задавать технические вопросы. В будущем я надеюсь продолжить анализ этого видео, ведя блог об ответах на технические вопросы.

В начале своего выступления Лаунди утверждает, что то, как сообщество обращается с помощью, определяет культуру этого сообщества. Независимо от того, является ли это сообщество сообществом, основанным на языке программирования, или компанией, способы, которыми мы задаем вопросы и отвечаем на них, будут определять, насколько наше сообщество развивающееся или токсичное. В The Iron Yard я встретил одноклассников и преподавателей, которые поощряли вопросы, чтобы улучшить наше понимание и знания. Все компании, которые хотят вырастить из молодых талантов лояльных и выдающихся старших разработчиков, будут иметь схожий менталитет в отношении вопросов и обучения.

Для учащихся Лаунди разбивает свои советы на две основные категории: мышление и инструменты. Мышление — это внутреннее отношение разработчика к себе и своей проблеме. Наше отношение к себе — это то, что Лаунди называет Маленьким Голосом. Мы все воспринимаем этот голос по-разному в разное время в зависимости от нашего происхождения; в основном он спрашивает нас, созданы ли мы для этого, или говорит нам, что мы никогда не будем достаточно хороши. Мы должны бороться с этим голоском в нашей голове, чтобы добраться до второй части внутреннего отношения: как мы подходим к проблеме. Проблемы — это признак того, что нам есть чему поучиться, а не признак того, что мы некомпетентны. Кэрол Дуэк отлично описывает подход к решению проблем с помощью установки на рост в этом выступлении на TED (я чувствую, скоро появится еще одна запись в блоге).

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

  1. Выберите правильную команду. Как уже говорилось ранее, то, как сообщество предлагает помощь, многое говорит о культуре. Программистам, ищущим работу или даже записывающимся в новую команду проекта в той же компании, мы должны наблюдать и задавать острые вопросы о культуре компании. Проповедуют ли основатели наставничество и обмен знаниями? Как они адаптируют новых сотрудников? Предлагают ли старшие разработчики помощь добровольно?
  2. Спросите заранее (правило 15 минут). Обращение за помощью к программисту на раннем этапе может помочь улучшить качество кода и ускорить завершение проекта. Предостережение к этому 15-минутному правилу заключается в том, что спрашивающие должны найти проблему в Google, прочитать сообщение об ошибке, спросить коллегу, а затем обратиться к наставнику или более старшему разработчику. Я определенно вижу важность этого правила после моего пребывания в The Iron Yard. Я мог бы избежать многих часов разочарования, просто спросив заранее.
  3. Скажите, что вам нужно. Важной частью этого совета является демонстрация компетентности, для чего иногда достаточно просто сказать: "Что вы думаете?" вместо "Ну... мне трудно это понять... я просто не понимаю". не понял… Что ты думаешь? Заблаговременное объяснение того, что нужно учащемуся, является важным шагом в том, чтобы убедиться, что его/ее наставник точно понимает, с чего начать. Честно говоря о потребностях, вы сможете избежать неловких исправлений или пространных ответов там, где это не нужно.
  4. Расскажите, что вы сделали. По словам Лаунди, самая важная часть разговора состоит из этого совета: используйте правило 30 %. Если вы обратитесь за помощью на 30-процентной стадии завершения проекта, это будет лучшим советом. На 30% программисты конкретизируют большую часть своей архитектуры для проекта, имея ровно столько проектов, что он/она все еще может внести существенные изменения, если это необходимо. На отметке 90% все, что действительно может сделать наставник, — это исправить некоторые опечатки. Отметка 30% — это разница между использованием разметки для белой доски и разметкой PDF с идеальной точностью до пикселя: тип обратной связи резко меняется от общих предложений до сосредоточения на мельчайших деталях.
  5. Скажите ему/ей это в ответ. Этот совет может помочь превратить потенциально длинный совет в краткий звуковой фрагмент, который наставник сможет подтвердить. В большинстве случаев резюме будет правильным, и каждый сможет вернуться к работе. В меньшинстве случаев это краткое изложение предотвратит опасную уверенность учащегося в неправильном направлении. Любое суждение, которого учащийся опасается за неправильное обобщение, определенно будет лучше, чем последующее разочарование как для учащегося, так и для наставника, если учащийся попытается реализовать это неправильное понимание в своем коде.

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