25563
Рассказываю, как руководить программистами fborshev@pm.me / borshev.com Реклама не продаётся
Почему у нас нет соглашения о непереманивании
В кровавом аутсорсе и аутстафе принято с каждым новым клиентом, помимо договора об услугах, заключать ещё и NSA: non-solicitation agreement или соглашение о непереманивании. Типа, если сотрудник из аутсорса\аутстафа переходит на сторону клиента — клиент платит большой штраф.
Даже если отбросить юридические моменты (уверен, способы обойти эту фигню всем очевидны), такой договор мне кажется ущербным. Во-первых, это выглядит как форма крепостного права — я, как работодатель, ограничиваю волю другого человека работать там, где он хочет.
Во-вторых, сотрудники работают в компании явно не потому, что им запретили уходить. Кто-то работает потому, что ему нравится график. Кто-то ценит проекты, коллег, или индивидуальные договорённости по оформлению и зарплате. В fands, уверен, есть ребята которые ценят анонсы — когда-то я унёс из студии прекрасную традицию писать имена сотрудников под рассказом о каждом проекте. Ну или нашу открытую разработку.
Заключая с клиентом соглашение о непереманивании, я расписываюсь, что построил компанию, люди из которой не уходят просто потому, что их не зовут. И вместо того, чтобы починить проблему, я трачу силы на возведение вокруг неё забора — получается нечестно не только по отношению к сотрудникам, но и к себе.
Напомню, что завтра в 19:00 MSK будет первый, бесплатный, вебинар курса «Тестирование в Python». Обсуждая курс с учениками, мы услышали сомнение — оказывается мидлы и синьёры сомневались что курс им будет интересен и полезен. Типа наши темы лучше подойдут для джунов. Про ложную уверенность в себе у мидлов\синьёров я ещё расскажу попозже, а сейчас хочу напомнить, что наш курс — совсем не для джунов.
Джуны — это ребята, которые далеко не всегда умеют отличить хороший код от плохого. Грубо говоря, уже понимают про цикломатическую сложность (функция, которая не входит в экран по ширине — плохая функция), но ещё не понимают про coupling\cohesion, правильный нейминг, могут не ценить KISS.
Наш рассказ о том, как писать хороший код в тестах скорее всего плохо ляжет на базу, в которой ребята ещё не умеют писать хороший код в приложении. Может что-то и получится, но лучше бы всё-таки приходить мидлам\синьёрам.
Так что если вы джун — подумайте ещё раз, и точно не лезьте дальше самостоятельного тарифа. А если синьёр-помидор — бросайте гордыню и приходите послушать Никиту, будет полезно.
Сервисы: 1Password + GitHub Actions
Меня давно бесило, как хранятся секреты для Actions в гитхабе — чтобы добавить доступ к кластеру для CI\CD, нужно быть админом репозитория, или вообще организации в целом. Менять эти секреты хуже некуда — если 20 разных репозиториев содержат один и тот же приватный ключик, то для его ротации админ должен зайти в 20 проектов.
Недавно нашёл решение — оказывается 1password умеет транслировать секреты прямо внутрь Actions: достаточно прописать один токен в гитхаб, и всё управление секретами переезжает в привычный и подходящий для этого 1password. Получаем всё, к чему привыкли с обычными паролями — гибкие пермишены, логи изменений, и даже логи доступа к секретам.
В простом случае, чтобы раскатать новый сервис в новое место, разработчику вообще не нужен доступ никуда — он просто использует внутри Actions все, что сам же положил в 1password.
Конечно возникает проблема с безопасностью сервисного токена 1password, но ничего не мешает сделать десяток таких токенов для разных групп доступа — все они будут управляться в одном месте.
Только тесты и спасают
Несмотря на энергию, с которой я топлю за чистый код, за последние несколько лет мои команды сделали парочку довольно стыдных проектов — с непонятной архитектурой, ненужными или протекшими абстракциями, грязью в функциях. Сами ребята были нипричём — все проблемы вылезали из-за плохого общения с бизнесом: мы плохо планировали фичи, меняли планы на ходу и делали всё то, с чем каждый сталкивается постоянно, когда работает реальную работу, а не слушает доклады с конференций.
Горжусь, что несмотря на проблемы, проекты оставались управляемыми — мы пилили фичи, успевали в сроки, не нарушали обещаний. Выезжали, в основном, на тестах — когда все точки интеграции, бизнес-истории и ручки API покрыты тестами, у команды остаётся время, чтобы поразбираться с наверченными проблемами: что легко — починить, что сложно — попрятать или задокументировать.
Для меня, как для CTO, тесты остаются самой важной точкой контроля — если тесты есть и стабильно пишутся, значит проект не сдохнет от первой же проблемы с бизнесом. И наоборот — когда тестов нет и разработка постоянно катит говно — проблемы с бизнесом полезут сами и довольно быстро потопят проект.
Если вы пишете на Python и почему-то не попали на прошлый поток нашего с Никитой Соболевым курса «Тестирование в Python» — приходите 6 сентября в 19.00 по Мск на бесплатный вебинар, где мы поговорим о базовых вещах — либах, подходах и правилах. Даже если не пойдете дальше на курс — все равно получите пользу.
Вебинар начинает второй поток курса, обучение на котором стартует 11 сентября. Курс научит вас делать тесты, которые будут жить и помогать проекту — понятные и быстрые.
Последняя неделя целиком посвящена внедрению тестов в реальную жизнь — как прививать хорошие практики коллегам и сделать так, чтобы на тесты не забивали, как только вы от них отворачиваетесь.
Зарегистрироваться на вебинар →
Запись вебинара получат те, кто пойдут на курс, остальные смогут послушать и задать вопросы только в лайве.
Ну а если сомнений нет, то покупайте сразу весь. Сэкономите денег — после 6 сентября мы повышаем цены. Курс можно оплатить любой картой мира, от юрлица из любой страны или частями, используя сервис Долями.
#вопрос как вежливо объяснить менеджеру, что он просит фигню? У нас горят дедлайны, нужно код писать, а он просит декомпозировать задачи и написать план на неделю.
Для начала я бы разобрался в причинах. Обычно, когда менеджер просит сделать неприятную фигню вроде плана на неделю — за этим стоит какая-то понятная проблема. Может вы несколько недель подряд не выполняли устных обещаний и теперь от вас требуют письменных? А может на проекте едут сроки, и менеджер пытается построить какой-то план выхода из кризиса? А может вообще он решает не очень внятную, но важную для всех задачу, вроде того, чтобы убедить заказчка, что он не зря тратит деньги на команду разработки?
Конечно дело может быть и в менеджере. Начинающие ребята иногда не могут отличить процесс от результата. Появляется ощущние, что они работают по скрипту — приходят в сработанную команду самостоятельных ребят, и начинают разбираться почему в ней нет дейли-митингов или каждую неделю все не собираются на ретроспективу.
Самый простой способ справиться с менеджером, который просит вас сделать фигню — это узнать, о чём у него сейчас болит голова, и как он собирается с помощью фигни, о которой вас просит, эту головную боль решить. Хороший менеджер ненавидит лишнюю работу, поэтому легко всё объяснит. Плохой начнёт мямлить по поводу процессов или того, что руководство попросило.
————————
Это — возвращение вопросов по понедельникам. Задавайте любые вопросы на fborshev@pm.me, с радостью отвечу здесь.
Начинать с выводов
Я давно поборол проблему белого листа с текстами — умею подбирать время и настроение чтобы изложить мысли, веду темник и вообще делаю все штуки, о которых когда-то рассказывал тут.
А вот с публичными выступлениями проблема белого листа довольно часто возвращается. Причём не важно, выступление ли это на крупной конфе, маленьком митапе или вебинар в школе — хватает запала придумать тему и заявиться, а вот подготовиться и рассказать нормальную историю — уже не всегда.
Самый рабочий для меня метод — это начать с последнего слайда с выводами. Для чего я выступаю? Что хочу, чтобы аудитория унесла с собой? Что поменяла в своей жизни/работе? Буквально 2–3 самых главных предложения. По готовым выводам рассказ строится сам собой — остаётся только поискать примеры и придумать переходы.
С текстами, кстати, тоже работает (этот пост я так и написал). Если упёрлись в белый лист — начните с выводов.
Ласт колл на «Асинхронную Архитектуру»
В пятницу стартует обучение на пятом потоке «Асинхронной Архитектуры». Курс окончили уже 1400 студентов, каждый из которых узнал, как выбивать из бизнеса требования при помощи EventStorming, строить из этих требований модели данных, проектировать коммуникации, выбирать брокеры, отлаживать и тестировать полученные распределённые системы. Многие после курса получили повышение — просто потому, что начали думать про бизнес и нашли аргументы для общения с руководителем/тимлидом.
На курсе объёмная домашка — посмотрите примеры работ на Ruby, Python, Go, JS, PHP, Java, Kotlin, Elixir или C#. Мы даже рекомендуем брать отпуск на пару дней в неделю на время обучения. Смысл домашки в том, чтобы попробовать новые знания в безопасной среде — на этом курсе у нас самые активные чаты, и в них (удивительно) никому не говорят «ты тупой, иди гугли».
Если вы джун, интроверт или просто интересуетесь архитектурой — берите самостоятельный тариф. Если хотите качественного скачка — берите «в тусовке». Если хотите, чтобы Антон гарантированно разобрал ваш личный кейс — берите «VIP», места ещё есть. Стартуем в пятницу, 28 июля. Это последний поток в 2023 году.
До встречи на курсе →
P.S. Если вы уже у нас учились на тарифах с обратной связью, не забудьте применить свой промокод. Если забыли где взять — спросите в чатике или в почте support@tough-dev.school
Вебинар «10 проблем асинхронных систем»
Перед запуском каждого нового потока мы обычно встречаемся с потенциальными учениками — делаем обзор материалов и отвечаем на вопросе о курсе и предметной области. Это отличная штука — сомневающиеся получают возможность развеять сомнения (или нет), а мы — вживую поговорить с аудиторией.
Однако мы не были бы собой, если бы повторяли одну и ту же активность без изменений. Поскольку по Асинхронной Архитектуре мы уже проводили такую штуку для прошлого потока, в этот раз мы немного поменяем формат.
Вместо обычного рассказа о курсе, Антон подготовил довольно полезный доклад, который называется «10 проблем асинхронных систем»:
— Циклические связи
— События с реализацией вместо событий о поведении
— Забивание на версионирование и обратную совместимость
— События из одного ID, по которому надо доставать дополнительные данные
— Отправка только изменённых полей вместо всего агрегата
— Распределённые саги
— Синхронные вызовы вместо асинхронных (и наоборот)
Прийти не помешает даже если вы у нас уже учились. Если интересуетесь большими системами, но пока не доросли до курса — тоже приходите.
Встречаемся в следующий вторник, 25 июля, в 19:00 MSK. Записи не будет.
Записаться →
Антиспам для комментов
Те кто заходят комменты к постам, наверняка заметили, что в последнее время количество кликбейтного спама в них всё увеличивается и увеличивается. Очень странно, что телеграм с этим не борется — с их инструментами, имея доступ ко ВСЕМ сообщениям и бесконечному машинного времени, это сделать очень просто.
Вообще, комменты в телеге — отличный инструмент для дискуссий: никакой аунтификации, пишешь там же где читаешь, работают все привычные форматы общения (хоть голосовые можно записать), легко перейти в личку.
Пока Дуров не завёз нам нормальный антиспам для комментов, я поддерживаю свой — бота, который автоматически трёт все сообщения со ссылками, написаные от чужого имени, состоящие из фоточек. Недавно добавили исключения — теперь правила не действуют для старожилов, которые давно тусят в группе.
Если хотите поставить бота к себе — добавляйте @discussion_sentinel_bot как админа в группу с комментами. Если есть идеи или хотите законтрибьютить — вот гитхаб.
The fast way vs the hard way
В обучении любому ремеслу есть дилемма — доскональное изучение теории с долгим и негарантированным выхлопом (условный институт) против максимально быстрых, но поверхностных результатов (условный предприниматель-самоучка, которому надо прямо сейчас что-то наговнокодить).
В вайтишной тематике первая крайность представлена книгами из серии Learning X: the Hard Way. Книги запрещают даже копипастить примеры, мотивируя это тем, что пока не научишься набирать текст без ошибок — не научишься кодить (кек, как им наверное стало грустно после появления GPT-powered кодинг-ассистентов). Вторая крайность — условный скиллбокс, который обещает из кого угодно сделать питониста за 3 месяца.
Раньше я безусловно топил за hard way — типа нафига учить питон, если не понимаешь как устроен компилятор и зачем нужен ассебмлер? Как в школе — не будут же дети писать сочинение, пока не пройдут алфавит, не научатся писать чёрточки, затем буквы, затем слова и предложения.
Когда я познакомился с Марьяной, понял, что такой метод обучения годится только для детей — взрослые люди устроены совсем по-другому. У них есть работа, куча дел и привычка оценивать промежуточные результаты. Если взрослому преподавать питон начиная с ассемблера — он сбежит минут через 10.
Жестить с быстрыми результатами тоже нельзя — если научить вайтишника писать базовые вьюхи на джанге, но не объяснить про тестирование, SOLID и чистый код — получите весь код приложения в одной вьюхе.
Сейчас я по прежнему считаю, что учиться надо через hard way, используя быстрые результаты так, чтобы взрослый не сбежал. Даёшь ученикам неделю теории — дай возможность за пару часов на ней что-нибудь собрать. Полтора часа играешь гаммы на гитаре— потрать 10 минут и сыграй что-нибудь кайфовое для себя.
10 лет назад я прочитал в книге Олега Тинькова, как он объяснял сыну, что нужно стремиться не меньше тратить, а больше зарабатывать. Разумеется, я не поверил и решил, что это какая-то причуда богатых людей из розового мира — зачем тратить деньги, если можно их экономить!
Лет через 5 я дошёл до этого принципа сам, а ещё через 3 года смог даже что-то реализовать. Объяснить этот принцип нормально нормально не могу до сих пор, но недавно нашёл эмоциональный пример.
Наткнулся на историю чувака, который себе древнюю БМВ, чтобы ездить по работе. За время владения вложил в неё 2.4 миллиона рублей и неподдающееся учёту количество времени. Работа у чувака, насколько я понял, — не хитрая: развозить запчасти для этих самых БМВ.
Так вот — что было бы, если бы чувак купил себе вместо БМВ жигули-четвёрку, взял оставшиеся от покупки деньги, добавил бы те же 2.5 миллиона, и за пару лет открыл бы собственный такой же бизнес по доставке запчастей? Сейчас бы ездил на такой же БМВ, только новой. А свободное время тратил бы на развитие бизнеса, семью, или на оживление какой-нибудь ещё более древней БМВ в качестве хобби.
Примеры из этой же области — снять квартиру на 10 000 дешевле, но в Подольске; закупаться на 10% дешевле, но тратить целый день на дорогу в ашан; юзать корпоративный почтовый сервер чтобы не платить гуглю.
В который раз убеждаюсь, что самые ценные ресурсы — это время и внимание, и никак не деньги.
https://www.youtube.com/watch?v=yIJU-B3kp90
Кто не может задать вопросы в ютубе — пишите в комменты, я буду смотреть
Readme driven development
У разработчиков библиотек есть классный способ проектировать API — Readme driven development. Смысл в том, что стартовать нужно не с кода, а с документации, которую пользователи увидят на гитхабе — написать текст, из которого будет ясно для чего нужна библиотека, привести самые яркие примеры задач, которые она решает, написать про ограничения.
Такой подход работает примерно как TDD — заставляет программиста думать не о реализации, а об окружающем мире, в котором эта реализация будет жить.
Readme driven development помогает, даже если вы скромно шлёпаете формы или лабаете CRUD-ы. Начиная сложную задачу — представьте, что вы её уже закончили и пишете коллегам, как пользоваться результатом вашей работы. Расскажите, где найти вашу новую форму и что туда вбить, чтобы увидеть самые интересные варианты поведения. Опишите, какие ошибки ваш CRUD выдаёт в каком случае, как можно в нём авторизоваться, чтобы проверить разные уровни доступа и т.д. В общем всё, что посчитаете важным для коллег.
Скорее всего на этапе описания повызелает куча вопросов, которые в обычном режиме вы бы спешно решали в момент написания кода. Если решить их сразу — это можно сделать спокойно и не торопясь, а значит ваша реализация будет лучше и полезнее для колег.
Данные нужны только фронту?
Я — старый ретроград и противник NoSQL: считаю их раздутым по функциональности кешем, в котором нельзя хранить ничего важного.
Недавно услышал новый аргумент в пользу schemaless — типа на проектах бывают данные, которые нужны только для фронта. Бекенду на них при этом пофиг — почему бы не засунуть их хотя бы в JSONB. Аргумент — плохой и вообще слишком программистский.
Если данные существуют — значит они нужны бизнесу. Вот представьте: вы делаете классифайд, у которого все параметры объявлений, кроме таксономии, хранятся в Elasticsearch. Для фронта хватает — поиск работает, дерево категорий строится, отдаётся все быстро, рендерится красиво. И тут вам прилетает задача — сделать выгрузку самых качественных объявлений в формате XML для какого-нибудь маркетплейса. Качественные объявления — это у которых чётко изображён предмет на фотке, у которых нет мата в описании, указан бренд, и ещё куча всего. Представьте, как весело будет перелопачивать все эти данные в момент выгрузки? Особенно, учитывая что Bosch можно обозвать Bosh, Boshc, Бош или Бошь?
Или вам нужно начать стримить объявления в микросервис на расте, который по супер-алгоритмам проверяет их на уникальность. Или перегружать их в BigQuery для аналитиков. Или пессимизировать в выдаче объявления со слишком длинным или слишком коротким содержимым?
Может для программистов NoSQL и выглядит красиво, но в реальной жизни всё для чего он годится — это специфичные read-модели в CQRS.
Променл мнение: Нужен ли докер в продакшене? Да
Прошло уже несколько лет, и пора признать, что я поменял мнение. Раньше я был уверен, что если вы задаёте себе вопрос «нужен ли докер в продакшене?», то докер вам брать не стоит. Сейчас я уверен, что стоит: любое приложение нужно паковать в докер таким образом, чтобы его можно было запустить там же в проде.
Я не вижу каких-то глобальных изменений в окружающих технологиях: k8s так и остался переусложнённым продуктом от программистов для программистов (и FAANG-ов). Dokku, Rancher или CapRover так и не определились, кто из них главный, и каждый продолжает развиваться в своём направлении. Наверное самое главное, что изменилось — появился MRSK, но в продакшен я его тащить пока не готов.
Возможно поменялся я — было довольно обидно в марте 2022 экстренно съезжать с хероку. Может быть и не из-за этого, а потому, что за прошедший год я развернул несколько продакшенов на нашей заготовке swarm+ansible и процесс мне показался не таким уж и сложным.
В любом случае, мнение я поменял и теперь считаю, что прод по умолчанию надо делать на докере. Правда, если вы не гугл и хотите платить сотни денег — постарайтесь не усложнять себе жизнь кубернетисом: возьмите комфортный для вас PaaS. Какой — не посоветую, все они до сих пор хреновые.
Синьёры и тесты
Помимо самостоятельности и умения закрывать бизнес-задачи, синьёр отличается от мидла ещё и тем, что повидал много говна. Джанговские синьёры знают, что нельзя даже близко подходить к GenericRelations, vue-синьёры успели пообновлять nuxt.js на проде и поэтому делают SSR сами.
Давая бизнес-задачу такому синьёру, можно быть уверенным, что он если проект и провалится, то не из-за технологий: скорее всего фреймворки и подходы будут если не самыми лучшими в индустрии, то уж точно общепринятыми.
К сожалению, такая взрослость обычно не касается тестов. Много синьёрных тест-сьютов на моей памяти превращались в длинную и запутанную кашу, пусть и разбитую на функции\тесты. Базовую задачу такой тест-сьют конечно выполнит — если программист что-то сломает, о проблеме ему всё-таки сообщат. Но вот качество такого сообщения оставит желать лучшего. Как звучит бизнес-история, которая сломалась? В каком контексте она выполняется? Точно ли она теперь сломана для бизнеса?
Чтобы тесты сохраняли ответы на все эти вопросы, тесты должны быть понятно названы и хорошо сгруппированы, состоять из короткого сетапа, который прячет всю сложность от конечного разработчика, понятного действия, которое выражено на языке бизнеса, и читаемого асёрта, из которого ясно, что было в голове у автора. Поддерживать такой порядок на протяжении всей жизни проекта — сложная работа, на которую легко забить: тесты пишутся, покрытие не падает — и ладно, пофиг что тесты не читаемые.
Лучше всего эту проблему решают технологии: если с самого начала жизни проекта показывать команде удобно построенный фреймворк для тестов, из которого понятно, как тестировать новые бизнес-требования, прятать сложность, делать тестовые фабрики и вообще писать лаконичный код — скорее всего тесты будут нормальными и без сложного код-ревью.
Ну а если ваши синьёры пишут на питоне — приводите их к нам на второй поток «Тестирования в Python». Сегодня вечером — первая встреча-знакомство, ещё можно запрыгнуть.
#вопрос Бесят деды на работе. Предлагаю им новые технологии — а они давят авторитетом и блокируют, как будто им ничего нового и не нужно. Что делать?
Во-первых, сочувствую вам — всегда тяжело, когда интересную работу, которую вы сделали с большой мотивацией, умножают на ноль люди, у которых есть власть. Опускаются руки, хочется больше ничего не делать или наоборот, идти и делать свой бизнес, где никто ничему не помешает.
В любом случае, посоветую вам смириться с тем, что сложные задачи, на которых можно одновременно отрабатывать навыки и получать за это деньги, всегда идут в комплекте с требовательными тимлидами, дедами, синьёр-помидорами, представителями бизнеса которые ничего не понимают в ИТ и собственниками бизнеса, которые обладают неограниченной властью в любой компании. И есть всего два варианта — либо встраиваться в эту систему и учиться договариваться, либо пилить пет-проекты, надеясь стать прийти к one-man software business.
Если выбираете первый вариант — учитесь договариваться с дедами. За один пост мне сложно дать нормальный ответ как это делать — мы с Марьяной вообще обсуждаем целый курс с условным названием «как продавать свою идею». Если вкратце — вы не продадите дедам того, что они сами не хотят.
Хотите новый фреймворк — выясните какие проблемы есть у дедов в текущем. Решает ли их ваш фреймворк? Если да — продемонстрируйте, как красиво и круто он это делает, заинтересуйте их.
Деды — ребята консервативные, но обычно за этим консерватизмом стоит не старческая уверенность в своём опыте, а довольно большой опыт, которым глупо пренебрегать. Пример: я на правах деда топлю за Джангу в нашей компании, но когда у меня заболит производительность, которую можно будет вылечить через asyncio, или мне понадобится десятками штамповать простые сервисы на похожем шасси — я с радостью поддамся уговорам про FastAPI.
Так что удачи вам на нелёгком пути поиска невыдуманных проблем!
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
#вопрос Что думаешь об No-code платформах вроде Zapier, Appwrite, Nocodb? Пробовал ли их использовать и можно ли их использовать на продакшене?
За два года моё мнение сильно не поменялось, я по-прежнему считаю, что no-code — это техдолг. И по-прежнему продолжаю затаскивать no-code решения к нам в школу — мы всё ещё не завели отдельную разработку, поэтому все свободные силы тратим на подключение систем, которые позволяют пилить фичи без разработчиков. Это полноценная, довольно сложная работа. Архитектурно вся система должна соблюдать баланс: с одной стороны не зависеть от вендора, а с другой — не писать много кода на своей стороне.
К примеру, мы интегрировались с сервисом рассылок dashamail так, чтобы весь таргетинг был у нас: мы генерим теги для пользователей на основе своих данных, а в dashamail прокидываем только контакты подписчиков. Таким образом, мы можем собирать произвольные сегменты для рассылок, но при этом можем за несколько дней заменить дашу на любой другой сервис.
Сейчас интегрируемся с AmoCRM, чтобы в одном информационном пространстве собрать информацию о сделках по корпоративному обучению и о студентах, которые приходят напрямую. Здесь тоже есть хитрость — приходится нормализовать данные на своей стороне, переводя их к максимально универсальным сущностям, чтобы не зависеть от AmoCRM как от вендора. К примеру у нас на каждую попытку купить курс, создаётся новый заказ, и если прокидывать эти данные как есть — сломается прогноз продаж: ведь из 10 переданных заказов ни при каких условиях не будет оплачено больше одного, а AmoCRM будет думать, что оплатить могут все.
Увы, наш случай — довольно редкий. Чтобы наш no-code работал и менеджеры могли мышкой натыкивать нужный workflow, приходится делать много подкапотной работы, которую в обычных условиях малого бизнеса делать некому — фаундер не станет думать о каплинге и идемпотентности, а программист не станет разбираться в бизнесе.
Так что в большинстве случаев, no-code — это техдолг.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Удостоверение тимлида
Постоянно встречаюсь с программистами, которые вроде бы хотят возглавить проект или команду, но чего-то ждут. Вроде и турбина под хвостом имеется, и умение общаться с людьми уже на достаточном уровне, и даже запрос на ответственность в команде есть: приходи и забирай. Но они ждут. Формально ждут разрешения на руководство, типа придёт босс и выдаст удостоверение тимлида. Неформально — просто боятся.
Так, увы, не работает. Если руководитель сам к вам пришёл с ведром ответственности в руке — скорее всего его уже всё очень сильно допекло, и вашу кандидатуру он выбрал не потому, что вы больше других достойны, а потому что меньше других недостойны.
Если хотите взять ответственность — берите, а не ждите, что вам её принесут. Это и есть самая сложная часть профессионального роста — научиться брать столько ответственности, сколько по силам. Сначала — ответственность за себя: научитесь делать что наобещали. Потом — ответственность за своё окружение: если бекендер не даёт вам нужную ручку в API — научитесь не бегать к менеджеру или ждать дейлика, а разбираться в причинах и помогать их исправить. Потом — за проект: если вы лучше других знаете, что за чем лучше делать — почему бы не применить это знание на практике? Можете взять ещё больше — отлично: в любой команде нужно заниматься джунами, общаться с бизнесом, пропихивать исправления техдолга, договариваться с соседними отделами.
Если всё это делать потихоньку, постоянно увеличивая нагрузку, когда вам принесут удостверение тимлида, вы уже не будете в нём нуждаться. А самое главное — так станете не вынужденным руководителем, которого поставили потому что никого другого не смогли, а настоящим: со своим уникальным набором скиллов, который будет работать в любой другой компании, в том числе и вашей.
За одного битого двух небитых дают
Когда я собеседую программистов, большой плюс для меня — это негативный опыт. Очень ценю ребят, которые могут рассказать, как они спроектировали систему, которая превратилась в большой комок грязи или проработали пару лет в кровавом энтерпрайзе без тестов и CI\CD.
Тут как с автомобилями. Я гораздо спокойнее буду чувствовать себя с водителем, который был в парочке ДТП (если он не идиот, конечно), нежели чем с чуваком, который утверждает, что за 20 лет у него не было ни одного происшествия. Аварии обычно происходят вне поля нашего зрения — сбоку, за спиной, из-за угла. И умение предчувствовать такие вещи лучше всего вырабатывается в момент опасности. Чуть не встретился с крузаком, который летел на красный свет — будешь знать, что такие водители существуют, и начнёшь сбавлять скорость перед всеми перекрёстками. Влетит тебе в зад невыспавшийся курьер на Дэу Матизе — запомнишь, что не у всех машин есть хорошие тормоза.
Точно такие же механизмы работают с кодом. Программист, который видел своими глазами, как код проекта превращается в лапшу, скорее всего знает антипаттерны не из книжек, а из собственной жизни. И, помня их на кончиках пальцев, с большей вероятностью не пропустит в работу говно.
Час в день
Один из немногих кусочков продуктивности, который не сломался у меня после ухода в предпринимательство — это подсмотренная у Николая Товеровского «Текущая Инциатива». Идея в том, что у меня есть гарантированное время в сутках, когда я занимаюсь Самым Важным Делом.
Самое Важное Дело постоянно меняется. На одной неделе это могут быть занятия музыкой, которые начали буксовать, на другой — пост-анонс клиентского проекта, на третьей — новое дело каждый день. Главное — что я гарантировано уделю Делу час времени.
Обычно мы слабо управляем своим временем — нас дёргают уведомления, нам ставят встречи, или просто сейчас хочется заняться чем-то новым. Чтобы не поддаваться соблазну, час нужно объявить святым временем: его нельзя потратить на встречу, его нельзя передвинуть или отменить (только если заранее, на еженедельном обзоре). Чтобы соблюдать святость, час лучше всего ставить с утра — пока есть силы сопротивляться отвлечениям. Если работаете в офисе — час лучше проводить дома или в кофейне возле офиса.
Попробуйте провести так хотя бы неделю — удивитесь, насколько много можно успеть всего лишь за час в день
Открываться без документации
Ненавижу проекты, в которых в readme в секции installing написано что-то сложнее, чем docker compose up. Таких проектов, к сожалению, большинство — нужно прописать какие-то токены для авторизации, докинуть недостающие файлы, поправить скрипты, перенести докер с qemu в virtualbox, потому что проект не билдится на arm64. А потом ещё ничего не будет работать, потому что на прошлой неделе добавили новую фичу, для которой нужно добавить отдельный redis в docker-compose, а выключить её через флаг забыли.
Вот приходит на такой проект программист, чтобы запилить полезную фичу — и пропадает на три дня. Мало того, что фича будет запилена позже, так ещё и когнитивные ресурсы, которые можно было потратить на пользу для бизнеса, уходят на ковыряние в чём-то бесполезном и попытки разобраться в устаревшей документации.
В каждой репе должен быть, ответственный за то, чтобы проект из неё запускался без десятка шагов в readme. Это важнее, чем технологии — что толку от всех кафок с кубернетисами, если у нас программисты сутками сидят с нейсвойственной себе работой, которая не приносит пользы бизнесу.
Что делаем → что не делаем
В компании гораздо важнее не то, чем она каждый день занимается, а то, от чего она осознанно отказалась.
Вот смотрите, если я опишу нашу с Саматом команду как программистов, которые пишут код на заказ — мы ничем не будем отличаться от агенства, которое делает SEO для автомойки из Тюмени. А вот если я опишу нас как аутсорсеров, которые работают без жиры, дейликов и ручного тестирования — в голове сложится уже совсем другая картина, да?
Умение не ввязываться в ненужные активности — это вообще один из основных скиллов руководителя: дел всегда больше, чем мы можем переварить, и если пытаться сделать их все, то не успеем ничего. Поэтому мы Саматом не связываемся с маркетплейсами и не берёмся за небольшие заказы, а в школе у нас с Марьяной нет курсов для вайтишников.
Я даже ввёл целый ритуал, который помогает мне отказываться от личных проектов — завёл заметку с названием «вещи, в которые я ввязался». На еженедельном обзоре я пересматриваю список этих вещей, и добавляю туда всё, над чем работаю. Когда список становится слишком большим — он начинает давить, хочется выкинуть оттуда что-нибудь.
Самый кайф — не просто убить проект из списка, а придумать, как реализовать его без меня — перепоручить, нанять или просто переформулировать. Хотя и просто убить что-то неважное — тоже приятно.
#новая_продуктивность
Привычные страдания
Недавно первый раз в жизни полетел в бизнес-классе, и сразу попал в «транслантический» — который с отдельными кабинками. Вообще я с самого первого раза привык, что перелёт, даже короткий, — это страдание: тесно, душно, куча людей, от которых никуда не деться, очередь в туалет и тряска. Можно конечно поупражняться и сделать себе более или менее комфортно — купить место возле аварийного выхода, разуться, прийти последним, чтобы не толкаться в очереди. Но что ни делай, перелёт — это страдание, так принято.
Так вот, ВНЕЗАПНО обнаружилось, что перелёт может быть не облегчённым страданием, а обычным отдыхом — когда ни с кем не толкаешься, а несколько часов полулежишь в кресле, слушаешь музыку укутавшись в плед, с нормальной едой и местом для ноутбука.
Похожие переживания я испытал, когда понял, что оказывается можно писать код, который тестирует сам себя, а не страдать в попытках починить баги на проде или в ожидании тестировщика. Тот же паттерн — с самого начала профессиональной деятельности я знал, что программирование — это когда ты пишешь сложный код с багами, а потом страдаешь, разбираясь в том, что написал полгода назад. Это знание было зашито в дискурсе — в разговорах, в мемах, в вакансиях. А оказалось — всё не так, и качество кода — это мой выбор.
Вокруг нас горы таких страданий, ставших привычными — работать на нелюбимой работе; писать код на ноутбуке марки Асер; сидеть в слаке и корячить себе на десктоп «Стахановца»; юзать электрон вместо нормального ПО; <вставьте своё>.
Это не значит, что я всегда буду летать в бизнес-классе — это довольно дорогое удовольствие. Но вот искать среди паттернов поведения привычные страдания и думать что с ними сделать — точно буду всегда.
Летний набор на Асинхронную Архитектуру
У коллег в образовании июль и август считаются «мёртвыми» месяцами — в это время у всех мало продаж. Предполагаю, что это из-за традиционного сезона отпусков. У нас как всегда всё не так, как у других, и летом мы работаем точно так же, как и весь остальной год. Основная причина — мы довольно редко повторяемся. У нас нет 15 «запусков» одного и того же материала в год — мы любим делать новое, а не вечно ездить на старом.
Сейчас мы объявляем летний набор на «Асинхронную архитектуру». Это — самый долгоживующий наш курс: запускаем набор уже в пятый раз. Обучение стартует 28 июля — будет легче взять отпуск для обучения. Курс полезен всем, кто имеет дело с продакшен-проектами, в которых больше одного репозитория. Даже если вы джун, который пилит монолит в маленьком стартапе, курс вам поможет: мышление проектировщика позволяет писать более понятный и изолированный код.
Обратите внимание — теперь у нас два курса о проектировании систем. Курс, на который мы открыли набор, посвящён проектированию распределённых систем, а недавно запущенный «Анализ систем» — более общий: он про стратегически анализ бизнеса и работу с требованиями. Говоря грубо — на «Асинхронной архитектуре» мы строим систему на event-driven архитетктуре, а на «Анализе систем» — учимся выбирать между 7 разными архитектурными стилями. Если не знаете с чего начать или хотите просто познакомиться с распределёнными системами — идите на «Архитектуру». Если ищете фундаментальных знаний по проектированию ПО — записывайтесь в список ожидания следующего потока «Анализа», надеемся он будет в этом году.
Обучение стартует 28 июля. До 1 июля действует цена для ранних пташек. Потоков в этому году больше не будет.
Смотреть программу и отызывы →
Преждевременное старение
В айтишечке (думаю и везде) есть понятие дедов — это чуваки, которые знают и умеют ТАК МНОГО, что имеют право с высоты взирать на происходящее, будь то новый статически типизированный язык, очки виртуальной реальности или новый способ разработки мобильных приложений. Деды знают, что технологии развиваются по спирали и ни за что не сядут ни на один хайптрейн (разве что за 2х).
В жизни у деда тоже всё хорошо — за свои 20 лет в айтишечке он скорее всего заработал себе на квартиру/дачу/эмиграцию. В общем-то, дед — состоявшийся успешный профессионал, по всем меркам.
Самый главный грех деда — отсутствие любопытства. Первые деды, которых я встретил в карьере, не признавали веб-фреймворки и считали, что это никчёмная обёртка над веб-скриптами с роутером. Потом были деды, которые не видели смысла в react.js (всё ж можно самому написать), в блокчейне, в SaaS. Где-то по дороге потерялись деды, которые не верили в сенсорные интерфейсы.
Наверное все деды, которых я встретил, были очень умными людьми — если бы они не потеряли любопытство, запершись в своём домике, индустрия сейчас продвинулась бы гораздо дальше — кто-нибудь на пару лет раньше наконтрибутил бы в реакт хуки и нормальный рендер, кто-нибудь помог бы новому стартапу найти product-market fit, пока не кончились деньги инвесторов. Материальное положение у таких дедов было бы стабильнее — они не приросли бы к одному работодателю, который поддерживает их старые технологии.
Лично я хочу оставаться любопытным как можно дольше. В жизни это получается довольно легко — всё-таки предпринимательство заставляет постоянно учиться новому. А вот в технологиях получается хреново: непонятно как отличать здоровый скепсис от преждевременного старения. Правда ли нет смысла переходить на новую macos, или это я старпёрю? Правда ли async в питоне не нужен? Правда ли кубернетис — раздутое говно? Может зря я не ношу Apple Watch?
Пока, самое лучшее, что я придумал — это тренировать любопытство в других местах: целенаправлено делать вещи, которых никогда не делал. Начиная с банальных активностей уровня съездить-куда-нибудь-испытать-что-нибудь и заканчивая длительными и сложными хобби вроде музыки.
А вы беспокоитесь о преждевременном старении? Как предотвращаете?
В пятницу стартует обучение на третьем потоке «Вы приняты». Помимо конкретных и хардовых знаний о поиске работы (выбор\поиск компании, резюме, собеседования), фишка курса — поддержка: работу искать гораздо легче, когда сидишь в чатике с несколькими десятками таких же как ты разработчиков, которые прямо сейчас отправляют резюме и проходят собеседования. Кто-то наступает на грабли, делится в чате — другие потом их обходят.
Если сомневаетесь стоит ли вообще искать работу за рубежом — посмотрите первый урок: засомневаетесь ещё больше (правда).
Если не сомневаетесь, но не уверены стоит ли покупать курс — приходите сегодня в 18:00 MSK на стрим: с Димой ответим на вопросы о курсе и, если успеем, — о поиске работы. Ссылку скину сюда ближе к делу. Записи не будет.
Управленческий долг
Развивал мысль про асинхронную коммуникацию, и задумался, что настраиваю бизнес по тем же алгоритмам, по которым раньше писал код — поддерживаю высокий cohesion внутри команд/отделов и низкий coupling между ними; стараюсь сделать происходящее понятным всем участникам без комментариев; ввожу метрики, которые показывают здоровье компании (в аутсорсе это в первую очередь runway). И конечно везде слежу за количеством управленческого долга.
Управленческий долг работает так же, как технический — в самый ненужный момент выстреливает и пожирает всё внимание. Неверно посчитанные налоги потребуют несколько десяток личных поездок в налоговую на другой конец города. Поверхностный онбординг для менеджеров со временем заставит срочно перехватывать управление у плохо внедреённого новичка. Неудачно нанятый человек будет требовать ресурсов, чтобы с ним няньчиться. По неподписанному договору рано или поздно не оплатят сделанную работу.
Кажется мне здорово повезло с этой программистской привычкой к порядку: каждый раз ужасаюсь, когда встречаю управленцев, которые постоянно сидят на связи и разруливают ВНЕЗАПНО выстреливший управленческий долг
Мы с Марьяной любим читать отзывы — обычно вместе с похвалой туда добавляют ещё важную обратную связь, которая помогает нам становиться лучше. Ещё больше я люблю наблюдать, как курсы меняют программистов в реальной жизни — в «Феде и Самате» все сотрудники бесплатно проходят наши курсы, и приносят наши же улучшения в ежедневную работу.
Довольно странные чувства я испытал, когда в прошлом году доступ к курсу «Вы приняты» попросил один из наших ведущих фронтендеров (привет, Миша!). Ну что я могу сказать — курс работает так же, как и остальные: Миша переехал в Германию и теперь работает в Джетбрейнсе.
В списке ожидания накопилось много запросов, так что мы запускаем третий поток. Если вы программист и ищете (или думаете искать) работу за рубежом — приходите, стартуем 16 июня. Главный эксперт курса — Дима Рожков, живет в Германии с 2014 года и сам прошел весь путь поиска работы за рубежом. Нанимает со всего мира, консультирует по переезду и собеседованиям.
Курс длится три недели. Первая посвящена поиску компании и оценке офера, вторая — линкедину, сопроводительным письмам и резюме, а третья — подготовке к собеседованиям. Для тех, кто купит курс до понедельника действует скидка 10% по промокоду AGRIMOTOR до 6 июня.
Если вы состоите в чатике сильных программистов — не забудьте применить свою скидку — она побольше. И если читаете рассылку — тоже подождите, мы скоро пришлем отдельное предложение.
#вопрос часто используем в работе headless cms для небольших проектов. Как относишься к такого рода продуктам?
Отношусь хорошо — мы и сами собрали несколько медиа-проектов на sanity. Риски у headless cms такие же, как и у любых других вендорских проектов:
— Точки интеграции: понятное ли API? Гибкое ли? Легко ли на нём выполнять требования бизнеса? Идеально при принятии решения накидать прототип, который показывает вашу таксономию, фильтры и подборки (читают так же/ похожие/что там у вас).
— Владение данными: понятно ли как доставать данные из вендора? Достаточно их, чтобы мигрировать к конкуренту?
— Quality of life: кайфовые ли технологии? Легко ди тестировать? не требует ли какого-нибудь экзотического дерьма для разработки? Может у вас все линуксоиды, а тестовый сервер поднимается только под виндой
— Сапорт. Хотят ли люди на той стороне решать ваши проблемы?
— Юрисдикция. Какие шансы, что вас заканселят?
Если прошлись по рискам и всё ок — поздравляю, вероятно вы сэкономите себе много времени.
Это был традиционный вопрос по понедельникам. Задать свой — fborshev@pm.me