25563
Рассказываю, как руководить программистами fborshev@pm.me / borshev.com Реклама не продаётся
#вопрос как вежливо объяснить менеджеру, что он просит фигню? У нас горят дедлайны, нужно код писать, а он просит декомпозировать задачи и написать план на неделю.
Для начала я бы разобрался в причинах. Обычно, когда менеджер просит сделать неприятную фигню вроде плана на неделю — за этим стоит какая-то понятная проблема. Может вы несколько недель подряд не выполняли устных обещаний и теперь от вас требуют письменных? А может на проекте едут сроки, и менеджер пытается построить какой-то план выхода из кризиса? А может вообще он решает не очень внятную, но важную для всех задачу, вроде того, чтобы убедить заказчка, что он не зря тратит деньги на команду разработки?
Конечно дело может быть и в менеджере. Начинающие ребята иногда не могут отличить процесс от результата. Появляется ощущние, что они работают по скрипту — приходят в сработанную команду самостоятельных ребят, и начинают разбираться почему в ней нет дейли-митингов или каждую неделю все не собираются на ретроспективу.
Самый простой способ справиться с менеджером, который просит вас сделать фигню — это узнать, о чём у него сейчас болит голова, и как он собирается с помощью фигни, о которой вас просит, эту головную боль решить. Хороший менеджер ненавидит лишнюю работу, поэтому легко всё объяснит. Плохой начнёт мямлить по поводу процессов или того, что руководство попросило.
————————
Это — возвращение вопросов по понедельникам. Задавайте любые вопросы на 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. Какой — не посоветую, все они до сих пор хреновые.
Тимлидская папка
Тут в ребята собрали папку с 15 телеграм-каналами для тимлидов. Я там тоже есть — кайф! Почитав папку, немного улучшил кругозор — кажется теперь я больше знаю, о чём болит голова у русскоязычных тимлидов и сочувствующих.
По ссылке можно сразу подписаться на все. Если беситесь от красных кружочков — выделите 30 минут, почитайте все каналы и подпишитесь на те, в которых найдёте что-нибудь непривычное или непонятное. Привычные и понятные каналы точно добавлять не стоит — нафига вам красные кружочки с тем, что вы уже знаете? :-)
Анализ систем: стартуем в пятницу!
12 мая, в эту пятницу, мы стартуем новый курс с Антоном Давыдовым — Анализ Систем.
Для меня курс — об осознанном проектировании систем. Каждый программист рано или поздно проектирует системы, но единицы делают это, понимая что происходит: большинство почему-то думает не от бизнеса, а от технологий, которые услышали на последней конференции.
На курсе учимся стратегическому анализу бизнеса и DDD, рассматриваем несколько архитектурных стилей, учимся выбирать БД и способы коммуникации, работать со стейкхолдерами и писать документацию. Самый главный урок, ради которого всё задумывалось — четвёртый: в нём мы даём пошаговые рекомендации по распилу монолитов на базе теории из первых уроков. Отдельная гордость Антона — несколько сотен ссылок на дополнительные материалы, если захотите углубиться в какую-то из тем. Хватит на год вперед.
Джунам курс не подойдёт. Мидлам подойдёт. Если есть, где применить полученные знания, или просто очень интересуетесь проектированиям — обязательно берите тарифы с обратной связью. Синьёрам, помидорам, принципалам и CTO пойдёт в любом случае.
Стартуем в пятницу, есть ещё одно VIP-место с личной обратной связью и консультацией.
Смотреть программу →
Достоен ли я асинхронной коммуникации?
Все хотят работать асинхронно — не быть постоянно на связи с коллегами, отвечать когда удобно, а не когда спросили, иметь большие промежутки времени на творческую работу. Но не все этого достойны.
Вообще-то начать работать асинхронно можно в любой команде — если телега\слак установлены у вас на компьютере, значит вы всегда можете их выключить или хотя бы отключить уведомления. Вопрос в том, что будет происходить во время вашего отсутствия.
Попробуйте честно ответить для себя — а достойны ли вы асинхроннной работы? Не нужно ли вас пинать, чтобы вы делали задачи вовремя? Когда вы говорите «сделал» это означает «создал пул-ревест» или «код работает на проде и влияет на метрики»? Достаточно ли ваших знаний находятся в общем пространстве, или коллегам без вас ничего не понятно?
Если что-то из этого в беспорядке — будет тяжело даже отключить уведомления: вас всё равно найдут и заставят общаться. А если всё в порядке — скорее всего никто и не заметит вашего отсутствия. Серьёзно — я видел ребят, которые асинхронно работают в совершенно синхронных офисных командах просто потому, что свято соблюдают принцип «пацан сказал — пацан сделал».
Аргумент как продавать мониторинг
Недавно убеждал одну команду установить себе нормальный APM. Основной аргумент против был «у нас есть <отечественный сервис-пинговалка>, если что-то случится, он нам сообщит».
Нормальный мониторинг по сравнению с пинговалками (не важно, отечественными или нет) — это как превентивный медосмотр против сообщения «поздравляем, вы умерли».
Мониторинг показывает проблемы в приложении задолго до того, как они выстреливают: если у вас 20% пользователей получают 500 ошибку, то с пинговалкой вы об этом не узнаете, пока она не попадёт в эти 20%. Если у вас потихоньку растёт latency у базы, вы не узнаете об этом, пока пинговалка, вместе с нормальными пользователями, не начнёт отваливаться по таймауту. Datadog, к примеру, позволяет даже не настраивать никакие триггеры — просто запускаете в нём watchdog, и он сам напишет, если что-то не так.
В общем сбор данных — это про проактивность, а алёрты «сайт упал» — про реактивность. Если у вас на работе всё ещё настроены пинговалки вместо нормального мониторинга — обязательно поговорите с CTO об этом.
За одного битого двух небитых дают
Когда я собеседую программистов, большой плюс для меня — это негативный опыт. Очень ценю ребят, которые могут рассказать, как они спроектировали систему, которая превратилась в большой комок грязи или проработали пару лет в кровавом энтерпрайзе без тестов и 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
Марьяна завела себе прикольную традицию — одной строкой рассказывать, как у неё в проектах идут дела, что нового\интересного случилось. Давайте попробуем это здесь?
— С Саматом доросли до двух ключевых клиентов и 20 человек в компании. За год мы выросли в два раза и не упали в качестве. Хоть и прощаемся сейчас с одним из клиентов — будем расти дальше.
— Запустили обучение на выстраданном курс «Анализ Систем». Материалами я доволен, хотя и недоволен количеством усилий, которое мы на них потратили: за год над текстами поработало 6 (!) человек, для нас это очень много.
— LMS: новая LMS в школе работает офигенно — у студентов нет вопросов, материалы рендерятся приятно глазам. Конечно огрехи есть, но они понятные, и их список — конечен.
— Недавно мы со своим хождением в приватное API ноушена стали попадать под капчу клаудфлера. Справились быстро, немного посомневались в идее юзать ноушен как бекенд для LMS, но решили что всё делаем правильно. Сейчас планируем ещё ряд продуктовых доработок.
— Сделал бухгалтерское открытие — оказывается в нашей стране электронный документооборот работает не только для юрлиц. Внедряем Контур.КЭДО, чтобы без бумаг обмениваться документами с сотрудниками. Горжусь что спрятал от команды ещё один бюрократический препон.
#вопрос Почему ты делаешь из vim IDE, хотя есть готовые IDE, в которые можно вставить vim?
Вообще я уже сейчас уже совсем мало пишу кода, но попробую ответить из полугодичной давности.
Во-первых, потому что могу. Несмотря на любовь к программированию и то, что я сам себе выбираю задачи — эта работа бывает для меня скучной, а значит выматывающей. Когда я пользуюсь инструментов, в котором я сам сконфигурил все нюансы, я получаю гораздо больше удовольствия от процесса, а значит меньше скучаю и меньше трачу сил.
Во-вторых, мне очень важна скорость и энергоэффективность. Скорость — потому что я ненавижу системы с плохим дизайном, которые тратят моё время на свои проблемы. Проиндексировать проект или загрузить все плагины — это работа IDE, а не моя. Так почему я должен этого ждать?
С энергоэффективностью тоже всё просто — я люблю покодить в кафе. Возможно на M1 всё стало побыстрее, не знаю — ни разу не запускал на нём ничего тяжёлого.
В любом случае я не призываю никого использовать редакторы текста вместо IDE — у нас в fands, к примеру, больше половины сотрудников пользуются продуктами jetbrains. Главное, в обоих случаях, — не жалеть времени на настройку инструментов.
Это был традиционный ответ на вопрос по понедельникам. Задать свой — fborshev@pm.me
В этот четверг проводим с Антоном Давыдовым стрим про будущий курс «Анализ Систем».
Мы проводим такие встречи уже год, со времён первого потока «Вы приняты» с Димой Рожковым. Для студентов — это возможность сделать превью и убрать сомнения: поговорить о формате обучения и о содержимом курса. Для нас — выровняться со студентами: всё ли хорошо рассказали на лендинге? полностью ли покрывает программа запросы?
Если сомневаетесь, стоит ли покупать курс — приходите 4 мая в 19:00. Ссылку на трансляцию выложим сюда. Записи не будет.
#вопрос вот бывает пишешь какому-нибудь занятому чуваку, типа CEO, а он не отвечает. Как тактично напомнить о себе?
Неответ — это тоже ответ. Поищете проблемы не в занятом чуваке, а в письме. Их не так уж и много — ваше письмо скорее всего или неинтересное, или сложное.
К примеру я не отвечаю на предложения купить рекламу в этом канале — мне это просто неинтересно. Занятый CEO наверняка не ответит вам на просьбу встретиться, если подумает, что вы захотите поговорить про технологии — для него это зона ответственности CTO.
Вторая причина — на ваше письмо ответить сложно. К примеру известный блогер вряд ли ответит на предложение прийти на очередную конференцию, если из этого предложения не будет понимать, какая там аудитория, и какие спикеры уже согласились. Занятый CEO большой компании вряд ли посмотрит ваше резюме на джуниорскую позицию — он скорее всего даже не знает, куда его форварднуть.
Так что если вам не отвечают — первым делом перечитайте письмо. Как можно сделать ваше предложение более интересным? Как можно сделать ответ на ваше письмо более простым? И только после этого — напоминайте.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me