Федор Борщев

Кручу гайки. Пишу матом о книгах, саморазвитии и об управлении проектами. Настраиваю ин-хаус разработку в стартапах.

Программистам: три варианта развития миддла

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

Их на самом деле всего три: ничего не делать, стать синьором или податься в управление.

Ничего не делать

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

Голован: чувак, который отлично умеет ничего не делать

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

Синьор

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

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

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

Жизнь в большой компании

Хороший синьор учит параллельные технологи. Синьор-бекендер учит фронтенд, синьор-рубист учит Голанг. Все учат devops, CI, автоматизацию тестирования и еще кучу всего. Ребята с широким кругозором нужны везде.

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

Тимлид\Менеджер

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

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

Скрам-доска: инструмент любого потного менеджера

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

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

А там уже до CTO недалеко.

Итого

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

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

Топ-даун и прогрессивный джипег для программистов

Правило Парето гласит, что 80% времени программиста тратится на 20% требований. К примеру, на любом современном фронтенд-фреймворке работающую корзину в интернет-магазине можно запилить за день — можно будет добавить/удалить товар и отправить заказ.

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

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

Инженеры называют этот подход top-down, дизайнеры — прогрессивным джипегом.

Проверь через два дня

Многим программистам (и менеджерам) не хватает простого навыка — проверить через два дня.

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

Проверка через два дня не требует никакого напряжения и предотвращает кучу долга — в проекте не копятся неработающие и невнедренные фичи.

Лучше через два дня самому узнать, что фича не работает, чем через неделю узнать то же самое от пользователей. Или не узнать вообще.

Кто должен проверять через два дня, если задачу делали впятером? Конечно ты.

Плато продуктивности

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

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

Программист делает твою (да-да, твою) задачу

Работа с некачественным кодом сильно выматывает — вместо фокуса на цели приходится разбираться, о чем же думал «тот парень» (и тот, кто его подгонял). В таком режиме волна продуктивности превращается в болото: ∿∿—\____. Хочется уволиться и пойти работать машинистом метро.

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

Технические долги

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

Представь что ты увидел в магазине новый охуенный iMac pro. Можно пойти и накопить 400 тысяч (долго и муторно), а можно достать кредитку и купить прямо сейчас.

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

Технический долг — он как финансовый

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

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

Расплата по долгам

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

Давайте жить не в долг и писать понятный код — так быстрее. И работу можно будет менять по собственной воле, а не из-за долговой ямы.

Какие технологии выбрать для нового проекта?

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

За пару дней до Нового Года я решил выбрать робот-пылесос. На рынке есть десятки брендов — iClebo моет полы, iRobot лучше всех строит карту помещения, Дайсон — мощный, а Сяоми вроде бы самый крутой, и стоит в 5 раз дешевле. Объединяет всех производителей одно — нихуя не понятно, какую из характеристик нужно выбрать, чтобы конкретно в моей квартире стало всегда чисто.

Когда руководитель не может делегировать выбор технологий для нового проекта, он оказызывается в такой же ситуации, как я на Новый Год. Проект нужно было начать еще вчера, а чем Руби отличается от Питона и Раста, и как эти отличия отразятся на сроки и целях — непонятно.

Выбор технологий с точки зрения менеджера

Ответ про пылесос я в итоге нашел на вечнозеленом ixbt. Но с языками программирования так не получается — вменяемых материалов нет. Даже если вы неделю будете изучать реддит, то узнаете только как правильно троллить ПХПшников или что наследование в Го лучше чем в Джаве. Какое это имеет отношение к срокам и целям — непонятно.

А ответ простой — новый проект нужно начинать на стеке, с которым работает команда, способная гарантировать результат. Вы же не обсуждаете с дантистом диаметр бура, а с дворником виды метел? С дантистом вы договариваетесь о том, чтобы не болели зубы, с дворником — чтобы во дворе не валялся мусор.

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

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

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

Если остались вопросы про выбор — пишите на почту.

Писать тесты — вежливо

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

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

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

Хорошая передача эстафетной палочки — 3 ссылки на тесты
Хорошая передача эстафетной палочки — 3 ссылки на тесты

Не пишете тесты? Откройте лучше автомойку, или завербуйтесь к газовикам на север.

Автоматизация рутины программиста

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

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

6 сервисов для автоматизации рутины программиста

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

Если рядом с вами программируют хоть что-нибудь сложнее сайта-визитки на вордпрессе — проверьте эти 6 направлений:

  • Непрерывная сборка и запуск. Решает проблему с выкатыванием софта — программисту достаточно отправить коммит в репозиторий, дальше все случается без его участия — запускаются тесты, собирается фронтенд, снимаются метрики. Если код в коммите рабочий, продакшн обновляется автоматически. Хороший сервис — CircleCI.
  • Замер качества кода. Ключевые метрики — покрытие тестами, сложность, читаемость, наличие копипейста. Хороший сервис — Code Climate.
  • Отдельным пунктом — процент покрытия. Это соотношение кода, который выполняется во время прогона тестов к общему количеству кода в приложении. Если у вас проверяется меньше 80%, значит вы пишете плохой код. Если покрытие меньше 50%, а вы работаете над новыми фичами — вы работаете зря. Хороший сервис — Codecov.
  • Обработка ошибок. Хранит журнал ошибок и позволяет анализировать продакшн на основе реальных цифр, а не жалоб пользователей. Хороший сервис — Sentry, есть клиенты для всех языков, включая браузерный JS.
  • Мониторинг производительности. APM снимет трейсы самых долгих запросов прямо с продакшена, нарисует графики скорости и подскажет узкие места, которые приводят к тормозам. Для каждого фреймворка нужен свой APM, для Джанго я использую Datadog. Еще есть New Relic и куча других.
  • Облачный хостинг. Если на вашем проекте есть жужжащая железяка с сисадмином в комплекте — смело избавляйтесь. Дешевле и проще взять ресурсы в аренду и исключить человеческий фактор, чем владеть коробкой, которая не приносит денег. Идите в Azure или хотя бы в Digital Ocean.

Что-то забыл? Пишите в комменты. Интересуетесь автоматизацией? Начните с free-for-dev.