Перевод публикуется с сокращениями, автор оригинальной статьи Pen
Magnet.
Если вы хорошо разбираетесь в программировании, то сможете произвести необходимое впечатление на людей, и ваш карьерный график наверняка будет замечательным.
Однако давно известно, что большинство знаний и навыков нужно впитывать в медленном темпе т. к. их постижение может даваться сложно. Когда вы овладеваете ими, в вашей жизни происходят радикальные позитивные изменения, а ваше место в команде не подвергается критике и сомнениям.
Посмотрим на следующую диаграмму:
Мы говорим о зеленом графике.
1. Возня с игрушками
Какое отношение игрушки (гаджеты) имеют к программированию?
Когда мне было 8 лет, я сломал свои цифровые часы, чтобы понять, как работает контроль времени. Мне потребовалось 2 дня, чтобы собрать все заново. После всех мучений я не смог понять, какова связь между микросхемой и цифрами на LCD-панели.
Непростые пути привели меня к изучению электроники, что в конечном итоге дало возможность сделать карьеру программиста. Начав с фирмы по обслуживанию ПО, я быстро перешел в продуктовые и спустя 20 лет я все еще программист.
Почти каждый успешный технический предприниматель в детстве постоянно возился с различными игрушками.
В этом занятии есть три важных момента:
- Это не должно быть сложно (нужно найти время, желание и т. д.).
- Это должно быть добровольным (не запихивайте своих детей в школы программирования). Хотя можно создать среду и направить их.
- Самое важное – это настойчивость. Сломайте все, и не сдавайтесь, пока не почините. Настойчивость подпитывает длительное желание решать проблемы. Это чувство – именно то, что поможет выжить в безжалостной индустрии ПО.
Если вы никогда раньше не создавали гаджеты, попробуйте посетить хакатон. Не чувствуйте себя там странным. Если стесняетесь, закажите домой Arduino и соберите что-нибудь. Выберите себе компанию, которая захочет следовать с вами по этому пути (например, ребенок).
2. Бросать вызов самому себе
Чтобы создание гаджетов могло повышать настойчивость, вам необходимо постоянно прокачивать этот скилл. Постоянный вызов делает все за вас.
Бросить вызов самому себе, значит сделать шаг вперед в решении сложных задач. Бросать вызов не значит, что необходимо постоянно решать алгоритмические головоломки, хотя это один из способов. Я обычно советую воздерживаться от напряженного конкурентного программирования, но если алгоритмы – ваше истинное призвание, попробуйте MAAMG. Такие задачи чрезвычайно полезны для геймификации вашего развития.
Допустим, вы написали функцию, которая считывает набор переменных из конфига. Реализация будет включать жестко заданное имя файла (например, «myfile.config»). Ее интерфейс выглядит следующим образом:
func readParams()
Чтобы испытать себя, после написания этой функции настройте ее так, чтобы она принимала имя файла (с аргументом по умолчанию, который является именем файла).
func readParams(filename: String="myfile.config")
Только подумайте, сколько возможностей откроет это небольшое изменение:
- Разработчик вашего клиента или конечный пользователь могут изменить параметры конфигурации в рантайме, а вам придется перезагрузить исполняемый код. Поэтому необходимо оптимизировать этот код и инкапсулировать его в функцию initialize(), которая вызывается в начале + при каждом изменении файла конфига.
- Предполагая, что файл имеет связь с пользователем, существует возможность поддержки нескольких пользователей с одной и той же установкой приложения.
3. Грамматика
В течение многих лет эксперты твердили: правое и левое полушария мозга контролируют различные функции. Одна из них делает вас лучше в математике, а другая – в искусстве и языке.
Если вы хорошо разбираетесь в грамматике любого языка (особенно английского), вы быстрее поймете что к чему. Вы сможете понимать код из интерфейсов иногда даже без необходимости в документации. Такие вещи, как isFinishedиwillRefresh, говорят сами за себя.
Присвоение имен переменным и функциям является священным для создания высококачественного ПО. Почти все софтверные компании неукоснительно следуют соглашениям об именовании именно по этой причине, и эксперты по грамматике получают от этого существенную выгоду.
Забагованный код с совершенной грамматикой раскрывает свои ошибки быстрее, чем идеальный код с плохой грамматикой. Задумайтесь, и вы поймете, почему ваша команда не может двигаться быстрее даже с более чем достаточным количеством хороших разработчиков.
Почему мы ставим словарный запас на второе место по сравнению с грамматикой? Потому что грамматика – это не что иное, как оперирующие словами правила. Каждый компилятор тоже является грамматикой. Обладая основными знаниями (времена, глаголы и т. д.), вы легко сможете найти более эффективные синонимы/подходящие слова. Обратное невозможно.
4. Презентация
Когда дело доходит до работы, программисты практически не общаются. Они либо общаются на непонятном для других техническом жаргоне, либо просто пишут код.
Представьте себе сценарий входа в систему, объясненный 2 программистами:
Программист A:
Пользователь приходит на
экран авторизации, вводит имя пользователя/пароль и нажимает кнопку входа. Если
он вводит символы #, & или *, вход отклоняется, и пользователь остается на
той же странице. Если все хорошо, генерируется запрос к API. Пароль должен
быть хэширован, т. к. API сопоставляет хэш пароля с хэшем, хранимым в БД. Эта
проверка не должна происходить, если имя пользователя не совпадает. Когда совпадают
оба введенных параметра, возвращается код 200 и пользователь перенаправляется
на страницу профиля, а если нет – 401. В случае успеха выдается токен,
который действителен в течение 2 недель.
Программист Б:
- У нас есть два процесса: внешний код и внутренний API (рисуем два квадрата).
- Оба общаются через HTTP-запрос (соединяем их стрелками).
- Фронтенд принимает вводимые пользователем данные и проверяет их.
- Бекенд должен проверять наличие пользователя в БД и правильность хэша пароля.
- И здесь начинается важная часть: если ответ будет успешным, фронт получит токен от серверной части, который будет хранить 2 недели. Пока он действителен, пользователь может сразу попадать на страницу профиля. Эта логика проверки токенов предшествует странице авторизации.
- Вы можете посмотреть подробности API в документе, который я отправил всем/загрузил в облако.
(на этом этапе, возможно, на доске/блокноте много стрелок, и каждая стрелка помечена порядковым номером)
В большинстве своем программисты не собраны. Они не могут долго заниматься одной задачей. В спешке с доставкой они в конечном итоге выражают себя только в коде. Если требуется презентация, они все портят (как программист А выше), и страдает вся команда.
Цель презентации – ясность и простота.
В Amazon это уже осознали
и теперь предпочитают шестистраничную
памятку, а не PPT-файл. Если вы не можете с помощью 6 страниц описать свою
идею, она не заслуживает внимания. Упростите любой ценой!
5. Переключение контекста
Мозг большинства программистов подобен микросервисам. Разберемся на примере.
Монолитный подход:
API: /get/payments
Сначала парсим входные параметры. Если есть ненулевой параметр учетной записи, он будет возвращать только платежи из учетной записи. В противном случае все платежи будут возвращены.
Микросервисный подход:
Микросервис более специфичен и ориентирован на объекты.
Микросервис для учетных записей (/get/payments) будет возвращать платежи только для учетной записи, с которой совершается вход.
Микросервис для платежей (/get/payments) вернет все платежи, произведенные в системе.
Микросервисы знают свою область видимости, которая привносит контекст.
Без надлежащего контекста любая презентация бесполезна. В приведенном ранее примере вспомним программиста Б (который был лучше), описывающего функцию входа в систему. Насколько он был бы уместен со своим пониманием фронтенда и бекенда?
Ваша работа программиста требует только доставки кода.
Я не советую ударяться только в многозадачность, потому что навыки многозадачности убивают сосредоточенность. Что действительно важно, так это определить идеальную реакцию вашего мозга до того, как он обработает входящую информацию – как в описанных выше микросервисах.
У вас должны быть определены категории в мозгу, и каждый раз, при появлении вопроса, вы должны решить, к какой категории он относится: бизнес, технологии, клиент, касается ли это вашей команды и т. д.
- Решите, нужно ли вам срочно отвечать на этот вопрос.
- Если да, уточните его категорию, прежде чем формулировать свой ответ.
- Все несрочные дела могут подождать.
- Для повторяющихся задач вы можете кэшировать свои ответы, как это делает ваш софт.
- Чаще всего ваш код является вашим главным приоритетом. Не тратьте сосредоточенность впустую. Сведите к минимуму время отвлечения внимания, используя переключение контекста.
Заключение
Естественно, речь здесь не идет о продуктивном программировании.
С другой стороны находятся обучающие программисты, которые думают о программировании как о чем-то продуктивном: больше кода и больше тикетов за меньшее время.
Истина лежит где-то посередине.
Естественно, что понимание и развитие навыков предшествует процессу кодинга. А еще вам придется потерпеть неудачу не один раз. Применение этих 5 навыков в реальном мире может сделать из вас востребованного программиста. Это может занять время, но, когда вы увидите результат, это заставит вас расти в геометрической прогрессии.
Дополнительный материал:
- Программирование с пассивным доходом: 5 способов для разработчиков ПО
- Функциональное программирование: рефакторинг, замыкания и функции высшего порядка
- Программирование на Go с нуля: 9 полезных видеоуроков
- Как превратить программирование в профессиональное ремесло за 8 простых шагов
- Асинхронное программирование: концепция, реализация, примеры
Комментарии