Программисту платят за код. Писать код — основной навык, который нужно показать в работе и на собеседовании. Знания технологий добавят очков, как и софт‑скилы. Но если программист не будет писать код, его уволят. Этот навык требует больше всего времени на освоение. Он же — лучший карьерный капитал программиста.

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

Что считается работой над навыком?

  • Работа в парадигме код‑ревью. Код для личных проектов не считается — у него нет ревьюверов. Код, написанный в open source‑проекте и прошедший ревью, — считается.
  • Работа над сложностью кода: работать над сложностью кода, который вы можете написать и поддерживать. Развивать личные инструменты для этого.

Рынок программистов — рынок одного навыка

В книге «Хватит мечтать. Займись делом» Ньюпорт описывает два разных типа рынков кандидатов по типу карьерного капитала:

  • рынок одного главного навыка;
  • рынок набора уникальных навыков.

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

Ключевые слова в вакансиях ничего не значат

Если смотреть на вакансии, кажется, что рынок программистов — рынок второго типа: тот, кто владеет набором специфичных знаний и умений, легче найдёт себе работу и удержится на ней. Это не так. От программиста требуется писать код.

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

Кандидаты поступают так же, как и работодатели: накидывают в свои резюме побольше ключевых слов. Надежда на то, что в больших компаниях резюме часто просматривают HR‑специалисты. Они не программисты: если раскидать в резюме нужные слова в правильном порядке, то прохождение этого фильтра улучшится. Уже на следующем этапе от этих «обязательных» требований ничего не останется.

Аргумент в пользу требований знаний технологий приводят тот, что это сокращает онбординг кандидата: полезный продукт от него будет поступать раньше. Но бо́льшая часть онбординга кандидата — это подстройка под культуру команды и под инфраструктуру работы вокруг проекта, а не под код.

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

Технологии меняются

Технологии меняются со временем. И даже за период от собеседования до выхода на работу может многое поменяться. Будьте аккуратнее в отсеивании вакансий по списку требований. На собеседовании важнее узнать про процессы и культуру в команде: они меняются медленнее.

Знание специфичных технологий имеет значение на уровне senior‑разработчика — когда кандидата подбирают на решение конкретной задачи, когда нужно быстро сделать проект под конкретный технологический стек. Такие истории редки. Чаще крутые разработчики — крутые кодеры, и это облегчает им поиск работы в большей степени, чем знание конкретной технологии.

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

Код — это важно

Это определяющий навык программиста. Научиться программировать сложно: на овладение уйдут годы упорного труда. Реклама курсов врёт: после них сложно найти работу, ещё сложнее на ней удержаться. Окончить курсы, пройти буткемп — только первый шажок в нужном направлении. Следующий — выяснить, как минимум, что в Python не только цикл for есть (это реальный пример с собеседования!). Затем — нарабатывать навык любым доступным способом.

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

В навыке написания кода есть несколько составляющих. Каждый аспект можно улучшать. Насколько сложный код может написать программист, определяет его уровень: можешь написать код небольшой фичи? Осилишь компоненту сервиса? Можешь один писать сервис?

Хорошему программисту нужен «второй мозг»

Размер кода, который может написать программист, зависит от его опыта и от его способности держать в голове нужный объём связей. Опытные программисты делают записи о текущем проекте. А ещё они рисуют схемы архитектуры, связи между системами — строят себе «второй мозг».

На момент написания этой статьи мой набор инструментов «второго мозга» такой:

  • бумажный блокнот, где записаны:
    • планы на день;
    • пометки по текущему статусу задач;
    • наброски архитектуры или подхода к решению задачи;
    • изредка рисунки и схемы;
  • электронный журнал в denote:
    • ссылки по текущим задачам;
    • куски скриптов;
    • куски логов;
  • персональная база знаний в denote:
    • заметки по процессам, коду, архитектуре;
    • к кому идти за помощью в различных ситуациях;
    • куда смотреть при дежурстве или при инцидентах;
    • и т. п.;
  • диаграммы в Excalidraw или на бумаге.

Кто не пользуется Emacs, denote можно заменить на Logseq или Obsidian. С последним — аккуратно: ознакомьтесь с лицензией на коммерческое использование. Ещё лучше — проконсультируйтесь с юристами в своей компании.

Если в компании есть Wiki и в ней можно завести свой личный кусочек, пользуйтесь этой возможностью. В корпоративной Wiki обычно можно хранить гораздо больше. Минус: если доступ к Wiki пропал, то пропал и доступ к базе знаний. Вдобавок пользоваться веб‑интерфейсом вики не так удобно.

Хм… Нужно два «вторых мозга».

Вести придётся две базы знаний: одна — по задачам и проектам у текущего работодателя, и ещё одна — личная. В личную складываются заметки по архитектуре, по методам написания кода или по находкам, не связанным с кодом работодателя.

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

Разделяйте базы знаний визуально или ведите в разном софте. Моя личная живёт в Obsidian, а рабочая — в Emacs. Рабочие заметки управляются пакетом denote.

Личная база живёт в Obsidian по историческим причинам: я начал её вести раньше, чем узнал о denote (а может, и раньше появления этого пакета). Смысла переходить нет: я не такой продвинутый пользователь Emacs, чтобы заметить разницу в скорости работы между denote и Obsidian.

Тем более что разделить рабочую базу и личную в denote будет проблематично: потребуется много настроек. И на Лиспе придётся писать, и отдельную тему настраивать — визуально надо делить.

Не надейтесь, что удастся построить систему, которая будет работать сразу. Не получится. Выстраивать придётся долго, а потом постоянно перестраивать и улучшать: появятся новые инструменты или изменятся требования.

Понимание бизнес‑задачи — это про код

Второй аспект — точность понимания бизнес‑задачи и её качественное переложение в код. Похоже на решение текстовых задач в математике: понял условие — решил задачу, понял условие неправильно — получил на выходе ерунду. Только условие (постановка задачи программисту) будет не таким точным и выверенным.

Это самый слабый аспект в плане личного контроля. Он сильно зависит от команды. Если у работодателя принято делать подробные постановки, проработанные аналитиками, то на программиста будет меньше нагрузка. За это придётся расплачиваться: такие компании будут писать софт для корпораций, банков или другой специфической области.

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

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

После каждой встречи с менеджерами я записываю что‑нибудь в свой словарик с терминами доменной области. И так — в последних двух проектах. Такой словарик — лучший помощник в решении повседневных задач.

Качество кода

Третий аспект — технический. От кода, помимо решения задачи, ждут читаемости, поддерживаемости, тестируемости и т. д. Код пишется один раз, а читается много раз. Если не заботиться о его читаемости, то можно застрять в младших разработчиках надолго.

Читаемость

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

Поддерживаемость

Обеспечить поддерживаемость коду сложнее, чем читаемость. Они связаны: поддерживаемый код обычно хорошо читается. Он разбит на куски в соответствии с принципами SOLID, принятым в проекте делением и здравым смыслом.