#⃣ Делай свою работу так, чтобы тебя можно было заменить уже завтра

Всегда работал под лозунгом: делать свою работу так, чтобы меня можно было заменить уже завтра. Это, конечно, иногда аукалось мне, но в итоге оказалось не просто красивой концепцией, а самой выгодной стратегией.

Главное — внутри компании тебя начинают окружать люди, которые хотят делать то же самое. И тогда вы уже вместе можете строить настоящие системы и заниматься архитектурой — как кода, так и бизнес-процессов.

А когда вас становится много, вы можете нанимать таких же людей, как вы. И тогда то, что вы построили, начинает поддерживать само себя — а у вас высвобождается много времени на настоящее развитие.

К сожалению, заставить людей хотеть расти невозможно. Нужно просто прийти в нужный момент к нужным людям и дать им возможности.

#⃣ Что делает разработчика хорошими?

Я очень рад, что в последнее время в дискуссиях всё чаще говорим о том, что делает разработчика хорошим — не столько навыки написания кода, сколько кое-что ещё. Пусть даже говорим из за страха или хайпа перед ИИ.

Умение писать код — это база, но, во-первых, только одна из двух, а во-вторых, это "кое-что ещё" — довольно обширное.

Да, существуют компании, достаточно большие, чтобы под каждый квадратик найти отдельного человека. Но подавляющее большинство компаний такими не являются. Плюс сами разработчики не хотят быть просто программистами — они хотят влиять на решения, которые в конечном итоге оказываются в коде.

И да, когда ты неплохо овладел всеми этими навыками, что требует ни плохого уровня абстрактного мышления, часть из них можно делегировать или заменить частично инструментами, потому что это лишь один из этапов твоей работы. При этом, чем выше ты поднимаешься по этим уровням, тем меньше на тебя влияет проблемы программирования — потому что ты их просто не создаёшь. А значит, можешь делегировать другим.

Кстати, в этой пирамидке обязательно должна быть ещё и обратная связь — но, думаю, это и так для всех очевидно.

#⃣ Основная проблема с процессами — что их нельзя просто так взять, натянуть, скопировать, повторить.
Есть ощущение, что в любой попытке вербализации словами или даже при описании в документации что-то теряется.

Хороший пример — скрам и все эти попытки заставить его работать. В последнее время всё больше склоняюсь к мысли, что процессы неразрывно связаны с культурой.

Правда, многие ошибочно считают, что культура может отсутствовать, или что нет процессов. Но так не бывает.

Есть культура А — она даёт результаты X.
Мы хотим культуру Б — и результаты Y.

Но между А и Б нужно как-то выстроить маршрут, чтобы он был нативный, и в каждом конкретном случае он будет свой. Либо невозможен, читай — нерентабелен, когда сумма затрат на изменение и внедрение перекрывает границу профита или уходит за горизонт событий.

С другой стороны, есть вариант пойти другим путём. Мы часто фокусируемся на том, что у команд получается плохо, пытаемся это оптимизировать, исправлять — это вызывает сопротивление и часто не даёт результата.

Но мы можем, напротив, сфокусироваться на сильных сторонах — они всегда есть — и делать не то, что принято, а то, что мы уже и так умеем делать лучше всего. Зашивать это в процессы и помогать.

Основная беда — что в то, что часто называют ценностями компании или миссией, вкладывают то, чего нет, то, для чего даже нет почвы — и потом пытаются натянуть сову на глобус.

Поэтому куда лучше вместо вечного сопротивления — плыть по течению. А ещё лучше — грести. Пусть и не всегда в том направлении, которое вы хотели бы. Но это движение. И это движение не будет сжирать ваши ценные ресурсы команды.

#️⃣Почему смена оргструктуры требует пересмотра архитектуры?
Поговорим про влияние коммуникации, контекста на технические решения

Об этом мало кто говорит, но при смене оргструктуры — например, вы выделили несколько фичей в отдельные команды — вам неминуемо придётся вносить изменения в архитектуру.

В целом, вы можете этого не делать, но тогда оргструктура и особенности коммуникации просачиваются в код.

Любая коммуникация в команде будет проходить лучше, быстрее, качественнее, чем между командами. Это неминуемо приведёт к последствиям.

Пусть вас не смущает, что раньше всё было хорошо, и пусть вас не обманывает ваша архитектура — даже если сейчас она хорошая.

Разработка — это результат коммуникации и контекста. Разрывая контекст и затрудняя коммуникацию, мы получаем проблемные решения на этих стыках.

В целом, в идеальном мире можно говорить о том, что у продукта может быть какая-то одна верная структура (system design) как проекция набора бизнес-требований — и с этим даже можно согласиться в некой степени.

Но системный дизайн — это только часть архитектуры.

Задача архитектора как раз — учитывать такой контекст, как организация процессов, команд, культура.

В рамках архитектурной работы вы намеренно “портите” системный дизайн, исходя из особенностей этой самой коммуникации, для того чтобы суммарно наше приложение было проще поддерживать и вносить в него изменения.

К сожалению, эта мысль контринтуитивна: нужно делать хуже, чтобы делать лучше. И часто нужен опыт и некая насмотренность, чтобы переключиться в этот режим.

Из хорошего — большинство людей в разработке это замечают, просто относятся к этому как к флуктуациям, убирая коммуникацию из расчёта. Но я советую вам пересмотреть, вспомнить кейсы, где у вас всё ехало легко на общем уровне, а где — напротив. И обратить как раз своё внимание на те самые флуктуации: а почему так?

Это и правда несложно. Нужна практика, желание и любовь к своему делу и немножко терпения и у вас все получится!

#️⃣Если так подумать, как же много завязано на веру.

Один из базовых принципов харизматической уверенности звучит так: всё нормально, всё будет нормально.

Вера в то, что что бы ни случилось, ты как-то справишься, разберёшься, каким-то странным образом даёт лично тебе сил, и другие люди по какой-то причине находят тебя из-за этого харизматичным.

В лидерстве способность верить в свою идею настолько, что она заражает других людей и заставляет их идти с тобой, помогает добиваться очень больших результатов и строить большие бизнесы и компании.

А в вопросе привычки, например, определяющим фактором для людей, которые бросили пить или курить, критерием того, что они не сорвутся, является вера: что бы ни случилось, ты справишься без алкоголя или сигарет.

Мы часто ассоциируем слово «вера» с религией, хотя по большей части вера касается почти всех вопросов — как личной жизни, так и работы.

Люди верят в бренды, в методологии, в спорт, да даже в программы, и на удивление это работает.

Возможно, даже существует метавера — вера в веру, но о таком я пока не слышал.

Так что желаю вам побольше веры в себя, в ваши идеи, ну и в других людей.

#️⃣ Какие пет-проекты делать?
Я пришёл к выводу, что в целом имеет смысл браться только за три типа — всё остальное не стоит отвлечения на себя времени и внимания.

1) Маленькие утилитарные проектики.
Буквально скрипт на коленке, когда вы устали выполнять какую-то рутинную операцию и вдруг думаете:
А почему бы не автоматизировать маленький шаг?

Из последних примеров: я хотел навести порядок в своём Obsidian — проставить атрибуты дат у заметок, разложить их по папкам, чуть подправить именование по паттерну.
Понятно, что сделать это можно и руками, но со скриптом — прикольнее.

У таких пет-проектов есть интересный побочный эффект: в процессе, когда вы уже получили первый результат, вы можете либо захотеть продолжать, либо просто выкинуть всё к чёрту. И тот, и другой вариант — хороший.
Как говорится, аппетит приходит во время еды.

2) Вам просто в кайф это делать.
Это, наверное, самая сложная категория — непонятно, откуда она появляется и почему исчезает, но она точно нестабильна.

Если нет никаких логических причин, но вам по какой-то причине интересно проводить время за написанием программы на Elixir, изучением Rust или чем-то ещё — делайте это.
Не пытайтесь в этот момент натянуть сову на глобус и добавить к интересу ощущение пользы — это только всё убьёт.

Если у вас ступор идей, начните делать что-то уже знакомое.
Например, одна из моих любимых практик — написать «игру жизнь». Она простая, понятная, с известными требованиями, визуализацию можно сделать буквально в консоли.
Можно повторить простые игры вроде тетриса, сапёра, 2048 — всё, что вам более-менее понятно.

Главное здесь — не загубить свой интерес попытками заработать на проекте или «увеличить импакт».

3) Проекты с конфликтом.
Многие думают, что самое главное — найти крутую идею.
Они задумываются о пет-проектах как о будущем бизнесе или чём-то большом. Но это часто ловушка.

Почему конфликт?
Потому что сама идея по себе — скучна. Когда у вас миллион вариантов, что сделать, вы впадаете в ступор: ничего не выбираете, интерес пропадает, а критерии успеха становятся размытыми.

Вот пример: у нас есть AI-агенты, ChatGPT, куча фреймворков и SaaS-платформ вроде Vercel и Supabase, где можно почти без кода поднять приложение.
Возможностей — море. Толку — немного.

Конфликт начинается, когда вы подходите к задаче с инженерной точки зрения:
вы берёте что-то, что не может одновременно существовать, и ищете способ, как этого добиться.

Например:
Мне надоела система сборки JavaScript, но с ней так удобно работать. Было бы круто, чтобы сборки не было, но всё работало как раньше — быстро и удобно.
Или:
Я люблю, когда в проекте есть требования, но ненавижу их писать. Было бы круто, если бы код одновременно был и требованиями, и реализацией.

Сам поиск решения в таких случаях становится интересным сам по себе.
Если вспомнить взрослые инженерные методологии вроде Теории ограничений или ТРИЗ, они буквально построены на этом принципе:

Если вы хотите добиться выдающегося результата — найдите конфликт и придумайте к нему не компромиссное решение.

Теория ограничений вообще утверждает, что такое решение всегда существует.
Мы просто часто его игнорируем, когда идём по проторенной дорожке.

4) И напоследок — оставляйте вкусное себе.
Это правило гораздо глубже, чем кажется, но многие про него забывают.

На работе мы привыкли, что бывают неинтересные задачи, которые нужно делать.
Но в своих проектах мы сами выбираем и скоуп, и объём, и способ реализации.
А в эпоху AI — можем ещё и делегировать рутину.

Вам нравится делать всратый дизайн, но вы этого не умеете?
Делайте, но не губите свой интерес, помните аппетит приходит вовремя еды, найдите конфликт, он в 100 раз дороже идеи.

И удачи вам с вашими петами.

#️⃣Схема проектирования процессов по Илону Маску. Грех который все мы совершаем.

Знаешь эту шутку про то, что в теории теория и практика совпадают, а на практике это не так?
Вообще, знания, полученные через опыт, радикально отличаются от теоретических.

Основная проблема начинается тогда, когда мы пытаемся на основании теоретических знаний что-то автоматизировать.

Обычно сюда добавляется ещё и человеческое недоверие — неверие в то, что процессы могут исполняться просто так.

В этом случае люди сразу начинают с последнего шага илонмасковской диаграммы — автоматизации:

«Давайте всем запретим, и будет работать только так».

Но прикол в том, что оно нифига не работает.

В некотором смысле процесс автоматизации похож на процесс обучения: мы получили новую информацию, что-то сделали, извлекли знания.
А знания появляются только из практики.

И тут как раз помогает схема маска:
Сначала ты пишешь самые простые, дурацкие требования и делаешь систему на костылях и палках.

Потом смотришь — что можно выкинуть, какой процесс или этап лишний, где можно упростить.

Дальше прогоняешь несколько циклов реальной работы и получаешь настоящий фидбэк: где и что идёт не так.

Тут есть ещё один прикол. Когда мы занимаемся автоматизацией, мы часто перезакладываемся — делаем с запасом «на всякий случай».
А идея в том, что перезакладываться нужно только там, где реально стреляет.

И вот когда система начинает работать как часики — тогда её и стоит автоматизировать.

Мне ещё очень понравилась мысль, которую я услышал в интервью с Илоном:

«У любого требования должен быть автор. И это должен быть не отдел маркетинга, а конкретный человек».

Потому что, когда нам нужно будет пересмотреть это требование, мы должны понимать, с кем его обсудить, кто его придумал и почему.
Это ведь и есть главная причина появления legacy.

Я для себя стал определять legacy как ту часть системы, у которой утеряно исходное требование, и больше нет владельца.

Когда-то мы добавили, например, новое поле — а теперь оно висит мёртвым грузом, никто не знает, зачем оно нужно, и все боятся его трогать.

А если такая система ещё и высечена в камне — то есть автоматизирована, тогда всё, пиши пропало.

Так что возможно, самая распространённая ошибка — оптимизация того, чего не должно было бы существовать вовсе 🤷🏼.

#⃣ Таинство обучения происходит внутри человека

Когда я пять лет работал в EdTech и много общался со студентами и методистами, я хорошо понял одну вещь

Мы можем сколько угодно стараться и делать всё возможное, создавая обучающие условия, но в конечном итоге таинство обучения происходит внутри человека.

Если описать это просто, то, наверное, так: мы не можем никого ничему научить — мы можем лишь создать для этого условия. Выбор в конечном счёте всегда за учеником.
Мы даже не можем гарантировать, чему именно человек будет учиться в той среде, которую мы создали — обману, прогуливанию, прокрастинации или же новым знаниям, которые он сможет применить на практике.

Если обратить внимание на то, как конкретно строятся обучающие материалы в различных школах, где люди действительно задумывались об образовательном процессе, можно заметить общее сходство: везде присутствует проектирование обучающего опыта.
— Сначала человеку дают общее представление и понимание важности предмета.
— Затем предоставляют возможность на практике «потыкать» руками, создавая условия, в которых он максимально быстро получит первый результат.
— Потом объясняют, что именно он получил, почему это важно, и дают дополнительные детали — как это можно применять в будущем.
— После этого снова проводят через практику для закрепления навыка.
— В завершение показывают общую картину: как знания, полученные на практике, складываются в целостную, пусть пока и упрощённую, систему.
— А дальше цикл замыкается — человека переводят к следующему материалу.

В некотором смысле это проектирование пользовательского опыта, только в данном случае пользователь — студент, а опыт — это те знания, которые он получает на практике. Образовательные материалы здесь лишь проводник.

Понимание такого подхода позволяет проектировать свой личный образовательный трек вне специализированных мест — точно так же, как вы проектируете свой опыт во время отпуска: какие впечатления хотите получить, куда сходить, какие блюда попробовать, какие места посетить.

Точно так же можно спроектировать собственный путь обучения — где и как вы будете получать новые знания через впечатления от практики, когда и каким образом будете рефлексировать над полученным опытом, и какой следующий шаг скорректируете для себя.

#️⃣ Цикл Колба: важность стадии эксперимента

Вообще, мне кажется, основная проблема в том, что когда люди обсуждают обучение, они почему-то исключают из него процесс эксперимента, хотя это является базовым требованием к самому процессу обучения.

Без практики обучение не существует.

Более того, если начать учиться и потерять этап практики, можно попасть в состояние переобучения — когда ты больше не способен узнавать ничего нового по той причине, что знаешь слишком много, но ничего не попробовал на практике и теперь тебе страшно сделать первые шаги.

Парадокс в том, что ты уже знаешь, как правильно, но всё ещё не можешь это сделать.

Поэтому чтобы понять чему ты на самом деле учишься на работе или в универе ты должен понять, а что ты делаешь каждый день руками на практике.

И да, практика отдельно не является самодостаточным обучением, без остальных этапов.

#️⃣ Закон Гудхарта об автоматизации
Когда автоматизация становится целью, а не побочным эффектом — она превращается в плохую автоматизацию.


У меня есть подозрение: если в разговоре звучат слова «рутина» и «автоматизация» — это уже тревожный звонок.
Значит, где-то есть проблема.

И если сейчас сделать следующий шаг — у тебя станет не одна проблема, а две:
— твоя текущая,
— и твоя новая — автоматизация.


Когда мы в здравом уме делаем продукт с конкретной пользой, мы не называем это «автоматизацией». Мы просто делаем продукт.
А когда начинаем автоматизировать рутину — обычно скрываем за этим то, что не хотим разбираться в кривом процессе.

Одно время я много работал с отделами маркетинга, продаж и в особенности с бухгалтерии — и заметил любопытную закономерность:
то, что действительно стоило бы автоматизировать, тебе никто не придёт и не скажет.
Потому что именно эту работу там считают самой важной, её обязательно нужно делать руками, и никому доверить нельзя.


И вот что обычно скрывается за фразой «мы автоматизировали рутину»:

Непонятен сам бизнес-процесс — может, из-за автоматизации теперь люди не могут вносить частные правки, которые они любили делать. Такое, кстати, часто бывает: автоматизация какой-то рутины портит процесс, просто потому что сам процесс был кривым.

Или, например, это мы делали раз в год, и нам вообще всё равно.

Или мы потратили на автоматизацию время, которое никогда не окупится, а на выходе ещё получили стоимость поддержки этого решения.

А бывает и хуже — после автоматизации появляется лок:
раньше люди могли менять процесс сами,
а теперь им нужно обращаться к кому-то.

Поэтому как раз в таких формулировках — «автоматизировали рутину» — обычно и прячется вся эта история.


Поэтому, когда человек начинает разговор с продукта и профита, тогда автоматизация становится всего лишь функциональностью, а не самоцелью.


Материалы по тема:
▸ Схема проектирования процессов по Илону Маску
▸ Про цели и метрики

#️⃣Идеального кода не существует — но в этом и прикол.

Мы иногда с вами говорим, что идеальный тот код, которого нету, но мне кажется, мало кто это воспринимает всерьёз, а зря.

В ТРИЗ есть такое понятие, как идеальный механизм или идеальное решение: это когда механизм отсутствует, а его задачи выполняются.

Например, ребята рассказывали, как они разрабатывали спутник, и к ним пришёл учёный и сказал, что хочет засунуть в их спутник двухкилограммовый новый объект. На что инженеры сначала ответили, что это невозможно, так как они больше года оптимизируют каждый квадратный миллиметр аппарата, и там просто нет зазора и тем более места под два килограмма — невозможно вставить ещё один объект.

А по итогу оказалось, что возможно. В спутнике был по центру металлический шар, который выполнял задачу балансира. Он примерно по объёму совпадал с устройством, которое хотели поместить. Груз убрали, а на его место поместили механизм, профит!

И теперь в системе нет балансира, но его функция продолжает выполняться.

Вообще это могло бы быть хорошей иллюстрацией к определению свойства эмерджентности у систем — когда система это больше, чем сумма элементов, как в данном случае...

Но, если это есть в ТРИЗ (а напомню, ТРИЗ — про решение сложных изобретательских задач, а разработку мы считаем инженерией), то, наверное, в разработке тоже должен существовать идеальный код — тот, которого не существует, но его функция продолжает выполняться.

Так что когда к вам в следующий раз придут с невозможной на первый взгляд задаче, не торопитесь говорить нет, вы это ещё и так всегда успеете сделать, остановитесь и подумайте, а вдруг у вас выйдет написать идеальный код?

Но про невозможные задачи в следующем раз и что с ними делать с точки решения теории ограничений и ТРИЗ


@DragorWW_space