Мне всегда была интересна тема антихрупкости и работы Нассима Талеба — особенно в контексте их применения в IT.

Книга «Антихрупкость в IT» попала в мой список рекомендаций больше года назад, после одной конференций в Казахстане.

Книга показалась мне интересно, по этому ниже обзор основных тем, и в каком случае вам стоит ее прочесть.

А так же ответим на вопросы: как продать микросервисы бизнесу? Почему у книги такая обложка? А есть ли что-то от антихрупкости Талеба в книги с таким название?

Переживание о том, что могут уволить, возникает и у новичков, и даже у профессионалов, которые склонны иметь синдром самозванца, что достаточно часто встречается в it-профессии.

Страх неудачи — распространённая проблема, когда ты начинаешь переживать: «я недостаточно знаю», «а что будет, если они догадались», «там все профессионалы, а я нет».

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

Но если копнуть поглубже — всё становится не так очевидно. Сейчас покажу на примерах

Привет! Я давно в IT, настолько что верстал еще под IE6. Начинал ещё со школы: сервера Diablo II, боты mIRC, карты Warcraft III на JASS, код, форумы, общение и дикий, нескончаемый интерес. Без какого-либо понимания, что я делаю и куда меня это приведёт.

Я никогда не считал это чем-то серьёзным, но был уверен, что в случае чего смогу этим прокормиться — так по итогу и вышло. Хоть я и усердно убегал от «бездушных железок».

Заваривайте чай, расскажу вам свою историю как я попал в IT и вот уже лет 13 тут, приятного прочтения

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

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

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

Скорочтение — это не про то, чтобы глотать страницы книг. Обучение — это не про курсы. Архитектурное мышление — это не про чертежи систем.

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

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

И самое интересное — вы сами увидите, как архитектурное мышление проявляется там, где его меньше всего ждёшь.

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

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

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

В какой-то определенный момент после старта нового проекта, когда «временный» MVP почти готов, весь интересный код уже написан, пакеты еще свежие и обновляются, команды начинают замедляться в Time to Market.

Для разработчиков обычно это выражается в переходе от «нам бы перестать добавлять технический долг» к пониманию того, что он нам уже реально мешает. Бизнес начинает все больше подгонять вперед, а разработчикам все сложнее держать код проекта в голове и безопасно его переписывать. Но уже поздно: проект прошел точку невозврата, и по опыту с таким подходом дальше будет только хуже.

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

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

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