IT – Гильдия

Суббота у всех проходит по-разному 🏎️

Илья сегодня на тренировке — трасса и гонки.

А что помогает вам перезагрузиться и переключиться от рабочих будней?

«У меня нет достижений для резюме. Я просто 5 лет закрывал таски»

Что обсуждали ребята в чате Гильдии 👀

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

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

В голове остаётся только:

«Ну… я просто делал свою работу».

Но в треде хорошо разложили, как на это смотреть.

Не:

❌ «Починил редирект».

А:

✅ «Повысил конверсию продаж, исправив проблему в логике редиректа».

Не:

❌ «Оптимизировал большую форму».

А:

✅ «Сократил время на выполнения задачи путем оптимизации формы

Достижение — это не то, что можно повесить на стену.

Главный вопрос:

👉 «Как то, что я сделал, помогло продукту или бизнесу?»

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

А ещё хороший совет из треда: начните вести журнал достижений сейчас.

Чтобы через год снова не сидеть перед пустым резюме и думать: «А что я вообще сделал?» 😄

А вы помните свои достижения за последний год?

Хорошая структура данных сокращает код и работу с AI

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

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

Если данные хранятся в обычном массиве, приходится описывать:

— как найти зависимые элементы;
— в каком порядке их пересчитать;
— как отметить уже обработанные;
— как избежать повторных вычислений;
— как обнаружить зацикливание.

Появляются флаги, вложенные условия и повторные обходы. AI быстро дописывает эту логику. Затем так же быстро добавляет новые проверки для каждого пограничного случая.

Кода становится больше, но система не становится понятнее.

Изменим структуру данных

Зависимости можно представить как граф: каждое значение — вершина, каждая зависимость — направленная связь.

Тогда операция выглядит проще:

1) Найти измененную вершину.

2) Получить связанные вершины.

3) Пересчитать их в нужном порядке.

4) Отдельно проверить граф на циклы.

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

Что это меняет при работе с AI

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

Если сложный механизм спрятан за надежным интерфейсом, AI видит несколько понятных операций:

addDependency()
updateValue()
getAffectedNodes()
validateGraph()

Контекст меньше. Промпт короче. Результат проще проверить.

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

AI ускоряет не только разработку

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

Поэтому главный навык работы с AI — не умение составлять длинные промпты. Важнее уметь:

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

Разработчик просит AI дописать очередное условие. Инженер сначала спрашивает: почему это условие вообще понадобилось?

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

Это помогает получать от AI не больше кода, а более простые и надежные системы.

Как Гильдийцы борются с отвлечениями во время работы?

Недавно обсуждали эту тему в Гильдии — собрали самые практичные советы, которыми делились участники.

Вот что советовали:

📱 Убирать телефон из комнаты.
Не рядом с ноутбуком, а буквально в другую комнату. Некоторые ещё отказываются от часов с уведомлениями.

💻 Разделять рабочую и личную среду.
Два профиля, две ОС или даже отдельная машина для работы и отдыха. Чтобы мозг понимал: здесь работаем, здесь отдыхаем.

🎧 Создать отдельный рабочий ритуал.
Например, одна музыка только для работы + таймер.

🚫 Убрать короткие видео.
TikTok, Reels, Shorts — удалить или технически заблокировать. Участники даже делились способами отключения Shorts на Android.

⏱️ Каждые 15–30 минут фиксировать, что реально сделал.
Не «работал над фичей», а конкретный результат за этот промежуток. Главное — максимально честно.

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

А какие лайфхаки помогают вам не улетать в Telegram, YouTube и другие порталы в прокрастинацию во время работы? 👇

Как развиваться, если ты уже перерос свою работу, но весь день занят текущими задачами?🫣

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

Не просто закрывать задачу, а искать способ сделать её системно.

Простые и повторяющиеся задачи — автоматизируйте. В идеале — до уровня dark software factory, где процесс практически работает сам.

Это сильно прокачивает.

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

И здесь появляется ещё один бонус.

Поиск ответов → общение → новые знакомства → новые возможности.

Поэтому развитие — это не обязательно уйти с текущей работы и найти новую.

Иногда достаточно начать делать текущую работу на уровне, до которого вы ещё не доросли.

⏰ Через 30 минут начинаем прямой эфир

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

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

И да, AI тоже причастен — только не в банальном смысле «теперь твою работу может делать GPT»

Подключайтесь, комментируйте и спорьте с нами в прямом эфире 🙂

Приходите завтра - поговорим об увольнениях "по горячим следам" :)

Утро начинается не с кофе или как я заплатил за то, что решил быть старым и скучным

Вчера обнаружил, что мои агенты на компьютере ведут себя супер-странно, перепроверяя себя по несколько раз, приходя к странным выводам и вообще проходя фазу "тупой и ещё тупее". Логи показали, что запуск тестов, которые агент делает 100500 раз падает по непонятным причинам. Еще 30 минут ковыряний, перезагрузка - запуск MemTest - ну и конечно же, с моей удачей, у меня умерла планка памяти (в нынешнюю то эпоху цен на DDR5 😢)

Но у меня же есть гарантия! И действительно, компьютер покупался в октябре 2023, гарантия аж 3 года... Но есть нюанс.

Три года назад, покупая новый системный блок после длительного ноутбучного перерыва я решил что я уже слишком взрослый и серьезный чтобы собирать компьютер самостоятельно - и взял готовую сборку. Удобно? Удобно! До тех пор пока не открываешь гарантию где русским по-белому написано "Системный блок продается как единое изделие и обслуживается как единое изделие, в случае наступления гарантийного случая на гарантию передается весь системный блок". А взять и отправить весь системник в Киев на неопределенный срок я просто не могу себе позволить.

Что ж :) Впредь буду умнее. Или может просто вселенная даёт мне понять, что не от всех "юношеских" привычек надо отказываться

— Илья

Так за два года изменилась доля сокращений в tech, которые Layoffs.fyi связывает с AI: с 6,6% в 2024 году до 77,2% в 2026-м.

Это не означает, что AI непосредственно заменил 77% сотрудников. Но динамика показывает: автоматизация, инвестиции в AI и перестройка бизнеса уже влияют на то, какие роли компании сохраняют, а какие — сокращают.

И здесь возникает неприятный вопрос:

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

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

Тот пришёл поговорить о поиске новой работы после увольнения. Но разговор быстро превратился в ретроспективу:

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

20 августа в 19:00 по Киеву состоится бесплатный live-эфир Ильи Климова: «Почему умных и продуктивных разработчиков увольняют»

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

Допустим, программа пересчитывает стоимость заказов:

сумма = цена × количество − скидка

В одном проекте такой цикл тормозит на 50 тысячах записей, в другом обрабатывает миллионы. Формула одинаковая. Разница — в структуре данных и их раскладке в памяти.

Тяжелые объекты

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

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

Программа тратит время не на вычисления, а на перемещение данных.

Данные под конкретную операцию

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

Формула не изменилась, а работа ускорилась.

Например, миллион объектов по 200 байт занимает около 200 МБ без учета служебной нагрузки. Если для расчета нужны только два числовых поля, достаточно обработать примерно 16 МБ полезных данных.

Важно и то, сколько записей мы проверяем

Представим систему зависимых значений. Изменение одной записи должно пересчитать еще пять.

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

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

Что проверить, если система тормозит

- Какие поля действительно нужны операции.

- Не загружаются ли остальные поля за компанию.

- Лежат ли данные последовательно или разбросаны по памяти.

- Не обходится ли вся коллекция ради нескольких элементов.

- Можно ли построить индекс или граф связей.

- Сколько временных объектов создается при обработке.

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

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

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

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

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

В ожидании повышения: что меняется на следующем уровне?

В GitLab выкатили ожидания для меня от следующей должности для повышения: Staff → Senior Staff (P5B).

И вот что интересно: если не брать AI, здесь почти 0 технической экспертизы.

Почти всё — про коммуникацию и влияние:

— влияние на несколько команд;
— архитектурное согласование;
— решение сложных проблем между командами;
— стратегическое планирование;
— техническое направление;
— стандартизация и переиспользование;
— менторинг Staff-инженеров и senior IC.

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

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

И отдельный пункт — AI.

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

По сути, переход Staff → Senior Staff — это переход от:

«Я решаю сложные технические задачи»

к

«Я меняю то, как несколько команд решают сложные технические задачи».

Вот где начинается настоящий масштаб.

— Илья

Хотите узнать, какой у нас неофициальный девиз AI-цеха в Гильдии? 👀
Смотрите видео 😁

«Нас заменят? Вас возможно - нас нет»

Вот он, если кому интересно, всего пару строк: https://github.com/nodejs/node/pull/2534

Мой наибольший радиус поражения был, во время публикации Node.js 8.0.0 - May 30, 2017
Мой PR для исправления утечки дескрипторов сокетов при разрушении соединенией
положил половину нодовских проектов, все, что писалось на express и родственных фреймворках, все на мидлварах, это было не специально, я чинил проблему, но проекты на Metarhia работали на 8.0.0, будем считать, что это просто случайное совпадение, которых так много в нашей жизни :)
Прошло 9 лет - радиус поражения до сих пор уточняется...

Такое случается даже у самых опытных. Спасибо Тимуру за честную историю из практики💪