Смеяться в коде
Обожаю смеяться в коде. Самый распространённый товар в тестах ГдеМатериала у нас назывался «Камаз Отходов». Иногда он трансформировался в «Камаз Овец» или «Камаз Гвоздей». Большинство прорабов звали «Львовичами» («Петрович» не хотелось по понятным причинам).
Чтобы аккаунты программистов в системе отличались от аккаунтов обычных пользователей, каждый придумал себе псевдоним, который начинался на «Отец О»: Отец Олексей, Отец Олег, Отец Онотолий.
Такие шутки — это творчество: дают дофаминчик, поднимают настроение, делают работу менее формальной. Начинаются негласные соревнования, кто придумает более смешной «камаз» — к примеру, «Камаз функциональных языков» или «Камаз Камазов».
Я не призываю вас шутить — вдруг вы пишете бэкенд для похоронного агентства (хотя, уверен, там самая мякотка). Но с шутками — гораздо веселее, это точно.
Обожаю смеяться в коде. Самый распространённый товар в тестах ГдеМатериала у нас назывался «Камаз Отходов». Иногда он трансформировался в «Камаз Овец» или «Камаз Гвоздей». Большинство прорабов звали «Львовичами» («Петрович» не хотелось по понятным причинам).
Чтобы аккаунты программистов в системе отличались от аккаунтов обычных пользователей, каждый придумал себе псевдоним, который начинался на «Отец О»: Отец Олексей, Отец Олег, Отец Онотолий.
Такие шутки — это творчество: дают дофаминчик, поднимают настроение, делают работу менее формальной. Начинаются негласные соревнования, кто придумает более смешной «камаз» — к примеру, «Камаз функциональных языков» или «Камаз Камазов».
Я не призываю вас шутить — вдруг вы пишете бэкенд для похоронного агентства (хотя, уверен, там самая мякотка). Но с шутками — гораздо веселее, это точно.
Научи ловить рыбу
Неискушённые в разработке бизнесовые ребята иногда используют программистов как очень умных бизнес-ассистентов — поручают мелкие задачи вроде «У нас заказик завис, помоги, пожалуйста», или «давай по-быстрому поменяем телефон на сайте / сбросим пароль / сделаем выгрузку». То, что это надо «по-быстрому», не плохо — обычно это действительно надо. Плохо, что для этого используют дорогущий труд программистов: такие задачи переключают контекст, вымывают, выдёргивают из потока.
Неопытные программисты в ответ на просьбу по-быстрому что-нибудь сделать обычно что-нибудь делают. Продвинутые даже выстраивают системы реагирования, типа «Сегодня Вася делает все задачи по-быстрому, а завтра — Федя».
Опытные же, наоборот, — не дают рыбу, а учат её ловить: они не сбрасывают пароль, а делают кнопку для сброса пароля; не меняют телефон, а делают поле в админке; не делают выгрузки, а ставят Metabase или PowerBI. В ГдеМатериале у меня вообще было правило, что разработчик никогда не участвует в операционке, что бы ни произошло: так мы тратим время разработчика не на решение задачи, а на фичу, которая нужна, чтобы подобные задачи больше никогда не приходили.
Неискушённые в разработке бизнесовые ребята иногда используют программистов как очень умных бизнес-ассистентов — поручают мелкие задачи вроде «У нас заказик завис, помоги, пожалуйста», или «давай по-быстрому поменяем телефон на сайте / сбросим пароль / сделаем выгрузку». То, что это надо «по-быстрому», не плохо — обычно это действительно надо. Плохо, что для этого используют дорогущий труд программистов: такие задачи переключают контекст, вымывают, выдёргивают из потока.
Неопытные программисты в ответ на просьбу по-быстрому что-нибудь сделать обычно что-нибудь делают. Продвинутые даже выстраивают системы реагирования, типа «Сегодня Вася делает все задачи по-быстрому, а завтра — Федя».
Опытные же, наоборот, — не дают рыбу, а учат её ловить: они не сбрасывают пароль, а делают кнопку для сброса пароля; не меняют телефон, а делают поле в админке; не делают выгрузки, а ставят Metabase или PowerBI. В ГдеМатериале у меня вообще было правило, что разработчик никогда не участвует в операционке, что бы ни произошло: так мы тратим время разработчика не на решение задачи, а на фичу, которая нужна, чтобы подобные задачи больше никогда не приходили.
Запись вебинара об автоматизации разработки
2 часа разговоров про построение рабочего места, мониторинг, хостинг, запуск проектов в одно лицо и (самое главное) про огородики и дизайн.
В честь первого дня продаж, цена — 1800 рублей.
2 часа разговоров про построение рабочего места, мониторинг, хостинг, запуск проектов в одно лицо и (самое главное) про огородики и дизайн.
В честь первого дня продаж, цена — 1800 рублей.
YouTube
Вебинар об автоматизации разработки
На вебинаре мы говорим о том, что и как нужно автоматизировать, чтобы писать код быстрее: как настроить vim, как работать с docker, как мониторить продакшн и производительность приложения.
Полная версия — https://education.borshev.com/courses/dev-automation
Полная версия — https://education.borshev.com/courses/dev-automation
FEDOR BORSHEV pinned «Запись вебинара об автоматизации разработки 2 часа разговоров про построение рабочего места, мониторинг, хостинг, запуск проектов в одно лицо и (самое главное) про огородики и дизайн. В честь первого дня продаж, цена — 1800 рублей.»
Качество ведения проекта
Понять, насколько хорошо менеджер ведёт проект, легко после его завершения. Всё просто — если менеджер успел в срок с хорошим качеством и не угробил команду, значит, молодец. Не успел — не молодец. Но как быть, когда проект ещё не завершён, а измерять качество уже надо?
Мой любимый способ — посмотреть на прозрачность. Насколько извне проекта видно, как идут дела? Публичны ли еженедельные планы? Как часто проводятся демо?
Отсутствие прозрачности не говорит, что проект не придёт к результату — бывают команды, которые привыкли держать всё в голове, и не мне их судить. Но вот если с прозрачностью всё в порядке — моя вера в проект сильно повышается.
Понять, насколько хорошо менеджер ведёт проект, легко после его завершения. Всё просто — если менеджер успел в срок с хорошим качеством и не угробил команду, значит, молодец. Не успел — не молодец. Но как быть, когда проект ещё не завершён, а измерять качество уже надо?
Мой любимый способ — посмотреть на прозрачность. Насколько извне проекта видно, как идут дела? Публичны ли еженедельные планы? Как часто проводятся демо?
Отсутствие прозрачности не говорит, что проект не придёт к результату — бывают команды, которые привыкли держать всё в голове, и не мне их судить. Но вот если с прозрачностью всё в порядке — моя вера в проект сильно повышается.
Фабрика фич и просранное время
Когда в компании появляется быстрая разработка (а такое бывает, да), возникает большой соблазн превратить команду разработки в фабрику фич. Фабрика фич — это маленький заводик по клепанию фич без оглядки на реальность, когда никто не прогнозирует и не замеряет воздействие на бизнес. Такой подход быстро превращает продукт в болото из ненужного кода, в котором никто, включая разработчиков и QA, не знает, как должна работать та или иная фича.
Чтобы вылечить такие ситуации, я внедряю цикл Шухарта, когда вместо больших фич мы делаем маленькие гипотезы, замеряем их воздействие на бизнес, а потом уже делаем большие задачи, точно так же замеряя их денежный выхлоп. Типичная проблема с внедрением — когда бизнесовым ребятам пофиг на все эти продуктовые циклы: у них прямо сейчас фича горит, надо просто сделать и, вообще, нет времени объяснять.
Специально для таких ребят я придумал статус задачи «просранное время». Туда мы переводим все задачи, которые сделали в обход полноценного цикла проверки гипотез и которые при этом не оказали никакого воздействия на деньги. Такая «доска позора» где-нибудь в Трелло здорово мотивирует думать головой вместо того, чтобы давить на продуктовую команду.
Очень важно — в «просранное время» ни в коем случае нельзя переводить гипотезы, которые прошли по продуктовому циклу, но не выстрелили — если вы сели, придумали, как быстро проверить гипотезу, проверили и она не выстрелила, вы молодцы, и никакого времени мы не просрали.
Когда в компании появляется быстрая разработка (а такое бывает, да), возникает большой соблазн превратить команду разработки в фабрику фич. Фабрика фич — это маленький заводик по клепанию фич без оглядки на реальность, когда никто не прогнозирует и не замеряет воздействие на бизнес. Такой подход быстро превращает продукт в болото из ненужного кода, в котором никто, включая разработчиков и QA, не знает, как должна работать та или иная фича.
Чтобы вылечить такие ситуации, я внедряю цикл Шухарта, когда вместо больших фич мы делаем маленькие гипотезы, замеряем их воздействие на бизнес, а потом уже делаем большие задачи, точно так же замеряя их денежный выхлоп. Типичная проблема с внедрением — когда бизнесовым ребятам пофиг на все эти продуктовые циклы: у них прямо сейчас фича горит, надо просто сделать и, вообще, нет времени объяснять.
Специально для таких ребят я придумал статус задачи «просранное время». Туда мы переводим все задачи, которые сделали в обход полноценного цикла проверки гипотез и которые при этом не оказали никакого воздействия на деньги. Такая «доска позора» где-нибудь в Трелло здорово мотивирует думать головой вместо того, чтобы давить на продуктовую команду.
Очень важно — в «просранное время» ни в коем случае нельзя переводить гипотезы, которые прошли по продуктовому циклу, но не выстрелили — если вы сели, придумали, как быстро проверить гипотезу, проверили и она не выстрелила, вы молодцы, и никакого времени мы не просрали.
#вопрос
Почему в твоей письменной/печатной речи так много грубых слов типа «говно» и так далее?
Если программисты себя считают элитой, то почему их общение (не только твоё) скатилось до смеси сленга с быдлятиной?
И второй, про сленг. Тебе правда нравится изобилие сленга и слов типа «фейлить», «факапить» и прочих в твоих текстах?
————
#ответ
Сленг складывается помимо нашей воли. Идти против сленга — глупо. Представьте себе дальнобойщика, который по рации скажет «Вижу засаду ГИБДД» вместо «машинка работает», или кладовщика, который назовёт рохлю «вилочным погрузчиком» — поймёте, о чём я.
Любая речь легко воспринимается только в случае, если соответствует контексту подачи. В электронной почте никто не ожидает стикеров с зелёной лягушкой или сообщений из одного слова «привет» — так же, как в Телеграме никто не ожидает красиво оттипографленных лонгридов. Я хочу, чтобы мои сообщения читались легко, поэтому и стараюсь, чтобы тексты не выходили за рамки привычного сообщения в чат — как по объёму, так и по форматированию и матюкам.
Вообще, я дотошный перфекционист. Когда я только начинал работать в студии Лебедева, одно из моих первых писем клиенту как-то вернули на доработку больше 10 раз. Сколько именно — не помню, но зато точно помню, что после двенадцатого раза я всё ещё получал удовольствие. Если бы я с таким подходом делал каждую заметку в этом канале — их было бы в лучшем случае на порядок меньше. В худшем — я бы заебал сам себя настолько, что забросил бы это всё в дальний угол и пошёл заниматься чем-нибудь, что можно никому не показывать.
Поэтому здесь я пишу коротко и без заморочек — как писал бы в рабочий чатик или в личку товарищу. Единственное отличие — недавно здесь появился корректор (Ольга, привет!): теперь, надеюсь, мои писюльки стало воспринимать ещё чуть легче.
Почему в твоей письменной/печатной речи так много грубых слов типа «говно» и так далее?
Если программисты себя считают элитой, то почему их общение (не только твоё) скатилось до смеси сленга с быдлятиной?
И второй, про сленг. Тебе правда нравится изобилие сленга и слов типа «фейлить», «факапить» и прочих в твоих текстах?
————
#ответ
Сленг складывается помимо нашей воли. Идти против сленга — глупо. Представьте себе дальнобойщика, который по рации скажет «Вижу засаду ГИБДД» вместо «машинка работает», или кладовщика, который назовёт рохлю «вилочным погрузчиком» — поймёте, о чём я.
Любая речь легко воспринимается только в случае, если соответствует контексту подачи. В электронной почте никто не ожидает стикеров с зелёной лягушкой или сообщений из одного слова «привет» — так же, как в Телеграме никто не ожидает красиво оттипографленных лонгридов. Я хочу, чтобы мои сообщения читались легко, поэтому и стараюсь, чтобы тексты не выходили за рамки привычного сообщения в чат — как по объёму, так и по форматированию и матюкам.
Вообще, я дотошный перфекционист. Когда я только начинал работать в студии Лебедева, одно из моих первых писем клиенту как-то вернули на доработку больше 10 раз. Сколько именно — не помню, но зато точно помню, что после двенадцатого раза я всё ещё получал удовольствие. Если бы я с таким подходом делал каждую заметку в этом канале — их было бы в лучшем случае на порядок меньше. В худшем — я бы заебал сам себя настолько, что забросил бы это всё в дальний угол и пошёл заниматься чем-нибудь, что можно никому не показывать.
Поэтому здесь я пишу коротко и без заморочек — как писал бы в рабочий чатик или в личку товарищу. Единственное отличие — недавно здесь появился корректор (Ольга, привет!): теперь, надеюсь, мои писюльки стало воспринимать ещё чуть легче.
Лайв-девопс: поднимаем кластер на docker swarm для W1D1
На прошлом стриме о докере вы просили рассказать, как запускать контейнеры не только на своей машине, но и в продакшене.
Сейчас подвернулся идеальный случай — я познакомился с прекрасными ребятами из W1D1, которые попросили меня помочь с переездом бэкенда в кластер. W1D1 — мобильное приложение, которое развивает креативность через небольшие ежедневные задания: к примеру, вчера нужно было встроить вещь из реального мира в бумажный рисунок, а позавчера — сделать какую угодно фотографию одинокого человека.
Сейчас бэкенд у W1D1 состоит из кучки микросервисов на ноде, которые поднимаются руками. Пора наводить порядок — проверить приложения по чек-листу 12 факторов, настроить централизованное логирование, описать инфраструктуру.
Ребята любезно разрешили мне сделать это публично, так что приходите на ютуб в 14:00 воскресенья — будем поднимать маленький кластер на docker swarm при помощи моего любимого Ansible. Как обычно, всё будет в лайве и без репетиций, так что никто не знает, получится ли у меня вообще что-нибудь.
На прошлом стриме о докере вы просили рассказать, как запускать контейнеры не только на своей машине, но и в продакшене.
Сейчас подвернулся идеальный случай — я познакомился с прекрасными ребятами из W1D1, которые попросили меня помочь с переездом бэкенда в кластер. W1D1 — мобильное приложение, которое развивает креативность через небольшие ежедневные задания: к примеру, вчера нужно было встроить вещь из реального мира в бумажный рисунок, а позавчера — сделать какую угодно фотографию одинокого человека.
Сейчас бэкенд у W1D1 состоит из кучки микросервисов на ноде, которые поднимаются руками. Пора наводить порядок — проверить приложения по чек-листу 12 факторов, настроить централизованное логирование, описать инфраструктуру.
Ребята любезно разрешили мне сделать это публично, так что приходите на ютуб в 14:00 воскресенья — будем поднимать маленький кластер на docker swarm при помощи моего любимого Ansible. Как обычно, всё будет в лайве и без репетиций, так что никто не знает, получится ли у меня вообще что-нибудь.
У меня вышел новый совет для тех, кто решил, что не будет учить новые технологии, а глубоко вкопается в одну и будет сидеть с ней до пенсии.
Полезно получилось?
Полезно получилось?
Не отдавайте технические решения
Начинающие менеджеры проектов часто ведут себя очень просто — видят результат и гребут к финишу, не оглядываясь по сторонам. Как инфузория-туфелька, которая увидела кучу водорослей, такой менеджер не думает о последствиях своих действий — накопленном техдолге, уставшей команде и юзерах, наталкивающихся на ошибки.
Само по себе это не плохо: человек-указатель «Результат — там» действительно помогает не забывать о важном в ежедневной рутине. Плохо становится, когда такой человек начинает принимать ВСЕ решения на проекте.
Как вы думаете, позволит ли вам человек-указатель написать интеграционные тесты (уж не говоря о TDD?). Сможете ли вы с ним заменить дурнопахнущую и устаревшую, но при этом готовую библиотеку своим кодом?
Чтобы не превращаться в раба человека-указателя, никогда не отдавайте технические решения наружу. Не обсуждайте, стоит ли вам писать тесты. Определяйте сами версии библиотек и фреймворков. Не спрашивайте, можно ли вам поправить техдолг, — просто берите и правьте.
Начинающие менеджеры проектов часто ведут себя очень просто — видят результат и гребут к финишу, не оглядываясь по сторонам. Как инфузория-туфелька, которая увидела кучу водорослей, такой менеджер не думает о последствиях своих действий — накопленном техдолге, уставшей команде и юзерах, наталкивающихся на ошибки.
Само по себе это не плохо: человек-указатель «Результат — там» действительно помогает не забывать о важном в ежедневной рутине. Плохо становится, когда такой человек начинает принимать ВСЕ решения на проекте.
Как вы думаете, позволит ли вам человек-указатель написать интеграционные тесты (уж не говоря о TDD?). Сможете ли вы с ним заменить дурнопахнущую и устаревшую, но при этом готовую библиотеку своим кодом?
Чтобы не превращаться в раба человека-указателя, никогда не отдавайте технические решения наружу. Не обсуждайте, стоит ли вам писать тесты. Определяйте сами версии библиотек и фреймворков. Не спрашивайте, можно ли вам поправить техдолг, — просто берите и правьте.
Сегодня я немного пожалел, что 3 года назад ушёл из студии Лебедева.
Я не до конца понимаю, как у них это вышло, но студия — это единственное место, где не только дизайнеры ходят к технологам, но технологи с такой же частотой приходят к дизайнерам со словами «я тут придумал пепяку, давай замутим что-нибудь классное». И мутят, а потом упаковывают в красивейшую обёртку. Именно так родилась нейросеть для раскраски чёрно-белых фотографий «Колор», в создании которой мне посчастливилось поучаствовать несколько лет назад.
Сегодня ребята анонсировали супер-важный проект на стыке дизайна, технологий и управления — нейросеть, которая целый год делала логотипы наравне с другими дизайнерами. Нейросеть зовут Николай Иронов, у него даже портфолио есть. Ни клиенты, ни другие дизайнеры не знали, что работают с нейросетью вместо живого человека — его представили всем, как дизайнера на удалёнке.
Бесконечный респект команде — чтобы сделать такой проект в реальной жизни и с клиентам масштаба студии, нужно иметь стальные яйца.
Я не до конца понимаю, как у них это вышло, но студия — это единственное место, где не только дизайнеры ходят к технологам, но технологи с такой же частотой приходят к дизайнерам со словами «я тут придумал пепяку, давай замутим что-нибудь классное». И мутят, а потом упаковывают в красивейшую обёртку. Именно так родилась нейросеть для раскраски чёрно-белых фотографий «Колор», в создании которой мне посчастливилось поучаствовать несколько лет назад.
Сегодня ребята анонсировали супер-важный проект на стыке дизайна, технологий и управления — нейросеть, которая целый год делала логотипы наравне с другими дизайнерами. Нейросеть зовут Николай Иронов, у него даже портфолио есть. Ни клиенты, ни другие дизайнеры не знали, что работают с нейросетью вместо живого человека — его представили всем, как дизайнера на удалёнке.
Бесконечный респект команде — чтобы сделать такой проект в реальной жизни и с клиентам масштаба студии, нужно иметь стальные яйца.
YouTube
Николай Иронов
Подробнее об Иронове: https://www.artlebedev.ru/ironov/
#вопрос. А расскажи просто по пунктам про корпоративную культуру в компании? Как сделать, чтобы люди забирали ответственность?
Ни одна моя попытка отдать ответственность человеку, который не хотел её брать, не окончилась ничем, кроме страданий и потраченного времени.
Наверное, где-то есть суперлюди, которые умеют менять сознание, мотивировать и перевоспитывать сотрудников. Возможно, кто-то даже от них не сбегает и действительно перевоспитывается.
Но вживую я такого не видел, поэтому мой подход к ответственности — простой:
1. Отдавать людям ответственность.
2. Если не берут — отдавать другим людям.
Задать вопрос → fedor@borshev.com
Ни одна моя попытка отдать ответственность человеку, который не хотел её брать, не окончилась ничем, кроме страданий и потраченного времени.
Наверное, где-то есть суперлюди, которые умеют менять сознание, мотивировать и перевоспитывать сотрудников. Возможно, кто-то даже от них не сбегает и действительно перевоспитывается.
Но вживую я такого не видел, поэтому мой подход к ответственности — простой:
1. Отдавать людям ответственность.
2. Если не берут — отдавать другим людям.
Задать вопрос → fedor@borshev.com
Хороший код не соответствует ТЗ
Хороший код отличается от плохого тем, что его легко и приятно менять: понятно, какой модуль за что отвечает, на каком слое архитектуры делать ту или иную задачу, какие модули можно расширять, а какие лучше выкинуть. Решения о качестве программисты принимают сами, в меру своей образованности, и никто эти решения не валидирует — обычно в ТЗ всё прозаично: поставь кнопку сюда, письмо уходит туда, циферки прибавляются вон там.
Проблема в том, что мир, описанный в ТЗ, часто успевает поменяться ещё до того, как по этому ТЗ что-нибудь сделают. И вот уже магазин превращается в службу доставки, а сервис подписок — в систему управления игровыми турнирами.
Если программист ни о чём, кроме ТЗ, не думал и из последних сил родил к дедлайну гору говнокода, то, скорее всего, всё, что умеет эта гора, — это чётко соответствовать ТЗ. Но то, изначальное, ТЗ уже никому не нужно — пока делали код, уже Путин успел три раза выступить, мир стал другим!
Хороший код, особенно в стартапе, — это не чёткое соответствие ТЗ, а вариация на тему ТЗ, которую легко можно адаптировать как к самому ТЗ, так и ко всему, что хоть как-то пересекается по предметной области.
См. также:
— Почему длинные ТЗ не работают
— Почему важно писать хороший код
Хороший код отличается от плохого тем, что его легко и приятно менять: понятно, какой модуль за что отвечает, на каком слое архитектуры делать ту или иную задачу, какие модули можно расширять, а какие лучше выкинуть. Решения о качестве программисты принимают сами, в меру своей образованности, и никто эти решения не валидирует — обычно в ТЗ всё прозаично: поставь кнопку сюда, письмо уходит туда, циферки прибавляются вон там.
Проблема в том, что мир, описанный в ТЗ, часто успевает поменяться ещё до того, как по этому ТЗ что-нибудь сделают. И вот уже магазин превращается в службу доставки, а сервис подписок — в систему управления игровыми турнирами.
Если программист ни о чём, кроме ТЗ, не думал и из последних сил родил к дедлайну гору говнокода, то, скорее всего, всё, что умеет эта гора, — это чётко соответствовать ТЗ. Но то, изначальное, ТЗ уже никому не нужно — пока делали код, уже Путин успел три раза выступить, мир стал другим!
Хороший код, особенно в стартапе, — это не чёткое соответствие ТЗ, а вариация на тему ТЗ, которую легко можно адаптировать как к самому ТЗ, так и ко всему, что хоть как-то пересекается по предметной области.
См. также:
— Почему длинные ТЗ не работают
— Почему важно писать хороший код
Забота 80 уровня от DigitalOcean
Недавно экспериментировал со своим облачным огородиком и получил вот такое письмо от DigitalOcean. Типа «Мы тут видим, что у тебя редис смотрит наружу. Это точно ок?»
DigitalOcean нигде на сайте это не продаёт, денег за такие письма не берёт. При этом они потратили силы — интегрировались с партнёром, который это делает, составили текст письма, настроили отправку. Обожаю компании, которые работают не только для того, чтобы было что написать на лендинге, но ещё и для счастья пользователей.
Недавно экспериментировал со своим облачным огородиком и получил вот такое письмо от DigitalOcean. Типа «Мы тут видим, что у тебя редис смотрит наружу. Это точно ок?»
DigitalOcean нигде на сайте это не продаёт, денег за такие письма не берёт. При этом они потратили силы — интегрировались с партнёром, который это делает, составили текст письма, настроили отправку. Обожаю компании, которые работают не только для того, чтобы было что написать на лендинге, но ещё и для счастья пользователей.
Если облажался — признавай сразу
Не люблю людей, которые не признают свои ошибки. Вот выкатил программист плохой код, ты указываешь на недостатки, а с тобой не соглашаются. По неопытности я тратил на таких людей силы — приводил примеры, приглашал коллег и независимых арбитров. Сейчас просто перестал — всё равно такие разговоры обычно ничем не заканчиваются.
Возможно, причины такого поведения лежат где-то в области психологии, что-нибудь вроде наказания детей за недостаточное количество пятёрок. Я — не большой эксперт в этом, зато могу точно привести пару рациональных аргументов, почему любую критику стоит принимать вообще всегда.
Во-первых, критика — это комплимент: если к вам никто не приходит рассказывать о ваших недостатки — значит, вы или ничего не делаете, или всем вокруг на вас пофиг. За любую критику (если она конструктивна, конечно) нужно говорить «Спасибо» — человек оторвал жопу от кресла, подошёл к вам, чтобы вы могли улучшить свою работу. Это же круто!
Во-вторых, не принимать критику — это неконструктивно. Представьте, что вы не сдали клиенту работу вовремя и доказываете, что это по его вине. Какая разница, чья вина, если проект не запущен?
В-третьих, это портит отношения. Если вы пару раз грубо пошлёте человека, который пришёл к вам с полезной критикой, он не просто перестанет вас критиковать — он, скорее всего, вообще начнёт избегать коммуникации с вами и будет прав.
Не люблю людей, которые не признают свои ошибки. Вот выкатил программист плохой код, ты указываешь на недостатки, а с тобой не соглашаются. По неопытности я тратил на таких людей силы — приводил примеры, приглашал коллег и независимых арбитров. Сейчас просто перестал — всё равно такие разговоры обычно ничем не заканчиваются.
Возможно, причины такого поведения лежат где-то в области психологии, что-нибудь вроде наказания детей за недостаточное количество пятёрок. Я — не большой эксперт в этом, зато могу точно привести пару рациональных аргументов, почему любую критику стоит принимать вообще всегда.
Во-первых, критика — это комплимент: если к вам никто не приходит рассказывать о ваших недостатки — значит, вы или ничего не делаете, или всем вокруг на вас пофиг. За любую критику (если она конструктивна, конечно) нужно говорить «Спасибо» — человек оторвал жопу от кресла, подошёл к вам, чтобы вы могли улучшить свою работу. Это же круто!
Во-вторых, не принимать критику — это неконструктивно. Представьте, что вы не сдали клиенту работу вовремя и доказываете, что это по его вине. Какая разница, чья вина, если проект не запущен?
В-третьих, это портит отношения. Если вы пару раз грубо пошлёте человека, который пришёл к вам с полезной критикой, он не просто перестанет вас критиковать — он, скорее всего, вообще начнёт избегать коммуникации с вами и будет прав.
Четвёртая часть совета об аккуратном коде: принцип единой ответственности
Я рассказал про S из SOLID — почему плохо делать божественные объекты и что каждый класс, должен решать только одну задачу.
Хотите получить развёрнутый совет об управлении разработкой? Задавайте вопросы. Только обязательно напишите, что задаёте вопрос Фёдору, чтобы я мог отличить ваш вопрос от вопросов к другим советчикам.
Я рассказал про S из SOLID — почему плохо делать божественные объекты и что каждый класс, должен решать только одну задачу.
Хотите получить развёрнутый совет об управлении разработкой? Задавайте вопросы. Только обязательно напишите, что задаёте вопрос Фёдору, чтобы я мог отличить ваш вопрос от вопросов к другим советчикам.
Список вопросов для 1:1
Отличный список для вдохновения, ~300 вопросов, которые можно задать на личной встрече с сотрудником.
Есть всё, от банального «Что ты думаешь о моей работе» до крутейшего «Если бы ты был CEO, что бы ты поменял первым делом?».
Отличный список для вдохновения, ~300 вопросов, которые можно задать на личной встрече с сотрудником.
Есть всё, от банального «Что ты думаешь о моей работе» до крутейшего «Если бы ты был CEO, что бы ты поменял первым делом?».
Скоро: как запускать проекты без хуйни
Самат круто придумывает названия. Когда он предложил назвать статью про особенности разработки в стартапах «как запускать проекты без хуйни» я сразу же согласился. «Без хуйни» — принцип, который я вынес ещё из Студии Лебедева.
Хуйня — это когда сорвал дедлайн, опоздал на встречу, сказал что починил, а оно не работает, пообещал написать и не написал. Дейли-митинги, ТЗ, свой инстанс гитлаба, стендапы, код без тестов, планинг-покер и релизные циклы — тоже хуйня.
Статья пока доступна у меня на патреоне, скоро опубликуем для всех.
Самат круто придумывает названия. Когда он предложил назвать статью про особенности разработки в стартапах «как запускать проекты без хуйни» я сразу же согласился. «Без хуйни» — принцип, который я вынес ещё из Студии Лебедева.
Хуйня — это когда сорвал дедлайн, опоздал на встречу, сказал что починил, а оно не работает, пообещал написать и не написал. Дейли-митинги, ТЗ, свой инстанс гитлаба, стендапы, код без тестов, планинг-покер и релизные циклы — тоже хуйня.
Статья пока доступна у меня на патреоне, скоро опубликуем для всех.
Мой супер-патч к django-money попал в историю — его записали на плёнку и сложили вместе с кучей другого опенсорсного кода в подземное хранилище где-то в Арктике.
Мне конечно приятно быть вписанным в вечность, но немного жаль, что туда попал однострочный патч к не очень полезной либе, который я сделал просто потому, что надо было бампнуть джангу.
Ну ничего, надеюсь, впишусь, в следующий пятилетний цикл архивирования с чем-нибудь более стоящим.
Мне конечно приятно быть вписанным в вечность, но немного жаль, что туда попал однострочный патч к не очень полезной либе, который я сделал просто потому, что надо было бампнуть джангу.
Ну ничего, надеюсь, впишусь, в следующий пятилетний цикл архивирования с чем-нибудь более стоящим.
Запретить float
Что только не хранят программисты во float — деньги, количество и вес, сотни всего. Особенно умиляют координаты — неужели они их реально складывать и вычитать собираются?
Если кто не знает, float — это числа с плавающей точкой, которые не гарантируют точности. Верно, вам никто не обещает, что 0.1 + 0.2 будет равно 0.3. Если говорить грубо, причина в том, что в компьютере нет нецелых чисел — там вообще только нули и единицы.
Если вам надо хранить десятичные дроби, используйте специальные типы данных, которые для этого разрабатывались: Decimal, или что там у вас в языке. Подробнее почитайте на https://0.30000000000000004.com.
Что только не хранят программисты во float — деньги, количество и вес, сотни всего. Особенно умиляют координаты — неужели они их реально складывать и вычитать собираются?
Если кто не знает, float — это числа с плавающей точкой, которые не гарантируют точности. Верно, вам никто не обещает, что 0.1 + 0.2 будет равно 0.3. Если говорить грубо, причина в том, что в компьютере нет нецелых чисел — там вообще только нули и единицы.
Если вам надо хранить десятичные дроби, используйте специальные типы данных, которые для этого разрабатывались: Decimal, или что там у вас в языке. Подробнее почитайте на https://0.30000000000000004.com.