Если вы хорошо разбираетесь в коде и продуктивно программируете — отлично! Вы можете произвести впечатление на людей в кратчайшие сроки. Ваша карьера будет замечательной.
Но вековая мудрость гласит, что в жизни есть вещи, к которым нужно идти медленно. Их может быть трудно понять.
Но когда вы овладеете ими, вы займете позицию, которую никто не сможет отнять. Когда все сделано правильно, такие вещи могут кардинально изменить вашу жизнь к лучшему.
Взгляните на следующую диаграмму:
Речь идет о зеленой линии.
Я описываю 5 вещей, которые могут привести к экспоненциальному росту вашей карьеры программиста.
№1: Возиться с игрушками
Какое отношение игрушки (аппаратные гаджеты) имеют к программированию?
Когда мне было 8 лет, я сломал свои цифровые часы (ценой меньше 1 доллара), чтобы посмотреть, как работает время. На сборку у меня ушло 2 дня. И все же я не мог понять связь между схемой и цифрами на ЖК-панели.
Это заставило меня погрузиться в журналы со схемотехникой. Это чтение, в свою очередь, заставило меня понять более важные концепции интерфейса и архитектуры в инженерии.
Этот путь привел меня к изучению электроники, что в конечном итоге и дало старт моей карьеры в программировании. Начав с фирмы по обслуживанию программного обеспечения, я быстро перешел в продуктовые компании. Спустя 20 лет я все еще программист.
Если бы меня в то время не интересовали цифровые устройства, я бы не полюбил программирование в достаточной степени. Я бы стал бояться отказов, которые происходят на каждом этапе неправильного подключения деталей машин.
Я бы превратился в презренного менеджера (которыми стали многие мои друзья).
Может быть, я все еще развиваюсь. Но подумайте вот о чем — почти каждый успешный технический предприниматель сегодня (Илон Маск, Джефф Безос, Ларри Пейдж, Стив Джобс и т.д.) бесконечно разбирался с игрушками в детстве.
Три замечательных момента в этом занятии:
- Это не должно быть сложно.
- Это должно быть добровольным (так что пока не водите своих детей в школы программирования.) Хотя можно создать среду, которая будет подпитывать это желание, или переместиться в нее.
- Самое главное: это должно быть постоянным. Сломайте что-нибудь и не останавливайтесь, пока не почините. Настойчивость подпитывает давний голод к решению проблем и созиданию. Этот голод — ваш самый важный актив в выживании в безжалостной индустрии программного обеспечения.
Если вы никогда раньше не создавали гаджеты, попробуйте посетить хакатон по разработке гаджетов. Не чувствуйте, будто вас судят. Если вам неудобно, закажите на дом Arduino и сделайте умный дом. Выберите кого-то, кто готов составить вам компанию (желательно ребенка).
№ 2: Бросить вызов самому себе
Если создание гаджетов может сформировать постоянство, вам также нужно использовать это достоинство. Постоянное соревнование с самим собой сделает это за вас.
Бросить вызов самому себе не означает решать проблемы программирования (алгоритмические головоломки), но это один из способов сделать это. Хотя я обычно советую избегать напряженного соревновательного программирования, если алгоритмы — ваше истинное призвание, то стремление к FAAMG+ будет только полезным. Эти задачи чрезвычайно полезны для геймификации вашего путешествия.
Бросить вызов самому себе — тоже не то же самое, что и устранять неполадки. Потому что, когда вы устраняете неисправность, проблема уже присутствует. Бросить вызов самому себе — это упреждающий шаг.
Бросить вызов самому себе — это сделать шаг вперед в преодолении сложностей без лишних разговоров.
Допустим, вы написали функцию, которая считывает набор переменных из предварительно определенного файла конфигурации. Реализация будет включать жестко запрограммированное имя файла (например, «myfile.config»). Его интерфейс выглядит следующим образом:
func readParams()
Чтобы испытать себя, вскоре после того, как вы напишете эту функцию, вы можете параметризовать ее, чтобы она принимала имя файла конфигурации (с аргументом по умолчанию, который является жестко заданным именем файла).
func readParams(filename: String="myfile.config")
Подумайте, сколько возможностей открывает это небольшое изменение:
- Разработчик или конечный пользователь может изменить параметры конфигурации во время выполнения. В результате вам будет необходимо изменить исполняемый код. Поэтому вы должны оптимизировать этот код и инкапсулировать его в функцию initialize(), которая вызывается в начале + каждый раз при изменении файла конфигурации.
- Предполагая, что файл конфигурации относится к пользователю, также существует возможность поддержки более чем одного пользователя с одной и той же установкой приложения.
- Вы также можете подумать о создании функции export(), которая экспортирует прочитанные параметры на диск, в сеть, в базу данных или во внешнюю систему обмена сообщениями (электронную почту и т.д.). Вы можете импортировать их в другое место с помощью readParams(). Таким образом, приложение переносится между машинами. Портативность = лучшее ценностное предложение = больше и более устойчивая клиентская база.
Если бы вы не бросили вызов себе и отправили V1 с версией без параметров, никто не стал бы винить вас. Ошибок ведь не возникнет.
Но затем представьте, что пользователям нравится ваш V1, они пользуются бесплатной пробной версией с 5-звездочным рейтингом и хотят большего. Им нужны все вышеперечисленные варианты использования в V2, в противном случае они откажутся от бесплатной пробной версии.
Теперь, когда у вас нога уже просунута в дверь, вернуться будет невозможно. И рефакторинг вызовов readParams() потребует много времени и ошибок. Это означает, что потребуется больше обновлений и больше тестов. V2 может быть полным хаосом.
Бросить вызов самому себе — верное определение амбиций в любой области, а не только в программировании. Амбициозный программист постоянно бросает вызов себе на работе (и в побочных проектах).
Если вы посмотрите на любую успешную компанию, то увидите, что успешные программисты работают в качестве технических соучредителей или технических директоров.
Если вам нужно время, не беспокойтесь. Все учатся в разном темпе. Важно то, что вы делаете малые шаги при вводе каждой строчки.
Прекратите романтизировать парня, который набирает сложный код быстрее вас. Он делает это, потому что делал это раньше, гораздо хуже, и тысячу раз. Вы тоже можете быть таким.
Важно помнить, что это не цель, а побочный эффект соревнования с самим собой.
№3: Грамматика
Да ладно! Мы говорим о программировании, а не о литературе. Вот облом!
В течение многих лет эксперты твердили: правое и левое полушария мозга контролируют разные функции. Один из них делает вас лучше в математике. Другой делает вас хорошими в искусстве и языке.
Сейчас эта теория опровергнута. А может, это все еще обсуждается. Верно это или нет, но вот горькая правда: без изучения языка нельзя программировать. Это не словарный запас. Это грамматика.
Если вы хорошо разбираетесь в грамматике (особенно в английском), вы быстрее найдете шаблоны. Фреймворки и старый код становятся легкой прогулкой. Вы можете понять код из интерфейсов, иногда даже без документации. Такие вещи, как isFinished и willRefresh, сами говорят о своей цели, не углубляясь в детали.
Именование переменных и функций является священным при создании высококачественного программного обеспечения. Практически все крупные компании неукоснительно следуют правилам именования именно по этой причине, и специалисты по грамматике получают от этого существенную пользу.
В информатике есть только две сложные вещи: инвалидация кеша и присвоение имен — Фил Карлтон.
Хорошая грамматика помогает не только понимать огромный код, но и писать легко понятный код. Хорошая грамматика заставляет разработчика писать краткие спецификации и описания ошибок, что приводит к меньшему количеству ошибок.
Ошибочный код с идеальной грамматикой обнаруживает свои ошибки быстрее, чем идеальный код с плохой грамматикой, раскрывающий свою функциональность. Задумайтесь на минутку над этим утверждением, и вы поймете, почему ваша команда не может работать быстрее даже с более чем достаточным количеством хороших разработчиков.
Почему мы ставим лексику на второй план по сравнению с грамматикой? Потому что грамматика — это не что иное, как правила, оперирующие словами. Каждый компилятор тоже грамматик. Зная основные грамматические термины (время, глаголы и т.д.), вы сможете легко найти более эффективные синонимы/подходящие слова. Обратное невозможно.
Так что не ждите. Просто начните. В кратчайшие сроки вы станете самым мудрым и ясным парнем в команде.
№4: Презентация
Когда дело касается работы, программисты практически не общаются. Они либо говорят на тяжелом техническом жаргоне, либо просто пишут код, исходя из своего лучшего понимания.
Код — это продукт двух вещей: бизнеса и технологий. Программист ходит по хранилищу технических знаний. Они учится бизнесу в основном у нетехнических специалистов.
Процесс, который создает код из этих двух ингредиентов, — это презентация. Если вы индивидуальный предприниматель в единственном лице, это может не иметь большого значения (это будет иметь значение, когда сложность возрастет). В общем, если вы хотите умножить свои усилия, используя навыки других программистов, презентация жизненно важна.
Представьте себе сценарий входа в систему, объясненный двумя программистами.
Программист А
Пользователь переходит к экрану входа в систему. Он вводит имя пользователя и пароль и нажимает кнопку «Войти». Если он вводит символы #, & или * в любое поле, ввод отклоняется. Пользователь остается на той же странице. После этого, когда он добивается успеха, интерфейсный код генерирует запрос API. Опять же, пароль необходимо хешировать, не забывайте! Затем API сопоставляет хэш пароля с хешем, хранящимся в БД. И эта проверка не пройдет, если имя пользователя не совпадает, так что это должно произойти в первую очередь! Когда оба совпадают, код 200 возвращается во внешний интерфейс. В противном случае возвращается 401. В случае 200 пользователь перенаправляется на страницу профиля. Также выдается токен со сроком действия 2 недели.
Программист Б
Ниже каждый маркер — это пауза в повествовании, а жирный шрифт — акцент в речи:
- У нас есть два процесса: front end код и back end API. (дополнить рисованием двух квадратов).
- Оба общаются через этот сетевые HTTP-вызовы (соединяет их стрелками).
- Внешний интерфейс должен принимать вводимые пользователем данные и проверять их.
- Серверная часть должна проверять существование пользователя в базе данных и правильность хэша пароля.
- И вот важная часть: если ответ успешен, внешний интерфейс получает токен от серверной части, который хранится до 2 недель. Пока он действителен, пользователь сразу попадает на страницу профиля. Очевидно, что эта логика проверки токенов идет перед front-end страницей входа в систему.
- Вы можете найти подробности API в документе, который я отправил всем/загрузил в облако.
(на этом этапе, возможно, на доске/блокноте есть много стрелок, и каждая стрелка помечена порядковым номером)
Чья презентация будет успешной? Программист А может быть на 100% прав в своем понимании, но ему наверняка не удастся передать идею. В основном коллегам будет скучно из-за его неорганизованного способа представления и ненужных деталей (кодов состояния HTTP).
Программист Б, с другой стороны, будет удерживать внимание своей аудитории, а также побуждать их вникать в детали после презентации.
Если компания решит провести бизнес-саммит, она, скорее всего, будет использовать Программиста Б в качестве главного евангелиста.
Большинство программистов беспокойны. Они не могут долго удерживать внимание на том, что им поручено. В спешке с доставкой они в конечном итоге выражают себя только с помощью кода. Если требуется презентация, они портят ее, как Программист А выше, и страдает вся команда.
Цель презентации — ясность и простота. Простота есть основа утонченности — Джефф Рич.
Amazon уже осознает это. Вот почему в компании предпочитают 6-страничный документ, а не маркированные презентации. Если вы не можете написать 6 страниц, чтобы подчеркнуть свою идею, она не заслуживает того, чтобы ее выслушали. Упростите любой ценой!
Тем не менее, большинство программистов действительно плохо разбираются в презентациях.
Если вы можете упростить свои презентации, вы — редкий зверь.
№5: Переключение контекста
Мозг большинства программистов подобен монолиту. То, что им нужно, похоже на микросервисы.
Разберитесь в разнице на примере.
Монолитный подход:
API: /get/payments
Сначала проанализируйте входные параметры.
Если параметр учетной записи не равен нулю, он вернет только платежи для этой учетной записи. В противном случае все платежи будут возвращены.
Микросервисный подход:
Микросервисы более конкретны и ориентированы на сущности.
Микросервис для учетных записей (/get/accounts) возвращает платежи только для учетной записи.
Микросервис для платежей (/get/payments) вернет все платежи, сделанные в системе.
В чем разница? Часть парсинга — это налог на монолит. Другими словами, микросервис уже знает, что должен делать. Есть и другие преимущества. Счета выставляются только за конкретное использование (стоимость больше инженерная, но в какой-то момент оправдывает вложения).
Микросервисы знают свою сферу деятельности. А сфера деятельности приносит контекст.
Без надлежащего контекста вся презентация бесполезна. В примере, приведенном в №4, представьте, что Программист Б (который был лучше) описывает функцию входа в систему для владельцев бизнеса. Или, что еще хуже, для конечных пользователей, которые не являются техническими специалистами.
Насколько он был бы актуален со всем своим пониманием back-end/front-end?
Может быть, это крайний случай. Но учтите следующее: во времена Agile программисты должны отвечать на вопросы, о которых они мало что знают. Если они не могут переключить контекст, они могут ввести аудиторию в заблуждение.
Или, что еще хуже, предоставить сторонним заинтересованным сторонам больше информации, чем требуется.
Ваша работа программиста требует, чтобы вы только поставляли код. Все остальное — шум.
Я не советую изучать многозадачность, потому что многозадачность убивает фокус. Что необходимо, так это способность определить идеальный ответ вашего мозга до того, как он обработает ввод, как в микросервисах выше.
В вашем мозгу должны быть отделы. Каждый раз, когда вопрос возникает в электронном письме/сообщении Slack/собрании, вы должны решить, к какому разделу он относится. Это из бизнеса? Это из технологий? Это от клиента? Это связано с вашей командой/отделом?
- Решите, нужно ли вам срочно ответить на вопрос.
- Если да, уточните его объем (раздел), прежде чем формулировать свой ответ.
- Все несрочные дела могут подождать времени вашей поездки на работу.
- Для повторяющихся задач вы также можете кэшировать свои ответы, как это делает ваше программное обеспечение. Сведите к минимуму время отклика на вещи, которые вряд ли приведут к увольнению.
- Чаще всего ваш код является вашим главным приоритетом. И именно здесь вам нужно сосредоточиться. Не тратьтесь на другие вещи. Сведите к минимуму время отвлечения внимания с помощью переключателя контекста.
И последнее, но не менее важное: у вас также должен быть психологический модуль для семейного времяпрепровождения. Он должен быть открыт, когда вы не на работе. Все рабочие отсеки должны быть закрыты на время семейного отдыха.
Если вы не можете переключить свой умственный контекст, находясь дома, смертельное выгорание (возможно, болезненный разрыв) встретит вас раньше, чем ожидалось.
Заключение
Многие компьютерные ученые считают, что программирование — это дисциплина, уходящая корнями в метафизику, поскольку она занимается категоризацией реальных вещей для создания автоматизированных рабочих процессов. Когда они хотят что-то построить, у них не бывает бессонных ночей из-за проблем с инструментами и такими вещами, как «почему фреймворк X лучше фреймворка Y». Если они не могут заставить его работать, они просто создают новый язык, соответствующий их потребностям.
Естественно, они редко думают о продуктивном программировании.
На другом конце спектра находятся программисты, обучающиеся на учебных курсах, которые думают о программировании как о чем-то продуктивном. Их девиз — больше кода, больше тикетов за меньшее время. Смена компании также происходит по финансовым и семейным причинам.
Такие программисты думают, что программирование может быть освоено только практикой и копированием из лучших источников, следуя указаниям их корпоративных мастеров.
Истина где-то посередине.
Естественно, что программированию предшествует ясность + развитие навыков. Верно также и то, что вы должны быстро терпеть неудачи, пачкая руки. Но эти вещи не обязательно должны лежать в сфере программного обеспечения или самой отрасли. В конце концов, программное обеспечение должно служить реальному миру.
Применение этих 5 практических навыков обучения к программному обеспечению может сделать вас самым релевантным программистом в вашей карьере. На это может потребоваться время, но когда они принесут свои плоды, это заставит вас расти в геометрической прогрессии.
В эпоху, когда данные дороже золота, актуальность — это золотая жила.