При росте качества ИИ в сто раз я с вами соглашусь. Но в такой вариант я веру уже с трудом.
Текущие ИИ это "всего лишь" очень хорошие угадывалки следующего подходящего токена. Думать они не умеют и, из текущих технологий, они этому не научатся. Значит задающим вопросы и проверяющим качество ответов все ещё остается человек.
если повышается производительность труда, то не факт, что снизится найм в отдельных компаниях. Просто все идеи, на которые не хватало ресурсов, теперь могут быть реализованы.
Плюсую на все сто процентов. Если ИИ сможет в разы увеличить производительность инженеров, то множество компаний начнут писать свои корп системы вместо покупки проприетарных SAP/Dynamics/Salesforce, которые стоят бешбабла, под уникальный бизнес-процесс часто не точатся (а в бизнес-процессе конкурентное преимущество компании часто и заключается) и с которых потом фиг слезешь так что будешь платить и платить.
Идея про замену инженеров ИИ была бы разумной, если бы мир был доволен имеющимися системами и - что ещё важнее - интеграциями между ними. Но, как минимум, в корп секторе это совершенно не так и с ростом производительности спрос на инженеров только вырастет - многие начнут автоматизировать себя сами.
Так что я с нетерпением жду когда ИИ оправдает возложенные на него ожидания.
В таком случае hotfix-ы можно раскатывать делая hotfix-ветку от master, а потом сливая обратно в develop. Но, полагаю, вы уже так и делаете.
А от develop в вашем случае да, не избавиться.
Если принимаете советы, то я бы посоветовал вам вот что сделать:
Оцените дизайн ваших микросервисов. Тот факт, что вам приходится ради одной задачи менять сразу несколько сервисов намекает на то, что сервисы распилены не очень удачно и кодовые базы у сервисов разделены, но связность между ними осталась высокой.
Оцените, действительно ли сервисы надо катить вместе или можно выкатывать каждый отдельно, сохраняя рабочим прежний контракт. Версионирование API и contract testing тут могут сильно помочь.
Посмотрите, возможно вам будет проще если переехать в монорепозиторий. Решение специфическое, но в некоторых случаях полезное.
У нас (теперь) нет спринтов и мы просто катим задачу на прод как только она готова. Ну или закрываем feature flag-ом и все равно катим, но такое бывает довольно редко. В такой схеме в develop, как в буфере перед релизом, просто нет необходимости. Сделали - релизим, стараемся в continuous delivery.
Если у вас 10 задач должны ехать на прод вместе, то, вероятно, мы с вами просто по-разному делим на задачи. У нас задача это либо цельный кусок ценности для пользователя (который уже довольно автономен по определению), либо как раз отдельно деплоящийся кусок технической работы (тоже автономный по определению). Поэтому связки на такое количество задач, как вы описали, у нас просто не возникает. У нас даже на 2 задачи связка это большая редкость.
Если вы расскажете, что у вас под задачей понимается, то я, вероятно, смогу на ваш вопрос полностью ответить.
Замечания справедливы, но для меня они не списывают ценность исследования в ноль.
Проблема представительности свойственна любым большим исследованиям. Но какие есть разумные альтернативы?
По поводу "корреляция не значит каузация" - это верно. Но есть ли (и возможны ли) исследования, подтверждающие причинно-следственную связь, а не корреляцию, для качественных показателей, тем более в таких сложных процессах, как разработка ПО?
По такой логике все исследования вроде уровня безопасности, образованности населения, социальной справедливости, уровня коррупции, индекса счастья, потребительских ожиданий - бесполезны.
Для меня все это поводы не воспринимать результаты исследования как догму и продолжать думать своей головой. Но не повод отбросить результаты как бесполезные.
Принимать решения имея в арсенале цифры+ориентиры+собственный опыт это лучше, чем принимать решения, имея только собственный опыт.
А вы можете более развёрнуто рассказать, в чем некорректность исследования? Ну или ссылкой поделиться.
По поводу модели бранчевания как главной причины - не совсем. Главным изменением было снятие избыточной нагрузки на e2e-тесты, как на главный bottleneck.
Ну и касательно очевидности. Вы знаете, когда все позади, и когда мы говорим только о применённом решении, то и правда кажется очевидным. Но так не было "внутри событий". У этого феномена даже отдельное название есть - hindsight bias, это одно из когнитивных искажений. Из-за него же человечество никогда не увидит объективных учебников истории, например.
Когда находишься внутри событий и у тебя прод разваливается, тесты флакуют, кучи legacy кода, задачи горят, люди горят, то лишняя ветка совсем не кажется важной :) Я уж не говорю о том, что я команду уговорил от этой ветки отказаться не с первого раза.
И вот тут как раз DORA-метрики и спасают, потому что они помогают в нужную сторону посмотреть, найти за какую ниточку начать вытягивать. И найти общий язык с окружением, чтобы за нужную ниточку всем вместе и потянуть.
Да, это арифметика по рабочему времени. Пайплайн, конечно, можно запустить и ночью. Но в изначальной реализации это мало помогало. Во-первых, тесты часто падали. Во-вторых, как я писал в статье, e2e-тесты можно запустить только одни за раз. А у билдов в CI таймауты настроены. Поэтому, запустив вечером 14 сборок сервисов, утром прийти и увидеть их все прошедшими было не очень-то реально.
Я показывал эти метрики нашему CTO и нашему CEO (по сути статья написана из материалов, которые я показывал им). Оба ответили, что ценность качественного конвейера поставки теперь очевидна и дали добро на дальнейшие работы по его прокачке.
Когда мы начали поставлять без факапов, перестали срывать сроки и порешали проблемы, до которых раньше просто не доходили руки - а всего этого мы добились - бизнес это еще как оценил. А с цифрами метрик еще и понятно где мы сейчас, а куда можем прийти если приложим еще усилия.
И, например, security упомянутый в статье, и до которого мы раньше никак не могли добраться, имеет вполне материальное выражение. Внешние аудиторы выставляют security rating нашей компании и это:
Имидж нашего продукта перед клиентами
Имидж компании перед инвесторами
Прямое влияние на стоимость страховки от security-рисков.
Для меня киллер-фичей стала проверка на совместимость лицензий зависимостей, используемых на проекте, с заданными политиками. Также умеет агрегировать репорты от других анализаторов.
Спасибо. Я писал статью именно с надеждой снизить размытость темы.
>Статья описывает качества идеального работника для работодателя, но не для самого работника.
Статья разбирает пример с решением "win-win", чтобы не разжигать. Пример может быть другим, с личностный конфликтом и рациональным решением "уволюсь". Но качества, необходимые для принятия осознанного решения вместо эмоций или пассивного бездействия, остаются те же - рефлексия, осознанность, ответственность.
Яростно плюсую, что на таких ситуациях можно здоровье потерять - у самого такой опыт есть. Но вот на вопрос:
Почему я, добросовестно отрабатывая свои 40 часов в неделю испытываю стресс, чувство долга и чувство, что я кого-то подвел?
Я решил менять не компании, а свое отношение к стрессу. Потому что видел руководителей, основателей стартапов и собственников бизнеса у которых нагрузка гораздо выше моей, но они почему-то не сгорали.
Вместо того, чтобы искать компанию с хорошими процессами, можно научиться их создавать. И я постепенно понял, что стрессоустойчивость это не про то, кто крепче всех сжал челюсти и пашет. Это про умение не вовлекаться в проблему лично, но спокойно и методично выстраивать те самые бизнес-процессы и культуру работы в компании.
Ведь хорошие бизнес-процессы и культура в компаниях сами собой не появляются. Их создают сотрудники, и в том числе тимлиды. И моя статья это опыт создания таких процессов и культуры. Все здесь описанное, это вместо 80-часовой недели и стресса, а не вдобавок к ним.
Это скорее не плохое, а просто имеющаяся реальность.
Никто не хочет лечиться у неопытного врача, отдавать ребенка неопытному преподавателю, нанимать на атомную станцию неопытного физика-ядерщика :)
Но, чтобы у нас были опытные специалисты, им нужно где-то получать опыт. Поэтому важно делиться своими знаниями с теми, кому они нужны, и оказывать поддержку новичкам. Другого пути я не вижу.
Мне кажется, мы с вами пишем об одной и той же проблеме.
"пытались починить все понемногу" - это как раз распыление, от которого я предостерегаю. За один раз надо решать одну проблему, но решать ее качественно, в идеале до конца.
"незавершенный рефакторинг делал код зачастую еще более дурнопахнущим" - а это как раз недовернутый цикл Деминга. Не закончили, отвлеклись, и вот у нас +1 долг.
Абсолютно согласен. Коллег не нужно "спасать" - вокруг люди взрослые и умные, сами все умеют. Смысл совета в том, чтобы подтолкнуть к открытому разговору того, кто видит проблему, но, например, стесняется ее обозначить. То есть просто "сделать первый шаг".
Но если запроса на твою помощь нет - просто устранись. И искать проблемы там, где их нет, конечно, тоже не стоит.
Это просто отличный вопрос, спасибо за него. Опыт есть, но очень разносторонний.
— В провалившихся переменах далеко не всегда виноват кто-то конкретный. Внедрение изменений в организациях это очень сложно и это отдельная большая ветвь менеджмента, полная психологии, системного анализа и т.п. Можно начать с гугления «change leadership», «change management», «change agent». Единого, достойного, бесплатного источника знаний не могу посоветовать, поскольку сам такой не нашел.
— Попробовать найти «спонсора изменений» — руководителя с достаточной властью для принятия решений и реально заинтереснованного в изменениях, которые вы предлагаете. Но в некоторых компаниях «объезд» непосредственного руководителя может к политическим игрищам привести.
— Есть простая мантра «Нет стрессора — нет изменений». Это из основ change leadership как раз идея. Иногда этот стрессор нужно создавать искусственно. Но это тоже, конечно, аккуратно и обдуманно.
Согласен и дополню, что техлидов лучше не один, а по одному на каждые 3-6 человек в команде. Без этого очень тяжело поддерживать коммуникации в большой команде.
Тимлид — за стратегию и people management. Техлиды — за тактику и глубоко в теме по технике/архитектуре.
У нас такой подход к организации команд.
Начав с похожих соображений я нашёл для себя идеальным Planyway. Он работает поверх Trello + интегрируется с календарями.
В Trello задачи. В корпоративном Outlook рабочие встречи. В Google календаре личные встречи, напоминания о днях рождения и т.д. А в Planyway на одном экране видишь все.
Плюс задачам из трелло можно длительность задавать, в виде таймлайна все вместе смотреть и т.д.
VS Code действительно быстро развивается, но как редактор общего назначения, годный для всего подряд, неспециализированный.
Любая «заточка» его под конкретные нужды (тот же C#) делается через расширения. Такая модель имеет ограничения, потому что правила игры определяет сам редактор кода и они должны оставаться универсальными, подходить всем плагинам.
Скорее всего, мы никогда не увидим такие возможности анализа, рефакторинга, автоисправлений, контекстных действий как в Rider и в той же Visual studio. А также штуки вроде дизайнеров DbContext-ов и прочие.
Полагаю, что все больше функционала будет перекочевывать в консоль. В dotnet CLI уже есть шаблоны проектов, работа с зависимостями, сборка, тесты, публикация, запуск — все через консоль вместо кнопок на UI.
И полноценным IDE в этих условиях всегда будет место и на них будет спрос. И, скорее всего, они так и будут платными именно за свою оптимальность и продуманность для конкретных задач.
Мой комментарий про разработку, а не про конечный хостинг.
Но про перфоманс очень интересно. Можете поделиться ссылкой на сравнения? Я даже не в курсе, что с перфомансом .Net на Linux есть серьёзные проблемы.
При росте качества ИИ в сто раз я с вами соглашусь. Но в такой вариант я веру уже с трудом.
Текущие ИИ это "всего лишь" очень хорошие угадывалки следующего подходящего токена. Думать они не умеют и, из текущих технологий, они этому не научатся. Значит задающим вопросы и проверяющим качество ответов все ещё остается человек.
Плюсую на все сто процентов. Если ИИ сможет в разы увеличить производительность инженеров, то множество компаний начнут писать свои корп системы вместо покупки проприетарных SAP/Dynamics/Salesforce, которые стоят бешбабла, под уникальный бизнес-процесс часто не точатся (а в бизнес-процессе конкурентное преимущество компании часто и заключается) и с которых потом фиг слезешь так что будешь платить и платить.
Идея про замену инженеров ИИ была бы разумной, если бы мир был доволен имеющимися системами и - что ещё важнее - интеграциями между ними. Но, как минимум, в корп секторе это совершенно не так и с ростом производительности спрос на инженеров только вырастет - многие начнут автоматизировать себя сами.
Так что я с нетерпением жду когда ИИ оправдает возложенные на него ожидания.
Понял.
В таком случае hotfix-ы можно раскатывать делая hotfix-ветку от master, а потом сливая обратно в develop. Но, полагаю, вы уже так и делаете.
А от develop в вашем случае да, не избавиться.
Если принимаете советы, то я бы посоветовал вам вот что сделать:
Оцените дизайн ваших микросервисов. Тот факт, что вам приходится ради одной задачи менять сразу несколько сервисов намекает на то, что сервисы распилены не очень удачно и кодовые базы у сервисов разделены, но связность между ними осталась высокой.
Оцените, действительно ли сервисы надо катить вместе или можно выкатывать каждый отдельно, сохраняя рабочим прежний контракт. Версионирование API и contract testing тут могут сильно помочь.
Посмотрите, возможно вам будет проще если переехать в монорепозиторий. Решение специфическое, но в некоторых случаях полезное.
У нас (теперь) нет спринтов и мы просто катим задачу на прод как только она готова. Ну или закрываем feature flag-ом и все равно катим, но такое бывает довольно редко. В такой схеме в develop, как в буфере перед релизом, просто нет необходимости. Сделали - релизим, стараемся в continuous delivery.
Если у вас 10 задач должны ехать на прод вместе, то, вероятно, мы с вами просто по-разному делим на задачи. У нас задача это либо цельный кусок ценности для пользователя (который уже довольно автономен по определению), либо как раз отдельно деплоящийся кусок технической работы (тоже автономный по определению). Поэтому связки на такое количество задач, как вы описали, у нас просто не возникает. У нас даже на 2 задачи связка это большая редкость.
Если вы расскажете, что у вас под задачей понимается, то я, вероятно, смогу на ваш вопрос полностью ответить.
Замечания справедливы, но для меня они не списывают ценность исследования в ноль.
Проблема представительности свойственна любым большим исследованиям. Но какие есть разумные альтернативы?
По поводу "корреляция не значит каузация" - это верно. Но есть ли (и возможны ли) исследования, подтверждающие причинно-следственную связь, а не корреляцию, для качественных показателей, тем более в таких сложных процессах, как разработка ПО?
По такой логике все исследования вроде уровня безопасности, образованности населения, социальной справедливости, уровня коррупции, индекса счастья, потребительских ожиданий - бесполезны.
Для меня все это поводы не воспринимать результаты исследования как догму и продолжать думать своей головой. Но не повод отбросить результаты как бесполезные.
Принимать решения имея в арсенале цифры+ориентиры+собственный опыт это лучше, чем принимать решения, имея только собственный опыт.
А вы можете более развёрнуто рассказать, в чем некорректность исследования? Ну или ссылкой поделиться.
По поводу модели бранчевания как главной причины - не совсем. Главным изменением было снятие избыточной нагрузки на e2e-тесты, как на главный bottleneck.
Ну и касательно очевидности. Вы знаете, когда все позади, и когда мы говорим только о применённом решении, то и правда кажется очевидным. Но так не было "внутри событий". У этого феномена даже отдельное название есть - hindsight bias, это одно из когнитивных искажений. Из-за него же человечество никогда не увидит объективных учебников истории, например.
Когда находишься внутри событий и у тебя прод разваливается, тесты флакуют, кучи legacy кода, задачи горят, люди горят, то лишняя ветка совсем не кажется важной :) Я уж не говорю о том, что я команду уговорил от этой ветки отказаться не с первого раза.
И вот тут как раз DORA-метрики и спасают, потому что они помогают в нужную сторону посмотреть, найти за какую ниточку начать вытягивать. И найти общий язык с окружением, чтобы за нужную ниточку всем вместе и потянуть.
Да, это арифметика по рабочему времени. Пайплайн, конечно, можно запустить и ночью. Но в изначальной реализации это мало помогало. Во-первых, тесты часто падали. Во-вторых, как я писал в статье, e2e-тесты можно запустить только одни за раз. А у билдов в CI таймауты настроены. Поэтому, запустив вечером 14 сборок сервисов, утром прийти и увидеть их все прошедшими было не очень-то реально.
Я показывал эти метрики нашему CTO и нашему CEO (по сути статья написана из материалов, которые я показывал им). Оба ответили, что ценность качественного конвейера поставки теперь очевидна и дали добро на дальнейшие работы по его прокачке.
Когда мы начали поставлять без факапов, перестали срывать сроки и порешали проблемы, до которых раньше просто не доходили руки - а всего этого мы добились - бизнес это еще как оценил. А с цифрами метрик еще и понятно где мы сейчас, а куда можем прийти если приложим еще усилия.
И, например, security упомянутый в статье, и до которого мы раньше никак не могли добраться, имеет вполне материальное выражение. Внешние аудиторы выставляют security rating нашей компании и это:
Имидж нашего продукта перед клиентами
Имидж компании перед инвесторами
Прямое влияние на стоимость страховки от security-рисков.
Из свежих и интересных ещё стоит упомянуть Qodana от Jetbrains.
Для меня киллер-фичей стала проверка на совместимость лицензий зависимостей, используемых на проекте, с заданными политиками. Также умеет агрегировать репорты от других анализаторов.
Спасибо. Я писал статью именно с надеждой снизить размытость темы.
>Статья описывает качества идеального работника для работодателя, но не для самого работника.
Статья разбирает пример с решением "win-win", чтобы не разжигать. Пример может быть другим, с личностный конфликтом и рациональным решением "уволюсь". Но качества, необходимые для принятия осознанного решения вместо эмоций или пассивного бездействия, остаются те же - рефлексия, осознанность, ответственность.
Яростно плюсую, что на таких ситуациях можно здоровье потерять - у самого такой опыт есть. Но вот на вопрос:
Почему я, добросовестно отрабатывая свои 40 часов в неделю испытываю стресс, чувство долга и чувство, что я кого-то подвел?
Я решил менять не компании, а свое отношение к стрессу. Потому что видел руководителей, основателей стартапов и собственников бизнеса у которых нагрузка гораздо выше моей, но они почему-то не сгорали.
Вместо того, чтобы искать компанию с хорошими процессами, можно научиться их создавать. И я постепенно понял, что стрессоустойчивость это не про то, кто крепче всех сжал челюсти и пашет. Это про умение не вовлекаться в проблему лично, но спокойно и методично выстраивать те самые бизнес-процессы и культуру работы в компании.
Ведь хорошие бизнес-процессы и культура в компаниях сами собой не появляются. Их создают сотрудники, и в том числе тимлиды. И моя статья это опыт создания таких процессов и культуры. Все здесь описанное, это вместо 80-часовой недели и стресса, а не вдобавок к ним.
Это скорее не плохое, а просто имеющаяся реальность.
Никто не хочет лечиться у неопытного врача, отдавать ребенка неопытному преподавателю, нанимать на атомную станцию неопытного физика-ядерщика :)
Но, чтобы у нас были опытные специалисты, им нужно где-то получать опыт. Поэтому важно делиться своими знаниями с теми, кому они нужны, и оказывать поддержку новичкам. Другого пути я не вижу.
Мне кажется, мы с вами пишем об одной и той же проблеме.
"пытались починить все понемногу" - это как раз распыление, от которого я предостерегаю. За один раз надо решать одну проблему, но решать ее качественно, в идеале до конца.
"незавершенный рефакторинг делал код зачастую еще более дурнопахнущим" - а это как раз недовернутый цикл Деминга. Не закончили, отвлеклись, и вот у нас +1 долг.
Или я что-то неверно понял из вашего комментария?
Абсолютно согласен. Коллег не нужно "спасать" - вокруг люди взрослые и умные, сами все умеют. Смысл совета в том, чтобы подтолкнуть к открытому разговору того, кто видит проблему, но, например, стесняется ее обозначить. То есть просто "сделать первый шаг".
Но если запроса на твою помощь нет - просто устранись. И искать проблемы там, где их нет, конечно, тоже не стоит.
— В провалившихся переменах далеко не всегда виноват кто-то конкретный. Внедрение изменений в организациях это очень сложно и это отдельная большая ветвь менеджмента, полная психологии, системного анализа и т.п. Можно начать с гугления «change leadership», «change management», «change agent». Единого, достойного, бесплатного источника знаний не могу посоветовать, поскольку сам такой не нашел.
— Попробовать найти «спонсора изменений» — руководителя с достаточной властью для принятия решений и реально заинтереснованного в изменениях, которые вы предлагаете. Но в некоторых компаниях «объезд» непосредственного руководителя может к политическим игрищам привести.
— Есть простая мантра «Нет стрессора — нет изменений». Это из основ change leadership как раз идея. Иногда этот стрессор нужно создавать искусственно. Но это тоже, конечно, аккуратно и обдуманно.
Тимлид — за стратегию и people management. Техлиды — за тактику и глубоко в теме по технике/архитектуре.
У нас такой подход к организации команд.
Начав с похожих соображений я нашёл для себя идеальным Planyway. Он работает поверх Trello + интегрируется с календарями.
В Trello задачи. В корпоративном Outlook рабочие встречи. В Google календаре личные встречи, напоминания о днях рождения и т.д. А в Planyway на одном экране видишь все.
Плюс задачам из трелло можно длительность задавать, в виде таймлайна все вместе смотреть и т.д.
Тоже пользуюсь физическим таймером, с ним гораздо проще сконцентрироваться.
Недавно нашёл идеальный — он вместо звука может сигналить подсветкой. Идеально если работаешь в команде. Или если удаленка и дети спят.
Плюс двухрежимный. Можно настроить по таймеру на работу и на отдых и одной кнопкой запускать нужный.
Если кто-то в поисках подобного — на всем известном китайском сайте можно найти по запросу "timer ys-390"
Любая «заточка» его под конкретные нужды (тот же C#) делается через расширения. Такая модель имеет ограничения, потому что правила игры определяет сам редактор кода и они должны оставаться универсальными, подходить всем плагинам.
Скорее всего, мы никогда не увидим такие возможности анализа, рефакторинга, автоисправлений, контекстных действий как в Rider и в той же Visual studio. А также штуки вроде дизайнеров DbContext-ов и прочие.
Полагаю, что все больше функционала будет перекочевывать в консоль. В dotnet CLI уже есть шаблоны проектов, работа с зависимостями, сборка, тесты, публикация, запуск — все через консоль вместо кнопок на UI.
И полноценным IDE в этих условиях всегда будет место и на них будет спрос. И, скорее всего, они так и будут платными именно за свою оптимальность и продуманность для конкретных задач.
Мой комментарий про разработку, а не про конечный хостинг.
Но про перфоманс очень интересно. Можете поделиться ссылкой на сравнения? Я даже не в курсе, что с перфомансом .Net на Linux есть серьёзные проблемы.