За что платят программисту?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Читаемость

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

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

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

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

Тестируемость

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

Пишите код, пишите тесты. Тесты на разных уровнях: от уровня функции до уровня бизнес-фичи. Упустить из тестов какой-то момент довольно опасно для проекта. Если не тестировать функции, то можно получить монстра на 1 тыс. строк, который делает все и еще за кофе бегает. Только делает свои задачи отвратительно и кофе приносит паршивый.

Если не тестировать бизнес-фичи, то можно надолго застрять на этапе QA, когда тестировщики будут находить и возвращать код постоянно на доработку. Такие тесты сложнее, но они ускоряют разработку практически всегда. Если вы точно знаете, когда тесты фичей будут только замедлять разработку до того, как написали эти тесты, я должен читать ваши посты, а не вы мои. Для всех остальных: напишите хотя бы один такой тест для фичи.

И что делать?

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

Только не перегорите. Иногда лучшая стратегия - сбавить скорость. Навык написания кода складывается долго. Торопиться особого смысла не имеет. И не обязательно использовать свой карьерный капитал для получения большей зарплаты. С какого-то этапа своей карьеры выбирайте больше свободы.

---
Возник вопрос? Мне всегда можно написать в Twitter: avkorablev