[Перевод] 6 правил, которые пригодились бы мне, когда я осваивал программирование
Как вы думаете, что такое программирование?
Написание кода?
Написание хорошего кода?
Нет.
Это только часть истины.
Программирование — это не про кодинг. Программирование — это о решении задач при помощи кодинга.
Конечного пользователя не волнуют используемые вами технологии, языки, фреймворки и методологии. Их беспокоит только одно: решает ли ваш продукт их задачу.
Именно поэтому никого не волнуют внутренние технологии, используемые в поиске Google. Пока люди могут находить с его помощью нужную информацию, они будут им пользоваться.
Это самое важное, что я бы хотел знать, когда учился программированию.
Тогда бы я меньше тратил времени на написание «лучшего кода» и больше времени — на оптимальное решение задач клиента.
Не пишите код просто для того, чтобы написать код — решайте задачи клиента при помощи кода.
Когда я только начал свою карьеру, недостаток социальных навыков не был моей основной проблемой. Но когда меня начали повышать до мидла, сениора и руководителя, мои слабые социальные навыки стали моей ахиллесовой пятой.
Когда вы работаете над продуктом с группой других людей (инженеров, дизайнеров. менеджеров), общение — это единственное, что делает вас «командой» и позволяет эффективно разрабатывать продукт.
Нехватка социальных навыков приводит к противоположному — увеличивает время разработки продукта и снижает общую производительность.
Вот реальная ситуация, с которой вы можете столкнуться:
Начальство сообщает вашему продакт-менеджеру, что хочет создать новую фичу продукта и выпустить её в следующем релизе. Она не срочная, они просто хотят выпустить её как можно быстрее (обычное дело).
Продакт-менеджер звонит вам в Zoom, сообщает, что вам нужно создать, и спрашивает: «Сколько времени вам на это понадобится?»
Вы производите примерные вычисления и говорите: «Мне нужно двадцать часов».
Продакт-менеджер недоволен вашим ответом. Он хочет выпустить фичу как можно быстрее и показать руководству, что способен быстро выдавать результат (очень распространённая ситуация).
Поэтому он спрашивает: «Справитесь за десять часов? Нам очень нужна эта фича к следующему релизу продукта!»
А вы знаете, что если начнёте срезать углы (откажетесь от тестов, будете писать неопрятный код), то вам придётся рефакторить работу, что займёт дополнительных тридцать часов, потому что после релиза с вашим запутанным кодом придётся работать другим инженерам. А после рефакторинга вам придётся интегрировать их код с вашим.
И вот что произойдёт дальше. Если вы обладаете плохими социальными навыками, то не сможете убедить продакт-менеджера в необходимости двадцати часов для создания этой фичи.
Почему?
Продакт-менеджеры часто имеют хорошие социальные навыки — говорю по своему опыту. Поэтому если вы не сможете убедить его, что рефакторинг позже хуже, чем потратить двадцать часов сейчас, то они легко возразят вам и убедят в том, что «рефакторить потом — это нормально». И вся команда потеряет дополнительно тридцать часов на этот рефакторинг (и я ещё не считаю время на устранение непредсказуемых багов после).
Но если вы имеете хорошие навыки общения, то вы сможете убедить менеджера в обратном.
Поэтому совершенствуйте свои социальные навыки наряду с навыками кодинга.
И не забывайте одну простую истину:
Люди работают с людьми, не с машинами.
Четыре года я ощущал себя уставшим после работы. Почему-то я мог продуктивно работать всего пару часов. После этого у меня оставалось очень мало энергии. Так продолжалось, пока я не узнал о технике «помодоро».
Она довольно проста. Вы работаете по 25 минут и делаете перерыв на пять минут.
Процесс работы становится таким:
8:00–8:25 — работа
8:25–8:30 — перерыв
8:30–8:55 — работа
8:55–9:00 — перерыв
…
Я попробовал поработать так в течение недели и был удивлён, насколько сосредоточенным, энергичным и продуктивным я стал.
Потом я пошёл дальше и реализовал свою систему 52+17, после чего мой уровень продуктивности увеличился на 200%.
Поэтому делайте регулярные перерывы, если хотите работать максимальной продуктивностью.
В начале своей карьеры я думал, что отличный программист — это человек, знающий десятки языков программирования, фреймворков и методологий.
Я ошибался.
Такое мировоззрение только стало причиной зарождения моего синдрома самозванца. Я думал, что не достоин своей нынешней должности, своей зарплаты, и что я «мошенник». Поэтому я подписался на всех популярных разработчиков в Twitter, читал все технические новости и тысячи блогов разработчиков, чтобы убедить себя, что заслуживаю того, что имею, и чтобы стать ближе к званию «отличного разработчика».
Но это нездоровое поведение.
Однако оно помогло мне понять, что многие люди, на которых я подписался (и считал их 10X-инженерами) на самом деле знают не очень многое. Они могут знать, как выполнять сложные задачи, требующие глубоких знаний в паре областей, но в то же время не знают примитивных вещей. Например, они знают, как проектировать хорошо масштабируемые архитектуры баз данных, но не знают как выровнять элемент по вертикали при помощи CSS.
Я благодарю этих разработчиков, в частности Дэна Абрамова (создателя Redux), который написал эту статью. Они излечили меня от синдрома самозванца и показали, что не знать чего-то вполне нормально.
Когда я начинал изучать JavaScript, это было сложно. Потому что учился я неправильно.
Я читал много теории без практики, без режима и конечной цели. Хаос. Я думал, что учиться так нормально. Но потом я узнал о deliberate practice. Это целенаправленный и систематический тип практики (обучения). Разница между обычной практикой и deliberate practice в том, что для последней требуется сосредоточенное внимание и она выполняется с конкретной целью — повышения показателей.
Применив deliberate practice, я начал замечать, насколько я быстро прогрессирую в изучении JavaScript. Мои знания оставались со мной дольше, а не на пять минут после завершения туториалов. Я выбрал конечную цель изучения JavaScript и начал понимать, что мне нужно учить, а что не нужно.
Вот что нужно, чтобы применять deliberate practice:
- Преподаватель: предоставляет практические задачи, позволяющие вам совершенствовать показатели.
- Работать с максимальными усилиями: постоянно находиться вне зоны комфорта.
- Чётко определить конкретные цели: не просто «общее совершенствование».
- Быть в фокусе: уделять всё своё внимание, ни на что не отвлекаться.
- Выполнять осознанные действия: никакого автопилота.
- Мгновенная реакция на обратную связь и изменение своей стратегии.
Когда вы начинаете изучать новый язык, технологию, фреймворк и так далее, придерживайтесь этих правил, чтобы максимально быстро добиться серьёзных результатов.
В мире нет чего-то «наилучшего». Есть только лучшее в какой-то области.
Например, возьмём автомобили. Как выбрать лучшую машину в мире? По скорости? По безопасности? По каким критериям? Это невозможно. Мы можем выбрать только лучший автомобиль в какой-то категории. Например, самый безопасный. Или лучший на бездорожье. И если приглядеться, каждая категория решает определённые задачи.
То же самое и с языками программирования. Некоторые языки и инструменты лучше решают одни задачи, чем другие. Если мы хотим создать интерактивный веб-сайт, то выберем JavaScript. Если хотим заняться машинным обучением или искусственным интеллектом, то выберем Python.
Помните, нет лучшего языка программирования, есть «лучший язык для…»
Поэтому начинайте с задачи и подбирайте язык для её решения.
