Собеседования как казино
К слову, за свою карьеру я провел под тысячу собеседований и сам прошел под сотню. Имею сказать, что собеседование - это полное казино. Безусловно, готовиться к собесам надо и можно провалидировать себя через какие-то сервисы или людей. Но вот оценивать себя только через них - нельзя, ибо уроните самооценку и уверенность в себе. Потому что честный фидбек вам никогда не дадут.
Топ моих забавных причин. когда-то отказывали мне:
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
По моему личному опыту, скрам-мастер НЕ технарь раскрывается только при наличии технического лидера в команде или если команда сама по себе сильная (типа, мотивированные профессионалы). В в таком случае он делает из хаоса систему и его помощь с фасилитацией очень в тему.
А в среднего уровня команде, ты хоть до смерти закоучи, результата не будет.
А в среднего уровня команде, ты хоть до смерти закоучи, результата не будет.
👍5
Как не деградировать в слабой команде
Где-то с середины моей карьеры я стараюсь не работать в слабых командах. Работа в них - это время в никуда. Научиться у таких коллег нечему, научить и подтянуть их - практически невозможно, да и незачем. Для менеджмента это не видно, денег за это не дают, а твои коллеги на своем перформанс ревью не будут упоминать твои старания.
В слабые команды стоит вписываться только если у тебя есть четкий план и цель. Например:
- Отдохнуть после сложного проекта/поделать дела - работаешь три-четыре часа, остальное время играешь в игры, ходишь в зальчик, готовишься к собесам. Твое раздолбайство все равно никто не заметит.
- Деньги - золотую клетку никто не отменял, семью кормить надо.
- Отрабатываешь навыки - нужна строчка в CV, хочешь потрогать технологию или побыть тимлидом.
Чтобы не выгореть и не деградировать, я себе ставил некоторые критерии выхода. Это помогает в особо тяжелые случаи, когда хочется все послать подальше.
- Временной промежуток - годик поработаю, посмотрю, что дальше будет.
- Критерий выполнения цели, ради которой пошел на дауншифтинг
- "Стоп-слово" - какой-то четкий критерий, что нужно валить. Например, явное выгорание или падение мотивации в плинтус даже для выполнения своих целей.
Мне этот прием помогает не выгорать и держать мотивацию и фокус.
Где-то с середины моей карьеры я стараюсь не работать в слабых командах. Работа в них - это время в никуда. Научиться у таких коллег нечему, научить и подтянуть их - практически невозможно, да и незачем. Для менеджмента это не видно, денег за это не дают, а твои коллеги на своем перформанс ревью не будут упоминать твои старания.
В слабые команды стоит вписываться только если у тебя есть четкий план и цель. Например:
- Отдохнуть после сложного проекта/поделать дела - работаешь три-четыре часа, остальное время играешь в игры, ходишь в зальчик, готовишься к собесам. Твое раздолбайство все равно никто не заметит.
- Деньги - золотую клетку никто не отменял, семью кормить надо.
- Отрабатываешь навыки - нужна строчка в CV, хочешь потрогать технологию или побыть тимлидом.
Чтобы не выгореть и не деградировать, я себе ставил некоторые критерии выхода. Это помогает в особо тяжелые случаи, когда хочется все послать подальше.
- Временной промежуток - годик поработаю, посмотрю, что дальше будет.
- Критерий выполнения цели, ради которой пошел на дауншифтинг
- "Стоп-слово" - какой-то четкий критерий, что нужно валить. Например, явное выгорание или падение мотивации в плинтус даже для выполнения своих целей.
Мне этот прием помогает не выгорать и держать мотивацию и фокус.
👍9
Не учите джунов лидами
Делал я недавно код-ревью у соседнего микросервиса . Код был с душком, я честно давал комментарии почти к каждой строчке. Минут через 15 появилось желание все реджектнуть с резолюцией "нах*р все переписать", потому что так и надо было сделать. В итоге, я сделал approve и merge. Микросервис не мой, а если совсем много проблем будет, то быстрее с нуля все переписать самому.
То рассказ не только про то, что я ленивый зажравшийся чудак, тут есть глубокая мысль.
Менторинг и обучение младшего специалиста лучше всего проводит специалист максимум на одну-две ступеньки выше. Для него это в новинку, он сам учится чему-то новому в процессе. Опытный лид будет это делать либо крайне грубо, либо на отвали. Ему банально скучно объяснять азы кодирования и очень дорого с точки зрения времени.
Есть единственное исключение - это инициатива старшего товарища. То может быть либо личная симпатия, либо обучение обучению (грубо говоря, лид учит сениора делать код-ревью без матов на примере джуна).
Так что если вы лид - не совершайте таких ошибок. Правда, если тебе лень ревьювить код, это совсем не значит, что ты мегасениор. Может, ты и правда лентяй (как я).
Делал я недавно код-ревью у соседнего микросервиса . Код был с душком, я честно давал комментарии почти к каждой строчке. Минут через 15 появилось желание все реджектнуть с резолюцией "нах*р все переписать", потому что так и надо было сделать. В итоге, я сделал approve и merge. Микросервис не мой, а если совсем много проблем будет, то быстрее с нуля все переписать самому.
То рассказ не только про то, что я ленивый зажравшийся чудак, тут есть глубокая мысль.
Менторинг и обучение младшего специалиста лучше всего проводит специалист максимум на одну-две ступеньки выше. Для него это в новинку, он сам учится чему-то новому в процессе. Опытный лид будет это делать либо крайне грубо, либо на отвали. Ему банально скучно объяснять азы кодирования и очень дорого с точки зрения времени.
Есть единственное исключение - это инициатива старшего товарища. То может быть либо личная симпатия, либо обучение обучению (грубо говоря, лид учит сениора делать код-ревью без матов на примере джуна).
Так что если вы лид - не совершайте таких ошибок. Правда, если тебе лень ревьювить код, это совсем не значит, что ты мегасениор. Может, ты и правда лентяй (как я).
👍5
К концу года сделал гайд, как получить максимальную пользу от Performance Review.
https://telegra.ph/Gajd-po-prohozhdeniyu-Performance-Review-10-23
https://telegra.ph/Gajd-po-prohozhdeniyu-Performance-Review-10-23
Telegraph
Гайд по прохождению Performance Review
Наступает конец года и работяги косяками потянулись на PPR - Personal Performance Review (aka Posideli Pogovorili Razoshlis). Поэтому я и решил написать небольшой гайд по его прохождению. Сам я провел под пару сотен таких встреч как манагер, лид и обучающий…
👍7🔥1
Про стандартизацию архитектуры и кодовой базы
Когда я был молодым и горячим, я люто горел от корпоративных стандартов в разработке. Приходишь ты такой в Кровавый Энтерпрайз, а там огромная портянка требований к коду, совершенно идиотские правила Sonarqube и покрытия тестами.
Я небезосновательно считал это помехой для быстрой и качественной разработки. Ну что за идиотизм, когда сборка заваливается от пары идиотских Code Smellов и нужно тратить время на прописывание эксклюдов. В ту же степь - test coverage 85%.
К чему я про это пишу? Сейчас я сижу и вылизываюяйтесты своего микросервиса до характерного блеска, пока коллеги в пожаре дописывают свою часть. Потому что я не могу быстро переключиться и напилить фичу в их кодовой базе - на вникание и банальный дебаг кода у меня неделя уйдет. Потому что у нас же микросервисы и каждый из разрабов пишет свое уникальное видение этого паттерна.
Так что опытные коллеги были тогда правы. И в любом проекте, где я имею власть, я прописываю эти самые стандарты. Это можно делать через документы (самый плохой способ) или через quickstart/backbone (это когда можно запулить код и начать писать функционал).
Когда я был молодым и горячим, я люто горел от корпоративных стандартов в разработке. Приходишь ты такой в Кровавый Энтерпрайз, а там огромная портянка требований к коду, совершенно идиотские правила Sonarqube и покрытия тестами.
Я небезосновательно считал это помехой для быстрой и качественной разработки. Ну что за идиотизм, когда сборка заваливается от пары идиотских Code Smellов и нужно тратить время на прописывание эксклюдов. В ту же степь - test coverage 85%.
К чему я про это пишу? Сейчас я сижу и вылизываю
Так что опытные коллеги были тогда правы. И в любом проекте, где я имею власть, я прописываю эти самые стандарты. Это можно делать через документы (самый плохой способ) или через quickstart/backbone (это когда можно запулить код и начать писать функционал).
👍6
Что такое DevOps мышление
После десятков проведенных тренингов и проектов, я наконец-то сформулировал для себя, что же такое "DevOps мышление". Объяснить это у меня не получится, поэтому специально для тебя, работяга, я сделал тест на это самое мышление.
За каждый ответ "Да" начисляй себе балл и ты все поймешь:
1. Я пишу код без логов, потому что все понятно из кода и вообще, можно дебагом на прод залезть
2. Тесты нужны для покрытия. assert(true==true) - наше все
3. Если что-то забыли специфицировать, то это проблема бизнеса. И хрен с ним, что не работает. Я все сделал как было написано
4. Задеплоенную версию не обязательно проверять (типа, послать пинг).
5. Вообще можно не смотреть, поднялось ли все. Пофигу, что куб уже 50 раз перезапустил контейнер. Если что-то плохое будет, то прометеус мне алерт кинет
6. Ошибки на проде - это проблемы суппорта. Они сами все должны понять без документации и operation мануала
7. Интеграция - это головная боль зависимой системы. Не, ну а фигли они запросы какие-то странные шлют?
Ответы:
0 - ты красавчик и девопёс.
1-6 - ты красавчик, но не девопёс
7 - ты просто пёс
DevOps мышление - это когда тебе непохуй все равно на конечный результат. А все остальные определения нужны для продажи тренингов и коучей.
После десятков проведенных тренингов и проектов, я наконец-то сформулировал для себя, что же такое "DevOps мышление". Объяснить это у меня не получится, поэтому специально для тебя, работяга, я сделал тест на это самое мышление.
За каждый ответ "Да" начисляй себе балл и ты все поймешь:
1. Я пишу код без логов, потому что все понятно из кода и вообще, можно дебагом на прод залезть
2. Тесты нужны для покрытия. assert(true==true) - наше все
3. Если что-то забыли специфицировать, то это проблема бизнеса. И хрен с ним, что не работает. Я все сделал как было написано
4. Задеплоенную версию не обязательно проверять (типа, послать пинг).
5. Вообще можно не смотреть, поднялось ли все. Пофигу, что куб уже 50 раз перезапустил контейнер. Если что-то плохое будет, то прометеус мне алерт кинет
6. Ошибки на проде - это проблемы суппорта. Они сами все должны понять без документации и operation мануала
7. Интеграция - это головная боль зависимой системы. Не, ну а фигли они запросы какие-то странные шлют?
Ответы:
1-6 - ты красавчик, но не девопёс
7 - ты просто пёс
DevOps мышление - это когда тебе не
❤12
Как читаемость кода влияет на Time to Market
Смотрел недавно на код коллег, которые не читали "Совершенный код" ичуть не ушел в запой задумался, а как набирать людей, которые будут писать нормальный промышленный код? Т.е. не решать задачки на LeetCode, а делать то, что живет на протяжении многих лет и не вызывает ненависти у следующих поколений, обслуживающих этот код.
И придумал вот такой вопрос для будущих собесов - "Какие требования к качеству кода ты считаешь самыми важными?". В дискуссии станет сразу понятно, насколько человек сможет писать командный код.
Вот мой личный топ:
- Readability/Understandability - насколько легко читать и понимать твой код.
- Testability - насколько легко протестировать код и написать для него автотесты по всей пирамиде тестирования.
- Maintainability - насколько просто делать новые фичи/чинить баги в коде.
- Observability - насколько легко отследить текущее состояние и локализовать ошибку.
Без соблюдения этих требований будет следующая безблагодатность:
- PR/MR review будет проходить более поверхностно (попробуй прочитать Stream или лямбду на два экрана). И чтение кода не будет обучать команду.
- RTO/RPO (как быстро вы поднимете упавший прод) упадут! Если код понимает только условный Вася, то в его отсутствие команда первые два часа будет пытаться понять, что имел ввиду автор.
- Упадет надежность приложения и заветные девятки вы не получите. Иногда хочется написать крутой тест, но время его написания сравнимо с реализацией самой фичи.
И так далее... Как следствие, у вас падает заветный Time to Market, на который яростно молятся все ведущие аджаел коучи. Да и в команде работать будет не так весело.
Смотрел недавно на код коллег, которые не читали "Совершенный код" и
И придумал вот такой вопрос для будущих собесов - "Какие требования к качеству кода ты считаешь самыми важными?". В дискуссии станет сразу понятно, насколько человек сможет писать командный код.
Вот мой личный топ:
- Readability/Understandability - насколько легко читать и понимать твой код.
- Testability - насколько легко протестировать код и написать для него автотесты по всей пирамиде тестирования.
- Maintainability - насколько просто делать новые фичи/чинить баги в коде.
- Observability - насколько легко отследить текущее состояние и локализовать ошибку.
Без соблюдения этих требований будет следующая безблагодатность:
- PR/MR review будет проходить более поверхностно (попробуй прочитать Stream или лямбду на два экрана). И чтение кода не будет обучать команду.
- RTO/RPO (как быстро вы поднимете упавший прод) упадут! Если код понимает только условный Вася, то в его отсутствие команда первые два часа будет пытаться понять, что имел ввиду автор.
- Упадет надежность приложения и заветные девятки вы не получите. Иногда хочется написать крутой тест, но время его написания сравнимо с реализацией самой фичи.
И так далее... Как следствие, у вас падает заветный Time to Market, на который яростно молятся все ведущие аджаел коучи. Да и в команде работать будет не так весело.
👍6😁2