Лекция 6. Системный анализ аппарата руководства.
🧩 Как устроен аппарат руководства:
Представьте: вы приходите на новое место работы — руководить управлением строительства. Вам дают кабинет, вешают табличку на дверь, вручают регламент, а в голове у вас — планы, схемы, цели. И вы — вроде бы винтик в большой машине под названием «организация».
Но... всё гораздо сложнее.
📌 Мышление и реальность — разные миры
Щедровицкий говорит: то, как вы мыслите — это не реальность. Это — ортогональная плоскость, не совпадающая с действием. Чтобы мысль воплотилась, нужны сложные процедуры переноса — иначе говоря, проектирование. Мы всё время живём «в системе зеркал» — реальность отражается в мышлении, но никогда не совпадает с ним.
📌 Аппарат руководства — не просто иерархия, а система
Начальник, его замы, главный инженер — это не люди, а должности, связанные формальными связями. Эти связи живут независимо от личностей. Подчинённый подчиняется не Иванову, а «начальнику управления». Винтики в схеме.
Но есть и другая сторона.
📌 Формальное и неформальное: два слоя одной ткани
Формальная структура задаётся должностными инструкциями. А неформальная? Это клуб. Не в смысле танцев, а в смысле человеческих отношений: дружбы, симпатий, негласных правил.
Причём клуб существует не только за пределами офиса. Он всегда проникает в производство: начальник может «договориться», «попросить по-человечески», а не сослаться на регламент.
📌 Человек — и винтик, и личность
Вы не выключаете эмоции, выходя на работу. Вы одновременно — и носитель должности (индивид), и человек со своими чувствами (личность). Это двойное существование рождает конфликты, решения, жизнь.
📌 И тут возникает парадокс системности
Формально — вы часть одной системы управления. Но каждый ваш заместитель тоже управляет своей мини-системой. И вот вы уже не в едином механизме, а в переплетении автономных подсистем, «насаженных» друг на друга. Как стержни, на которые нанизаны сети — вы становитесь точкой пересечения.
📌 А что же тогда такое система?
Не вещи. Не «столы и стулья». Система — это связи и процессы. Но если убрать один элемент, система разрушается. И в то же время — каждый элемент участвует во множестве других систем. Формально отрезать границы нельзя — всё взаимопроникает. Получается слоёный пирог.
📌 Идея, изменившая подход к человеку
Маркс сказал: человек — это совокупность общественных связей. Без места в социальной структуре — нет человека. Даже тунеядец становится «человеком», когда получает определённую функцию. Иными словами: мы — это не только тело, но и место в системе. Сложной, многослойной, переплетённой.
📌 Управленец — это не кукловод, а режиссёр ансамбля
Он каждый день решает: дать свободу или зажать дисциплину. Где провести границу? Где остановить вертикаль? Как удержать равновесие между структурами, которые живут по разным законам, но сосуществуют на одних и тех же людях?
🤔 Главный вывод Щедровицкого:
И для этого одних схем и инструкций недостаточно. Нужно новое мышление. Новые понятия целостности. И новое понимание того, что такое — быть человеком в системе.
🧩 Как устроен аппарат руководства:
Представьте: вы приходите на новое место работы — руководить управлением строительства. Вам дают кабинет, вешают табличку на дверь, вручают регламент, а в голове у вас — планы, схемы, цели. И вы — вроде бы винтик в большой машине под названием «организация».
Но... всё гораздо сложнее.
📌 Мышление и реальность — разные миры
Щедровицкий говорит: то, как вы мыслите — это не реальность. Это — ортогональная плоскость, не совпадающая с действием. Чтобы мысль воплотилась, нужны сложные процедуры переноса — иначе говоря, проектирование. Мы всё время живём «в системе зеркал» — реальность отражается в мышлении, но никогда не совпадает с ним.
📌 Аппарат руководства — не просто иерархия, а система
Начальник, его замы, главный инженер — это не люди, а должности, связанные формальными связями. Эти связи живут независимо от личностей. Подчинённый подчиняется не Иванову, а «начальнику управления». Винтики в схеме.
Но есть и другая сторона.
📌 Формальное и неформальное: два слоя одной ткани
Формальная структура задаётся должностными инструкциями. А неформальная? Это клуб. Не в смысле танцев, а в смысле человеческих отношений: дружбы, симпатий, негласных правил.
Причём клуб существует не только за пределами офиса. Он всегда проникает в производство: начальник может «договориться», «попросить по-человечески», а не сослаться на регламент.
📌 Человек — и винтик, и личность
Вы не выключаете эмоции, выходя на работу. Вы одновременно — и носитель должности (индивид), и человек со своими чувствами (личность). Это двойное существование рождает конфликты, решения, жизнь.
📌 И тут возникает парадокс системности
Формально — вы часть одной системы управления. Но каждый ваш заместитель тоже управляет своей мини-системой. И вот вы уже не в едином механизме, а в переплетении автономных подсистем, «насаженных» друг на друга. Как стержни, на которые нанизаны сети — вы становитесь точкой пересечения.
📌 А что же тогда такое система?
Не вещи. Не «столы и стулья». Система — это связи и процессы. Но если убрать один элемент, система разрушается. И в то же время — каждый элемент участвует во множестве других систем. Формально отрезать границы нельзя — всё взаимопроникает. Получается слоёный пирог.
📌 Идея, изменившая подход к человеку
Маркс сказал: человек — это совокупность общественных связей. Без места в социальной структуре — нет человека. Даже тунеядец становится «человеком», когда получает определённую функцию. Иными словами: мы — это не только тело, но и место в системе. Сложной, многослойной, переплетённой.
📌 Управленец — это не кукловод, а режиссёр ансамбля
Он каждый день решает: дать свободу или зажать дисциплину. Где провести границу? Где остановить вертикаль? Как удержать равновесие между структурами, которые живут по разным законам, но сосуществуют на одних и тех же людях?
🤔 Главный вывод Щедровицкого:
Чтобы управлять системами, нужно сначала научиться правильно их мыслить.
И для этого одних схем и инструкций недостаточно. Нужно новое мышление. Новые понятия целостности. И новое понимание того, что такое — быть человеком в системе.
👍1
Рефлексия начальника управления строительством.
Зарисую возможные позиции начальника управления строительством. На схеме три позиции. Но у нас ведь не три начальника управления строительством, а один. А я зафиксировал его тройное существование: один раз он существует как место — как начальник управления строительством; второй раз он существует как наполнение этого места; третий раз он существует без места (скажем, кончились работы, он поехал отдыхать или приехал сюда, в ИПК).
И наконец, у него есть четвертая позиция, со звездочкой, когда он рефлектирует и сам себя во всех своих ипостасях и формах существования анализирует и представляет. И за счет этого в рефлексивной позиции у него на доске и на табло может получаться интересная вещь.
На доске он сам может быть представлен как объект: он сам себя видит со стороны. Если он изощренный, он себя рефлектирующим тоже представит, если не очень, то представит себя только в остальных позициях.
Про PERT из лекции 6.
#лек_6
#лек_6
Сетевые графики вводились как метод системного анализа. Это альтернатива календарному плану — «альтернатива», то есть принципиально другой ход. Если вам дают сетевой график в виде календарного плана — это означает, что вас лишили возможности осуществлять сетевое планирование. Потому что принцип сетевого планирования состоит в том, что имеется календарный план, а дальше вы с вашими ресурсами, временем, начинаете искать варианты распределения ресурсов. Сетевые графики — это метод свободного маневрирования ресурсами.
Необходимость в сетевых графиках возникает тогда, когда вы можете не выполнить календарный план, и тогда вы начинаете играть в эти сетевые графики. Чтобы наверстать, вы составляете варианты такой организации работы... Когда американцы разрабатывали систему подводной лодки «Поларис», у них была технология, а сетевые графики родились из организации системы поставок. Им надо было получить два миллиона шестьсот четыре тысячи узлов. И нужно было определить, когда что. Технологический процесс определял сроки, а дальше надо было с помощью метода сетевого планирования определить начало работ, распределить ресурсы и т. д. Реально технология всегда есть ограничение на сетевой график. Она — как глубинная структура, а дальше мы должны маневрировать ресурсами с помощью метода сетевого планирования там, где нас не держит технология — в зазорах, на стыках, в степенях свободы от технологического процесса.
Как Проверка Тестовых Заданий Перезагрузила Мое Видение
Знаете, иногда рутина может незаметно подкрасться. Взялся недавно проверять тестовые задания кандидатов в стажёры. Казалось бы, что тут такого? Смотришь код, пишешь плюсы и минусы каждого кандидата и оцениваешь его вконце, нажимая зовем/не зовем на интервью. Но этот простой процесс начал меня... выматывать. Каждый день количество кандидатов увеличивалось. Эйчар мне посылает каждый день по 2-3 анкеты с заданием. Я начал хватать выгорание.
Почему? А потому что на работе мне нравится энергия цикла разработки. Мне нравится разбираться с архитектурой. Писать код. Я люблю копаться в отладчике, смотреть как течет код, и видеть все новые и новые нестыковки и повороты потока выполнения программы в новых задачах. Мне нравится писать тесты. Нравится видеть, как все спроектировано, возвращаясь к первому шагу цикла разработки. Это драйв, азарт, адреналин и удовлетворение! А тут десятки чужих однотипных работ, которые нужно прочесть и посмотреть и проверить по чек-листу, запустить. Я начал чувствовать, как подкрадывается это самое выгорание: ощущение, что ты один в поле воин, а результат твоего труда - это капля в море.
НО! И вот это но перевернуло ситуацию. Погрузившись в работы кандидатов, когда счетчик работ зашкалил за десятки, я увидел искру. Уведел реальную страсть и старание:
🔄 Паттерны применены у 5 процентов! Сколько же грамотного применения Consumer-Producer! Фабрики там, где они действительно нужны. Это не просто код, это уже применение опыта из книжек и советов stackoverflow.
🧪 Тесты? Обязательно! Многие (20 %) использовали gtest. Видеть юнит-тесты в тестовом задании – это уровень. Приятно видеть, как тестовый код запускает пользотельский. Это говорит о понимании качества.
✨ GitHub-портфолио: Около 40% работ были оформлены на GitHub не просто как код, а как презентация себя и своих четких достижений. Чистые репозитории, внятные README, project-tree в середине, шаги к тому как запустить код и тесты. Это показатель ответственности и желания добить задачу до конца.
❓ Те самые 3%: И – особый увжение людям! – те единицы, кто спросил. Уточнили у рекрутера, задали осмысленные вопросы. Знаете, для меня это ключевой индикатор. Я всегда готов с огромной прилежностью уделить внимание задающему вопрос.
Конечно, был разброс: кто-то показал навыки уверенного мидла, а кто-то... даже не дочитал задание до конца или проигнорировал требования (надо было сделать под Линукс 😉).
Но главное открытие пришло неожиданно:
Мое выгорание было иллюзией. Иллюзией "одиночества моих стараний". Когда ты видишь десятки работ, видишь искренние старания, видишь интерес в глазах (пусть даже через код), видишь, как люди применяют те же паттерны, пишут те же тесты, сталкиваются с похожими задачами... Ты понимаешь:
Мы все – часть одного большого Дела. 🔥 Мы все проектируем, создаем, отлаживаем, тестируем. Каждый на своем месте, но ВМЕСТЕ.
И это – ТРИУМФ! Триумф не над кем-то, а над усталостью и сомнениями. Триумф понимания, что поток талантов и энтузиазма – реальность.
Поэтому о выборе:
Я не буду искать просто "самых лучших" по формальным критериям. Я не буду искать просто "самых прилежных".
Я буду искать самых ИНТЕРЕСУЮЩИХСЯ. Тех, кто спрашивает. Тех, у кого горят глаза. Тех, для кого этот код – не просто тест, а шаг в профессию, которой они искренне хотят учиться.
Потому что именно интерес – тот самый двигатель, который превращает стажёра в крутого специалиста. И именно с такими людьми хочется строить будущее. Проверка тестовых – это не рутина. Это вдохновение. Это напоминание, ради чего мы все здесь. Это видение будущего нашей индустрии, и оно – яркое! 💪
Напишите в комментариях: что для вас самое главное в программировании, конкретно, то, ради чего садитесь за код? Что самое главное в будущих стажерах?
Скоро: чек-лист 5 признаков сильного стажера в C++
#разработка #стажировка #программирование #карьера #мотивация #it #github #тестирование #gtest #паттерны #выгорание #триумф #команда #интерес #вопросы #учиться #будущееIT
Знаете, иногда рутина может незаметно подкрасться. Взялся недавно проверять тестовые задания кандидатов в стажёры. Казалось бы, что тут такого? Смотришь код, пишешь плюсы и минусы каждого кандидата и оцениваешь его вконце, нажимая зовем/не зовем на интервью. Но этот простой процесс начал меня... выматывать. Каждый день количество кандидатов увеличивалось. Эйчар мне посылает каждый день по 2-3 анкеты с заданием. Я начал хватать выгорание.
Почему? А потому что на работе мне нравится энергия цикла разработки. Мне нравится разбираться с архитектурой. Писать код. Я люблю копаться в отладчике, смотреть как течет код, и видеть все новые и новые нестыковки и повороты потока выполнения программы в новых задачах. Мне нравится писать тесты. Нравится видеть, как все спроектировано, возвращаясь к первому шагу цикла разработки. Это драйв, азарт, адреналин и удовлетворение! А тут десятки чужих однотипных работ, которые нужно прочесть и посмотреть и проверить по чек-листу, запустить. Я начал чувствовать, как подкрадывается это самое выгорание: ощущение, что ты один в поле воин, а результат твоего труда - это капля в море.
НО! И вот это но перевернуло ситуацию. Погрузившись в работы кандидатов, когда счетчик работ зашкалил за десятки, я увидел искру. Уведел реальную страсть и старание:
🔄 Паттерны применены у 5 процентов! Сколько же грамотного применения Consumer-Producer! Фабрики там, где они действительно нужны. Это не просто код, это уже применение опыта из книжек и советов stackoverflow.
🧪 Тесты? Обязательно! Многие (20 %) использовали gtest. Видеть юнит-тесты в тестовом задании – это уровень. Приятно видеть, как тестовый код запускает пользотельский. Это говорит о понимании качества.
✨ GitHub-портфолио: Около 40% работ были оформлены на GitHub не просто как код, а как презентация себя и своих четких достижений. Чистые репозитории, внятные README, project-tree в середине, шаги к тому как запустить код и тесты. Это показатель ответственности и желания добить задачу до конца.
❓ Те самые 3%: И – особый увжение людям! – те единицы, кто спросил. Уточнили у рекрутера, задали осмысленные вопросы. Знаете, для меня это ключевой индикатор. Я всегда готов с огромной прилежностью уделить внимание задающему вопрос.
Конечно, был разброс: кто-то показал навыки уверенного мидла, а кто-то... даже не дочитал задание до конца или проигнорировал требования (надо было сделать под Линукс 😉).
Но главное открытие пришло неожиданно:
Мое выгорание было иллюзией. Иллюзией "одиночества моих стараний". Когда ты видишь десятки работ, видишь искренние старания, видишь интерес в глазах (пусть даже через код), видишь, как люди применяют те же паттерны, пишут те же тесты, сталкиваются с похожими задачами... Ты понимаешь:
Мы все – часть одного большого Дела. 🔥 Мы все проектируем, создаем, отлаживаем, тестируем. Каждый на своем месте, но ВМЕСТЕ.
И это – ТРИУМФ! Триумф не над кем-то, а над усталостью и сомнениями. Триумф понимания, что поток талантов и энтузиазма – реальность.
Поэтому о выборе:
Я не буду искать просто "самых лучших" по формальным критериям. Я не буду искать просто "самых прилежных".
Я буду искать самых ИНТЕРЕСУЮЩИХСЯ. Тех, кто спрашивает. Тех, у кого горят глаза. Тех, для кого этот код – не просто тест, а шаг в профессию, которой они искренне хотят учиться.
Потому что именно интерес – тот самый двигатель, который превращает стажёра в крутого специалиста. И именно с такими людьми хочется строить будущее. Проверка тестовых – это не рутина. Это вдохновение. Это напоминание, ради чего мы все здесь. Это видение будущего нашей индустрии, и оно – яркое! 💪
Напишите в комментариях: что для вас самое главное в программировании, конкретно, то, ради чего садитесь за код? Что самое главное в будущих стажерах?
Скоро: чек-лист 5 признаков сильного стажера в C++
#разработка #стажировка #программирование #карьера #мотивация #it #github #тестирование #gtest #паттерны #выгорание #триумф #команда #интерес #вопросы #учиться #будущееIT
❤3🔥1
5 признаков сильного стажера в C++.pdf
106.4 KB
Делюсь своим чек-листом чек-лист 5 признаков сильного стажера в C++
❤2👍1
Что важнее в тестовом задании?
Anonymous Poll
0%
Код без ошибок (но без вопросов)
25%
Код с багами, но с уточняющими
0%
Тесты через GTest
0%
README как в продакшене
75%
Доп вопросы
❄️ Холодный пот: Когда за словами — пустота. ❄️
Сегодня было собеседование. Студент. Сделал задание хорошо. Говорит уверенно:
Фух, знает - мелькает надежда...
Уточняю: Зачем подставлять реализацию в него? Можно же скопировать код, или изменить изначальный класс?
Тишина. Глаза бегают. Уверенность тает на глазах.
Ну... для гибкости? — неуверенный шепот.
Холодок по коже. Иду глубже:
Допустим, враппер должен уведомить нас о завершении долгой операции. Как?
Эээ... Колбэк? — ловит спасательный круг-термин.
А ЗАЧЕМ? Что происходит, когда ВЫЗЫВАЕТСЯ этот колбэк? Как управление возвращается?
Абсолютная тишина. Вижу панику. За термином колбэк — зияющая пустота. Нет понимания того, что коллбек можно использовать для инверсии ветви агрегации и направлять вызов назад.
Чувствую ледяную тревогу.
Не за него — выучит.
За НАС. За индустрию, за университет.
Когда базовые паттерны (Wrapper/Adapter) и принципы (инверсия управления) — просто слова без понимания сути...
Что мы строим? На каком фундаменте? На каком образовании?
Как вам кажется? Это только у меня так? 🤯 Обсудим в комментариях?
#cpp #тимлид #собеседование #паттерны #тревога
Сегодня было собеседование. Студент. Сделал задание хорошо. Говорит уверенно:
О, враппер? Класс-обертка для расширения поведения!
Фух, знает - мелькает надежда...
Уточняю: Зачем подставлять реализацию в него? Можно же скопировать код, или изменить изначальный класс?
Тишина. Глаза бегают. Уверенность тает на глазах.
Ну... для гибкости? — неуверенный шепот.
Холодок по коже. Иду глубже:
Допустим, враппер должен уведомить нас о завершении долгой операции. Как?
Эээ... Колбэк? — ловит спасательный круг-термин.
А ЗАЧЕМ? Что происходит, когда ВЫЗЫВАЕТСЯ этот колбэк? Как управление возвращается?
Абсолютная тишина. Вижу панику. За термином колбэк — зияющая пустота. Нет понимания того, что коллбек можно использовать для инверсии ветви агрегации и направлять вызов назад.
Чувствую ледяную тревогу.
Не за него — выучит.
За НАС. За индустрию, за университет.
Когда базовые паттерны (Wrapper/Adapter) и принципы (инверсия управления) — просто слова без понимания сути...
Что мы строим? На каком фундаменте? На каком образовании?
Как вам кажется? Это только у меня так? 🤯 Обсудим в комментариях?
#cpp #тимлид #собеседование #паттерны #тревога
❤3
Когда "Нет" стало стартом: история собеса, где мы дали шанс вместо отказа
Второе интервью 👋 Хочу поделиться необычным кейсом. Эмоции после — легкая ирония, но главное: уверенность, что потраченные 30 минут стоили того.
Сценарий:
🧑 Кандидат: вежливый, резюме — "3 года учебного С++", тестовое — идеально (спасибо его "другу" 👀).
💣 На техсобесе: тишина. Базовые вопросы — "простите, не знаю". Три тимлида — ноль ответов.
Вместо "до свидания":
Мы осознанно устроили мини-обзор работы! Каждый за 5 минут дал практический срез своей реальности:
✔️ "Какие задачи решает трейни у нас?"
✔️ "С какими вызовами столкнешься?"
Его вопрос: "Какую задачу дадут в первый день?" (респект за смелость!)
Почему закончили интервью?
👉 Честность: Он не врал — "Не знаю" звучало чаще любого паттерна.
👉 Готовность учиться: Впитывал как губка.
👉 Ностальгия: Узнал себя студентом.
Мой вклад:
Рассказал фундамент, который выручит всегда:
🌐 HTTP: как клиент/сервер "разговаривают"
🔧 Парсеры: зачем они и что парсят (html, xml, json)
🚀 Чеклист: сети (TCP/IP), алгоритмы, паттерны → учить системно.
Выводы для команды (без стыда!):
Эта ситуация — отправная точка для калибровки процессов:
1️⃣ HR + Tech: синхронизируем чеклисты
• Какие конкретные базовые вопросы задавать на скрининге под "3 года опыта"?
• Как проверять понимание, а не умение гуглить?
• Тестовое + разбор решения с кандидатом (чтобы "друг" не делал всю работу).
2️⃣ Техлидам: рефлексия вместо допросов
• Где в собесе точки остановки? Говорить "нет"?
• Что реально должен знать trainee в 2025?
• Избегать сценария "допрос vs бесплатная лекция"?
P.S. Ваша смелость + честное "не знаю" + готовность впитывать — вызывают уважение. Учитесь — и возвращайтесь!
#HR_процессы #Собеседования #Trainee #Менторинг #Рефлексия
#Человечность #JuniorDev #КарьерныйРост
Второе интервью 👋 Хочу поделиться необычным кейсом. Эмоции после — легкая ирония, но главное: уверенность, что потраченные 30 минут стоили того.
Сценарий:
🧑 Кандидат: вежливый, резюме — "3 года учебного С++", тестовое — идеально (спасибо его "другу" 👀).
💣 На техсобесе: тишина. Базовые вопросы — "простите, не знаю". Три тимлида — ноль ответов.
Вместо "до свидания":
Мы осознанно устроили мини-обзор работы! Каждый за 5 минут дал практический срез своей реальности:
✔️ "Какие задачи решает трейни у нас?"
✔️ "С какими вызовами столкнешься?"
Его вопрос: "Какую задачу дадут в первый день?" (респект за смелость!)
Почему закончили интервью?
👉 Честность: Он не врал — "Не знаю" звучало чаще любого паттерна.
👉 Готовность учиться: Впитывал как губка.
👉 Ностальгия: Узнал себя студентом.
Мой вклад:
Рассказал фундамент, который выручит всегда:
🌐 HTTP: как клиент/сервер "разговаривают"
🔧 Парсеры: зачем они и что парсят (html, xml, json)
🚀 Чеклист: сети (TCP/IP), алгоритмы, паттерны → учить системно.
Выводы для команды (без стыда!):
Эта ситуация — отправная точка для калибровки процессов:
1️⃣ HR + Tech: синхронизируем чеклисты
• Какие конкретные базовые вопросы задавать на скрининге под "3 года опыта"?
• Как проверять понимание, а не умение гуглить?
• Тестовое + разбор решения с кандидатом (чтобы "друг" не делал всю работу).
2️⃣ Техлидам: рефлексия вместо допросов
• Где в собесе точки остановки? Говорить "нет"?
• Что реально должен знать trainee в 2025?
• Избегать сценария "допрос vs бесплатная лекция"?
P.S. Ваша смелость + честное "не знаю" + готовность впитывать — вызывают уважение. Учитесь — и возвращайтесь!
#HR_процессы #Собеседования #Trainee #Менторинг #Рефлексия
#Человечность #JuniorDev #КарьерныйРост
🔥3🤔1
Почему мой блог о C++ не будет выходить каждый день
Меня последнее время преследует одно чувство. Хочешь вести свой блог, писать о том, что волнует. Но идеи, развернутые в пост не приходят. Возможно и сил писать ежедневно просто нет. Вести свой блог - это не должно стать тем самым состоянием, которого все боятся. Думаю, я не буду писать все о метапрограммировании, скорее напишу, как использовал сам constexpr. Постараюсь не писать книгу про многопоточность, как Райнер Гримм. Напишу про разницу между conditional variable и применение мьютексов. Мои первые 20-30 постов будут сырыми как
#тимлид #cplusplus #разработка #карьера #блогинг #менторство
Меня последнее время преследует одно чувство. Хочешь вести свой блог, писать о том, что волнует. Но идеи, развернутые в пост не приходят. Возможно и сил писать ежедневно просто нет. Вести свой блог - это не должно стать тем самым состоянием, которого все боятся. Думаю, я не буду писать все о метапрограммировании, скорее напишу, как использовал сам constexpr. Постараюсь не писать книгу про многопоточность, как Райнер Гримм. Напишу про разницу между conditional variable и применение мьютексов. Мои первые 20-30 постов будут сырыми как
raw pointers . Хочу создать свой уникальный путь, а не очередной учебник. Может быть в итоге собрать вокруг себя единомышленников, как хотел когда-то мой приятель в школе. Напишу пару новостных постов, например о том, что вышел ремастер MGS3, или про то, как устроено PS3. Или о том, что андроид хочет запретить установку через apk-файлы, и как подобраться к сборке AOSP, или Kiwi Browser. Посты будут выходить раз в две недели, по пятницам. Без суеты. #тимлид #cplusplus #разработка #карьера #блогинг #менторство
👏2
Важность планирования на планшете.
С одной стороны, это на столько банальная идея. Сидеть и что-то рисовать как ребенок. Но с другой, я много раз замечал, как деловые люди могут передавать быстро свои бизнес идеи на бумаге. Они берут лист, или открывают ежедневник, делают краткие надписи с цифрами, разрисовывая их значками и обводя важные места.
Сейчас набирает популярность open-source сервис excalidraw.com Его применение все чаще можно встретить у блоггеров в видео на ютубе.
Простой инструмент удобный, collaborative, можно с командой в реальном времени рисовать, а потом ссылку кинуть — и всё работает без регистрации.
В каком то смысле, это и есть тот планшет со схемами, о котором говорил Щедровицкий в #лек_5. В посте о важности схем приведены конкретные цитаты.
Например, нужно структурировать сложные, разрозненные идеи и донести их до команды/менеджера/себя самого. Стандартные инструменты (тот же Confluence) для этого слишком формальны и негибки.
А тут перед тобой открывается простой минималистичный холст, в котором можно писать текст, добавлять различные фигуры (ромб, квадрат, круг). Писать внутри них. Соединять стрелками. При последующем перемещении стрелки магнитятся к краям фигур и могут перемещаться вместе с ними. Можно вставить картинку, видео с ютуба, которое будет in place проигрываться.
Но мне могут возразить:
Рисовать схемы вручную? В 2024-том? Это же так... Долго. Я промптом в GPT-4o или Claude прошу: «нарисуй диаграмму последовательности для микросервиса аутентификации на C++ с использованием JWT и Redis для кеширования». И через 10 секунд получаю готовую, идеальную диаграмму в PlantUML или Mermaid. Я её потом только немного кастомизирую. Зачем тратить время на ручное рисование, если ИИ может сделать это за меня и, возможно, учесть нюансы, о которых я даже не подумал? Ваш Excalidraw — это крутой костыль, но будущее за prompt-based design.
Но схема, полученная таким путем, не является продуктом твоей мыследеятельности.
Все же рисовать какие-то схемки на бумаге куда приятнее. К этим каракулям быстро привязывается наше воображение. А далее включается язык с идеями и представлениями в виде символов и значков. Появляется смысл и рефлексия. Но об этом в следующем посте.
С одной стороны, это на столько банальная идея. Сидеть и что-то рисовать как ребенок. Но с другой, я много раз замечал, как деловые люди могут передавать быстро свои бизнес идеи на бумаге. Они берут лист, или открывают ежедневник, делают краткие надписи с цифрами, разрисовывая их значками и обводя важные места.
Сейчас набирает популярность open-source сервис excalidraw.com Его применение все чаще можно встретить у блоггеров в видео на ютубе.
Простой инструмент удобный, collaborative, можно с командой в реальном времени рисовать, а потом ссылку кинуть — и всё работает без регистрации.
В каком то смысле, это и есть тот планшет со схемами, о котором говорил Щедровицкий в #лек_5. В посте о важности схем приведены конкретные цитаты.
Например, нужно структурировать сложные, разрозненные идеи и донести их до команды/менеджера/себя самого. Стандартные инструменты (тот же Confluence) для этого слишком формальны и негибки.
А тут перед тобой открывается простой минималистичный холст, в котором можно писать текст, добавлять различные фигуры (ромб, квадрат, круг). Писать внутри них. Соединять стрелками. При последующем перемещении стрелки магнитятся к краям фигур и могут перемещаться вместе с ними. Можно вставить картинку, видео с ютуба, которое будет in place проигрываться.
Но мне могут возразить:
Рисовать схемы вручную? В 2024-том? Это же так... Долго. Я промптом в GPT-4o или Claude прошу: «нарисуй диаграмму последовательности для микросервиса аутентификации на C++ с использованием JWT и Redis для кеширования». И через 10 секунд получаю готовую, идеальную диаграмму в PlantUML или Mermaid. Я её потом только немного кастомизирую. Зачем тратить время на ручное рисование, если ИИ может сделать это за меня и, возможно, учесть нюансы, о которых я даже не подумал? Ваш Excalidraw — это крутой костыль, но будущее за prompt-based design.
Но схема, полученная таким путем, не является продуктом твоей мыследеятельности.
Все же рисовать какие-то схемки на бумаге куда приятнее. К этим каракулям быстро привязывается наше воображение. А далее включается язык с идеями и представлениями в виде символов и значков. Появляется смысл и рефлексия. Но об этом в следующем посте.
❤4
Услышал на стриме у Декабриста
Все знают, что резюме проверяют с помощью ИИ.
при этом все знают, что резюме пишут с помощью ИИ.
Поэтому они с помощью ИИ проверяют, чтобы резюме не было написано с помощью ИИ.
Ох...
Но при этом они знают, что можно руками подредактировать резюме, которое написала ИИ, и его все равно не заметит система... Вот это да!
Все знают, что резюме проверяют с помощью ИИ.
при этом все знают, что резюме пишут с помощью ИИ.
Поэтому они с помощью ИИ проверяют, чтобы резюме не было написано с помощью ИИ.
Ох...
Но при этом они знают, что можно руками подредактировать резюме, которое написала ИИ, и его все равно не заметит система... Вот это да!
😁5
Внезапно Linux не грузится и показывает странную консоль
Помните: это не ошибка, а аварийный режим для вмешательства. Ваш шанс проявить себя.
ПЛАН (что делать):
1. В строке
2. Если просит — жмём
3. Пишем
Готово? Система запустилась? Вы только что вручную починили файловую систему! Теперь можно выдохнуть и разобраться в сути.
А ЧТО ЭТО БЫЛО?
Initramfs — Это мини-ОС в оперативке, чья задача — подготовить всё для загрузки основной системы. Если он не справляется и зовёт вас, причины обычно в этом:
▫️ ФС была повреждена (самое частое после сбоя питания)
▫️ Не может найти корневой диск (проблема с драйверами или конфигом)
▫️ Аппаратный сбой (отходит шлейф, умер диск)
Ваша реакция на
Для студентов: Любой сбой — это возможность глубже понять систему и прокачать скиллы. Возможность стать тем, кто расскажет о себе и про это на следующем собесе.
#linux #admin #восстановление #hardcore #timely_advice #собес
initramfs> после сбоя? Не паникуйте. Это не крах — это система просит вас о помощи. Помните: это не ошибка, а аварийный режим для вмешательства. Ваш шанс проявить себя.
ПЛАН (что делать):
1. В строке
initramfs> пробуем команду fsck -y /dev/sda1 (чаще всего sda1, но может быть nvme0n1p2 и т.д., можно посмотреть ls /dev).2. Если просит — жмём
y (yes). Ждём завершения.3. Пишем
exit и пробуем загрузиться. В 90% случаев этого хватает.Готово? Система запустилась? Вы только что вручную починили файловую систему! Теперь можно выдохнуть и разобраться в сути.
А ЧТО ЭТО БЫЛО?
Initramfs — Это мини-ОС в оперативке, чья задача — подготовить всё для загрузки основной системы. Если он не справляется и зовёт вас, причины обычно в этом:
▫️ ФС была повреждена (самое частое после сбоя питания)
▫️ Не может найти корневой диск (проблема с драйверами или конфигом)
▫️ Аппаратный сбой (отходит шлейф, умер диск)
Ваша реакция на
initramfs> — это и есть то, что отличает специалиста от пользователя. Вы не переустанавливаете систему с нуля, а чините и подкручиваете её. Это ценный навык.Для студентов: Любой сбой — это возможность глубже понять систему и прокачать скиллы. Возможность стать тем, кто расскажет о себе и про это на следующем собесе.
#linux #admin #восстановление #hardcore #timely_advice #собес
👍2❤1
Смотрел сегодня мок-собесы и увидел совместную реализацию двух паттерное.
1. Первый - такназываемый «синглтон Мейерса»
Этот паттерн особенно подходит для управления доступом к ресурсам, таким как конфигурационные файлы, аппаратные интерфейсы, логгеры, или управление состоянием для всего приложения.
Это идиома реализации синглтона в C++, предложенная Скоттом Мейерсом. Она использует статическую локальную переменную внутри функции-геттера:
Какие особенности есть у этого похода:
- Ленивая инициализация: объект создаётся при первом вызове
- Автоматическая корректная деинициализация: деструктор вызывается при завершении программы.
- Потокобезопасность (в C++11 и выше): стандарт гарантирует, что инициализация статической локальной переменной атомарна и потокобезопасна.
Доступность: к открытым методам такого класса можно получить доступ из любой точки мира, при условии, что вы включили заголовочный файл в другие файлы проекта с помощью #include.
2. CRTP (Curiously Recurring Template Pattern)
CRTP — это идиома, где базовый класс принимает в шаблоне тип производного класса:
Преимущества данного похода
- Код переиспользуется: один шаблонный базовый класс для всех синглтонов.
- Статическая полиморфность: нет виртуальных функций, всё разрешается на этапе компиляции.
- Типобезопасность: каждый синглтон — свой тип.
#singleton #design_patterns #crtp
1. Первый - такназываемый «синглтон Мейерса»
Этот паттерн особенно подходит для управления доступом к ресурсам, таким как конфигурационные файлы, аппаратные интерфейсы, логгеры, или управление состоянием для всего приложения.
Это идиома реализации синглтона в C++, предложенная Скоттом Мейерсом. Она использует статическую локальную переменную внутри функции-геттера:
class Singleton {
public:
static Singleton& instance() {
static Singleton s_instance;
return s_instance;
}
private:
Singleton() = default;
~Singleton() = default;
Singleton(const Singleton&) = delete;
Singleton& operator=(const Singleton&) = delete;
};Какие особенности есть у этого похода:
- Ленивая инициализация: объект создаётся при первом вызове
instance().- Автоматическая корректная деинициализация: деструктор вызывается при завершении программы.
- Потокобезопасность (в C++11 и выше): стандарт гарантирует, что инициализация статической локальной переменной атомарна и потокобезопасна.
Доступность: к открытым методам такого класса можно получить доступ из любой точки мира, при условии, что вы включили заголовочный файл в другие файлы проекта с помощью #include.
2. CRTP (Curiously Recurring Template Pattern)
CRTP — это идиома, где базовый класс принимает в шаблоне тип производного класса:
template <typename Derived>
class SingletonBase {
public:
static Derived& instance() {
static Derived s_instance;
return s_instance;
}
protected:
SingletonBase() = default;
~SingletonBase() = default;
};
class MySingleton : public SingletonBase<MySingleton> {
friend class SingletonBase<MySingleton>; // чтобы конструктор был доступен
private:
MySingleton() = default;
};
Преимущества данного похода
- Код переиспользуется: один шаблонный базовый класс для всех синглтонов.
- Статическая полиморфность: нет виртуальных функций, всё разрешается на этапе компиляции.
- Типобезопасность: каждый синглтон — свой тип.
#singleton #design_patterns #crtp
👍1
Точечные оценки — красивая ложь
— слышали такое?
Я слышу это постоянно. И каждый раз внутри меня что-то сжимается 😅
Эта цифра создаёт иллюзию точности. Как будто кто-то заглянул в будущее и увидел дату релиза. Реальность: это одна из тысяч возможностей.
Помню, как в одном проекте менеджер с уверенным видом объявил:
Спойлер: проект занял 22 недели.
И знаете, что самое интересное? Никто даже не удивился. Все молча кивнули и продолжили работать, как будто так и было задумано.
Точечная оценка без вероятности бессмысленна.
Она подразумевает 100% гарантию, хотя в разработке нет ничего гарантированного.
Три понятия, которые путают:
Оценка — вероятностный прогноз
Цель — желаемый результат
Обязательство — договорённость с учётом рисков
Когда менеджер говорит «14 недель», спросите: «Какова вероятность этого числа? 50%? 30%? 10%?»
Я начал задавать этот вопрос на каждой встрече. Сначала на меня смотрели как на человека, который усложняет простые вещи. Потом начали понимать. А потом — сами стали говорить в диапазонах и вероятностях.
Без ответа цифра остаётся пустым звуком.
Или, как я люблю говорить — красивой ложью, которая всех устраивает. До момента, когда дедлайн пролетает мимо, а релиза всё нет 🙃
А как у вас в команде с оценками? Говорите диапазонами или всё ещё верите в магию точных цифр?
Проект займёт 14 недель
— слышали такое?
Я слышу это постоянно. И каждый раз внутри меня что-то сжимается 😅
Эта цифра создаёт иллюзию точности. Как будто кто-то заглянул в будущее и увидел дату релиза. Реальность: это одна из тысяч возможностей.
Помню, как в одном проекте менеджер с уверенным видом объявил:
12 недель, не больше
Спойлер: проект занял 22 недели.
И знаете, что самое интересное? Никто даже не удивился. Все молча кивнули и продолжили работать, как будто так и было задумано.
Точечная оценка без вероятности бессмысленна.
Она подразумевает 100% гарантию, хотя в разработке нет ничего гарантированного.
Три понятия, которые путают:
Оценка — вероятностный прогноз
Цель — желаемый результат
Обязательство — договорённость с учётом рисков
Когда менеджер говорит «14 недель», спросите: «Какова вероятность этого числа? 50%? 30%? 10%?»
Я начал задавать этот вопрос на каждой встрече. Сначала на меня смотрели как на человека, который усложняет простые вещи. Потом начали понимать. А потом — сами стали говорить в диапазонах и вероятностях.
Без ответа цифра остаётся пустым звуком.
Или, как я люблю говорить — красивой ложью, которая всех устраивает. До момента, когда дедлайн пролетает мимо, а релиза всё нет 🙃
А как у вас в команде с оценками? Говорите диапазонами или всё ещё верите в магию точных цифр?
❤5🔥1😁1
Асимметрия реальности
Многие представляют сроки проекта как колоколообразную кривую - симметричное распределение вокруг среднего (как нормальное распределение Гаусса).
Это неправда.
Знаете, что меня всегда удивляло? Как упорно люди верят в эту красивую симметрию. Я сам когда-то так думал, пока не словил пару болезненных уроков в моем проекте 😅
Существует предел того, насколько быстро команда может работать. Левая сторона графика обрезана - нельзя писать код быстрее физических возможностей.
Помню, как менеджер спросил меня: «А если мы добавим ещё разработчиков?» Я ответил: «Девять женщин не родят ребёнка за месяц». Он не оценил мою метафору, но суть понял 🙃
А вот количество проблем ничем не ограничено:
Критические баги в продакшене
Уход ключевого разработчика
Изменение требований на 80% готового проекта
Проблемы с инфраструктурой
Интеграция, которая «должна была работать из коробки»
Эти пункты - не теория. Это список из моего последнего квартала. Причём все пять случились в ОДНОМ проекте. Одновременно. Я до сих пор не понимаю, как мы выжили 😁
Результат: график вероятностей имеет короткий левый хвост и длинный правый.
Медиана (точка 50/50) показывает: половина проектов завершится раньше, половина - позже. И эта «половина позже» может растянуться ОЧЕНЬ далеко.
Самый долгий проект в моей практике должен был занять 3 месяца. Закончили через 11. И нет, это не провал - это просто реальность, в которой работают разработчики.
А у вас был такой проект-долгострой? Сколько в итоге длился и что пошло не так?
Многие представляют сроки проекта как колоколообразную кривую - симметричное распределение вокруг среднего (как нормальное распределение Гаусса).
Это неправда.
Знаете, что меня всегда удивляло? Как упорно люди верят в эту красивую симметрию. Я сам когда-то так думал, пока не словил пару болезненных уроков в моем проекте 😅
Существует предел того, насколько быстро команда может работать. Левая сторона графика обрезана - нельзя писать код быстрее физических возможностей.
Помню, как менеджер спросил меня: «А если мы добавим ещё разработчиков?» Я ответил: «Девять женщин не родят ребёнка за месяц». Он не оценил мою метафору, но суть понял 🙃
А вот количество проблем ничем не ограничено:
Критические баги в продакшене
Уход ключевого разработчика
Изменение требований на 80% готового проекта
Проблемы с инфраструктурой
Интеграция, которая «должна была работать из коробки»
Эти пункты - не теория. Это список из моего последнего квартала. Причём все пять случились в ОДНОМ проекте. Одновременно. Я до сих пор не понимаю, как мы выжили 😁
Результат: график вероятностей имеет короткий левый хвост и длинный правый.
Медиана (точка 50/50) показывает: половина проектов завершится раньше, половина - позже. И эта «половина позже» может растянуться ОЧЕНЬ далеко.
Самый долгий проект в моей практике должен был занять 3 месяца. Закончили через 11. И нет, это не провал - это просто реальность, в которой работают разработчики.
А у вас был такой проект-долгострой? Сколько в итоге длился и что пошло не так?
🔥1
Иллюзия 90% уверенности
Эксперимент: людям дали тест из 10 вопросов. Нужно указать диапазон ответа с «90% уверенностью».
Результаты:
Средний балл: 2.8 из 10
Только 2% получили 8+ правильных ответов
Никто не ответил верно на все 10
Когда я впервые прочитал про этот эксперимент, подумал:
Провёл похожий тест в своей команде. Угадайте результат? Правильно, точно такой же провал 😅
Вывод: интуитивное ощущение «90% уверенности» на деле соответствует примерно «30% уверенности».
То же самое в проектах. Команды регулярно представляют графики с «90% уверенностью» и регулярно их превышают — в 50-60% случаев, а не в 10%.
Был у меня один тимлид, золотой человек. На каждой планёрке: «Я на 90% уверен, что закончим к пятнице». Знаете, сколько раз из десяти он укладывался? Три. ТРИ, Карл! Это вообще 30%, а не 90%.
Я его спросил:
Он посмотрел на меня и честно ответил:
Вот она, вся наша «уверенность» 🙃
Правило: не давайте оценок с процентами уверенности, если у вас нет статистического обоснования.
Без анализа данных конкретные проценты — это желаемое, выдаваемое за действительное.
Сейчас, когда кто-то в команде говорит «я на 90% уверен», я достаю блокнот и говорю:
.Обычно после этого люди начинают говорить более честно: «Ну... наверное, половина на половину» 😁
А вы когда-нибудь ловили себя на таком? Говорили «я уверен на 90%», а потом оказывалось совсем не так?
Эксперимент: людям дали тест из 10 вопросов. Нужно указать диапазон ответа с «90% уверенностью».
Результаты:
Средний балл: 2.8 из 10
Только 2% получили 8+ правильных ответов
Никто не ответил верно на все 10
Когда я впервые прочитал про этот эксперимент, подумал:
Ну это же они, обычные люди. Мы-то в IT поумнее
Провёл похожий тест в своей команде. Угадайте результат? Правильно, точно такой же провал 😅
Вывод: интуитивное ощущение «90% уверенности» на деле соответствует примерно «30% уверенности».
То же самое в проектах. Команды регулярно представляют графики с «90% уверенностью» и регулярно их превышают — в 50-60% случаев, а не в 10%.
Был у меня один тимлид, золотой человек. На каждой планёрке: «Я на 90% уверен, что закончим к пятнице». Знаете, сколько раз из десяти он укладывался? Три. ТРИ, Карл! Это вообще 30%, а не 90%.
Я его спросил:
Слушай, а ты понимаешь, что значит 90%?
Он посмотрел на меня и честно ответил:
Ну... я просто так чувствую
Вот она, вся наша «уверенность» 🙃
Правило: не давайте оценок с процентами уверенности, если у вас нет статистического обоснования.
Без анализа данных конкретные проценты — это желаемое, выдаваемое за действительное.
Сейчас, когда кто-то в команде говорит «я на 90% уверен», я достаю блокнот и говорю:
Отлично! Давай запишем. Будем проверять калибровку твоей уверенности
.Обычно после этого люди начинают говорить более честно: «Ну... наверное, половина на половину» 😁
А вы когда-нибудь ловили себя на таком? Говорили «я уверен на 90%», а потом оказывалось совсем не так?
❤2