Forwarded from artalog (artalar)
Раз Андрей высказался, то и мне пора: моя история участия в токсичном стартапе
Telegram
BEARlogin Dev
Экзитнулся
Вчера я принял решение выйти из стартапа Funlee, которому отдал 2,5 года.
В итоге — дырка от бублика, испорченные отношения с семьей из-за постоянной занятости, бесконечные созвоны. Полное отсутствие заботы о людях, манипуляции в духе "чёрное…
Вчера я принял решение выйти из стартапа Funlee, которому отдал 2,5 года.
В итоге — дырка от бублика, испорченные отношения с семьей из-за постоянной занятости, бесконечные созвоны. Полное отсутствие заботы о людях, манипуляции в духе "чёрное…
Жена звонит:
— Где твоя машина? На парковке нету...
Я завис... 🤔 Где машина-то?..
Вспоминаю: остановился у кафе, зашел, поел… и ушел домой пешком. 🚶♂️
Определенно пора отдохнуть. 😅
— Где твоя машина? На парковке нету...
Я завис... 🤔 Где машина-то?..
Вспоминаю: остановился у кафе, зашел, поел… и ушел домой пешком. 🚶♂️
Определенно пора отдохнуть. 😅
😁24💯5
Заменит ли AI разработчиков?
Думаю, каждый об этом задумывался. И слышал противоположные мнения: от того, что да, всех заменит железный болван, до того, что волноваться не о чем.
Но истина всегда не на максимумах или минимумах. Она посередине.
AI УЖЕ заменил разработчиков. Но не так, как ты думаешь.
Он не пришёл и не сказал: «Всё, кожаный мешок, твоё время ушло, теперь кодим мы». Он изменил систему.
Сильные разрабы стали ещё сильнее.
По сути, AI — это экзоскелет, который усиливает твои способности.
Если ты ходить не умеешь, экзоскелет не поможет. Скорее, твои навыки ещё больше атрофируются.
Так что AI не заменяет людей, но делает сильных сильнее, а слабых — бесполезными.
Так работает естественный отбор.
А вы что думаете по этому поводу?
P.S. я советую людям, которые сейчас проходят обучение на разраба - вырубайте AI помощников, совсем, наглухо.
Можно пользоваться только AI-чатами, чтобы лучше разобраться в какой то теме, и то, не факт что вам верно чатгпт все объяснит. Может такую ахинею занести, что на собесе просто ржать все будут.
—-
Делаю слабых сильными, чтобы вас не заменил AI или чтобы пройти испытательный срок и не вылететь, пишите в ЛС @bearlogin — разберемся :)
BEARlogin dev — подпишись!
Думаю, каждый об этом задумывался. И слышал противоположные мнения: от того, что да, всех заменит железный болван, до того, что волноваться не о чем.
Но истина всегда не на максимумах или минимумах. Она посередине.
AI УЖЕ заменил разработчиков. Но не так, как ты думаешь.
Он не пришёл и не сказал: «Всё, кожаный мешок, твоё время ушло, теперь кодим мы». Он изменил систему.
Сильные разрабы стали ещё сильнее.
По сути, AI — это экзоскелет, который усиливает твои способности.
Если ты ходить не умеешь, экзоскелет не поможет. Скорее, твои навыки ещё больше атрофируются.
Так что AI не заменяет людей, но делает сильных сильнее, а слабых — бесполезными.
Так работает естественный отбор.
А вы что думаете по этому поводу?
P.S. я советую людям, которые сейчас проходят обучение на разраба - вырубайте AI помощников, совсем, наглухо.
Можно пользоваться только AI-чатами, чтобы лучше разобраться в какой то теме, и то, не факт что вам верно чатгпт все объяснит. Может такую ахинею занести, что на собесе просто ржать все будут.
—-
Делаю слабых сильными, чтобы вас не заменил AI или чтобы пройти испытательный срок и не вылететь, пишите в ЛС @bearlogin — разберемся :)
BEARlogin dev — подпишись!
👍11🔥2👎1
Вопрос
Есть такой метод
Не спрашивая у chatgpt скажите, что тут не так?
Upd1. С кодом, входными данными все в порядке, дело в другом.
Ответ напишу в 13.30
Есть такой метод
class UserService {
...
async updateUser(id, data) {
await this.user.update(id, data);
await this.logger.log('User updated', id, data);
}
...
}Не спрашивая у chatgpt скажите, что тут не так?
Upd1. С кодом, входными данными все в порядке, дело в другом.
Ответ напишу в 13.30
Как мозг дорисовывает контекст
Эксперимент оказался интересным — как только мозг видит код, он сразу начинает достраивать отсутствующий контекст.
Кто-то решил, что это контроллер и что он блокирует ответ пользователю. Хотя этот метод мог быть вызван где угодно:
— Планировщиком
— Консюмером события
— Обработчиком джобы
— что угодно
Кто то искал ошибки в коде :)
Но суть не в этом.
Настоящая проблема — отсутствие транзакции ⚠️
Если логгер падает, система остаётся в несогласованном состоянии:
1. Данные обновились
2. Логирование не произошло
Что делать?
Используем транзакцию
Если и логгер, и данные пишутся в БД, оборачиваем всё в транзакцию:
А если логер внешний, то после обновления пользователя он так же мог упасть, например сервис логирования не доступен.
Таким образом, всегда думайте о сценариях, когда система может оказаться в несогласованном состоянии.
#архитектура
Эксперимент оказался интересным — как только мозг видит код, он сразу начинает достраивать отсутствующий контекст.
Кто-то решил, что это контроллер и что он блокирует ответ пользователю. Хотя этот метод мог быть вызван где угодно:
— Планировщиком
— Консюмером события
— Обработчиком джобы
— что угодно
Кто то искал ошибки в коде :)
Но суть не в этом.
Настоящая проблема — отсутствие транзакции ⚠️
Если логгер падает, система остаётся в несогласованном состоянии:
1. Данные обновились
2. Логирование не произошло
Что делать?
Используем транзакцию
Если и логгер, и данные пишутся в БД, оборачиваем всё в транзакцию:
...
// это просто пример, показать принцип, воспринимайте как псевдоязык
async function updateUser(id, data) {
const transaction = await this.db.transaction(); // Начинаем транзакцию
try {
await this.user.update(id, data, { transaction });
await this.logger.log('User updated', data, { transaction });
await transaction.commit(); // Подтверждаем изменения
} catch (error) {
await this.logger.error('User update failed', data);
await transaction.rollback(); // Откатываем всё, если что-то пошло не так
throw error;
}
}
...
А если логер внешний, то после обновления пользователя он так же мог упасть, например сервис логирования не доступен.
Таким образом, всегда думайте о сценариях, когда система может оказаться в несогласованном состоянии.
#архитектура
👎15👍4🔥2🗿1
Гарантированная доставка и очередность событий.
Конечно круто что у охранной системы моей машины гарантированная доставка пуш уведомлений.
Но не очень круто получать уведомление, что автомобиль снят с охраны «сейчас», после того, как ты его закрыл и ушел на километр…
Конечно круто что у охранной системы моей машины гарантированная доставка пуш уведомлений.
Но не очень круто получать уведомление, что автомобиль снят с охраны «сейчас», после того, как ты его закрыл и ушел на километр…
😁8
Мышление архитектора и разработчика
По поводу вчерашней задачки — интересно, сколько негативной реакции она вызвала. Я порефлексировал на эту тему и понял, что мышление архитектора и разработчика сильно отличается. Разработчик начинает видеть паттерн только когда сталкивается с проблемой напрямую. Но, например, в случае с логированием можно вообще никогда не столкнуться с такой проблемой — и это нормально.
Я бы тоже не обратил на это внимание, если бы не читал книги и не проходил/проводил курсы по архитектуре. Архитектор учится видеть паттерны, предугадывать потенциальные проблемы, влияющие на качества системы. Но при этом он может не знать и не замечать специфических сложностей имплементации с точки зрения конкретного языка или фреймворка.
Эта разница в подходах и приводит к недопониманию. Разработчик оценивает проблему, исходя из своего опыта и практического столкновения с ней, а архитектор — через призму рисков и долгосрочных последствий. Часто это выглядит как «надуманная» проблема, потому что на уровне кода её ещё нет, но на уровне системы последствия могут оказаться критичными.
В итоге хороший архитектор не просто видит потенциальные узкие места, но и умеет донести их значимость до команды. А хороший разработчик, в свою очередь, не просто решает текущие задачи, а способен взглянуть на систему шире, задавая правильные вопросы.
BEARlogin dev — подпишись!
#рефлексия #архитектура
По поводу вчерашней задачки — интересно, сколько негативной реакции она вызвала. Я порефлексировал на эту тему и понял, что мышление архитектора и разработчика сильно отличается. Разработчик начинает видеть паттерн только когда сталкивается с проблемой напрямую. Но, например, в случае с логированием можно вообще никогда не столкнуться с такой проблемой — и это нормально.
Я бы тоже не обратил на это внимание, если бы не читал книги и не проходил/проводил курсы по архитектуре. Архитектор учится видеть паттерны, предугадывать потенциальные проблемы, влияющие на качества системы. Но при этом он может не знать и не замечать специфических сложностей имплементации с точки зрения конкретного языка или фреймворка.
Эта разница в подходах и приводит к недопониманию. Разработчик оценивает проблему, исходя из своего опыта и практического столкновения с ней, а архитектор — через призму рисков и долгосрочных последствий. Часто это выглядит как «надуманная» проблема, потому что на уровне кода её ещё нет, но на уровне системы последствия могут оказаться критичными.
В итоге хороший архитектор не просто видит потенциальные узкие места, но и умеет донести их значимость до команды. А хороший разработчик, в свою очередь, не просто решает текущие задачи, а способен взглянуть на систему шире, задавая правильные вопросы.
BEARlogin dev — подпишись!
#рефлексия #архитектура
👍6👎5🔥3🗿3💯1
Подписчик попросил разместить вакансию.
Вакансия:
https://hh.ru/vacancy/116796914?from=share_android
Как я понял, надо пилить плагины под Jetbrains IDEхи
Попросил для вас прямой контакт HR - вот он @max_toky
Что это значит? Значит можете резюмехи свои кидать прям ему. (и не только на джаву :))
P.S. Только не волки, волки идут сразу нахуй.
Вакансия:
https://hh.ru/vacancy/116796914?from=share_android
Как я понял, надо пилить плагины под Jetbrains IDEхи
Попросил для вас прямой контакт HR - вот он @max_toky
Что это значит? Значит можете резюмехи свои кидать прям ему. (и не только на джаву :))
P.S. Только не волки, волки идут сразу нахуй.
hh.ru
Вакансия Java разработчик в Москве, работа в компании Т1 Иннотех (вакансия в архиве c 6 марта 2025)
Зарплата: не указана. Москва. Требуемый опыт: 3–6 лет. Полная. Дата публикации: 05.02.2025.
💯3🔥2
Кароче, само видео еще смешней, чем его описание https://www.youtube.com/watch?v=x6x2h4kWx2c
"Это абстракция"(с)
"Это абстракция"(с)
YouTube
Принципы ООП в React.
В этом видео разберем основные принципы ООП — инкапсуляцию, наследование, полиморфизм и абстракцию — и покажем, как они работают в React. Узнаем, что такое Render Props, Component Injection, композиция и декомпозиция, и применим их в функциональных компонентах…
😁2😱1
Этот IT-найм сломался, несите следующий!
У нас большая проблема. Быстрый рост зарплат в IT, который явно не соответствует уровню других профессий, привёл к буму курсов, обещающих за пару месяцев подготовить джуна, а иногда даже миддла. Были даже программы с гарантированным трудоустройством.
Но рынок настолько насытился новичками, которые по факту не джуны, а максимум стажёры, неспособные приносить пользу сразу, а только после длительного обучения и адаптации внутри компании, что HR начали резко ужесточать фильтры. Компании закрыли институт найма молодых специалистов и повысили требования. И всё это усугубилось тем, что денег во всем мире стало меньше – мы увидели масштабные сокращения IT-специалистов. На рынок выплеснулось столько крутых специалистов, что даже небольшие компании теперь могут позволить себе нанимать синьоров и миддлов, а джуны и, тем более, стажёры стали практически не нужны.
В итоге новички поняли, что им не рады, и возник спрос на менторов и сообщества, которые помогают выдавать себя за опытных специалистов. За деньги стали подделывать резюме, накручивать опыт, готовить к прохождению собеседований, а в некоторых случаях даже помогать кандидатам во время интервью через голосовые подсказки. При этом после трудоустройства такие специалисты не оказывают поддержки, а система ужесточает проверки ещё больше – тысячи резюме сразу отправляются в мусор. Реальному честному трудяге пробиться стало практически невозможно.
Пострадали даже миддл+ и синьоры, потому что теперь их тоже подозревают, а их резюме тонут в потоке заявок от новичков, выдающих себя за опытных специалистов.
Это как играть в MMORPG, честно выполняя квесты, повышая уровень и зарабатывая золото, когда вокруг все покупают за реальные деньги «паровозы» – когда высокоуровневый персонаж помогает проходить низкоуровневые подземелья, снаряжение и игровую валюту. И вот что происходит: после того как новичок выполнил 1001-е тестовое задание, которое осталось без ответа, он тупо идёт к таким дельцам и проходит этот квест.
Кто виноват? Что делать? Как сломать систему?
Если коротко, никак не сломать. Рынок уже порешал. HR просто ставят фильтры 3+ года опыта, автоматические ассесменты, потому что иначе невозможно обработать 1000 резюме, из которых 90% с накрученным опытом и отправлены автоматически. Через ATS-системы просто не пройти
Выбор небольшой: либо читерить, либо менять стратегию.
1. Заходить не через HR – ищите CTO, разрабов, менеджеров в LinkedIn, Telegram, Discord комьюнити.
2. Участвовать в хакатонах, OpenSource (Awesome GitHub Projects, Open Source Friday, Good First Issues).
3. Pet-проекты, но осмысленные. Автоматизируй что-то полезное: бот, сервис, парсер, мониторинг, дашборд. Заведи портфолио, где проект задеплоен и им можно пользоваться.
4. Фриланс и волонтёрство. Делать не ради денег, а ради опыта. Стартапы, малый бизнес, НКО – им нужны сайты, боты, CRM, API. Варианты поиска: фриланс-биржи, комьюнити фаундеров.
На одной чаше весов — быстрое выгорание, синдром реального самозванца, страх, что тайное станет явным, а на другой — долгий путь, требующий терпения, но дающий уверенность в своих знаниях и реальную ценность как специалиста.
BEARlogin dev — подпишись!
#hr #найм
У нас большая проблема. Быстрый рост зарплат в IT, который явно не соответствует уровню других профессий, привёл к буму курсов, обещающих за пару месяцев подготовить джуна, а иногда даже миддла. Были даже программы с гарантированным трудоустройством.
Но рынок настолько насытился новичками, которые по факту не джуны, а максимум стажёры, неспособные приносить пользу сразу, а только после длительного обучения и адаптации внутри компании, что HR начали резко ужесточать фильтры. Компании закрыли институт найма молодых специалистов и повысили требования. И всё это усугубилось тем, что денег во всем мире стало меньше – мы увидели масштабные сокращения IT-специалистов. На рынок выплеснулось столько крутых специалистов, что даже небольшие компании теперь могут позволить себе нанимать синьоров и миддлов, а джуны и, тем более, стажёры стали практически не нужны.
В итоге новички поняли, что им не рады, и возник спрос на менторов и сообщества, которые помогают выдавать себя за опытных специалистов. За деньги стали подделывать резюме, накручивать опыт, готовить к прохождению собеседований, а в некоторых случаях даже помогать кандидатам во время интервью через голосовые подсказки. При этом после трудоустройства такие специалисты не оказывают поддержки, а система ужесточает проверки ещё больше – тысячи резюме сразу отправляются в мусор. Реальному честному трудяге пробиться стало практически невозможно.
Пострадали даже миддл+ и синьоры, потому что теперь их тоже подозревают, а их резюме тонут в потоке заявок от новичков, выдающих себя за опытных специалистов.
Это как играть в MMORPG, честно выполняя квесты, повышая уровень и зарабатывая золото, когда вокруг все покупают за реальные деньги «паровозы» – когда высокоуровневый персонаж помогает проходить низкоуровневые подземелья, снаряжение и игровую валюту. И вот что происходит: после того как новичок выполнил 1001-е тестовое задание, которое осталось без ответа, он тупо идёт к таким дельцам и проходит этот квест.
Кто виноват? Что делать? Как сломать систему?
Если коротко, никак не сломать. Рынок уже порешал. HR просто ставят фильтры 3+ года опыта, автоматические ассесменты, потому что иначе невозможно обработать 1000 резюме, из которых 90% с накрученным опытом и отправлены автоматически. Через ATS-системы просто не пройти
Выбор небольшой: либо читерить, либо менять стратегию.
1. Заходить не через HR – ищите CTO, разрабов, менеджеров в LinkedIn, Telegram, Discord комьюнити.
2. Участвовать в хакатонах, OpenSource (Awesome GitHub Projects, Open Source Friday, Good First Issues).
3. Pet-проекты, но осмысленные. Автоматизируй что-то полезное: бот, сервис, парсер, мониторинг, дашборд. Заведи портфолио, где проект задеплоен и им можно пользоваться.
4. Фриланс и волонтёрство. Делать не ради денег, а ради опыта. Стартапы, малый бизнес, НКО – им нужны сайты, боты, CRM, API. Варианты поиска: фриланс-биржи, комьюнити фаундеров.
На одной чаше весов — быстрое выгорание, синдром реального самозванца, страх, что тайное станет явным, а на другой — долгий путь, требующий терпения, но дающий уверенность в своих знаниях и реальную ценность как специалиста.
BEARlogin dev — подпишись!
#hr #найм
🔥13👍5💯3
Как найти работу фронтендеру в 2к25 году
1. Изучаешь Ember.js https://emberjs.com/
2. Добавляешь навык на LinkedIn
3. Получаешь оффер x2 к своей текущей з\п React разработчика
4. PROFIT
P.S. основано на реальных событиях...
BEARlogin dev — подпишись!
#frontend #js
1. Изучаешь Ember.js https://emberjs.com/
2. Добавляешь навык на LinkedIn
3. Получаешь оффер x2 к своей текущей з\п React разработчика
4. PROFIT
P.S. основано на реальных событиях...
BEARlogin dev — подпишись!
#frontend #js
🤣6🔥3👍2🗿2
Что такое DevOps
Перефразируя классику, DevOps — это человек и пароход.
Изначально DevOps — это процесс, а не роль. Суть в том, что "кто разрабатывает, тот и деплоит".
Окей, вроде логично: написал сервис, завернул в Docker, задеплоил в Kubernetes или куда-нибудь ещё. Но если разраб сам деплоит, то кто тогда DevOps и что он делает?
А вот тут важно понимать: DevOps — это не просто инженер, а создатель процессов. Его задача — не деплоить код вручную, а сделать так, чтобы разработчик мог деплоить сам, быстро и без боли.
Идеально: поднять DevOps-платформу, где всё — от инструментов разработки и выделения ресурсов до мониторинга и CI/CD — автоматизировано.
Минимально:
- Поднять\настроить GitLab / GitHub Actions / Jenkins для CI/CD.
- Развернуть\купить Kubernetes (например, с FluxCD для GitOps).
- Настроить мониторинг и логи: Grafana, Prometheus, Loki, OpenTelemetry.
- Сделать инфраструктуру предсказуемой и самодостаточной, чтобы DevOps-инженер не был просто "тем, кто деплоит руками".
Так что DevOps — это не человек, который нажимает кнопки, а тот, кто создаёт среду, в которой разработчики могут деплоить и сопровождать код без лишних сложностей.
То есть, если ты просишь задеплоить свой сервис DevOps специалиста, то у вас нет DevOps, а есть админ со скриптами.
#devops
BEARlogin dev — подпишись!
Перефразируя классику, DevOps — это человек и пароход.
Изначально DevOps — это процесс, а не роль. Суть в том, что "кто разрабатывает, тот и деплоит".
Окей, вроде логично: написал сервис, завернул в Docker, задеплоил в Kubernetes или куда-нибудь ещё. Но если разраб сам деплоит, то кто тогда DevOps и что он делает?
А вот тут важно понимать: DevOps — это не просто инженер, а создатель процессов. Его задача — не деплоить код вручную, а сделать так, чтобы разработчик мог деплоить сам, быстро и без боли.
Идеально: поднять DevOps-платформу, где всё — от инструментов разработки и выделения ресурсов до мониторинга и CI/CD — автоматизировано.
Минимально:
- Поднять\настроить GitLab / GitHub Actions / Jenkins для CI/CD.
- Развернуть\купить Kubernetes (например, с FluxCD для GitOps).
- Настроить мониторинг и логи: Grafana, Prometheus, Loki, OpenTelemetry.
- Сделать инфраструктуру предсказуемой и самодостаточной, чтобы DevOps-инженер не был просто "тем, кто деплоит руками".
Так что DevOps — это не человек, который нажимает кнопки, а тот, кто создаёт среду, в которой разработчики могут деплоить и сопровождать код без лишних сложностей.
То есть, если ты просишь задеплоить свой сервис DevOps специалиста, то у вас нет DevOps, а есть админ со скриптами.
#devops
BEARlogin dev — подпишись!
👍8🔥1
Scrum-стройка - АКТ 1
Сцена 1: Утро на стройке
Камера медленно показывает стройку. Недостроенный дом третий год «вот-вот» сдаётся. На фоне — кран, который никто не видел в движении с прошлого сезона. Несколько рабочих в касках и резиновых сапогах пьют чай из алюминиевых кружек. Один задумчиво ковыряет гвоздём кусок хлеба.
Прораб (в новом жилете, с планшетом и в галстуке):
— Так, срочно собираемся! Я тут на курсах был. Нам теперь работать по Scrum!
Рабочий №1 (переставая размешивать чай):
— Это кто? Новый прораб?
Прораб (воодушевлённо):
— Это метод такой погрессивный! Теперь у нас спринты, стендапы и эти, как их (судорожно листает книгу "Скрам для чайников") бэкилоги!
Рабочий №2 (щурится):
— Спринт? Это как футбол? Мы бегать будем?
Прораб (вздыхает):
— Нет, брат, это когда мы короткими этапами работаем. Каждые две недели будем что-то сдавать.
Рабочий №3:
— А деньги тоже каждые две недели будем получать?
Прораб (недовольно поправляет жилет):
— Давайте без провокаций, главное — начать!
Сцена 2: Первый стендап
Рабочие стоят в кругу, как на зарядке в пионерском лагере. Прораб деловито держит планшет и объясняет новый процесс.
Прораб:
— Теперь каждое утро будем делать «стендап». Отвечаем на три вопроса: что сделал вчера, что делаешь сегодня и какие есть проблемы.
Рабочий №1:
— Вчера кирпичи носил. Сегодня носил кирпичи. Проблема — кирпич тяжёлый.
Рабочий №2:
— Вчера мешал бетон. Сегодня мешать бетон. Проблема — бетономешалка не работает.
Рабочий №3:
— Вчера красил забор. Сегодня буду красить забор. Проблема — краска нет.
Прораб (вытирая пот со лба):
— Ну хоть честно. Всё, разбежались!
Сцена 3: Планирование спринта
Рабочие сидят на перевёрнутых вёдрах. Прораб рисует что-то на стене куском кирпича.
Прораб:
— Вот наш бэклог: построить стену, залить фундамент, поставить крышу. Давайте оценим, сколько это займёт.
Рабочий №1:
— Стена — два дня.
Рабочий №2:
— Фундамент — неделя.
Рабочий №3:
— Крыша... Если материалы будут, три дня.
Прораб (радостно):
— Отлично! Спринт на две недели! Погнали!
Через две недели: стена кривая, фундамент никто не заливал, а крышу в смету не внесли на этапе проектирования.
Сцена 4: Ретроспектива
Рабочие снова сидят на перевёрнутых вёдрах, пьют чай. Прораб пытается провести ретроспективу.
Прораб:
— Итак, что у нас прошло хорошо?
Рабочий №1:
— Чай вкусный был.
Прораб (пауза):
— А что можно улучшить?
Рабочий №2:
— Кирпичи сделать легче.
Прораб (прикрывает лицо руками):
— Ладно... Что мы сделаем по-другому в следующем спринте?
Рабочий №4: (отхлёбывая чай, задумчиво):
— Работать без Scrum... но с зарплатой!
Все одобрительно кивают и чокаются кружками чая.
—
Сцена 5: Финал
Камера показывает стройку. Рабочие снова пьют чай, лениво переговариваются. Прораб сидит в стороне, хмуро листает книгу «Scrum для чайников».
Прораб (читающий вслух):
— «Ключевая роль в Scrum — Scrum-мастер...»
Прораб медленно поднимает глаза, его лицо озаряет надежда.
Прораб (воодушевлённо, в камеру):
— Так вот в чём проблема! Нам нужен Scrum-мастер!
Камера медленно отъезжает, показывая табличку: «Сдача в 2021 году»
Продолжение следует...
BEARlogin dev — подпишись!
#юмор #scrum
Сцена 1: Утро на стройке
Камера медленно показывает стройку. Недостроенный дом третий год «вот-вот» сдаётся. На фоне — кран, который никто не видел в движении с прошлого сезона. Несколько рабочих в касках и резиновых сапогах пьют чай из алюминиевых кружек. Один задумчиво ковыряет гвоздём кусок хлеба.
Прораб (в новом жилете, с планшетом и в галстуке):
— Так, срочно собираемся! Я тут на курсах был. Нам теперь работать по Scrum!
Рабочий №1 (переставая размешивать чай):
— Это кто? Новый прораб?
Прораб (воодушевлённо):
— Это метод такой погрессивный! Теперь у нас спринты, стендапы и эти, как их (судорожно листает книгу "Скрам для чайников") бэкилоги!
Рабочий №2 (щурится):
— Спринт? Это как футбол? Мы бегать будем?
Прораб (вздыхает):
— Нет, брат, это когда мы короткими этапами работаем. Каждые две недели будем что-то сдавать.
Рабочий №3:
— А деньги тоже каждые две недели будем получать?
Прораб (недовольно поправляет жилет):
— Давайте без провокаций, главное — начать!
Сцена 2: Первый стендап
Рабочие стоят в кругу, как на зарядке в пионерском лагере. Прораб деловито держит планшет и объясняет новый процесс.
Прораб:
— Теперь каждое утро будем делать «стендап». Отвечаем на три вопроса: что сделал вчера, что делаешь сегодня и какие есть проблемы.
Рабочий №1:
— Вчера кирпичи носил. Сегодня носил кирпичи. Проблема — кирпич тяжёлый.
Рабочий №2:
— Вчера мешал бетон. Сегодня мешать бетон. Проблема — бетономешалка не работает.
Рабочий №3:
— Вчера красил забор. Сегодня буду красить забор. Проблема — краска нет.
Прораб (вытирая пот со лба):
— Ну хоть честно. Всё, разбежались!
Сцена 3: Планирование спринта
Рабочие сидят на перевёрнутых вёдрах. Прораб рисует что-то на стене куском кирпича.
Прораб:
— Вот наш бэклог: построить стену, залить фундамент, поставить крышу. Давайте оценим, сколько это займёт.
Рабочий №1:
— Стена — два дня.
Рабочий №2:
— Фундамент — неделя.
Рабочий №3:
— Крыша... Если материалы будут, три дня.
Прораб (радостно):
— Отлично! Спринт на две недели! Погнали!
Через две недели: стена кривая, фундамент никто не заливал, а крышу в смету не внесли на этапе проектирования.
Сцена 4: Ретроспектива
Рабочие снова сидят на перевёрнутых вёдрах, пьют чай. Прораб пытается провести ретроспективу.
Прораб:
— Итак, что у нас прошло хорошо?
Рабочий №1:
— Чай вкусный был.
Прораб (пауза):
— А что можно улучшить?
Рабочий №2:
— Кирпичи сделать легче.
Прораб (прикрывает лицо руками):
— Ладно... Что мы сделаем по-другому в следующем спринте?
Рабочий №4: (отхлёбывая чай, задумчиво):
— Работать без Scrum... но с зарплатой!
Все одобрительно кивают и чокаются кружками чая.
—
Сцена 5: Финал
Камера показывает стройку. Рабочие снова пьют чай, лениво переговариваются. Прораб сидит в стороне, хмуро листает книгу «Scrum для чайников».
Прораб (читающий вслух):
— «Ключевая роль в Scrum — Scrum-мастер...»
Прораб медленно поднимает глаза, его лицо озаряет надежда.
Прораб (воодушевлённо, в камеру):
— Так вот в чём проблема! Нам нужен Scrum-мастер!
Камера медленно отъезжает, показывая табличку: «Сдача в 2021 году»
Продолжение следует...
BEARlogin dev — подпишись!
#юмор #scrum
🤣8🔥2😁2😢1
This media is not supported in your browser
VIEW IN TELEGRAM
Jira сломана от рождения, как этим куском говна вообще можно пользоваться?
Ну то есть даже обоссаный котами блокнот лучше и функциональней, чем Jira.
#хуевыйux
BEARlogin dev — подпишись!
Ну то есть даже обоссаный котами блокнот лучше и функциональней, чем Jira.
#хуевыйux
BEARlogin dev — подпишись!
👍11😁6💯3😢1
В общем, комрад в комментах пояснил, что такое поведение, это из-за "мягкого переноса" — shift + enter. Собственно, AI сделала список почему то с таким переносом, я его вставил, и такая мутотень произошла. В гугл доках такая же фигня. Но это не отменяет тот факт, что жира та еще всрань по куче других причин.
👍5😁4