IT – Гильдия

Почему без структур данных вы будете тратить на AI больше и часто переделывать

1 августа приходите на стрим https://youtube.com/live/qNAjrZ07un0

В JavaScript-мире почти нет культуры использования структур данных. Их изучают на задачах с LeetCode и перед собеседованиями: разбирают внутреннее устройство, вычислительную сложность, потребление памяти, оптимизацию под V8 и GC. А затем в реальном коде снова остаются только [], {}, Set и Map.

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

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

Чтобы не пропустить начало, следите за этим каналом или поставьте нотификацию в ютюбе https://youtube.com/live/qNAjrZ07un0

Почему просто деливерить сеньйорские задачи недостаточно, чтоб ощущать себя сеньйором

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

1. Хроническое обесценивание

Однажды мой ментор попросил меня написать 10 вещей которыми я горжусь в своей жизни. Я с трудом написал 3... Почему так? Задумавшись об этом я понял - каждый раз взяв очередную "вершину" я очень быстро начинаю считать это достаточным. Ну раз смог - значить "вроде нормально", пора двигаться дальше. Таким образом, передо мной всегда стоят "амбициозные задачи" впереди и "ну такое" позади. Не повторяйте этой моей ошибки

2. Пожары дедлайнов

Процентов 90 моих задач до того, как я присоединился к GitLab были сделаны в пожарах, а иногда уже и пожарищах, дедлайнов. Когда в огне всё, включая твою пятую точку, то единственное что хочется сделать по достижению - забыть об этом как о страшном сне, передохнуть (ударение всё же на "у") пару дней и работать дальше

3. Насыщенная жизнь

Раз в год мне надо заполнять отчет о своем перформансе за год. Я открываю историю своих merge request и такой - о, ого, это же было 9 месяцев назад. Ух, и это я делать... Всего лишь раз в год я ощущаю как много сделано, потому что даже когда нет дедлайнов и когда я не обесцениваю - у меня просто нет времени помнить о том, какой я крутой. Как я с этим борюсь - я каждый день выписываю в конце дня что я сделал и раз в неделю (в воскресенье) это перечитываю

4. Сравнение не с собой

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

5. Невидимая работа

Самые сеньорские вещи, которые я делаю — это вообще не код. Это разговор с коллегой, который сомневался, правильно ли он делал задачу. которая оказалась сложнеее чем он думал. Это "нет", сказанное фиче на этапе дизайна — вместо трёх недель переделки потом. Это митинг, на котором я просто внимательно выслушал всех и отфасилитировал. Все из этого - это ОТСУТСТВИЕ видимого артефакта. а не его появления. Поэтому для себя самого я как будто и не сеньор — если после дня не осталось pull request'а, в моей голове я "ничего не сделал"

Что в итоге?

Если сложить все пять пунктов вместе, получается забавная штука: ни один из них не про то, чтобы делать более сложные задачи. Все они про то, чтобы разрешить себе заметить, что ты их уже делаешь. Ощущение "я сеньор" — это не автоматический бонус за выполненную работу, а отдельный навык, который надо тренировать так же осознанно, как и любой технический. У меня получается через силу и немного читерским путём — дневник, воскресные перечитывания, честные попытки написать 10 пунктов гордости (сейчас уже получается больше 3, если что 😄). А как вы боретесь со своим внутренним самозванцем?

— Илья

Решил поделиться "на ходу" своими мыслями про "идти одному" vs "идти толпой" и почему я верю в магию толпы

— Илья

«Senior frontend по грейду, но джуниор в душе. Многие называют это синдромом самозванца»

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

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

Получается замкнутый контур:

принял решение → сам его оценил → усомнился в своей оценке.

В Гильдии одна участница рассказала, как занималась observability на проекте.

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

Готовой постановки не было. Она сама увидела системную проблему и решила привести логирование в порядок.

После материалов Гильдии начала с ADR: описала текущее состояние и зафиксировала, куда должна прийти система. По ходу миграции ADR дополнялся и стал основной документацией проекта.

Дальше она:

— перевела логирование с Tracy на Monolog;
— сделала структурированный пайплайн с контекстом, событиями и метаданными;
— добавила логи в критические сценарии;
— перенесла всё на ELK и Kibana;
— сделала формат совместимым с Serilog, чтобы PHP-сервис работал рядом с сервисами на .NET.

В результате логи перестали исчезать, дебажить стало проще, а бизнес получил нормальную наблюдаемость.

Участница поделилась результатом в Гильдии и получила 24 реакции от других инженеров.

Это не повышение и не новый тайтл. Коллеги из Гильдии не решают, какую зарплату ей платить, и не участвуют в её корпоративной иерархии.

Поэтому они могут оценить саму работу:

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

Так появляется независимая сверка с реальностью.

Гильдия не будет убеждать вас, что вы великий инженер. Это бесполезно.

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

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

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

Если узнали себя — загляните сегодня в канал.

Нужен опыт, практическое суждение, а не знания

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

В Twitter - все резко стали умными, спорят до посинения о технологиях, которые ни разу на практике не применяли.

В Youtube появилось много дикторов, им AI пишет текст, а они как харнес для него - генерация голоса.
Все это собирать и классифицировать уже нет никаких сил.
Вот узнал про технологию (например, я вчера и сегодня постал у себя про Passkey и Web Authn API) ну так возьми ссылки на репозитории, забери примеры и внедри у себя альтернативный способ входа в приложение, если что-то непонятно или вызывает сомнение - приходи на стримы, которые веду я и Илья на наших каналах, задавай вопросы.
И так с любой новой технологией или идеей, их нужно или обходить стороной или пробовать на практике.

Примеры кода:
- Passkey, Web Authn: https://github.com/HowProgrammingWorks/Passkey
- Web Crypto + OPFS: https://github.com/HowProgrammingWorks/ChallengeSignIn

— Тимур

GitLab собирает всех инженеров в Испании 🤔

🔥 Этот пост собрал больше всего огоньков на канале всего за сутки

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

По реакциям видно: проблема не единичная.

В работе инженера хорошо настроена обратная связь на ошибки:

— упал прод — узнают все;
— в MR проблема — оставят комментарий;
— решение не сработало — разберут на ретро.

А сильная работа часто проходит бесшумно. Архитектура выдержала нагрузку. Рефакторинг убрал будущие проблемы. Команда стала двигаться быстрее. Задачу закрыли — и пошли дальше.

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

В работе уже есть доказательства сеньорского уровня. В голове всё ещё старая оценка себя.

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

Судя по вашим реакциям, тема попала в нерв. Мы к ней ещё вернёмся — продолжение уже готовится.

Поставьте 👀, если ждёте.

Уже изрядно подзабытый мной навык - собрать сетап для записи контента на крохотном столике в гостинице

Часто спрашивают - зачем я с собой всё это вожу? Причина очень проста - я увлекающийся человек. Если я не буду записывать то, что болит у меня прямо сейчас - то "сильно потом" получается не так выразительно и интересно

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

Прошло уже 6 лет, а я до сих пор помню вот этот MR в GitLab. Почему? Потому что это был один из первых MR который я ощущал как соответствующий уровень senior в компании - он решал сложную инженерную задачу, убирал боль и вообще - я и тогда гордился решением и даже сейчас.

В GitLab я пришел имея за плечами 12+ лет опыта в разработке. Почему же я не ощущал себя уверенно? Потому что философия компании на тот момент - be the manager of one. С одной стороны это конечно убирает микроменеджмент, но с другой - большую часть времени ты один. Ты вряд-ли получишь ревью от крутого специалиста пока не попросишь - все заняты своими зонами ответственности. К тебе не придут и не скажут "тебе надо вот это выучить" - решай сам.

Вообще "отсутствие внешней сверки" - а если убрать заумные слова то "когда нету коллеги, который скажет что ты молодец" - хроническая проблема всех нас. Причем часто еще и в ассиметричном формате - когда мы делаем хрень нам сообщают сразу и резко - а вот с похвалами и менторством у нас традиционно беда. Как следствие - а как можно быть уверенным в себе когда тебя ни разу (или исчезающе мало) хвалили за свои действия?

Ставь 🔥 если эта проблема болит для вас - если проблема откликнулась то попробуем об этом поговорить

— Илья

Нормальный человек так на отдых не ездит😅
Но у меня свой формат «отпуска»)

— Илья

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

Недавно я две недели разбирался с архитектурной задачей для GitLab где самым сложным оказался не код.

🎥 Приятного просмотра!

Код дешевеет, решения дорожают

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

Я прокомментировал так:

Человека в наше время нужно оценивать по общей сообразительности, ответственности и честности, а знания - вторично.

Быстро писать код больше не преимущество, даже знания - не преимущество.

Компоненты и формочки, CRUDы и модельки, тесты, DTO, апишки и контроллеры, типовой рефакторинг AI делает быстро, дешево и не ленится, как люди. Качество приемлимое, джуны чаще пишут лажу, у AI уровень крепкого мидла. Если ваша главная ценность в том, что вы быстрее остальных перекладываете JSON из одного объекта в другой, то пора что-то думать.

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

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

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

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

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

— Тимур