5 сложных навыков, которые окупаются в программировании

Навык 1. Баловаться с игрушками

Как тут оказались игрушки? Когда мне было восемь, я разломал свои цифровые часы за доллар и посмотрел, как они работают. У меня ушло два дня, чтобы починить их. Но даже после этого я не мог понять связь между их электронной схемой и цифрами на LCD панели.

Так во мне появилось любопытство — и я подписался на все журналы по электротехнике. Когда я стал разработчиком, этот интерес облегчил мне понимание интерфейсов и архитектуры. При этом мой путь в IT начался именно с интереса к электронике. Даже первая моя работа была в сервисе по ремонту техники, хотя я не надолго там задержался — в итоге я перешел в разработку и занимаюсь этим уже 12 лет.

Я бы получал меньше удовольствия от разработки, если бы тогда, в детстве, не проводил бы столько времени, экспериментируя с простым механизмами. Я привык к тому, что одно неверное движение грозит поломкой всей схемы, и это бесстрашие помогает мне в работе инженером.

При этом не я один заинтересовался программированием благодаря баловству с игрушками. Илон Маск, Джефф Безос, Ларри Пейдж и Стив Джобс тоже разбирали и собирали обратно разные механизмы, когда были детьми.

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

• Механизм должен быть самым простым
• Ваш интерес должен быть естественным
• У вас есть детское любопытство к вещам, которые вы не понимаете

Последний пункт, пожалуй, самый важный. Подход «Сломай что-нибудь, а потом почини» делает из вас творцов и учит решать проблемы. Только такое отношение позволит выжить в диких условиях нашей индустрии.

Навык 2. Бросать себе вызов

Электротехника разовьет в вас усидчивость, но я предлагаю пойти еще дальше. Привыкайте бросать себе вызовы, это позволит обрести то, что люди называют талантом.

Вызов — это не просто задачки на знание алгоритмов, хотя конечно их тоже бывает нелегко решать. Делать упор на решение задач по алгоритмам — это просто непрактично. Если вам все же очень нравятся такие задачи, то вас ожидает прямая дорога в компании FAAMG+.

Еще к вызовам не относится исправление проблем. Вызов — это проактивность, то есть эта история скорее про инициативу, а не про исправление своих же косяков и проблем. Инициатива — это когда вы делаете шаг вперед и берете на себя ответственность даже тогда, когда никто этого не просил.

Вот практический пример. Допустим, вы написали функцию, которая читает переменные из файла конфигурации. Файл конфигурации известен заранее и не будет меняться, он называется myfile.config. Поэтому мы укажем имя файла в теле кода (это называется хардкод, то есть код, завязанный на конкретные данные). Вот как будет выглядеть интерфейс такой функции: func readParams()

Как бросить себе вызов? Ну, вы могли бы изменить функцию так, чтобы она могла принимать первым параметром имя файла конфигурации. Код было бы проще читать и менять. Мы можем просто указать имя myfile.config как значение по умолчанию.

func readParams(filename: String="myfile.config")

Вот сколько всего надо учесть после этой маленькой перемены:

• Во время жизни программы конечный пользователь или клиентский программист могут изменить файл конфигурации. Это приведет к перезагрузке исполняемого кода. Так что надо оптимизировать код так, чтобы файл конфигурации действительно можно было менять. Например, реализовать инкапсуляцию.
• Если исходить из предположения, что файл конфигурации относится к пользователю, то возникает вероятность того, что пользователей у нас несколько, но устанавливают они одно и то же приложение.
• И не забываем про функцию экспорта export(). Она экспортирует на диск, сеть, на сторонний сервис обмена сообщениями (на почту, например). Можно импортировать функцию так: readParams(). Тогда приложение становится переносимым (portable) между машинами. Переносимость = Выше ценностное предложение (value proposition) = Бóльшая, более надежная клиентская база.

Если вы не приняли этот вызов и написали код как в первом варианте — никто вас за это не съест. И новые баги из-за этого тоже не появится. Но представьте ситуацию: пользователям очень понравилось такое приложение, они поставили пробной версии пять звезд и жаждут продолжения. Но если не добавить функционал из второго варианта, то они вряд ли купят полную версию.

Принять вызов — это значит быть амбициозным, вне зависимости от того, о какой отрасли идет речь. Амбициозный программист бросает себе вызов вместо того, чтобы устраивать офисные игры в борьбе за красивую должность. Недаром многие компании обязаны своим успехом именно главному инженеру (технический директор, англ. CTO), а не кому-то с должностью покруче.

Навык 3. Быть грамотным

Годами эксперты говорили: правая и левая лобные доли отвечают за разные функции. Одна половина мозга для точных наук, другая — для гуманитарных. Но сейчас нам известно, что это не так. Да это и не важно, а важно вот что: если вы не знаете грамматику, вы не можете программировать. И я не про словарный запас говорю, а именно про грамматику.

Если вы хорошо понимаете правила грамматики (особенно английской), то вам легче распознавать повторяющиеся паттерны. Благодаря этому работа со старым кодом или новыми фреймфорками становится проще пареной репы. Вы можете понять, что делает код, просто взглянув на интерфейс, и даже документацию открывать не надо. Функции типа isFinished или willRefresh станут понятны благодаря одному своему названию.

Хорошее знание грамматики — это не только бонус к продуктивности, но также и гарантия того, что ваш код будет читабельным. А еще грамматика позволяет программисту писать отличные спецификации и точно описывать баги. Все это экономит на ревью огромное количество времени.

Забагованный код с превосходной грамматикой будет понятнее, чем рабочий код с плохой грамматикой. Так что понятно, почему некоторые команды работают очень медленно, хотя разработчики в них сильные.

Навык 4. Уметь публично рассказывать о своей работе

Когда дело касается процесса работы, то программисты общаются не очень то много — либо обмениваются хардовыми терминами, либо молча пишут код.

Программирование стоит на стыке бизнеса и технологий. А программист — это все же источник технических знаний, знания о бизнесе он получает от других. При этом бизнес и технологии пересекаются в одной точке, и эта точка — презентации, где разные стороны рассказывают про свои аспекты работы.

Часто программисты не умеют рассказывать о себе и своей работе. Вот пример из реального опыта — в нем обсуждаются сценарии входа пользователя на сайт по логину. Я перескажу два сценария, которые описывали разные программисты:

Программист А:

Пользователь переходит на страницу входа. Он вводит логин и пароль, нажимает кнопку Войти. Если он введет символы #, & или *, то произойдет ошибка входа. Пользователь останется на этой же странице. После этого, если пользователь ввел корректные данные, то фронтенд-часть отправит API-запрос. Еще раз, пароль должен быть хэширован. Потом API сравнивает хэш пароля с тем, что есть в БД. Если имя пользователя не найдено в базе, то пароль проверяться не будет, поэтому сначала проверяется имя пользователя. А если и то, и другое совпадают, то код удовлетворения запроса возвращается из фронтенда. Если нет, то возвращается ошибка 401. Если вернулось одобрение, то пользователя перенаправляют на страницу с профилем. А еще запрошен токен и он будет валиден две недели.

Программист Б:

(После каждого пункта выступающий делает паузу. Там, где текст выделен жирным, он делает акцент при помощи тона голоса):

• У нас есть два процесса. Первый — это фронтенд, второй — это бэкенд и API (рисует на доске два квадрата)
• Оба общаются через запрос по сети HTTP (соединил квадраты стрелочками)
• Фронтенд-часть должна принять данные от пользователя и проверить, валидны ли они
• Бэкенд-часть должна проверить, совпадают ли данные от пользователя с данными в базе данных. Она проверяет, верен ли хэш пароля
• И самое главное: Если ответ от бэкенда положительный, фронтенд получает токен, который действителен две недели. В течение этого срока пользователь сразу будет перенаправляться на страницу профиля. Логика проверки токена, очевидно, запускается до логики страницы входа
• Вы можете посмотреть подробности запроса к API в документе, который я уже всем разослал/залил на облако.

(в этот момент на доске множество стрелочек, и каждая стрелочка пронумерована)

Чья презентация более успешна? Программист А может на 100% понимать, что происходит в коде, но ему определенно не удалось донести идею. Слушатели замучаются слушать его путанную речь и лишние подробности (например, про коды статуса HTTP). Программист Б — захватил и удержал внимание аудитории, а для любопытных составил документ с подробностями.

Большинство программистов идут по пути первого нашего разработчика — они не умеют красиво и подробно рассказывать о своих рабочих процессах. При этом презентация — очень важный навык, без которого невозможно профессионально расти.