Quant Valerian

Но равномерное распределение какое-то неживое. Гораздо более правильным будет взять логнормальное, на мой вкус. Мне просто кажется, что относительные оценки сроков задач (ну, считай, ошибки в оценке) распределены нормально, а не сами оценки (было бы тупо). Да и в целом график выглядит убедительно, сами смотрите: макс вероятность закончить реально где-то ближе к сроку, но в теории можно никогда не закончить 🤡 Короч, вот я взял логнормальное распределение. Например, со стандартным отклонением 30% (графики есть для 10, 30 и 90). В среднем проект тогда будет закрываться за 1420+-100 часов, а 99%% это 1665 часов. Что меня несколько удивило, так это что при увеличении неопределенности (она симметричная), вероятность закончить в срок только растёт (см. для 0.1 и для 0.9). Контринтуитивно, если честно. Во всех случаях вероятность закончить проект в срок, если каждая задача придет в срок с вероятностью 90%, сильно больше 99% и уж никак не 12%.

Несколько месяцев назад прочитал статью про проектный менеджмент. Там утверждалось, что если в проекте из 20 задач, каждая сходится в срок с вероятностью 90%, то проект целиком сходится в срок с вероятностью *попробуйте угадать*. Ответ, который загадал автор посчитать довольно просто, вы умеете, спрячу под спойлер (12%). Но вот только он неверный. КАРТИНКИ КАРТИНОЧКИ ЩАС БУДУТ! Во-первых, когда ответ верный? Только, когда это не проект, а куча независимых задач, все из которых делаются одновременно и параллельно. Тогда, действительно, вероятность, что хотя бы одна задача завалится и мы продолбаем сроки такая, как загадал автор. Но давайте, все-таки проект возьмем. Здесь нужно явно проговорить предпосылки. 1. Задачи не параллелятся и идут строго друг за другом 2. Вероятности закрыть задачи в срок не зависят друг от друга 3. Все задачи одинаковой длины Давайте ещё всё-таки считать, что если с 90% вероятностью задача попадает в дедлайн, то она с некоторой вероятностью может быть сделана и раньше дедлайна. Вопреки "закону Дорофеева", я верю, что так бывает. Ещё давайте считать не точное попадание проекта в дедлайн (оно очевидно стремится к нулю с ростом размера и количества задач), а вероятность закончить проект _до_ дедлайна включительно. Я взял задачи размером 100 (давайте считать часов). Я взял 20 задач в проекте. Тогда проектный дедлайн это 2000 часов. И расчехляем Монте-Карло симулятор! Для простоты можем считать, что распределение вероятностей сделать задачку в первый, второй и т.д. час равномерное. Тогда надо взять распределение на (0, 111], на нем с 90% вероятностью задача займет 100 часов. В среднем проект из 20 задач займёт тогда 1113+-144(1 std) часов. С вероятностью 99% проект займет не более 1457 часов. Можно посмотреть график. На нем есть черным плотность вероятности и гистограмма одного из реально сгенерированных сэмплов (я делал по 1000 симуляций на каждый проект). Оси не подписал, каюсь. По горизонтали длительность одной задачи, по вертикали вероятность того, что задача займет именно столько времени. И, да, считаем, что среднее сходится к матожиданию здесь, поэтому длительность проекта это сумма длительностей задач.

Вчера разбирали с тимлидами главы с седьмой по девятую Брукса. В главе Calling the Shot есть прям данные. Я люблю данные, вы любите данные (основано на данных о похожих на мой каналах), все любят данные (не основано на данных). Данные говорят о нескольких вещах. 1. Чем больше система (просто в количестве инструкций), тем меньше кода в ней производят разработчики. Потому что система сложнее. Причем там нелинейный рост сложности. На данных из книги у Брукса получилось effort = C * (LOC)^1.5. 2. Чем больше коммуникаций между разработчиками (для синхронизации работы), тем меньше кода они пишут. 3. Чем больше коммуникаций (неявно выводим — точек сочленения) между командами, тем меньше кода пишут программисты. Здесь вообще всё драматично: 10к инструкций per man-year при маленьком количестве взаимодействий и 1,5к инструкций per man-year при частых взаимодействиях. На порядок! 4. Есть существенная разница в скорости разработки между командами, работающими над разными классами задач (управляющие программы разрабатывались в пять раз медленнее на программиста, чем, пусть и сложный, продукт: компиляторы и ассемблеры). 5. На языках высокого уровня инструкций в единицу времени пишется в пять раз больше, чем на ассемблере. 6. Половина времени разработчиков уходит НЕ на написание и отладку кода. Митинги, больничные, оформление бумаг, личные дела, срочные важные задачи, УМЕР ВАЙФАЙ, ДАЛЕКО ИДТИ ЗА КОФЕ, РАЗМЯТЬ СПИНУ — подобные вещи отъедают половину рабочего времени. Мы у себя наблюдаем эти закономерности прямо сейчас. Программисты в инфраструктурных командах пишут меньше кода, чем программисты в продуктовых. Даже если это один и тот же программист (у нас есть люди, перешедшие по ротации из продукта, тот же язык, тот же опыт, те же технологии — кода меньше). Есть и обратные примеры. Кроме того, новые системы, как наш PSP, разрабатываются быстрее, чем большие старые. А разработка сильно замедляется после ввода системы в эксплуатацию — прорастают коммуникации с другими командами, появляется фон багов и т.д. Какие выводы можно сделать? Не знаю. Но как минимум мы видим, что сравнивать разработчиков по объемам кода очень сложно. Ещё мы видим, что не приходится расчитывать на 40 часов в неделю от среднего разработчика. Вот про последнее есть у Джоела и здесь. В первой статье рассказывается про компании быстрого роста: покупай время за деньги (здесь про зп выше рынка, три бэхи и ассистентов). А во второй про продуктивность сотрудников в зависимости от условий на работе (опенспейсы, кофемашины, хороший рабочий софт и железо). Вообще статьи не об этом, но моментики важные. Советов не будет.

шок-контент— сравнение математического образования на МКН и в MIT не в пользу последнего. разная философия образования, и устройство общества. В хороших местах в России вас сразу много и интенсивно учат, бакалаврские спецкурсы сравнимы с аспирантскими в Штатах. Поэтому в аспирантуре вас нечему учить (и обычно нет аспирантских курсов). Казалось бы, занимайся наукой в нехочу. но для этого нужны крутые научные руководители (а среднего возраста учёных в России мало, провал) и вообще привлекательность научной карьеры тоже так себе. Получается гипертрофированная первая ступень — в толпу умных людей вбивают много знаний, которые потом не нужны. условная "либеральная западная модель" гораздо менее интенсивна на первых этапах (с "нестрогими идеями" вместо доказательств в бакалавриате, например) и серьёзное обучение начинается в аспирантуре. Зато к этому моменту отсеялись те, кому неинтересно, и кто не хочет сам разбираться в материале, и в топовых местах много крутых учёных для научного руководства (+ многие аспиранты приезжают в топовые места из нетоповых). это не лучше и не хуже, просто другая модель (для поддержания которой, например, кажется важным большой приток умных иностранцев аспирантов), с другими акцентами. Ну а для науки (как мне кажется) важно не то, как учат, а концентрация очень сильных учёных в одном пространстве. так что хорошо, что цветут все цветы.

MIT и МФТИ братья навек 😁 Это я перешёл по ссылке и почитал мнение студента

Очень интересная статья про грозы с картинками и фотографиями. Люблю такое

https://telegra.ph/FAQ-chto-takoe-superyachejka-08-15 FAQ: что такое суперячейка? То чувство, когда сел отвечать на вопрос подписчика в комментарии и случайно написал самый подробный материал о суперячейках на русском языке. Признаться честно, за эти две недели работы над статьей я сам намного лучше стал понимать внутренние механизмы суперячейковых гроз (какие они все-таки удивительные!). Надеюсь, что для вас этот материал будет полезным! В будущем этот FAQ можно будет дополнять, к примеру более подробно написать о мультиячейковых грозах и линиях шквалов в частности (одно bow echo чего стоит) или добавить больше информации о торнадо. Если вам понравился этот материал и вы хотели бы поддержать автора, то можете сделать это по ссылке: ko-fi.com/nenevreme

Ооооо! 500! Нас пятьсот! Это целых пять сотен или пятьдесят десятков! Невероятно! Я вообще зашёл токсичный пост написать, но теперь обрадовался и не буду ❤️