«Наша способность извлечь максимальную пользу из неопределенности — это то, что создает наибольшую потенциальную ценность».
Эта цитата автора Озана Варола из его книги Думай как ученый-ракетчик: простые стратегии, которые можно использовать для гигантских скачков в работе и жизни в последнее время не дает мне покоя.
Я приближаюсь к концу своего первого года работы профессиональным инженером-программистом. Естественно, я размышлял о своем пути к этому моменту. В частности, я размышлял о роли, которую принятие неопределенности сыграло для меня после того, как я бросил два высших образования и 7-летнюю карьеру общественного педагога почти 3 года назад.
В то время у меня не было наставников по программированию или кого-либо из знакомых, которые могли бы хотя бы дать представление о том, на что будет похожа карьера инженера-программиста, или как добиться успеха, если мне удастся войти в дверь. Другими словами, я был окружен неопределенностью.
К счастью, у меня были решимость, стремление к обучению, управляемые отношения с неопределенностью, несколько счастливых моментов и чрезвычайно поддерживающая жена и дети.
Итак, какие уроки, не зависящие от языка, я извлек за первый год работы разработчиком программного обеспечения, которые могли бы помочь другим справиться с их собственной неуверенностью в программировании как карьере или хобби?
- Сосредоточьтесь на том, чтобы каждый день совершенствоваться понемногу. Просто, верно? Не сначала. Каждый раз, когда мы начинаем новое занятие, крутизна кривой обучения может стать ошеломляющей. Соедините это с нашей естественной склонностью сравнивать себя с окружающими, и иногда может показаться, что мы никогда не «поймем это». Возможно, вы слышали об этом чувстве как о синдроме самозванца. Вместо того чтобы сосредотачиваться на том, чтобы получить это, что бы это ни было, это, сосредоточьтесь на том, чтобы каждый день получать что-то новое, чего вы не знали раньше. Иногда это может быть большим открытием. Чаще это будет что-то небольшое, но фундаментальное. Несмотря на это, наше обучение со временем накапливается и продолжает экспоненциально расти, если мы уделяем ему внимание с самого начала.
- Имейте смелость браться за проекты или задания без четкого плана действий. В начале этого года мне предложили проект по созданию функции во внутреннем инструменте, о котором а) я понятия не имел как даже начать думать о том, и б) уже было сделано в моей компании раньше. Моя первоначальная реакция состояла в том, чтобы предположить, что я не готов к такой ответственности и что, возможно, кто-то другой будет более квалифицированным, чтобы взять на себя это задание. К счастью, моя совесть прервала меня, напомнив, что у меня никогда не будет необходимого опыта для подобного проекта, если я никогда не попытаюсь взяться за такой проект. Итак, я начал с того, что знал, и работал, чтобы со временем заполнить пробелы (подробнее об этом в моем четвертом пункте ниже), в конечном итоге доведя этот проект до финишной черты и укрепив свою уверенность в будущем.
- Читайте код вслух и записывайте, что происходит, с помощью бумаги и карандаша, если это необходимо. Этот пункт оказался решающим для включения двух вышеперечисленных пунктов. Из опыта я понял, что можно просто смотреть на блок кода и спокойно обдумывать его. Но смотреть на этот блок кода, объяснять его вслух моей собаке и даже писать на простом английском языке на листе бумаги работает еще лучше. Я полагаю, что где-то в Интернете этому есть научное объяснение. Возможно, это избавляет мозг от перегрузки, или то, что повторение ваших мыслей помогает прояснить проблему. Как бы то ни было, самыми важными данными, с которыми я столкнулся, было то, сколько раз я ловил себя на том, что говорю: «О, подождите минутку. . ». когда я читаю код вслух, а не думаю об этом в своей голове.
- Напишите, отдохните, рефакторинг. В начале этого первого года я был просто доволен созданием работающего программного обеспечения. Для меня не имело значения, как я туда попал. Если он не был сломан, то и чинить его было не нужно. Однако со временем и скромным опытом пришло новое понимание шаблонов проектирования, высушивание моего кода, обеспечение удобочитаемости для людей и желание быть не просто программистом, а хорошим программистом. В результате теперь я использую то, что я называю «написать, отдохнуть, рефакторить». Будь то меньший метод или более крупный класс (я программирую на Ruby on Rails), я работаю над тем, чтобы получить работающее решение любыми необходимыми средствами. Затем я отхожу от компьютера и либо прогуливаюсь, либо перекусываю, либо просто делаю дыхательные упражнения. Все, что может изменить контекст, подойдет. По возвращении я бросаю себе вызов пройтись по своему коду, прочитать его вслух и найти способы его улучшения, такие как устранение дублирования, улучшение имен переменных, извлечение частей кода в повторно используемые помощники, удаление строк, которые, как я теперь понимаю, не нужны. , и больше. Эта практика не только улучшила качество написания моего кода, но и повысила мои представления о качестве кода.
- Выполните домашнее задание, прежде чем просить о помощи. Кто-то может сказать, что грубо беспокоить кого-то другого с просьбой о помощи, если вы сами не приложили особых усилий. В некоторых случаях это правда. Но это не то, что я хочу сделать здесь. Скорее, когда вы сталкиваетесь с новой концепцией или вызовом, уделите время тому, чтобы выяснить, что вы можете, и определить, что вы не понимаете, и это подготовит вас к тому, чтобы обратиться за помощью, которая вам действительно нужна, и потенциально позволит вам соединить точки в одном вопросе. твой собственный. Например, вместо того, чтобы говорить: «Эй, мне нужно сделать X, и я понятия не имею, как это сделать, не могли бы вы мне помочь?», подготовьтесь к разговору, чтобы сказать что-то вроде: «Эй, мне нужно сделать X. Я видел что-то похожее, используемое в Y. Я погуглил и узнал о Z, но я не уверен, что полностью его понимаю. Я пробовал A, B и C, чтобы проверить это, и теперь я застрял. Не могли бы вы взглянуть на мой код, чтобы убедиться, что я правильно использую Z?» Этот тип просьбы о помощи часто приводит не только к решению, но и к более ценному, богатому разговору, который неизбежно улучшит ваше критическое мышление и понимание программного обеспечения, которое вы пишете.
Надеюсь, эти несколько уроков, которые я извлек из собственного опыта, максимально используя неопределенный путь к новой карьере, помогут вам сделать то же самое. Мне также очень интересно узнать, какие идеи вы получаете благодаря своему опыту. Они также помогли бы мне стать лучшим программистом. В конце концов, когда мы принимаем неопределенность, мы узнаем, «что создает наибольшую потенциальную ценность».