Еще про планирование
В предыдущем посте выяснили, что у нас проект это какой-то стохастический процесс. Что это значит? Это значит, что у нас есть вероятностное пространство! (Omega, F, P) — множество элементарных исходов, сигма алгебра и вероятностная мера. Что примечательно, сигма алгебра вообще говоря не обязана быть одинаковой для каждого момента времени t. Более того, если мы с вами посмотрим на то, как устроены большинство стох моделей, имеющих отношение к реальному миру, то увидим, что сигма алгебра в них расширяется со временем.
Я напомню, что сигма алгебра это, простыми словами, набор того, что может случиться. И вот эта мера P, она задана именно на сигма-алгебре F, т.е. она умеет мерить вероятность конкретного события.
Так вот, из-за того, что какие-то события происходят, информация о них имеется во все последующие моменты времени. Но вот в моменты времени t<t_n нет никакой информации о событиях, которые происходят начиная с момента t_n. Из-за этого сигма алгебра расширяется, информированность растёт. Уровень неопределенности уменьшается (*не убывает для душнил типа меня).
Получается, то наша стохастическая модель планирования подталкивает нас к выводу, что решения нужно принимать максимально поздно, имея максимально много информации и минимальный уровень неопределенности.
В предыдущем посте выяснили, что у нас проект это какой-то стохастический процесс. Что это значит? Это значит, что у нас есть вероятностное пространство! (Omega, F, P) — множество элементарных исходов, сигма алгебра и вероятностная мера. Что примечательно, сигма алгебра вообще говоря не обязана быть одинаковой для каждого момента времени t. Более того, если мы с вами посмотрим на то, как устроены большинство стох моделей, имеющих отношение к реальному миру, то увидим, что сигма алгебра в них расширяется со временем.
Я напомню, что сигма алгебра это, простыми словами, набор того, что может случиться. И вот эта мера P, она задана именно на сигма-алгебре F, т.е. она умеет мерить вероятность конкретного события.
Так вот, из-за того, что какие-то события происходят, информация о них имеется во все последующие моменты времени. Но вот в моменты времени t<t_n нет никакой информации о событиях, которые происходят начиная с момента t_n. Из-за этого сигма алгебра расширяется, информированность растёт. Уровень неопределенности уменьшается (*не убывает для душнил типа меня).
Получается, то наша стохастическая модель планирования подталкивает нас к выводу, что решения нужно принимать максимально поздно, имея максимально много информации и минимальный уровень неопределенности.
😁12❤1👍1🤔1
Зачем нужны джуны?
Многие задумывались: почему бы не взять в команду одних сеньоров и херачить всё быстро, качественно и умно? Хороших ответов я не слышал. Обычно говорят, мол, дорого. В том смысле, что всегда есть рутинная и простая работа, за которую платить сенбору дорого. Возможно. Но, честно говоря, не убедительно. С моим опытом не бьется. Сеньоры простые рутинные задачи делают гораздо быстрее, не тратят время на корректировки решений от младших, могут нормально подумать о сложных вещах, пока код пишут. Time to market одними сеньорами точно меньше.
Так вот, нужно вспомнить, что вообще-то в хорошей команде люди должны развиваться. В том числе сеньоры. А самый эффективный путь сеньора в лиды (ведущий разработчик, IC) — прокачивать младших. Менторинг развивает ментора. Это очевидно каждому, кто пытался что-то объяснить детям. Свежий взгляд с неожиданной стороны, прилив новых идей и технологий, безумные теории из самых темных углов интернета, невероятные семиколёсные летающие сани — всё это можно встретить, работая с младшими.
Дальше уже про бигтех. В больших компаниях всё стараются унифицировать, потому что индивидуальный подход — это слишком дорого. Отсюда линейки грейдов (привет, levels.fyi), матрицы компетенций, перфоманс ревью и т.д.
Так вот, чтобы в твоей команде были успешные, уважаемые лиды, нужно их в эти общекомпанейские фреймворки правильно вставить.
Ведущие разрабы очень часто оказываются в ситуации, когда они мало пишут кода, потому что архитектурные комитеты проводят, какие-то там гайдлайны разрабатывают, космолёты строят, короче. От них, соответственно, не ожидается много кода (т.е. логика, как на младших грейдах, где мидл должен писать больше джуна, не работает). Но зато от них ожидается, что они будут не только красивые устойчивые и надежные архитектуры делать, но еще улучшать качество кода и окружения систем и разработки вообще. Отсюда же делаем вывод, что они должны прокачивать младших (чтобы те писали код качественнее, быстрее и надежнее). Это ожидание отражается в перфоманс ревью, в матрицах компетенций (могу накидать в комменты, если хотите).
То есть джун нужен, чтобы сеньора сделать лидом, а лиду, чтобы иметь побольше бласт радиус своей работы.
Так, ок, а че джуну делать?
ОТВЕЧУ ПРИТЧЕЙ.
Когда я был маленький, я смотрел на сеньоров вокруг, делал всё то же, что они и не понимал, какого хрена я джун, а они сеньоры, если мы делаем одно и то же. Потом я вырос и понял, что разница между нами была в том, что сеньоры еще могли и мидловскую работу делать, а я — нет. Но матриц компетенции не было, а на мидлов я не особо смотрел (вероятно из-за высокомерия, а может потому что смотрел на "лучших" — не знаю). Поэтому я не знал, что есть что-то еще посередине. Сегодня я вижу таких же ребят в дельта окрестности от себя. Они уже умеют всякое сеньорское (пусть сильно медленнее), но не умеют мидловское. Вспоминаем про бигтехи, ревью и матрицы компетенций. Там прыгнуть через грейд нельзя. А чтобы вырасти в мидла, нужно обладать навыками мидла. Не сеньора. Вот такой парадокс.
Поэтому рекомендация джуну: найти матрицу компетенций, вытрясти из рук-ля образ следующего грейда и качаться в этом направлении. 1/2
Многие задумывались: почему бы не взять в команду одних сеньоров и херачить всё быстро, качественно и умно? Хороших ответов я не слышал. Обычно говорят, мол, дорого. В том смысле, что всегда есть рутинная и простая работа, за которую платить сенбору дорого. Возможно. Но, честно говоря, не убедительно. С моим опытом не бьется. Сеньоры простые рутинные задачи делают гораздо быстрее, не тратят время на корректировки решений от младших, могут нормально подумать о сложных вещах, пока код пишут. Time to market одними сеньорами точно меньше.
Так вот, нужно вспомнить, что вообще-то в хорошей команде люди должны развиваться. В том числе сеньоры. А самый эффективный путь сеньора в лиды (ведущий разработчик, IC) — прокачивать младших. Менторинг развивает ментора. Это очевидно каждому, кто пытался что-то объяснить детям. Свежий взгляд с неожиданной стороны, прилив новых идей и технологий, безумные теории из самых темных углов интернета, невероятные семиколёсные летающие сани — всё это можно встретить, работая с младшими.
Дальше уже про бигтех. В больших компаниях всё стараются унифицировать, потому что индивидуальный подход — это слишком дорого. Отсюда линейки грейдов (привет, levels.fyi), матрицы компетенций, перфоманс ревью и т.д.
Так вот, чтобы в твоей команде были успешные, уважаемые лиды, нужно их в эти общекомпанейские фреймворки правильно вставить.
Ведущие разрабы очень часто оказываются в ситуации, когда они мало пишут кода, потому что архитектурные комитеты проводят, какие-то там гайдлайны разрабатывают, космолёты строят, короче. От них, соответственно, не ожидается много кода (т.е. логика, как на младших грейдах, где мидл должен писать больше джуна, не работает). Но зато от них ожидается, что они будут не только красивые устойчивые и надежные архитектуры делать, но еще улучшать качество кода и окружения систем и разработки вообще. Отсюда же делаем вывод, что они должны прокачивать младших (чтобы те писали код качественнее, быстрее и надежнее). Это ожидание отражается в перфоманс ревью, в матрицах компетенций (могу накидать в комменты, если хотите).
То есть джун нужен, чтобы сеньора сделать лидом, а лиду, чтобы иметь побольше бласт радиус своей работы.
Так, ок, а че джуну делать?
Когда я был маленький, я смотрел на сеньоров вокруг, делал всё то же, что они и не понимал, какого хрена я джун, а они сеньоры, если мы делаем одно и то же. Потом я вырос и понял, что разница между нами была в том, что сеньоры еще могли и мидловскую работу делать, а я — нет. Но матриц компетенции не было, а на мидлов я не особо смотрел (вероятно из-за высокомерия, а может потому что смотрел на "лучших" — не знаю). Поэтому я не знал, что есть что-то еще посередине. Сегодня я вижу таких же ребят в дельта окрестности от себя. Они уже умеют всякое сеньорское (пусть сильно медленнее), но не умеют мидловское. Вспоминаем про бигтехи, ревью и матрицы компетенций. Там прыгнуть через грейд нельзя. А чтобы вырасти в мидла, нужно обладать навыками мидла. Не сеньора. Вот такой парадокс.
Поэтому рекомендация джуну: найти матрицу компетенций, вытрясти из рук-ля образ следующего грейда и качаться в этом направлении. 1/2
👍4❤1
Хорошо, но мы вообще-то здесь все менеджеры, почему нам не пофиг?
Как можно догадаться из предыдущего рассуждения, руководителю нужно выстроить команду так, чтобы младшие писали больше кода и качались в мидлов, мидлы качались в сеньоров, а сеньоры писали меньше кода, а больше менторили младших и качались в лидов.
Это в целом здоровая команда, где люди развиваются. Но для бигтеха это еще и способ подойти к ревью с адекватными грейдам достижениями. А значит и способ раздать плюшки наиболее справделиво. 2/2
Как можно догадаться из предыдущего рассуждения, руководителю нужно выстроить команду так, чтобы младшие писали больше кода и качались в мидлов, мидлы качались в сеньоров, а сеньоры писали меньше кода, а больше менторили младших и качались в лидов.
Это в целом здоровая команда, где люди развиваются. Но для бигтеха это еще и способ подойти к ревью с адекватными грейдам достижениями. А значит и способ раздать плюшки наиболее справделиво. 2/2
👍5
Я забуксовал на чтении Канемана примерно на четверти книги. Возможно, потому что пытаюсь читать на отдельном устройстве, возможно, что текст не мой -- не знаю. Но мне понравился эффект от прочтения книг в предыдущие периоды, поэтому нужен был способ мотивации себя. Очень кстати я набрел в интернетиках на идею профессионального книжного клуба. Сначала, я хотел предложить ребятам читать в командах всякие книжки с кабанчиками, но потом понял, что можно читать еще и управленческую литературу в таком формате.
Всё ещё считаю, что разработчикам надо организоваться и тоже вместе что-то читать или проходить курсы. Но тут жду инициативы от лидов -- им виднее, чего там в командах не хватает.
Мы же уже провели первую встречу книжного клуба. А читать мы начали не абы что: классику айтишного управления, книгу, на которую ссылалось вообще всё, что я читал хотя бы косвенно связанное с управлением, великий и ужасный The Mythical Man-Month Брукса. Пока мы прочли только первые три главы, но я уже кайфанул. Книге 50 лет, а сутёво ничего не поменялось. Всё те же причины любить программирование, всё те же причины не любить. Мимоходом всё тот же МЕТОД критической цепи (всегда удивлялся, что это прям особый метод, а не что-то очевидное), всё та же история про коммуникации и ресурсы на них, всё те же ошибки в оценках сроков (никто никогда не думает, что будет тетсировать код в три раза дольше, чем будет его писать, но все всегда так и делают).
Отдельно отмечу главу про операционную. Метафора, как обычно, сомнительная, но есть несколько моментов. Во-первых, кросс-функциональная команда (эджайл тренеры до сих пор думают, что это они придумали). Во-вторых, есть явно выделенный лидер, за которым последнее слово, на котором ответственность (это такая борьба с долгим принятием решений и срачами, какой фреймворк болие лудший). В-третьих, в команде специалисты разного уровня! У них там разные функции. Есть самый главный программист, он ДУМАЕТ и принимает решения. Есть copilot (надеюсь, что современная тула это пасхалка), который в целом такой же крутой, но менее опытный. Он челленджит, об него думает главный, он ищет всякие проблемные места, а еще ходит на встречи, где нужна экспертиза в системе. Еще есть чувак, который просто набивает код (на перфокарты, но чем питон лучше?). Еще один чел пилит вспомогательный софт: всякие библиотечки, тулы, окружение (короче, программки масштабом поменьше основного продукта). И отдельно есть language lawyer, человек, который умеет на этих ваших алголах красивые конструкции делать, чтобы код был круче. Остальные там не программисты.
Это, кстати, типовая история для хорошей команды и сегодня, если почитать интернет и посмотреть, каких людей ищут в команды. Обычно нужен какой-то крутой убер-архитектор, какой сеньор, который будет всех учить жизни и учиться у архитектора, тот парень, который просто херачит код от забора до обеда и ходит к сеньору на ревью, студент, который притащит очередную прикольную библиотеку или обновит вам джаву с восьмой версии уже, а еще меценат, который будет автоматизировать всякую мерзкую рутину для всей команды. Бывают и еще пожелания, но идея всё та же.
Мы, к сожалению, не как пацаны из тинька, на ютуб свой книжный клуб пока не выложим. Но я буду держать вас в курсе, как там прогресс.
А вообще книжку можете почитать и сами. Там независимые эссе, которые Брукс с первого издания не менял. Только дописывал в конец новые. Поэтому в целом вам подойдет любое издание.
Всё ещё считаю, что разработчикам надо организоваться и тоже вместе что-то читать или проходить курсы. Но тут жду инициативы от лидов -- им виднее, чего там в командах не хватает.
Мы же уже провели первую встречу книжного клуба. А читать мы начали не абы что: классику айтишного управления, книгу, на которую ссылалось вообще всё, что я читал хотя бы косвенно связанное с управлением, великий и ужасный The Mythical Man-Month Брукса. Пока мы прочли только первые три главы, но я уже кайфанул. Книге 50 лет, а сутёво ничего не поменялось. Всё те же причины любить программирование, всё те же причины не любить. Мимоходом всё тот же МЕТОД критической цепи (всегда удивлялся, что это прям особый метод, а не что-то очевидное), всё та же история про коммуникации и ресурсы на них, всё те же ошибки в оценках сроков (никто никогда не думает, что будет тетсировать код в три раза дольше, чем будет его писать, но все всегда так и делают).
Отдельно отмечу главу про операционную. Метафора, как обычно, сомнительная, но есть несколько моментов. Во-первых, кросс-функциональная команда (эджайл тренеры до сих пор думают, что это они придумали). Во-вторых, есть явно выделенный лидер, за которым последнее слово, на котором ответственность (это такая борьба с долгим принятием решений и срачами, какой фреймворк болие лудший). В-третьих, в команде специалисты разного уровня! У них там разные функции. Есть самый главный программист, он ДУМАЕТ и принимает решения. Есть copilot (надеюсь, что современная тула это пасхалка), который в целом такой же крутой, но менее опытный. Он челленджит, об него думает главный, он ищет всякие проблемные места, а еще ходит на встречи, где нужна экспертиза в системе. Еще есть чувак, который просто набивает код (на перфокарты, но чем питон лучше?). Еще один чел пилит вспомогательный софт: всякие библиотечки, тулы, окружение (короче, программки масштабом поменьше основного продукта). И отдельно есть language lawyer, человек, который умеет на этих ваших алголах красивые конструкции делать, чтобы код был круче. Остальные там не программисты.
Это, кстати, типовая история для хорошей команды и сегодня, если почитать интернет и посмотреть, каких людей ищут в команды. Обычно нужен какой-то крутой убер-архитектор, какой сеньор, который будет всех учить жизни и учиться у архитектора, тот парень, который просто херачит код от забора до обеда и ходит к сеньору на ревью, студент, который притащит очередную прикольную библиотеку или обновит вам джаву с восьмой версии уже, а еще меценат, который будет автоматизировать всякую мерзкую рутину для всей команды. Бывают и еще пожелания, но идея всё та же.
Мы, к сожалению, не как пацаны из тинька, на ютуб свой книжный клуб пока не выложим. Но я буду держать вас в курсе, как там прогресс.
А вообще книжку можете почитать и сами. Там независимые эссе, которые Брукс с первого издания не менял. Только дописывал в конец новые. Поэтому в целом вам подойдет любое издание.
👍16
Сербская культура проникает в меня. Видимо, поэтому я почти перестал пить чай. Кофе-кофе-кофе, целыми днями кофе. Нагружу вам и сюда чего-то с кофейным вайбом.
Автоматизации двигания задачек туды-сюды. У нас не джира, а Трекер, поэтому готовых рецептов не будет, но вот идеи могут быть полезны.
Какую проблему решаем? Разработчики хотят программирование программировать, а не тикеты между колонками двигать. Менеджеры хотят видеть актуальные статусы проектов. Лид хочет мониторить проблемные места в процессах (например, долгое код-ревью или залеживающиеся решения, не уезжающие в прод после мёржа).
Типовые решения
- Синхронные дейлики (в лучшем случае виклики), где вся команда сидит и смотрит, как менеджер под диктовку двигает карточки в правильные статусы.
- Карательные меры. Лид наказывает разработчиков за неактуальные статусы. Например, запрещает неделю смотреть мультики или не поручает важные задачи.
- Асинхронная ежедневная многократная долбежка в личку, где мы выясняем "ну чо там с задачей?".
- Продать всем ценность двигания тикетов, завести будильники на реактуализацию статусов, поощрять за щепитильность.
Всё фигня, по-моему. Лучше заставить машину двигать тикеты за людей.
1. Идентифицируем проблемные места
Обычно, если человек что-то поделал в тикете, то он не забывает нажать кнопку "я закончил". Поэтому статусы вроде "закончил писать тех дизайн" или "закончил ревьюить дизайн" можно не автоматизировать.
А вот закончил писать код, закончил ревьюить код, выложил в тестинг, выложил в прод -- тут, зачастую, нужно сделать ментальное усилие, чтобы вспомнить про тикет.
2. Переносим действие в ту систему, где человек совершает действие
В нашем случае, система контроля версий, код-ревью, ci/cd -- всё в одном месте, в Аркануме. Настраиваем его так, что на создание пулл-реквеста тикет двигается в статус "пора смотреть", а при мёрже в статус "смёржено". Для гита есть гит-хуки, которые могут точно так же дергать таск-трекер за веб ручки (наверное). Собственно, события сборки и деплоя тоже в идеале должны двигать статусы тикетов.
3. Если не переносится
Тогда есть такой способ последней мили: пинать исполнителя, если тикет дольше нормы в каком-то статусе. У нас это просто джоба, которая раз в час ходит собирает подходящие тикеты и раз в n дней пинает в них исполнителя в комментариях с призывом
Ещё есть проблема с тем, что нужно заполнять какие-то там поля в этих ваших тикетах! Тут тоже спасают напоминалки (проставь исполнителя или оценку), автоматические значения (текущий спринт или дашборда с задачами в работе), калькуляторы полей (у нас CD3 считается автоматом при изменении оценок).
Отдельная форма боли нормального человека -- создавать задачи. Меня тоже ломает каждый раз. Тут есть две штучки в помощь: автосоздание тикетов и формы. Если можно создавать тикеты автоматически, то нужно это делать обязательно. У нас, например, при создании фича-тикета создается автоматом подзадача на декомпозицию -- мелочь, а приятно. А формочки помогают заполнить всё, что нужно, умеют валидировать типы (например, календарик для дедлайнов нарисуют), заставляют писать обязатльные поля, но так же и дают подсказки по формулировкам и контенту. Чтобы ты ничего не забыл, дорогой.
Кстати, про ничего не забыл. У нас всё обложено чек-листами, как у пилотов. Очень удобно эти чек-листы подсовывать по ходу движения тикетов по статусам. Например, на этапе тех дизайна мы напоминаем, что нужно не забыть про схему бд, изменения в API, изменения в нагрузке и т.п., а на этапе раскатки в прод надо вспомнить, на какие графики посмотреть (бизнесовые, железячные, всяких там очередей и т.п.). Иногда для чек-листа текста получается многовато, поэтому можно научить робота присылать комментарии в тикет. А в них можно уже и ссылочки на нужные графики приложить, например.
Рассказывайте про свою борьбу с рутиной!
Автоматизации двигания задачек туды-сюды. У нас не джира, а Трекер, поэтому готовых рецептов не будет, но вот идеи могут быть полезны.
Какую проблему решаем? Разработчики хотят программирование программировать, а не тикеты между колонками двигать. Менеджеры хотят видеть актуальные статусы проектов. Лид хочет мониторить проблемные места в процессах (например, долгое код-ревью или залеживающиеся решения, не уезжающие в прод после мёржа).
Типовые решения
- Синхронные дейлики (в лучшем случае виклики), где вся команда сидит и смотрит, как менеджер под диктовку двигает карточки в правильные статусы.
- Карательные меры. Лид наказывает разработчиков за неактуальные статусы. Например, запрещает неделю смотреть мультики или не поручает важные задачи.
- Асинхронная ежедневная многократная долбежка в личку, где мы выясняем "ну чо там с задачей?".
- Продать всем ценность двигания тикетов, завести будильники на реактуализацию статусов, поощрять за щепитильность.
Всё фигня, по-моему. Лучше заставить машину двигать тикеты за людей.
1. Идентифицируем проблемные места
Обычно, если человек что-то поделал в тикете, то он не забывает нажать кнопку "я закончил". Поэтому статусы вроде "закончил писать тех дизайн" или "закончил ревьюить дизайн" можно не автоматизировать.
А вот закончил писать код, закончил ревьюить код, выложил в тестинг, выложил в прод -- тут, зачастую, нужно сделать ментальное усилие, чтобы вспомнить про тикет.
2. Переносим действие в ту систему, где человек совершает действие
В нашем случае, система контроля версий, код-ревью, ci/cd -- всё в одном месте, в Аркануме. Настраиваем его так, что на создание пулл-реквеста тикет двигается в статус "пора смотреть", а при мёрже в статус "смёржено". Для гита есть гит-хуки, которые могут точно так же дергать таск-трекер за веб ручки (наверное). Собственно, события сборки и деплоя тоже в идеале должны двигать статусы тикетов.
3. Если не переносится
Тогда есть такой способ последней мили: пинать исполнителя, если тикет дольше нормы в каком-то статусе. У нас это просто джоба, которая раз в час ходит собирает подходящие тикеты и раз в n дней пинает в них исполнителя в комментариях с призывом
Ещё есть проблема с тем, что нужно заполнять какие-то там поля в этих ваших тикетах! Тут тоже спасают напоминалки (проставь исполнителя или оценку), автоматические значения (текущий спринт или дашборда с задачами в работе), калькуляторы полей (у нас CD3 считается автоматом при изменении оценок).
Отдельная форма боли нормального человека -- создавать задачи. Меня тоже ломает каждый раз. Тут есть две штучки в помощь: автосоздание тикетов и формы. Если можно создавать тикеты автоматически, то нужно это делать обязательно. У нас, например, при создании фича-тикета создается автоматом подзадача на декомпозицию -- мелочь, а приятно. А формочки помогают заполнить всё, что нужно, умеют валидировать типы (например, календарик для дедлайнов нарисуют), заставляют писать обязатльные поля, но так же и дают подсказки по формулировкам и контенту. Чтобы ты ничего не забыл, дорогой.
Кстати, про ничего не забыл. У нас всё обложено чек-листами, как у пилотов. Очень удобно эти чек-листы подсовывать по ходу движения тикетов по статусам. Например, на этапе тех дизайна мы напоминаем, что нужно не забыть про схему бд, изменения в API, изменения в нагрузке и т.п., а на этапе раскатки в прод надо вспомнить, на какие графики посмотреть (бизнесовые, железячные, всяких там очередей и т.п.). Иногда для чек-листа текста получается многовато, поэтому можно научить робота присылать комментарии в тикет. А в них можно уже и ссылочки на нужные графики приложить, например.
Рассказывайте про свою борьбу с рутиной!
🔥2👍1
Я ПРОШЁЛ ТИМЛИДА 🤡🤡🤡
по метрикам
У нас в компании замутили пилот оценки руководителей их сотрудниками по восьми показателям. Вот тут наша HR директор Даша рассказывала.
Свойства красивые и задумка классная: типа команда анонимно закидывает лиду за воротник, а тот понимает, куда ему расти, какие навыки развивать. На оценку это не влияет (в этот раз по крайней мере), поэтому не должно быть эффекта "похвалю начальника, он добрее будет". По идее. Наверное. Не знаю. Может и есть.На самом деле есть.
Мои ребята там наотвечали так, что я всесторонне развит на максималки.
Как в анекдоте с Физтеха. Почему ты лежишь и нихрена не делаешь? МЫ НА ПЕРЕДНЕМ КРАЕ НАУКИ, ДАЛЬШЕ НИЧЕГО НЕТ.
Короче, приходите ко мне в команду программировать процессинг на golang'е. Метрики говорят, что я идеальный руководитель.
https://yandex.ru/jobs/vacancies/разработчик-процессинга-платежей-golang-15169
У нас в компании замутили пилот оценки руководителей их сотрудниками по восьми показателям. Вот тут наша HR директор Даша рассказывала.
Свойства красивые и задумка классная: типа команда анонимно закидывает лиду за воротник, а тот понимает, куда ему расти, какие навыки развивать. На оценку это не влияет (в этот раз по крайней мере), поэтому не должно быть эффекта "похвалю начальника, он добрее будет". По идее. Наверное. Не знаю. Может и есть.
Мои ребята там наотвечали так, что я всесторонне развит на максималки.
Как в анекдоте с Физтеха. Почему ты лежишь и нихрена не делаешь? МЫ НА ПЕРЕДНЕМ КРАЕ НАУКИ, ДАЛЬШЕ НИЧЕГО НЕТ.
Короче, приходите ко мне в команду программировать процессинг на golang'е. Метрики говорят, что я идеальный руководитель.
https://yandex.ru/jobs/vacancies/разработчик-процессинга-платежей-golang-15169
🔥16❤5😁5👍2🌚1
У Брукса есть повторяющийся тезис о том, что всегда нужен один человек, принимающий решения. Иначе будет долго. Один архитектор, один главный программист и т.д.
И, чёрт возьми, это так. Однако, как водится, абсолют не работает и тут. Если решение не продать команде, это влияет на мораль, скорость и качество решения. Вплоть до саботажа.
И здесь снова нужно ловить баланс между выйгрышем времени от скорости принятия решения и проигрышем в скорости из-за падающей производительности исполнителей.
Я бы сказал, что нужно стараться продать каждое решение, искать кворум (а лучше консенсус), но так вы рискуете погрязнуть в обсуждениях типа в какое время команда ходит на обед по четвергам. В таком случае вы не сделаете не то, что поздно, вы никогда ничего не сделаете. Ищите баланс.
И, чёрт возьми, это так. Однако, как водится, абсолют не работает и тут. Если решение не продать команде, это влияет на мораль, скорость и качество решения. Вплоть до саботажа.
И здесь снова нужно ловить баланс между выйгрышем времени от скорости принятия решения и проигрышем в скорости из-за падающей производительности исполнителей.
Я бы сказал, что нужно стараться продать каждое решение, искать кворум (а лучше консенсус), но так вы рискуете погрязнуть в обсуждениях типа в какое время команда ходит на обед по четвергам. В таком случае вы не сделаете не то, что поздно, вы никогда ничего не сделаете. Ищите баланс.
👍12
Ооооо! 500! Нас пятьсот! Это целых пять сотен или пятьдесят десятков! Невероятно!
Я вообще зашёл токсичный пост написать, но теперь обрадовался и не буду ❤️
Я вообще зашёл токсичный пост написать, но теперь обрадовался и не буду ❤️
❤16🥰5😁3🎉2👏1
Forwarded from Nevreme
https://telegra.ph/FAQ-chto-takoe-superyachejka-08-15
FAQ: что такое суперячейка?
То чувство, когда сел отвечать на вопрос подписчика в комментарии и случайно написал самый подробный материал о суперячейках на русском языке. Признаться честно, за эти две недели работы над статьей я сам намного лучше стал понимать внутренние механизмы суперячейковых гроз (какие они все-таки удивительные!). Надеюсь, что для вас этот материал будет полезным!
В будущем этот FAQ можно будет дополнять, к примеру более подробно написать о мультиячейковых грозах и линиях шквалов в частности (одно bow echo чего стоит) или добавить больше информации о торнадо.
Если вам понравился этот материал и вы хотели бы поддержать автора, то можете сделать это по ссылке: ko-fi.com/nenevreme
FAQ: что такое суперячейка?
То чувство, когда сел отвечать на вопрос подписчика в комментарии и случайно написал самый подробный материал о суперячейках на русском языке. Признаться честно, за эти две недели работы над статьей я сам намного лучше стал понимать внутренние механизмы суперячейковых гроз (какие они все-таки удивительные!). Надеюсь, что для вас этот материал будет полезным!
В будущем этот FAQ можно будет дополнять, к примеру более подробно написать о мультиячейковых грозах и линиях шквалов в частности (одно bow echo чего стоит) или добавить больше информации о торнадо.
Если вам понравился этот материал и вы хотели бы поддержать автора, то можете сделать это по ссылке: ko-fi.com/nenevreme
Telegraph
FAQ: что такое суперячейка?
В комментариях к постам телеграм канала Nevreme часто встречаются различные вопросы о суперячейковых грозах. Для того, чтобы ответить на эти вопросы, я написал гайд, в котором собрал всю самую важную информацию по этой теме. Но прежде чем переходить непосредственно…
👍3
Forwarded from tropical saint petersburg
шок-контент— сравнение математического образования на МКН и в MIT не в пользу последнего.
разная философия образования, и устройство общества. В хороших местах в России вас сразу много и интенсивно учат, бакалаврские спецкурсы сравнимы с аспирантскими в Штатах. Поэтому в аспирантуре вас нечему учить (и обычно нет аспирантских курсов). Казалось бы, занимайся наукой в нехочу.
но для этого нужны крутые научные руководители (а среднего возраста учёных в России мало, провал) и вообще привлекательность научной карьеры тоже так себе. Получается гипертрофированная первая ступень — в толпу умных людей вбивают много знаний, которые потом не нужны.
условная "либеральная западная модель" гораздо менее интенсивна на первых этапах (с "нестрогими идеями" вместо доказательств в бакалавриате, например) и серьёзное обучение начинается в аспирантуре. Зато к этому моменту отсеялись те, кому неинтересно, и кто не хочет сам разбираться в материале, и в топовых местах много крутых учёных для научного руководства (+ многие аспиранты приезжают в топовые места из нетоповых).
это не лучше и не хуже, просто другая модель (для поддержания которой, например, кажется важным большой приток умных иностранцев аспирантов), с другими акцентами. Ну а для науки (как мне кажется) важно не то, как учат, а концентрация очень сильных учёных в одном пространстве.
так что хорошо, что цветут все цветы.
разная философия образования, и устройство общества. В хороших местах в России вас сразу много и интенсивно учат, бакалаврские спецкурсы сравнимы с аспирантскими в Штатах. Поэтому в аспирантуре вас нечему учить (и обычно нет аспирантских курсов). Казалось бы, занимайся наукой в нехочу.
но для этого нужны крутые научные руководители (а среднего возраста учёных в России мало, провал) и вообще привлекательность научной карьеры тоже так себе. Получается гипертрофированная первая ступень — в толпу умных людей вбивают много знаний, которые потом не нужны.
условная "либеральная западная модель" гораздо менее интенсивна на первых этапах (с "нестрогими идеями" вместо доказательств в бакалавриате, например) и серьёзное обучение начинается в аспирантуре. Зато к этому моменту отсеялись те, кому неинтересно, и кто не хочет сам разбираться в материале, и в топовых местах много крутых учёных для научного руководства (+ многие аспиранты приезжают в топовые места из нетоповых).
это не лучше и не хуже, просто другая модель (для поддержания которой, например, кажется важным большой приток умных иностранцев аспирантов), с другими акцентами. Ну а для науки (как мне кажется) важно не то, как учат, а концентрация очень сильных учёных в одном пространстве.
так что хорошо, что цветут все цветы.
Digital Russia
Миф о классном обучении математике и компьютерным наукам в бакалавриате MIT
Об авторе: Анатолий Шалыто, профессор, д.т.н., Университет ИТМО. На канале «Гарвард-Оксфорд» вышло видео, в котором Данил Сибгатуллин из Казани,
Вчера разбирали с тимлидами главы с седьмой по девятую Брукса. В главе Calling the Shot есть прям данные. Я люблю данные, вы любите данные (основано на данных о похожих на мой каналах), все любят данные (не основано на данных). Данные говорят о нескольких вещах.
1. Чем больше система (просто в количестве инструкций), тем меньше кода в ней производят разработчики. Потому что система сложнее. Причем там нелинейный рост сложности. На данных из книги у Брукса получилось
2. Чем больше коммуникаций между разработчиками (для синхронизации работы), тем меньше кода они пишут.
3. Чем больше коммуникаций (неявно выводим — точек сочленения) между командами, тем меньше кода пишут программисты. Здесь вообще всё драматично: 10к инструкций per man-year при маленьком количестве взаимодействий и 1,5к инструкций per man-year при частых взаимодействиях. На порядок!
4. Есть существенная разница в скорости разработки между командами, работающими над разными классами задач (управляющие программы разрабатывались в пять раз медленнее на программиста, чем, пусть и сложный, продукт: компиляторы и ассемблеры).
5. На языках высокого уровня инструкций в единицу времени пишется в пять раз больше, чем на ассемблере.
6. Половина времени разработчиков уходит НЕ на написание и отладку кода. Митинги, больничные, оформление бумаг, личные дела, срочные важные задачи, УМЕР ВАЙФАЙ, ДАЛЕКО ИДТИ ЗА КОФЕ, РАЗМЯТЬ СПИНУ — подобные вещи отъедают половину рабочего времени.
Мы у себя наблюдаем эти закономерности прямо сейчас. Программисты в инфраструктурных командах пишут меньше кода, чем программисты в продуктовых. Даже если это один и тот же программист (у нас есть люди, перешедшие по ротации из продукта, тот же язык, тот же опыт, те же технологии — кода меньше). Есть и обратные примеры.
Кроме того, новые системы, как наш PSP, разрабатываются быстрее, чем большие старые. А разработка сильно замедляется после ввода системы в эксплуатацию — прорастают коммуникации с другими командами, появляется фон багов и т.д.
Какие выводы можно сделать?
Не знаю. Но как минимум мы видим, что сравнивать разработчиков по объемам кода очень сложно. Ещё мы видим, что не приходится расчитывать на 40 часов в неделю от среднего разработчика.
Вот про последнее есть у Джоела и здесь. В первой статье рассказывается про компании быстрого роста: покупай время за деньги (здесь про зп выше рынка, три бэхи и ассистентов). А во второй про продуктивность сотрудников в зависимости от условий на работе (опенспейсы, кофемашины, хороший рабочий софт и железо).
Вообще статьи не об этом, но моментики важные.
Советов не будет.
1. Чем больше система (просто в количестве инструкций), тем меньше кода в ней производят разработчики. Потому что система сложнее. Причем там нелинейный рост сложности. На данных из книги у Брукса получилось
effort = C * (LOC)^1.5.2. Чем больше коммуникаций между разработчиками (для синхронизации работы), тем меньше кода они пишут.
3. Чем больше коммуникаций (неявно выводим — точек сочленения) между командами, тем меньше кода пишут программисты. Здесь вообще всё драматично: 10к инструкций per man-year при маленьком количестве взаимодействий и 1,5к инструкций per man-year при частых взаимодействиях. На порядок!
4. Есть существенная разница в скорости разработки между командами, работающими над разными классами задач (управляющие программы разрабатывались в пять раз медленнее на программиста, чем, пусть и сложный, продукт: компиляторы и ассемблеры).
5. На языках высокого уровня инструкций в единицу времени пишется в пять раз больше, чем на ассемблере.
6. Половина времени разработчиков уходит НЕ на написание и отладку кода. Митинги, больничные, оформление бумаг, личные дела, срочные важные задачи, УМЕР ВАЙФАЙ, ДАЛЕКО ИДТИ ЗА КОФЕ, РАЗМЯТЬ СПИНУ — подобные вещи отъедают половину рабочего времени.
Мы у себя наблюдаем эти закономерности прямо сейчас. Программисты в инфраструктурных командах пишут меньше кода, чем программисты в продуктовых. Даже если это один и тот же программист (у нас есть люди, перешедшие по ротации из продукта, тот же язык, тот же опыт, те же технологии — кода меньше). Есть и обратные примеры.
Кроме того, новые системы, как наш PSP, разрабатываются быстрее, чем большие старые. А разработка сильно замедляется после ввода системы в эксплуатацию — прорастают коммуникации с другими командами, появляется фон багов и т.д.
Какие выводы можно сделать?
Не знаю. Но как минимум мы видим, что сравнивать разработчиков по объемам кода очень сложно. Ещё мы видим, что не приходится расчитывать на 40 часов в неделю от среднего разработчика.
Вот про последнее есть у Джоела и здесь. В первой статье рассказывается про компании быстрого роста: покупай время за деньги (здесь про зп выше рынка, три бэхи и ассистентов). А во второй про продуктивность сотрудников в зависимости от условий на работе (опенспейсы, кофемашины, хороший рабочий софт и железо).
Вообще статьи не об этом, но моментики важные.
Советов не будет.
Joel on Software
Strategy Letter I: Ben and Jerry’s vs. Amazon
Building a company? You’ve got one very important decision to make, because it affects everything else you do. No matter what else you do, you absolutely must figure out which camp you’…
👍7❤2
Несколько месяцев назад прочитал статью про проектный менеджмент. Там утверждалось, что если в проекте из 20 задач, каждая сходится в срок с вероятностью 90%, то проект целиком сходится в срок с вероятностью *попробуйте угадать*. Ответ, который загадал автор посчитать довольно просто, вы умеете, спрячу под спойлер (12% ).
Но вот только он неверный.
КАРТИНКИ КАРТИНОЧКИ ЩАС БУДУТ!
Во-первых, когда ответ верный?
Только, когда это не проект, а куча независимых задач, все из которых делаются одновременно и параллельно. Тогда, действительно, вероятность, что хотя бы одна задача завалится и мы продолбаем сроки такая, как загадал автор.
Но давайте, все-таки проект возьмем.
Здесь нужно явно проговорить предпосылки.
1. Задачи не параллелятся и идут строго друг за другом
2. Вероятности закрыть задачи в срок не зависят друг от друга
3. Все задачи одинаковой длины
Давайте ещё всё-таки считать, что если с 90% вероятностью задача попадает в дедлайн, то она с некоторой вероятностью может быть сделана и раньше дедлайна. Вопреки "закону Дорофеева", я верю, что так бывает.
Ещё давайте считать не точное попадание проекта в дедлайн (оно очевидно стремится к нулю с ростом размера и количества задач), а вероятность закончить проект _до_ дедлайна включительно.
Я взял задачи размером 100 (давайте считать часов).
Я взял 20 задач в проекте.
Тогда проектный дедлайн это 2000 часов.
И расчехляем Монте-Карло симулятор!
Для простоты можем считать, что распределение вероятностей сделать задачку в первый, второй и т.д. час равномерное. Тогда надо взять распределение на (0, 111], на нем с 90% вероятностью задача займет 100 часов. В среднем проект из 20 задач займёт тогда 1113+-144(1 std) часов. С вероятностью 99% проект займет не более 1457 часов.
Можно посмотреть график. На нем есть черным плотность вероятности и гистограмма одного из реально сгенерированных сэмплов (я делал по 1000 симуляций на каждый проект). Оси не подписал, каюсь. По горизонтали длительность одной задачи, по вертикали вероятность того, что задача займет именно столько времени. И, да, считаем, что среднее сходится к матожиданию здесь, поэтому длительность проекта это сумма длительностей задач.
Но вот только он неверный.
КАРТИНКИ КАРТИНОЧКИ ЩАС БУДУТ!
Во-первых, когда ответ верный?
Только, когда это не проект, а куча независимых задач, все из которых делаются одновременно и параллельно. Тогда, действительно, вероятность, что хотя бы одна задача завалится и мы продолбаем сроки такая, как загадал автор.
Но давайте, все-таки проект возьмем.
Здесь нужно явно проговорить предпосылки.
1. Задачи не параллелятся и идут строго друг за другом
2. Вероятности закрыть задачи в срок не зависят друг от друга
3. Все задачи одинаковой длины
Давайте ещё всё-таки считать, что если с 90% вероятностью задача попадает в дедлайн, то она с некоторой вероятностью может быть сделана и раньше дедлайна. Вопреки "закону Дорофеева", я верю, что так бывает.
Ещё давайте считать не точное попадание проекта в дедлайн (оно очевидно стремится к нулю с ростом размера и количества задач), а вероятность закончить проект _до_ дедлайна включительно.
Я взял задачи размером 100 (давайте считать часов).
Я взял 20 задач в проекте.
Тогда проектный дедлайн это 2000 часов.
И расчехляем Монте-Карло симулятор!
Для простоты можем считать, что распределение вероятностей сделать задачку в первый, второй и т.д. час равномерное. Тогда надо взять распределение на (0, 111], на нем с 90% вероятностью задача займет 100 часов. В среднем проект из 20 задач займёт тогда 1113+-144(1 std) часов. С вероятностью 99% проект займет не более 1457 часов.
Можно посмотреть график. На нем есть черным плотность вероятности и гистограмма одного из реально сгенерированных сэмплов (я делал по 1000 симуляций на каждый проект). Оси не подписал, каюсь. По горизонтали длительность одной задачи, по вертикали вероятность того, что задача займет именно столько времени. И, да, считаем, что среднее сходится к матожиданию здесь, поэтому длительность проекта это сумма длительностей задач.