Про переусложнение простого
Начинающие сениоры и архитекторы часто страдают болезнью переусложнения. Почему-то они считают, что простое решение недостойно звания старшего специалиста и в него нужно добавить изюминку. Помню, как в давние времена разработчики лепили паттерны из GoF в каждом первом проекте. Там были сигнлтоны, которые порождали абстрактные фабрики, которые создавали стратегии. Для дебага и поиска ошибок в этом поделии нужно было хорошо так залезать на Балмеровский пик.
Для меня признаком зрелости спеца - это умение делать сложное простым. Поэтому для код-ревью я использую "Критерий уставшего мидла". Если уставший после пятницы мидл в три часа ночи может починить упавший прод, поправив багу в незнакомом ему коде - это хороший, годный код.
Это критично для устойчивости проекта во времени. Потому что ваши сениоры уйдут на повышения, на их место придут новенькие и ваш код сразу станет черным ящиком - работает, но непонятно как и который никто не хочет трогать.
Даже годовалый проект таким образом может стать легаси.
Начинающие сениоры и архитекторы часто страдают болезнью переусложнения. Почему-то они считают, что простое решение недостойно звания старшего специалиста и в него нужно добавить изюминку. Помню, как в давние времена разработчики лепили паттерны из GoF в каждом первом проекте. Там были сигнлтоны, которые порождали абстрактные фабрики, которые создавали стратегии. Для дебага и поиска ошибок в этом поделии нужно было хорошо так залезать на Балмеровский пик.
Для меня признаком зрелости спеца - это умение делать сложное простым. Поэтому для код-ревью я использую "Критерий уставшего мидла". Если уставший после пятницы мидл в три часа ночи может починить упавший прод, поправив багу в незнакомом ему коде - это хороший, годный код.
Это критично для устойчивости проекта во времени. Потому что ваши сениоры уйдут на повышения, на их место придут новенькие и ваш код сразу станет черным ящиком - работает, но непонятно как и который никто не хочет трогать.
Даже годовалый проект таким образом может стать легаси.
👍4
Байка про переусложнение
Немедленно вспомнился один релиз, который мы делали 30 декабря. Все были на позитивчике, готовятся к праздникам, шутят шутки. Хотели закончить на позитиве год, порадовать заграничного заказчика свеженьким функционалом.
Наш лид-бекенд пушит код и уходит в закат. Лид был грамотным, поэтому никто в его рабочести не сомневался. Но конечно же, на стейдже нашлась сотня строчек в базе, на которых код падал. Так как лид был грамотным, два миллиона записей обрабатывались одним Java стримом с лямбдой внутри. Лямбда была строчек на 10, в ней вселенные росли и рушились, а падала она после 20 минут работы.
Продолбавшись пару часов, мы откатили все обратно и пошли выпивать уже с горя. С тех пор сложный код я не пропускаю...
Немедленно вспомнился один релиз, который мы делали 30 декабря. Все были на позитивчике, готовятся к праздникам, шутят шутки. Хотели закончить на позитиве год, порадовать заграничного заказчика свеженьким функционалом.
Наш лид-бекенд пушит код и уходит в закат. Лид был грамотным, поэтому никто в его рабочести не сомневался. Но конечно же, на стейдже нашлась сотня строчек в базе, на которых код падал. Так как лид был грамотным, два миллиона записей обрабатывались одним Java стримом с лямбдой внутри. Лямбда была строчек на 10, в ней вселенные росли и рушились, а падала она после 20 минут работы.
Продолбавшись пару часов, мы откатили все обратно и пошли выпивать уже с горя. С тех пор сложный код я не пропускаю...
👍1
Зачем нужно два саб-лида
В любой долгоживущей команде от 5 человек нужно заводить себе заместителя. Он может принимать решения от моего имени, имеет полномочия и ответственность. Это нужно на случай:
- отпуска
- карьерного роста
- смены проекта
- личностного кризиса, когда все надоело
- ухода из компании/проекта
Про это учил еще Стратоплан в 2010-х годах, но почему-то для многих лидов сейчас это становится инсайтом....
Но эта структура хрупкая. Заместитель сам может уволиться, уйти на другой или просто не справиться. Поэтому я всегда завожу двух подлидов. Оно надежней с точки зрения рисков, распределения нагрузки и антихрупкости.
Потому что самая устойчивая фигура - это треугольник.
В любой долгоживущей команде от 5 человек нужно заводить себе заместителя. Он может принимать решения от моего имени, имеет полномочия и ответственность. Это нужно на случай:
- отпуска
- карьерного роста
- смены проекта
- личностного кризиса, когда все надоело
- ухода из компании/проекта
Про это учил еще Стратоплан в 2010-х годах, но почему-то для многих лидов сейчас это становится инсайтом....
Но эта структура хрупкая. Заместитель сам может уволиться, уйти на другой или просто не справиться. Поэтому я всегда завожу двух подлидов. Оно надежней с точки зрения рисков, распределения нагрузки и антихрупкости.
Потому что самая устойчивая фигура - это треугольник.
Микросервисы: байка с собеседования
Как-то я собеседовался на Solution Architect к одному большому, но не особо интересному мне заказчику. Настроение было хорошим и я решил отвечать не по стандартному STAR, а по настроению.
И на стандартный вопрос "Ваше самое сложное решение в архитектуре" я ответил - "Уговорил заказчика переехать с микросервисов на монолит". Потому что его желание сделать модно и отрапортавать о внедрении подхода прямо конфликтовало с нефункциональными требованиями и fit for purpose. А так как само приложение было важнее, чем фейковые микросервисы, мы быстро его написали и укатили в прод.
Неожиданно для меня, CTO на той стороне оказался нашим человеком и понимающе заулыбался. Для меня это было как осознать, что мы не одни во вселенной.
Как-то я собеседовался на Solution Architect к одному большому, но не особо интересному мне заказчику. Настроение было хорошим и я решил отвечать не по стандартному STAR, а по настроению.
И на стандартный вопрос "Ваше самое сложное решение в архитектуре" я ответил - "Уговорил заказчика переехать с микросервисов на монолит". Потому что его желание сделать модно и отрапортавать о внедрении подхода прямо конфликтовало с нефункциональными требованиями и fit for purpose. А так как само приложение было важнее, чем фейковые микросервисы, мы быстро его написали и укатили в прод.
Неожиданно для меня, CTO на той стороне оказался нашим человеком и понимающе заулыбался. Для меня это было как осознать, что мы не одни во вселенной.
😁3
Собеседования как казино
К слову, за свою карьеру я провел под тысячу собеседований и сам прошел под сотню. Имею сказать, что собеседование - это полное казино. Безусловно, готовиться к собесам надо и можно провалидировать себя через какие-то сервисы или людей. Но вот оценивать себя только через них - нельзя, ибо уроните самооценку и уверенность в себе. Потому что честный фидбек вам никогда не дадут.
Топ моих забавных причин. когда-то отказывали мне:
1. Я не знаю, как создать команду с нуля (ответил на вопрос поверхностно). К этому моменту у меня было два выступления на TLC про создание команды и я кидал рекрутерам статьи.
2. Я плохо отношусь к людям и в Scrum-мастера не подойду.
3. Я не умею запускать потоки в Java Swing.
4. Я никогда не вел к общей цели большие команды. То, что я был программом на 50+ человек - это не считается, потому что у каждой команды цели были свои.
За этими отказами может стоять все, что угодно:
- с женой утром поругался
- не состоялась химия
- отвечал слишком уверенно
- отвечал неуверенно
- резюме слишком большое
- человека уже заофферили на позицию и тебя собеседуют как запасной аэродром
При случае расскажу, по каким странным причинам отказывали коллеги.
К слову, за свою карьеру я провел под тысячу собеседований и сам прошел под сотню. Имею сказать, что собеседование - это полное казино. Безусловно, готовиться к собесам надо и можно провалидировать себя через какие-то сервисы или людей. Но вот оценивать себя только через них - нельзя, ибо уроните самооценку и уверенность в себе. Потому что честный фидбек вам никогда не дадут.
Топ моих забавных причин. когда-то отказывали мне:
1. Я не знаю, как создать команду с нуля (ответил на вопрос поверхностно). К этому моменту у меня было два выступления на TLC про создание команды и я кидал рекрутерам статьи.
2. Я плохо отношусь к людям и в Scrum-мастера не подойду.
3. Я не умею запускать потоки в Java Swing.
4. Я никогда не вел к общей цели большие команды. То, что я был программом на 50+ человек - это не считается, потому что у каждой команды цели были свои.
За этими отказами может стоять все, что угодно:
- с женой утром поругался
- не состоялась химия
- отвечал слишком уверенно
- отвечал неуверенно
- резюме слишком большое
- человека уже заофферили на позицию и тебя собеседуют как запасной аэродром
При случае расскажу, по каким странным причинам отказывали коллеги.
👏2
Про Agile-коучей
В среде разработчиков Agile-коучей часто считают лучезарными п*здаболами, которые мешают писать код. Раньше я на эгегей начинал объяснять, что это сопротивление переменам и вообще они все скоро поймут как были неправы.
Только вот они правы. Agile-коуч - это такое же расплывчатое наименование, как разработчик. Если мы делим разрабов по технологиям, направлениям, фокусам, то почему такого нет с коучами?
Для себя я выделяю следующие породы агилистов:
- новичек-процессник - умеет выстраивать Scrum или SAFe как по книжке.
- коуч-фасилитатор - задает мощные вопросы и делает все через фасилитацию. Закончил Эриксона. В технике полный ноль.
- технарь-девопёс - настраивает технический поток ценности, JIRA всякие и прочие автоматизации. Фасилитировать не любит, с топами общаться не умеет.
- Труъ-коуч - может комбинировать любые из этих ролей, умеет найти корень проблемы. Вот он - ваш бро и принесет пользу. Стоит как крыло самолета и на рынке не валяется.
- еще 300 гендеров видов и названий себя, которые являются попыткой сделать Уникальное Торговое Предложение, но с своей сути относятся к первым трем.
Если по счастливой случайности HR'ы выбрали правильную породу, то происходит матч и кейс схлопывается. А вот если не повезло, то коуч выдрючивает команду на то, что сам умеет. В лучшем случае выходит локальная субоптимизация. В худшем - ломается текущий статус-кво и команда перестает нормально деливерить.
Поэтому выбирайте инструменты под ваши цели, а не по инсте/фоточкам/цене. Вы же не посадите писать Java код специалиста по микроконтроллерам, хотя и тот и тот - программисты.
В среде разработчиков Agile-коучей часто считают лучезарными п*здаболами, которые мешают писать код. Раньше я на эгегей начинал объяснять, что это сопротивление переменам и вообще они все скоро поймут как были неправы.
Только вот они правы. Agile-коуч - это такое же расплывчатое наименование, как разработчик. Если мы делим разрабов по технологиям, направлениям, фокусам, то почему такого нет с коучами?
Для себя я выделяю следующие породы агилистов:
- новичек-процессник - умеет выстраивать Scrum или SAFe как по книжке.
- коуч-фасилитатор - задает мощные вопросы и делает все через фасилитацию. Закончил Эриксона. В технике полный ноль.
- технарь-девопёс - настраивает технический поток ценности, JIRA всякие и прочие автоматизации. Фасилитировать не любит, с топами общаться не умеет.
- Труъ-коуч - может комбинировать любые из этих ролей, умеет найти корень проблемы. Вот он - ваш бро и принесет пользу. Стоит как крыло самолета и на рынке не валяется.
- еще 300 гендеров видов и названий себя, которые являются попыткой сделать Уникальное Торговое Предложение, но с своей сути относятся к первым трем.
Если по счастливой случайности HR'ы выбрали правильную породу, то происходит матч и кейс схлопывается. А вот если не повезло, то коуч выдрючивает команду на то, что сам умеет. В лучшем случае выходит локальная субоптимизация. В худшем - ломается текущий статус-кво и команда перестает нормально деливерить.
Поэтому выбирайте инструменты под ваши цели, а не по инсте/фоточкам/цене. Вы же не посадите писать Java код специалиста по микроконтроллерам, хотя и тот и тот - программисты.
🔥1
Не используйте микросервисы в глухом энтерпрайзе
Это небольшой тизер статьи про микросервисы.
Интегрировался как-то мой друг с одним микросервисом в большом энтерпрайзе. Контракт описан JSON схемой, по ней сгенерирован класс. Казалось бы, напишет такое даже восьмилетний ребенок. Но как-то все время получается, что микросервис отдает всегда пустой ответ (контрактом не запрещено, аналог 404). Коллега c другой стороны говорит, что все работает и данные отдаются.
В общем, надо было залезть в дебаг и посмотреть ответ (см. картинка 2). Автор микросервиса с тиой стороны утверждает, что все ок и иногда он будет слать ошибки. А чтобы было проще читать (?) он свалили все поля в optionalParameters.
Именно поэтому я всегда говорю, что микросервисны крайне требовательны к команде/культуре и то, что не нужно их пихать где придется.
Это небольшой тизер статьи про микросервисы.
Интегрировался как-то мой друг с одним микросервисом в большом энтерпрайзе. Контракт описан JSON схемой, по ней сгенерирован класс. Казалось бы, напишет такое даже восьмилетний ребенок. Но как-то все время получается, что микросервис отдает всегда пустой ответ (контрактом не запрещено, аналог 404). Коллега c другой стороны говорит, что все работает и данные отдаются.
В общем, надо было залезть в дебаг и посмотреть ответ (см. картинка 2). Автор микросервиса с тиой стороны утверждает, что все ок и иногда он будет слать ошибки. А чтобы было проще читать (?) он свалили все поля в optionalParameters.
Именно поэтому я всегда говорю, что микросервисны крайне требовательны к команде/культуре и то, что не нужно их пихать где придется.
Про диктатуру архитектората и техлидеротората
Самоорганизация команды вокруг требований, intentional архитектура - это правильно и модно. Я даже такое на тренингах советую. Но есть ряд вещей, которые должен решать только архитектор/техлид с группой избранных.
В основном, это касается явных (масштабируемость, скорость, нагрузка) и неявных (мониторинг, майнтейнабилити) нефункциональных требований. Для контроля исполнения обязателен архитектурный надзор, потому что разработчики на все ваши требования положат огромный болт. А разгребать это все придется вам.
Вот вам живой пример заваленного NFR
Поэтому, если вы техлид или архитектор:
1. NFR всегда становятся частью Code Review. За несоблюдение - жесткая кара
2. То же логирование можно проверять на уровне анализаторов кода. Тогда карать будет бездушная железка.
Правила возводятся в абсолют, пока это не станет частью инженерной культуры.
А критерий проверки хороших логов - дать их почитать рандомному суппорту 2-3 уровня. Если он поймет где ошибка и что с ней делать, то логи годные.
Самоорганизация команды вокруг требований, intentional архитектура - это правильно и модно. Я даже такое на тренингах советую. Но есть ряд вещей, которые должен решать только архитектор/техлид с группой избранных.
В основном, это касается явных (масштабируемость, скорость, нагрузка) и неявных (мониторинг, майнтейнабилити) нефункциональных требований. Для контроля исполнения обязателен архитектурный надзор, потому что разработчики на все ваши требования положат огромный болт. А разгребать это все придется вам.
Вот вам живой пример заваленного NFR
Observability. C ошибкой падает один из микросервисов, в логах одна строчка IllegalArgumentException: Invalid Data без указания чего бы то ни было. Ей богу, лучше бы стектрейс выплюнули. Воспроизводится, конечно же, только на окружении. А логи писать не нужно, потому что ну и так все работает и из кода понятно.Поэтому, если вы техлид или архитектор:
1. NFR всегда становятся частью Code Review. За несоблюдение - жесткая кара
2. То же логирование можно проверять на уровне анализаторов кода. Тогда карать будет бездушная железка.
Правила возводятся в абсолют, пока это не станет частью инженерной культуры.
А критерий проверки хороших логов - дать их почитать рандомному суппорту 2-3 уровня. Если он поймет где ошибка и что с ней делать, то логи годные.
👍3
Тест на профессионализм скрам-мастера
Если скрам-мастер не умеет сам настраивать JIRA/Trello/YouTrack, то это не повелитель скрама, а п*здабол. Для инспекции процесса, создании прозрачности и фокуса, таск трекер обязан быть! Исключение - оффлайн доска в офисе (что-то на древнем сказал).
По опыту скажу, что разработчики ругаются на JIRA если:
- она не отображает текущий процесс разработки
- доска не настроена поэтому не имеет ценности
- процесс бюрократизирован
Редкая команда знает, как на самом деле надо, поэтому и считает JIRA отстоем по-умолчанию. А виноват-то на самом деле неквалифицированный кое-кто. Но не бойся мой друг, я скоро выпущу статью про базированную JIRA и твоя доска станет самой лучшей в компании.
А пока протестируй себя или своего скрам-мастера!
Дано: команда фигачит так, что перья летят и закрывает задачи вовремя. Даже берет что-то из беклога. Но её бёрндаун выглядит как на картинке (как в 90% случаев во всех командах).
Вопрос: как сделать так, чтобы берндаун отображался правильно?
Если скрам-мастер не умеет сам настраивать JIRA/Trello/YouTrack, то это не повелитель скрама, а п*здабол. Для инспекции процесса, создании прозрачности и фокуса, таск трекер обязан быть! Исключение - оффлайн доска в офисе (что-то на древнем сказал).
По опыту скажу, что разработчики ругаются на JIRA если:
- она не отображает текущий процесс разработки
- доска не настроена поэтому не имеет ценности
- процесс бюрократизирован
Редкая команда знает, как на самом деле надо, поэтому и считает JIRA отстоем по-умолчанию. А виноват-то на самом деле неквалифицированный кое-кто. Но не бойся мой друг, я скоро выпущу статью про базированную JIRA и твоя доска станет самой лучшей в компании.
А пока протестируй себя или своего скрам-мастера!
Дано: команда фигачит так, что перья летят и закрывает задачи вовремя. Даже берет что-то из беклога. Но её бёрндаун выглядит как на картинке (как в 90% случаев во всех командах).
Вопрос: как сделать так, чтобы берндаун отображался правильно?
👍6
Как и обещал, статья по настройке JIRA и по базированному процессу. Пользуйся, мой юный скрам-мастер и тимлид. https://telegra.ph/Bazirovannaya-JIRA-dlya-timlidaskram-mastera-10-10
Telegraph
Базированная JIRA для тимлида/скрам-мастера
Без таск-трекера (aka JIRA) вы не построите ни скрам, ни канбан, ни херак-херак-в-продакшен. На курсах тимлидов и скрам-мастеров такие низменные вещи не преподают (они сами не знают, это же не цикл Такмана). А без этого инструмента ты теряешь прозрачность…
👍9🔥2
Стоит ли работать с коллегами-м*даками?
Частый вопрос на тренингах скрам-мастеров и тимлидов - "Что делать со сложными подчиненными?". Мой ответ всегда однозначный - если человек м*дак, то убирайте его с горизонта команды. Даже если вы его закоучите и зафасилитируйте до полусмерти, он все равно будет портить атмосферу и командную динамику. Из-за него группа будет меньше общаться, меньше поднимать острых вопросов, не будет доверия.
Что делать, если твой начальник м*дак?
Тут все не так однозначно. Если он - пустышка, то меняйте его безжалостно. Я, обычно, ухожу сам в другую команду/компанию. Просто терпеть и игнорировать у вас долго не получится - вы потеряете мотивацию к работе и получите выгорание. Я в таком случае сразу дистанцируюсь и сворачиваю общение и начинаю искать варианты.
A если вам есть чему поучиться у этого человека, то можно заключить договор с совестью и стиснуть зубы. Гениальность и сумасшествие - они хотят вместе. Больше всего знаний и опыта я получил от крайне сложного человека, который меня практически довел до дурдома. Но оно того точно стоило. Только чтобы не выгореть, нужно вовремя соскочить. Лучше всего поставить себе какие-то четкие критерии по времени или по своему состоянию. Иначе - дурка.
Частый вопрос на тренингах скрам-мастеров и тимлидов - "Что делать со сложными подчиненными?". Мой ответ всегда однозначный - если человек м*дак, то убирайте его с горизонта команды. Даже если вы его закоучите и зафасилитируйте до полусмерти, он все равно будет портить атмосферу и командную динамику. Из-за него группа будет меньше общаться, меньше поднимать острых вопросов, не будет доверия.
Что делать, если твой начальник м*дак?
Тут все не так однозначно. Если он - пустышка, то меняйте его безжалостно. Я, обычно, ухожу сам в другую команду/компанию. Просто терпеть и игнорировать у вас долго не получится - вы потеряете мотивацию к работе и получите выгорание. Я в таком случае сразу дистанцируюсь и сворачиваю общение и начинаю искать варианты.
A если вам есть чему поучиться у этого человека, то можно заключить договор с совестью и стиснуть зубы. Гениальность и сумасшествие - они хотят вместе. Больше всего знаний и опыта я получил от крайне сложного человека, который меня практически довел до дурдома. Но оно того точно стоило. Только чтобы не выгореть, нужно вовремя соскочить. Лучше всего поставить себе какие-то четкие критерии по времени или по своему состоянию. Иначе - дурка.
👍11❤2