Второй совет про аккуратный код: связность
Вышел второй совет об аккуратном коде, где я простым языком рассказываю о принципе единой ответственности (S из SOLID).
Опять прошу от вас обратной связи — понятно ли это для людей, которые не сильно разбираются в программировании?
Вышел второй совет об аккуратном коде, где я простым языком рассказываю о принципе единой ответственности (S из SOLID).
Опять прошу от вас обратной связи — понятно ли это для людей, которые не сильно разбираются в программировании?
#вопрос: объектно-ориентированный стиль или функциональный?
На похожий вопрос я уже отвечал в посте про монорепозитории. Если вкратце — выбор технологий зависит не от того, какая технология «лучше», а от того, насколько она применима к задачам, которые решает команда. Вы же не станете забивать гвозди копёром, просто потому, что вам нравится дёргать за рычаги и слушать звук дизеля?
Однако в выборе парадигмы программирования зарыта ещё одна интересная проблема — это уровень счастья людей, которые потом будут ей пользоваться. К примеру лично я получаю гораздо больше удовольствия, когда пишу функциональный код, нежели чем структурный.
Уверен, что я такой не один, поэтому жёстко приходить в команду с тем, что «мы теперь пишем только ООП» я бы не стал. Если бы я, как CTO, был уверен, что у нас вся команда хочет писать в функциональном стиле, функциональный стиль подходит ко всем нашим core-библиотекам, и мы сможем нанимать неограниченное количество новых людей, которые будут это поддерживать — я бы, наверное, согласился.
Задайте свой вопрос на [email protected]
На похожий вопрос я уже отвечал в посте про монорепозитории. Если вкратце — выбор технологий зависит не от того, какая технология «лучше», а от того, насколько она применима к задачам, которые решает команда. Вы же не станете забивать гвозди копёром, просто потому, что вам нравится дёргать за рычаги и слушать звук дизеля?
Однако в выборе парадигмы программирования зарыта ещё одна интересная проблема — это уровень счастья людей, которые потом будут ей пользоваться. К примеру лично я получаю гораздо больше удовольствия, когда пишу функциональный код, нежели чем структурный.
Уверен, что я такой не один, поэтому жёстко приходить в команду с тем, что «мы теперь пишем только ООП» я бы не стал. Если бы я, как CTO, был уверен, что у нас вся команда хочет писать в функциональном стиле, функциональный стиль подходит ко всем нашим core-библиотекам, и мы сможем нанимать неограниченное количество новых людей, которые будут это поддерживать — я бы, наверное, согласился.
Задайте свой вопрос на [email protected]
Коридорное тестирование
Коридорное тестирование — это когда берёшь систему (или её прототип), выходишь в коридор и просишь первого встречного решить с их помощью задачу. Скажем, делаешь новую навигацию для интернет-магазина и просишь пару случайных пользователей найти глубокозапрятаный пылесос определённой марки.
Есть ребята, которые под коридорным тестированием понимают «взять макеты и побегать с ними по коридору». То есть не тестируют прототипы, а просто показывают макеты разным людям и спрашивают «что думаешь?».
Кроме очевидной глупости — увеличения энтропии на проекте, эти ребята ещё и тратят силы всей команды. Даже для того, чтобы просто забить болт на самое некомпетентное мнение, нужно проделать несколько операций: это мнение нужно записать, донести до дизайнера, послушать его аргументы против, решить что с ними делать. А если принести громкое мнение авторитетного человека, составленное по всем правилам обратной связи, да ещё и таких мнений несколько — проект можно вообще парализовать: ведь нет никакой связи между тем, что человек говорит громко и авторитетно и тем, что он несёт не полную чушь.
Берегите свой проект от излишней обратной связи — показывайте промежуточные результаты только людям, которым доверяете.
См. также «Одна задача — один ответственный»
Коридорное тестирование — это когда берёшь систему (или её прототип), выходишь в коридор и просишь первого встречного решить с их помощью задачу. Скажем, делаешь новую навигацию для интернет-магазина и просишь пару случайных пользователей найти глубокозапрятаный пылесос определённой марки.
Есть ребята, которые под коридорным тестированием понимают «взять макеты и побегать с ними по коридору». То есть не тестируют прототипы, а просто показывают макеты разным людям и спрашивают «что думаешь?».
Кроме очевидной глупости — увеличения энтропии на проекте, эти ребята ещё и тратят силы всей команды. Даже для того, чтобы просто забить болт на самое некомпетентное мнение, нужно проделать несколько операций: это мнение нужно записать, донести до дизайнера, послушать его аргументы против, решить что с ними делать. А если принести громкое мнение авторитетного человека, составленное по всем правилам обратной связи, да ещё и таких мнений несколько — проект можно вообще парализовать: ведь нет никакой связи между тем, что человек говорит громко и авторитетно и тем, что он несёт не полную чушь.
Берегите свой проект от излишней обратной связи — показывайте промежуточные результаты только людям, которым доверяете.
См. также «Одна задача — один ответственный»
Forwarded from запуск завтра
Спецвыпуск подкаста, в котором мы с Федей договариваемся про своё дело с помощью крутого юриста Димы Грица. Только что прослушал мастер и чувствую себя раздетым от того, что вы можете послушать этот довольно личный разговор.
Последний, 15-й эпизод в этом сезоне. Уходим на месяц каникул и вернемся со вторым сезоном, ещё интереснее первого. Спасибо замечательной команде — Андрею Борзенко, Юле Яковлевой, Павлу Цурикову, Павлу Боровкову и Полине Агарковой. Вы лучшие!
Спасибо вам большое, что слушаете! Пожалуйста, пишите в личку, что вы думаете о подкасте — даже (особенно) если вы не довольны и хотите что-то поменять.
Последний, 15-й эпизод в этом сезоне. Уходим на месяц каникул и вернемся со вторым сезоном, ещё интереснее первого. Спасибо замечательной команде — Андрею Борзенко, Юле Яковлевой, Павлу Цурикову, Павлу Боровкову и Полине Агарковой. Вы лучшие!
Спасибо вам большое, что слушаете! Пожалуйста, пишите в личку, что вы думаете о подкасте — даже (особенно) если вы не довольны и хотите что-то поменять.
Три абзаца
Тупое, но важное правило почтовой переписки, которое я объясняю всем ребятам во всех удалённых командах — если ты сел писать письмо, и у тебя получается больше трёх абзацев — удаляй его нафиг.
Чем больше текста в письме, тем больше шанс, что его поймут неправильно. Если ты принял решение и не можешь его объяснить за три абзаца — это плохое решение. Если ты выражаешь мнение, и оно не входит в три абзаца — это плохое мнение. Если ты ставишь задачу и не можешь объяснить её за три абзаца — это плохая задача.
Конечно, иногда людям нужно передавать друг-другу действительно много информации. Но почему бы тогда просто не поговорить голосом, и в процессе всё не записать? Когда говоришь лично, включается мимика и интонации, а с помощью этих инструментов гораздо легче передать любое послание.
В общем, если ты написал длинное письмо — стирай его нафиг и назначай встречу.
См. также Длинные ТЗ не работают
#тупое_правило
Тупое, но важное правило почтовой переписки, которое я объясняю всем ребятам во всех удалённых командах — если ты сел писать письмо, и у тебя получается больше трёх абзацев — удаляй его нафиг.
Чем больше текста в письме, тем больше шанс, что его поймут неправильно. Если ты принял решение и не можешь его объяснить за три абзаца — это плохое решение. Если ты выражаешь мнение, и оно не входит в три абзаца — это плохое мнение. Если ты ставишь задачу и не можешь объяснить её за три абзаца — это плохая задача.
Конечно, иногда людям нужно передавать друг-другу действительно много информации. Но почему бы тогда просто не поговорить голосом, и в процессе всё не записать? Когда говоришь лично, включается мимика и интонации, а с помощью этих инструментов гораздо легче передать любое послание.
В общем, если ты написал длинное письмо — стирай его нафиг и назначай встречу.
См. также Длинные ТЗ не работают
#тупое_правило
Больше не работаю в ГдеМатериале
ГдеМатериал — классный проект, который работает на очень интересном рынке. Привести в порядок рынок стройки так же, как Яндекс привёл в порядок рынок такси — это сверхзадача.
В разработке мы дошли до стадии, когда команда перестала во мне нуждаться — сильные разработчики, которые умеют общаться с бизнесом и не стесняются тратить время на исправление техдолга, вполне могут работать и без CTO. Вова, Дима, Леван, Лёша, Лёша, Никита — вы крутые, спасибо вам!
Ну а у меня впереди то же самое, что я сделал в ГдеМатериале, только умноженное на 10. Если вы хотите, чтобы мы с Саматом сделали в вашем бизнесе продуктовую разработку, которая внимательно слушает бизнес и не проёбывает дедлайны — пишите.
ГдеМатериал — классный проект, который работает на очень интересном рынке. Привести в порядок рынок стройки так же, как Яндекс привёл в порядок рынок такси — это сверхзадача.
В разработке мы дошли до стадии, когда команда перестала во мне нуждаться — сильные разработчики, которые умеют общаться с бизнесом и не стесняются тратить время на исправление техдолга, вполне могут работать и без CTO. Вова, Дима, Леван, Лёша, Лёша, Никита — вы крутые, спасибо вам!
Ну а у меня впереди то же самое, что я сделал в ГдеМатериале, только умноженное на 10. Если вы хотите, чтобы мы с Саматом сделали в вашем бизнесе продуктовую разработку, которая внимательно слушает бизнес и не проёбывает дедлайны — пишите.
Обычно я не пишу на громкие темы. Зачем конкурировать за внимание с журналистами и блогерами, у которых занимать внимание — это фуллтаймовая работа? Но сегодня я понял, что не могу пройти мимо коронавируса, простите.
Меня волнует не возможный масштаб эпидемии, уровень смертности или способы передачи вируса — не спускаться лишний раз в метро и почаще мыть руки не помешало бы и в любом другом марте, не только во времена пандемии. Скорее меня волнует то бесчисленное количество энергии, которое мы сжигаем на обновление главных страниц новостных изданий, комменты на фейсбучке, обсуждения в чатиках и возле кулера.
Коронавирус, падение рубля и передача власти когда-нибудь всё равно закончатся — как ICO, атипичная пневмония или прошлое падение рубля. И тогда вы останетесь с последствиями решений, которые напринимали на этом хайпе: с незаконченными делами, распроданными активами, невыполненными договорённостями, сорванными встречами.
Важно ли вам будет через год, сколько заболевших коронавирусом найдут в России 18 марта? Или всё-таки вас будет волновать настроение, с которым вы проснётесь утром, количество денег на ваших счетах и отношения с близкими людьми?
Если второе — прямо сейчас перестаньте читать новости и займитесь делом.
Меня волнует не возможный масштаб эпидемии, уровень смертности или способы передачи вируса — не спускаться лишний раз в метро и почаще мыть руки не помешало бы и в любом другом марте, не только во времена пандемии. Скорее меня волнует то бесчисленное количество энергии, которое мы сжигаем на обновление главных страниц новостных изданий, комменты на фейсбучке, обсуждения в чатиках и возле кулера.
Коронавирус, падение рубля и передача власти когда-нибудь всё равно закончатся — как ICO, атипичная пневмония или прошлое падение рубля. И тогда вы останетесь с последствиями решений, которые напринимали на этом хайпе: с незаконченными делами, распроданными активами, невыполненными договорённостями, сорванными встречами.
Важно ли вам будет через год, сколько заболевших коронавирусом найдут в России 18 марта? Или всё-таки вас будет волновать настроение, с которым вы проснётесь утром, количество денег на ваших счетах и отношения с близкими людьми?
Если второе — прямо сейчас перестаньте читать новости и займитесь делом.
Тесты снимают когнитивную нагрузку
Чтобы соответствовать бизнес-требованиям, нужно постоянно с ними сверяться (написал и почувствовал себя инфобизнесменом — покупайте мои курсы, кек).
Есть ребята, которые сверяются вручную — прямо садятся раз в пару часов и прогоняют мышкой операции, похожие на поведение пользователя. Кроме того, что выглядит это глупо (всегда хотел посмотреть как без автотестов проверяют свой код разработчики API), это ещё и жрет кучу времени.
Кроме прямых затрат, есть ещё косвенные — программист без тестов за спиной постоянно вынужден думать, «как бы чего не сломать»: ведь не будешь же после каждого ветвления в коде садиться и протыкивать весь интерфейс заново.
У ребят с тестами все наоборот, спокойно: у них всегда на экране есть лампочка. Зелёная — все работает, красная — все сломалось. Конечно хорошие разработчики всегда ходят в пользовательский интерфейс, но только для того, чтобы увидеть картинку глазами пользователя.
А не чтобы убедиться, что не сломали все нафиг.
Чтобы соответствовать бизнес-требованиям, нужно постоянно с ними сверяться (написал и почувствовал себя инфобизнесменом — покупайте мои курсы, кек).
Есть ребята, которые сверяются вручную — прямо садятся раз в пару часов и прогоняют мышкой операции, похожие на поведение пользователя. Кроме того, что выглядит это глупо (всегда хотел посмотреть как без автотестов проверяют свой код разработчики API), это ещё и жрет кучу времени.
Кроме прямых затрат, есть ещё косвенные — программист без тестов за спиной постоянно вынужден думать, «как бы чего не сломать»: ведь не будешь же после каждого ветвления в коде садиться и протыкивать весь интерфейс заново.
У ребят с тестами все наоборот, спокойно: у них всегда на экране есть лампочка. Зелёная — все работает, красная — все сломалось. Конечно хорошие разработчики всегда ходят в пользовательский интерфейс, но только для того, чтобы увидеть картинку глазами пользователя.
А не чтобы убедиться, что не сломали все нафиг.
Сейчас очень горячие времена для всех служб доставки — люди сидят дома и делают в 2–5 раз больше заказов, чем обычно. Растёт нагрузка и на ИТ — всех этих юзеров нужно обслуживать: показывать сайты/каталоги/лендинги, принимать заказы, управлять курьерами. Уверен, пуканы горят не только у нас в iGooods — закрывались Окей и Утконос, вводят ограничения другие службы доставки.
Сегодня мы переменным успехом пролежали почти полдня. Сейчас заскейлились с пятикратным запасом, выдохнули и пишем пост-мортемы. Причины падений кажутся очевидными (надеюсь из-за послезнания), но я всё равно поделюсь парой советов, что делать, чтобы не быть как мы.
— Научитесь понимать, что происходит. Мастхев — APM, дешборды с нагрузкой по каждому серверу, количеством тасков в очередях и внутренними метриками приложения. Идеально подходит Датадог. Дешборды не должны быть «номинальными», в них нужно смотреть.
— Собирайте артефакты. Пусть логи буду доступны всегда в одном месте (лучше — в том же датадоге). Настройте контроль ошибок с помощью Sentry или Bugsnag, и приучитесь туда ходить.
— Сделайте приложение 12-факторным. Если приложение не может запуститься одной командой на вашей домашней тачке — вы не заскейлитесь.
— Проверьте, насколько ваша инфраструктура способна к горизонтальному масштабированию. Проведите лёгкий мысленный эксперимент — возьмите каждый сервер, который у вас есть и представьте, что рядом стоит второй такой же. Сможете его нагрузить?
— Заведите «план побега» на случай выросшей нагрузки. Пусть вся команда знает, какие сервисы нужно сохранять в любом случае, а какими можно на время пожертвовать. Мы в iGooods к примеру сразу сфокусировались на внутренних интерфейсах, чтобы сначала отвезти уже сделанные заказы, а потом принимать новые.
Очень часто под нагрузкой вылезает весь накопленный техдолг — не тяните, расплачивайтесь сейчас.
Сегодня мы переменным успехом пролежали почти полдня. Сейчас заскейлились с пятикратным запасом, выдохнули и пишем пост-мортемы. Причины падений кажутся очевидными (надеюсь из-за послезнания), но я всё равно поделюсь парой советов, что делать, чтобы не быть как мы.
— Научитесь понимать, что происходит. Мастхев — APM, дешборды с нагрузкой по каждому серверу, количеством тасков в очередях и внутренними метриками приложения. Идеально подходит Датадог. Дешборды не должны быть «номинальными», в них нужно смотреть.
— Собирайте артефакты. Пусть логи буду доступны всегда в одном месте (лучше — в том же датадоге). Настройте контроль ошибок с помощью Sentry или Bugsnag, и приучитесь туда ходить.
— Сделайте приложение 12-факторным. Если приложение не может запуститься одной командой на вашей домашней тачке — вы не заскейлитесь.
— Проверьте, насколько ваша инфраструктура способна к горизонтальному масштабированию. Проведите лёгкий мысленный эксперимент — возьмите каждый сервер, который у вас есть и представьте, что рядом стоит второй такой же. Сможете его нагрузить?
— Заведите «план побега» на случай выросшей нагрузки. Пусть вся команда знает, какие сервисы нужно сохранять в любом случае, а какими можно на время пожертвовать. Мы в iGooods к примеру сразу сфокусировались на внутренних интерфейсах, чтобы сначала отвезти уже сделанные заказы, а потом принимать новые.
Очень часто под нагрузкой вылезает весь накопленный техдолг — не тяните, расплачивайтесь сейчас.
Живые советы в следующую среду
25 марта в Коворкафе пройдут очередные живые советы. Как всегда, будем говорить об управлении программистами — как навести порядок, где искать время на исправление техдолга, как найти общий язык с бизнесом и вообще всё успевать. Если программист, которым надо управлять — это вы сами, тоже приходите.
Формат у нас каждый раз разный — иногда это камерные посиделки с жарким обсуждением способов тестирования питоньего кода, иногда — жёсткие менеджерские советы. В любом случае — будет интересно.
25 марта в Коворкафе пройдут очередные живые советы. Как всегда, будем говорить об управлении программистами — как навести порядок, где искать время на исправление техдолга, как найти общий язык с бизнесом и вообще всё успевать. Если программист, которым надо управлять — это вы сами, тоже приходите.
Формат у нас каждый раз разный — иногда это камерные посиделки с жарким обсуждением способов тестирования питоньего кода, иногда — жёсткие менеджерские советы. В любом случае — будет интересно.
#вопрос: как разбивать монолит на части?
Я постараюсь ответить не про архитектуру (микросервисы или нет — думаю, вам виднее), а про управление процессом.
Разбивать монолит на части нужно так же, как и исправлять любой другой технический долг — синхронизировавшись с бизнесом. Скажем, если ваш бизнес планирует новую систему управления логистикой — будет странно, если вы первым начнёте вынимать из монолита не её, а какую-нибудь систему отчётов.
Поговорите с бизнесом о планах на ближайшее время, и впишите туда рефакторинг тех частей приложения, которые ускорят вашу работу. Жёстко: если задача по рефакторингу не ускоряет работу — нафиг. Переписывать ради переписывания не хочет никто.
Как и с любым рефакторингом, важно не пропадать надолго: если вы берёте у бизнеса полгода, жиденько поясняя, что по-другому никак и «всё плохо» — скорее всего, что-то идёт не так. Подумайте, как разобрать вашу работу на понятные и короткие части: скажем для новых микросервисов можно использовать существующее HTTP API, а затягивать сразу какую-нибудь Kafka.
Задавайте свои вопросы на [email protected]
Я постараюсь ответить не про архитектуру (микросервисы или нет — думаю, вам виднее), а про управление процессом.
Разбивать монолит на части нужно так же, как и исправлять любой другой технический долг — синхронизировавшись с бизнесом. Скажем, если ваш бизнес планирует новую систему управления логистикой — будет странно, если вы первым начнёте вынимать из монолита не её, а какую-нибудь систему отчётов.
Поговорите с бизнесом о планах на ближайшее время, и впишите туда рефакторинг тех частей приложения, которые ускорят вашу работу. Жёстко: если задача по рефакторингу не ускоряет работу — нафиг. Переписывать ради переписывания не хочет никто.
Как и с любым рефакторингом, важно не пропадать надолго: если вы берёте у бизнеса полгода, жиденько поясняя, что по-другому никак и «всё плохо» — скорее всего, что-то идёт не так. Подумайте, как разобрать вашу работу на понятные и короткие части: скажем для новых микросервисов можно использовать существующее HTTP API, а затягивать сразу какую-нибудь Kafka.
Задавайте свои вопросы на [email protected]
Давно не рассказывал новостей об iGooods, исправляюсь.
Самое главное — мы смасштабировались, теперь работаем с запасом на x2 увеличение нагрузки. После обращения президента в среду был рекорд по RPS за всю жизнь сервиса — инфраструктуре, в целом, пофиг.
Смасштабировались конечно плохо, но быстро — просто заткнули дыры новым железом. Теперь смотрим в датадог, ищем самые нагруженные места и оптимизируем: где-то чиним кеш, где-то избавляемся от N+1. Узкие места — не API, а старое рельсовое приложение (кто бы мог подумать!): если нагрузка будет больше расти с мобилок, чем с десктопа — выдержим наверное x3 или даже x4.
Готовимся к ядерному апокалипсису — пишем план на случай если в Москве и Питере одновременно запретят выходить из дома всем, кроме служб доставки. Упираемся в техдолг — наша версия рельсы не даёт масштабировать БД: она банально не умеет писать в один сервер, а читать из другого. Известные гемы не проходят регрессионное тестирование, так что если не успеем бампнуть рельсу до апокалипсиса, придётся искать эксклюзивное железо под БД, вроде обещают за 3 дня поставить.
Пока выдохнули, занимаемся командой — отправили тимлида в отпуск, я перехватил оперативное управление. В который раз убеждаюсь, что слек — огромная потеря времени.
Нанимаем бекендеров в продуктовые команды, активно используем две триальные недели. Есть даже первый финишировавший — привет, Андрей!
В бизнесе смасштабироваться не так просто, но мы активно помогаем — за эту неделю сделали два новых сервиса, которые помогают увеличить штат. Код пишем так, чтобы его можно было в любой момент вырвать из монолита, «сбоку» — на телеграме, внешних сервисах, костыльных админках.
Почти внедрили datadog — собираем уже все нужные метрики, настраиваем триггеры. Есть борды по 4 золотым сигналам для всего, кроме фоновых задач. Странный resque вместо sidekiq бесит — чтобы собирать статистику по наполненности очередей, приходится использовать prometheus посередине. Но тоже вроде справились.
Самое главное — мы смасштабировались, теперь работаем с запасом на x2 увеличение нагрузки. После обращения президента в среду был рекорд по RPS за всю жизнь сервиса — инфраструктуре, в целом, пофиг.
Смасштабировались конечно плохо, но быстро — просто заткнули дыры новым железом. Теперь смотрим в датадог, ищем самые нагруженные места и оптимизируем: где-то чиним кеш, где-то избавляемся от N+1. Узкие места — не API, а старое рельсовое приложение (кто бы мог подумать!): если нагрузка будет больше расти с мобилок, чем с десктопа — выдержим наверное x3 или даже x4.
Готовимся к ядерному апокалипсису — пишем план на случай если в Москве и Питере одновременно запретят выходить из дома всем, кроме служб доставки. Упираемся в техдолг — наша версия рельсы не даёт масштабировать БД: она банально не умеет писать в один сервер, а читать из другого. Известные гемы не проходят регрессионное тестирование, так что если не успеем бампнуть рельсу до апокалипсиса, придётся искать эксклюзивное железо под БД, вроде обещают за 3 дня поставить.
Пока выдохнули, занимаемся командой — отправили тимлида в отпуск, я перехватил оперативное управление. В который раз убеждаюсь, что слек — огромная потеря времени.
Нанимаем бекендеров в продуктовые команды, активно используем две триальные недели. Есть даже первый финишировавший — привет, Андрей!
В бизнесе смасштабироваться не так просто, но мы активно помогаем — за эту неделю сделали два новых сервиса, которые помогают увеличить штат. Код пишем так, чтобы его можно было в любой момент вырвать из монолита, «сбоку» — на телеграме, внешних сервисах, костыльных админках.
Почти внедрили datadog — собираем уже все нужные метрики, настраиваем триггеры. Есть борды по 4 золотым сигналам для всего, кроме фоновых задач. Странный resque вместо sidekiq бесит — чтобы собирать статистику по наполненности очередей, приходится использовать prometheus посередине. Но тоже вроде справились.
#вопрос: как найти удалённую работу на полставки? Хочу перейти на частичную удалёнку, чтобы учить параллельно новое направление — NLP. Курсы по NLP требуют большого количества выполнения домашки поэтому не хочу на фулл-тайм.
Будучи джуниором, найти удалённую парт-тайм работу весьма тяжело: таких как вы, скорее всего, на рынке труда очень много.
Выделитесь из толпы — к примеру, направьте время, которое собирались тратить на парт-тайме, на собственный проект для портфолио. Если занимаетесь NLP — сделайте бота, который как-нибудь интересно и с пользой разбирает речь, к примеру делает эмоциональный анализ сообщений в рабочих чатах.
Уверен, такой проект можно сделать, и не отрываясь от основной работы. А имея за спиной законченный и работающий проект, вы автоматически перестаёте быть джуном, а значит и спрос на ваши услуги на рынке сильно повышается — можно искать уже фалл-тайм работу в хорошей компании.
Задавайте вопросы на [email protected].
Будучи джуниором, найти удалённую парт-тайм работу весьма тяжело: таких как вы, скорее всего, на рынке труда очень много.
Выделитесь из толпы — к примеру, направьте время, которое собирались тратить на парт-тайме, на собственный проект для портфолио. Если занимаетесь NLP — сделайте бота, который как-нибудь интересно и с пользой разбирает речь, к примеру делает эмоциональный анализ сообщений в рабочих чатах.
Уверен, такой проект можно сделать, и не отрываясь от основной работы. А имея за спиной законченный и работающий проект, вы автоматически перестаёте быть джуном, а значит и спрос на ваши услуги на рынке сильно повышается — можно искать уже фалл-тайм работу в хорошей компании.
Задавайте вопросы на [email protected].
Инфостиль в заголовках задач
Я не сильно докапываюсь к чистоте текста в задачах и служебной переписке: конечно клёво, когда люди пишут понятно, но не всем нужно это учить: нафига какому-нибудь руководителю логистической службы писать тексты на 8 баллов главреда? Главное, чтобы он мог хоть как-то сформулировать сигнал, что болит — а дальше придут опытные продакты/проджекты и всё выяснят.
Но есть одно место, где я жёстко включаю Ильяхова — это заголовки задач в трекере. На сколько вы бы захотели работать в команде, которая целый день занимается какой-нибудь «необходимостью реализовать новый механизм построения отчётности» и, чтобы не произносить это дерьмо в слух, называет задачи по номерам (типа «Как там задача 1238?»). Я — не хотел бы.
Вот пара правил для заголовков задач, которые помогут не превращать трекер в бухгалтерский отчёт:
— Из заголовка чётко понятно, что нужно сделать. Не «доработать логику корзины», а «Сделать, чтобы при удалении последнего товара корзина очищалась».
— Никакой воды: смело рубить всякие «необходимо реализовать» и «отсутствие возможности».
— В заголовке есть понятные для всей команды ключевые слова. Если задача про вкладку Логистика, то так и писать «логистика», а не «интерфейс менеджера-логиста».
— Если задача мало декомпозирована («привести в порядок учёт зарплаты») то заголовок должен описывать следующий понятный шаг, к примеру «Понять, почему заказ 100500 не пробросился в 1с» или «сделать кнопку «не согласен с расчётом».
Update: для любой проблемы уже давно написан специализированный сервис. Мне тут подсказали https://bugred.ru, который как главред, только для задач в трекере.
Я не сильно докапываюсь к чистоте текста в задачах и служебной переписке: конечно клёво, когда люди пишут понятно, но не всем нужно это учить: нафига какому-нибудь руководителю логистической службы писать тексты на 8 баллов главреда? Главное, чтобы он мог хоть как-то сформулировать сигнал, что болит — а дальше придут опытные продакты/проджекты и всё выяснят.
Но есть одно место, где я жёстко включаю Ильяхова — это заголовки задач в трекере. На сколько вы бы захотели работать в команде, которая целый день занимается какой-нибудь «необходимостью реализовать новый механизм построения отчётности» и, чтобы не произносить это дерьмо в слух, называет задачи по номерам (типа «Как там задача 1238?»). Я — не хотел бы.
Вот пара правил для заголовков задач, которые помогут не превращать трекер в бухгалтерский отчёт:
— Из заголовка чётко понятно, что нужно сделать. Не «доработать логику корзины», а «Сделать, чтобы при удалении последнего товара корзина очищалась».
— Никакой воды: смело рубить всякие «необходимо реализовать» и «отсутствие возможности».
— В заголовке есть понятные для всей команды ключевые слова. Если задача про вкладку Логистика, то так и писать «логистика», а не «интерфейс менеджера-логиста».
— Если задача мало декомпозирована («привести в порядок учёт зарплаты») то заголовок должен описывать следующий понятный шаг, к примеру «Понять, почему заказ 100500 не пробросился в 1с» или «сделать кнопку «не согласен с расчётом».
Update: для любой проблемы уже давно написан специализированный сервис. Мне тут подсказали https://bugred.ru, который как главред, только для задач в трекере.
Как быть, если всё время уходит на разработку всё новых и новых фич?
Написал мега-полезный практический совет. Рассказываю, как продать бизнесу необходимость расплачиваться с техдолгом, и как построить систему, при которой расплата происходит системно.
Написал мега-полезный практический совет. Рассказываю, как продать бизнесу необходимость расплачиваться с техдолгом, и как построить систему, при которой расплата происходит системно.
#вопрос: У нас небольшая компания, и нет команды разработки, я — единственный программист. Поработал полтора года и что-то заскучал: задач хватает как раз примерно на одного человека. Конечно, мне всегда кажется, что их больше, чем я бы мог сделать, но это сглаживается отсутствием жестких сроков. Сделал — хорошо, не сделал — ну потом как-нибудь сделаешь. То есть бизнес готов мириться с тяготами ограниченного ресурса разработки, готов долго ждать выполнения задач, готов потерять разработчика и искать нового пару месяцев (и ничего плохого за это время не случится).
Среди потока бизнес-задач, напрямую приносящих компании деньги, мои попытки оптимизировать процессы, порешать техдолг, наладить инфраструктуру выглядят, как никому не нужное ковыряние в песочнице.
В конечном счете я потерял в этом смысл, потому что «и так все работает». Что бы ты порекомендовал в подобной ситуации? Стоит ли менять место работы, или же можно что-то исправить, чтобы не застаиваться?
————————
Ответ
Многие люди годами сидят на одном месте, фокусируясь на всём, кроме работы — семье и детях, ипотеке, плейстейшене или вышивании крестиком. Это — не хорошо и не плохо: это их жизнь и их выбор.
Подумай, а какой выбор делаешь ты? Этот выбор нельзя откладывать или игнорировать — если всю жизнь поступать так как получается, а не как хочется — вряд ли к 50 годам окажешься счастлив.
Если соберёшься менять работу — имей ввиду: твоя история не очень хорошо продаст тебя на собеседовании. Не забудь про домашнюю работу — собери портфолио, поконтрибьють в опенсорс.
Среди потока бизнес-задач, напрямую приносящих компании деньги, мои попытки оптимизировать процессы, порешать техдолг, наладить инфраструктуру выглядят, как никому не нужное ковыряние в песочнице.
В конечном счете я потерял в этом смысл, потому что «и так все работает». Что бы ты порекомендовал в подобной ситуации? Стоит ли менять место работы, или же можно что-то исправить, чтобы не застаиваться?
————————
Ответ
Многие люди годами сидят на одном месте, фокусируясь на всём, кроме работы — семье и детях, ипотеке, плейстейшене или вышивании крестиком. Это — не хорошо и не плохо: это их жизнь и их выбор.
Подумай, а какой выбор делаешь ты? Этот выбор нельзя откладывать или игнорировать — если всю жизнь поступать так как получается, а не как хочется — вряд ли к 50 годам окажешься счастлив.
Если соберёшься менять работу — имей ввиду: твоя история не очень хорошо продаст тебя на собеседовании. Не забудь про домашнюю работу — собери портфолио, поконтрибьють в опенсорс.
Dotbot и Ansible
Настроить новый компьютер, особенно для программиста — это всегда тяжело: нужно ставить кучу программ и утилит, переносить их настройки (iCloud для них не работает).
Раньше у меня на это уходило по нескольку дней, при этом жутко обидно было тратить кучу времени на бессмысленную возню мышкой, учитывая что в большом мире всё уже давно решено — давно уже есть Ansible и куча скриптов для dotfiles.
Как только я это осознал, я занялся автоматизацией. Получилось не с первого раза, но в итоге получилось. На выходных представился случай проверить — мой основной ноутбук с Catalina после последнего обновления стал зависать по два раза в день.
В итоге, я развернул с нуля компьютер, на котором пишу этот пост, примерно за полтора часа. И это включая всё моё окружение для разработки, все маковские программы и заморочки вроде Karabiner Elements и BetterTouchTool.
Если тоже пользуетесь маком для разработки и не пугаетесь слов homebrew и git — посмотрите мои наработки на гитхабе. Не уверен, что они пригодятся из коробки, на даже если почерпнёте оттуда пару идей — буду рад.
Настроить новый компьютер, особенно для программиста — это всегда тяжело: нужно ставить кучу программ и утилит, переносить их настройки (iCloud для них не работает).
Раньше у меня на это уходило по нескольку дней, при этом жутко обидно было тратить кучу времени на бессмысленную возню мышкой, учитывая что в большом мире всё уже давно решено — давно уже есть Ansible и куча скриптов для dotfiles.
Как только я это осознал, я занялся автоматизацией. Получилось не с первого раза, но в итоге получилось. На выходных представился случай проверить — мой основной ноутбук с Catalina после последнего обновления стал зависать по два раза в день.
В итоге, я развернул с нуля компьютер, на котором пишу этот пост, примерно за полтора часа. И это включая всё моё окружение для разработки, все маковские программы и заморочки вроде Karabiner Elements и BetterTouchTool.
Если тоже пользуетесь маком для разработки и не пугаетесь слов homebrew и git — посмотрите мои наработки на гитхабе. Не уверен, что они пригодятся из коробки, на даже если почерпнёте оттуда пару идей — буду рад.
Единицы смысла в электронной почте
Четверть рабочего времени я провожу в почтовом клиенте. Как отследить эффективность расхода такой кучи времени? Количественные показатели не подходят — можно написать 70 писем, а в ответ вместо результата получить 70 новых писем.
Лебедев оценивает дизайнеров единицами смысла. У электронного письма есть похожий показатель — если вкратце, то в письме нет смысла, если в ответ на него прилетает ещё одно письмо.
В поставленной задаче нет смысла, если она требует уточнений. Информация не нужна, если не отвечает на вопрос, который беспокоит запросившего (а не тот который написан в письме). Вопрос, на который нельзя ответить двумя предложениями, тоже не несёт смысла — на него скорее всего не ответят.
Повысить осмысленность своих писем легко — сократите количество подходов к почтовому клиенту. Обидно написать с утра письмо, и только вечером увидеть в ответ «ой, а я не понял» — за целый день задача не продвинется из-за одного ленивого менеджера. Волей-неволей будете писать понятнее.
Кстати, показатель осмысленности письма нужно разделять на количество тех, кто стоит в копии. Если письмо получит 10 человек — до каждого из них долетит только 0,1 смысла. Или вкладывайте в такие письма в 10 раз больше смысла, или пишите одному человеку.
Четверть рабочего времени я провожу в почтовом клиенте. Как отследить эффективность расхода такой кучи времени? Количественные показатели не подходят — можно написать 70 писем, а в ответ вместо результата получить 70 новых писем.
Лебедев оценивает дизайнеров единицами смысла. У электронного письма есть похожий показатель — если вкратце, то в письме нет смысла, если в ответ на него прилетает ещё одно письмо.
В поставленной задаче нет смысла, если она требует уточнений. Информация не нужна, если не отвечает на вопрос, который беспокоит запросившего (а не тот который написан в письме). Вопрос, на который нельзя ответить двумя предложениями, тоже не несёт смысла — на него скорее всего не ответят.
Повысить осмысленность своих писем легко — сократите количество подходов к почтовому клиенту. Обидно написать с утра письмо, и только вечером увидеть в ответ «ой, а я не понял» — за целый день задача не продвинется из-за одного ленивого менеджера. Волей-неволей будете писать понятнее.
Кстати, показатель осмысленности письма нужно разделять на количество тех, кто стоит в копии. Если письмо получит 10 человек — до каждого из них долетит только 0,1 смысла. Или вкладывайте в такие письма в 10 раз больше смысла, или пишите одному человеку.
#вопрос Есть разработчик, который неплохо справлялся с задачами в офисе — если и срывал сроки, то по объективным причинам. Сейчас из-за коронавируса команда полностью перешла на удалёнку, и разработчик начал срывать сроки — говорит, что ему не нравится работать на удалёнке. Чтобы вы могли посоветовать?
Я бы начал с разговора. Удалённая работа — это не «как в офисе в только дома», она требует совсем другого подхода.
Дома совсем другие отвлекающие факторы: если в офисе это коллеги, которые соблюдают определённые границы, то дома это может быть всё, что угодно — от холодильника и плейстейшна до близких, которые просто не понимают, что их любимый человек сейчас не с ними, а на работе.
Нужно не забывать и про психологическое давление — читать новости в Москве сейчас как никогда тяжело. Лично мне пришлось отказаться даже от еженедельных рассылок, чтобы чувствовать себя в порядке.
Вовлекающие факторы дома тоже другие — многие из нас лишились привычных больших мониторов, кресел, любимых диванчиков для работы. У кого-то даже компьютеры остались в офисе!
В общем поговорите с разработчиком, выясните, что у него не так в новом окружении. Вдруг поймёте, что удалёнка не нравится потому, что дома у него какой-нибудь неудобный стол — просто купите новый, и всё будет хорошо. Если дело не во внешней среде, а во внутренней — предложите оплатить пару пробных занятий у психотерапевта, это сейчас полезно всем.
Я бы начал с разговора. Удалённая работа — это не «как в офисе в только дома», она требует совсем другого подхода.
Дома совсем другие отвлекающие факторы: если в офисе это коллеги, которые соблюдают определённые границы, то дома это может быть всё, что угодно — от холодильника и плейстейшна до близких, которые просто не понимают, что их любимый человек сейчас не с ними, а на работе.
Нужно не забывать и про психологическое давление — читать новости в Москве сейчас как никогда тяжело. Лично мне пришлось отказаться даже от еженедельных рассылок, чтобы чувствовать себя в порядке.
Вовлекающие факторы дома тоже другие — многие из нас лишились привычных больших мониторов, кресел, любимых диванчиков для работы. У кого-то даже компьютеры остались в офисе!
В общем поговорите с разработчиком, выясните, что у него не так в новом окружении. Вдруг поймёте, что удалёнка не нравится потому, что дома у него какой-нибудь неудобный стол — просто купите новый, и всё будет хорошо. Если дело не во внешней среде, а во внутренней — предложите оплатить пару пробных занятий у психотерапевта, это сейчас полезно всем.