[Перевод] 6 правил, которые пригодились бы мне, когда я осваивал программирование

9b498e7825e4f82ae5b7af6bcfd73db3


Как вы думаете, что такое программирование?

Написание кода?

Написание хорошего кода?

Нет.

Это только часть истины.

Программирование — это не про кодинг. Программирование — это о решении задач при помощи кодинга.

Конечного пользователя не волнуют используемые вами технологии, языки, фреймворки и методологии. Их беспокоит только одно: решает ли ваш продукт их задачу.

Именно поэтому никого не волнуют внутренние технологии, используемые в поиске 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:

  1. Преподаватель: предоставляет практические задачи, позволяющие вам совершенствовать показатели.
  2. Работать с максимальными усилиями: постоянно находиться вне зоны комфорта.
  3. Чётко определить конкретные цели: не просто «общее совершенствование».
  4. Быть в фокусе: уделять всё своё внимание, ни на что не отвлекаться.
  5. Выполнять осознанные действия: никакого автопилота.
  6. Мгновенная реакция на обратную связь и изменение своей стратегии.


Когда вы начинаете изучать новый язык, технологию, фреймворк и так далее, придерживайтесь этих правил, чтобы максимально быстро добиться серьёзных результатов.
В мире нет чего-то «наилучшего». Есть только лучшее в какой-то области.

Например, возьмём автомобили. Как выбрать лучшую машину в мире? По скорости? По безопасности? По каким критериям? Это невозможно. Мы можем выбрать только лучший автомобиль в какой-то категории. Например, самый безопасный. Или лучший на бездорожье. И если приглядеться, каждая категория решает определённые задачи.

То же самое и с языками программирования. Некоторые языки и инструменты лучше решают одни задачи, чем другие. Если мы хотим создать интерактивный веб-сайт, то выберем JavaScript. Если хотим заняться машинным обучением или искусственным интеллектом, то выберем Python.

Помните, нет лучшего языка программирования, есть «лучший язык для…»

Поэтому начинайте с задачи и подбирайте язык для её решения.

© Habrahabr.ru