Just a kind reminder 🤗

Сегодня ждём вас на круглом столе, посвящённому роли Тимлида.

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

Регистрацию и свои вопросы оставляйте по ссылке. Всех ждем вечером 🙌

Друзья, с пятницей 🤗

Делимся с вами записями событий этой недели:

1. В среду прошел H&S Conclave на тему Контейнеризация и CI/CD для .NET приложений с использованием Docker и Kubernetes
🎞 Запись доступна по ссылке

2. Вчера провели Круглый стол про Тимлида на проекте: как получать удовольствие от роли, приносить пользу бизнесу и не выгорать.
🎞 Смотреть на ютубе

Хорошего просмотра и классных выходных!

В чем заключается рост инженера и как опыт влияет на его мышление?

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

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

Рост Middle-разработчика – это расширение стека и углубление знаний о нем. Чем больше фреймворков и инструментов он знает, и чем лучше он ими владеет, тем выше его компетенции и ценность на рынке труда.

Для Senior-а такой подход уже не годится. Сеньор, который продолжает осваивать все новые и новые технологии, спустя какое-то время обнаруживает, что он по-прежнему сеньор и выполняет те же задачи, но с более модным стеком. Это – стеклянный потолок сеньора.

🚀 Как его пробить? Расширять технический кругозор, обобщать и систематизировать знания, подкреплять их фундаментальными законами, которые меняются медленно, в отличие от фреймворков и конкретных инструментов, – ограничения железа и сети, шаблоны распределенных систем и т.д.

Но самое главное – расширять свою зону ответственности за рамки одной фичи/задачи. А для этого, кроме hard skills, нужны и другие навыки – понимание бизнеса, умение отстаивать решения и договариваться с коллегами, руководством и другими командами.

Знания, необходимые для этого перехода, мы упаковали в программу курса [Технический Лидер]. За 3 месяца вы систематизируете уже имеющийся опыт, расширите кругозор, и на практике научитесь проектировать распределенные системы исходя из потребностей бизнеса.

Записывайтесь на бесплатную консультацию!

Привет! Как вы знаете, мы в Hard&Soft Skills занимаемся профессиональным развитием разработчиков и очень хорошо представляем, какой путь обычно проходит инженер от первой работы junior-ом до высоких позиций вроде CTO и Enterprise Architect.

🔬Мы проводим исследование, в котором хотим дополнить наши данные цифрами, и будем благодарны, если вы заполните вот этот опросник.

Кроме нашей благодарности, за участие в опросе вы получите бонусный материал “Подходы к оптимизации приложений” и закрепите за собой скидку в 5% на любой из наших курсов:

[Технический Лидер]
[из Middle в Senior]
[Team Leadership]
[Solution Architecture in the Wild]
[CTO Starter Pack]

Чтобы воспользоваться скидкой – до конца сентября оставьте заявку на сайте или запишитесь на бесплатную консультацию. Спасибо!

Друзья, мы движемся к завершению разбора книги "Designing Data-Intensive Applications" Мартина Клеппмана.

Во вторник 1 октября мы соберемся для обсуждения 11 главы "Stream Processing". Ведущим встречи будет Александр Кохно. Читайте, регистрируйтесь и приходите!

А также предлагаем вам выбрать - какую книгу будем читать и разбирать далее 👇

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

Хотим поделиться с вами несколькими такими историями и начнем с Никиты Шумилина – выпускника 9-го потока курса [Технический Лидер].

До курса:
* 12+ лет опыта
* Только что получил повышение до техлида
* Хочет систематизировать знания и закрыть пробелы в них.

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

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

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

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

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

Подробнее о курсе [Технический Лидер] читайте на сайте или записывайтесь на бесплатную консультацию.

Всем привет! Наверное вы заметили, что Архитектурных Трепов стало меньше, но очень надеемся что от этого не стали менее ценными 🤗

Приходите сегодня вечером обсуждать с Юрой Морозовым Актуальные практики и инструменты построения CI\CD. Поговорим с чего начать, чем является Continuous Integration, Continuous Deployment/Delivery, какие бывают с ними проблемы и многое другое.

Задавайте свой вопрос в форме регистрации и до встречи вечером 🙌

Что мешает разработчику расти?

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

🤕 Неумение извлекать пользу из ошибок и нежелание учиться.

🪫 Отсутствие инициативы. Doing the minimum to get by.

🤐 Слабые навыки коммуникации. Неумение отстаивать свое мнение, принимать критику, решать конфликты и обмениваться знаниями.

Это те самые soft skills, отсутствие которых препятствует росту не только в разработке, а в любой профессии и вообще в жизни. А теперь сфокусируемся на специфических проблемах инженеров:

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

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

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

А что мешало или по-прежнему мешает расти вам? Делитесь в комментариях 👇

🚀 Друзья, через час стартуем с Кабанчиком. Сегодня обсуждаем 11 главу Stream Processing. Присоединяйтесь!

Продолжаем рассказывать о наших выпускниках. Николай Яснов закончил 9-ый поток [Технического Лидера].

До курса:
* 13+ лет опыта. C#, Ruby
* Пришел в новую компанию как Senior developer
* Не хватает знаний в архитектуре, из-за чего проваливал собеседования

В начале курса я только-только получил оффер от компании. Тогда казалось, что применить эти знания получится не скоро, ведь в компании 400+ человек, процессы и архитектура уже сформированы. Плюс в новой среде почувствовал синдром самозванца.

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

Сейчас у меня закончился probation и скоро начнется рост внутри компании. Я знаю, что можно предложить и как это сделать.

Павел Вейник, Преподаватель курса, Solution Architect, Staff Engineer:

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

Подробнее о курсе [Технический Лидер] читайте на сайте или записывайтесь на бесплатную консультацию.

Синдром самозванца бывает только у настоящих специалистов, а кто я такой?

Синдром самозванца – это неспособность объективно оценивать свои способности и достижения. “Мне просто повезло”, “Это все команда, я только внес небольшой вклад”, “Если я задам глупый вопрос, все поймут, что я ничего не умею”.

Почему этот синдром так распространен в ИТ?

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

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

Я сомневаюсь при решении задачи ➡️ я ищу решение ➡️ мне повезло/я скопировал чужое решение/мне помогли ➡️ я ничего не умею/обо мне слишком хорошо думают ➡️ я еще больше сомневаюсь при решении следующей задачи

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

🏆 Признавать усилия и достижения. Вы находитесь на своей позиции не просто так. У вас есть коллеги и начальство – специалисты, обмануть которых разом невозможно. А если у вас это получилось, то, вероятно, вы гениальный актер 😉
🫵 Опираться на свою оценку. Если вам кажется, что работа сделана хорошо, и нет крепких аргументов, почему это не так, – значит работа сделана хорошо.
🏄 Относиться к работе проще. Кроме нее в жизни есть много интересного. Успехи и неудачи в работе не характеризуют вас как человека.
🗣 Пообщаться с коллегами. Общение в кругу профессионалов помогает избавиться от завышенных ожиданий от себя.

За последним пунктом приходите на наши мероприятия

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

Докладчик: Cергей Ткачев, Lead Software Engineer, 17+ лет в IT, из них 5+ лет опыта в коммерческой разработке на Java и Kotlin

Начало в 20.00 GMT+3

Регистрация по ссылке. До вечера!

Как узнать, что принимаешь правильное решение, если его последствия проявятся через год?

Работа техлида и архитектора – про принятие технических решений. Использовать ту или иную базу данных, применять тот или иной фреймворк, фокусироваться на performance или availability.

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

❗️ Каждый tradeoff и каждый выбор из нескольких альтернатив – это и есть архитектурное решение. И оно перестает быть правильным тогда, когда перестает удовлетворять потребности бизнеса.

Как сделать, чтобы это происходило реже? Архитектуру можно разделить на логическую и физическую:

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

Доменная область меняется медленно – если это ресторан, то 100% будет закупка и доставка продуктов, официанты принимают и доставляют заказы, повара готовят эти заказы в соответствии с меню. Эта логика скорее всего не изменится, и систему, которая ее обслуживает, можно сделать негибкой.

Бизнес-процессы конкретной компании менее постоянны. Это то, как принято обслуживать клиентов, какая иерархия управления, в правовом поле какой страны мы работаем. Части системы, которые сильно зависят от этих вещей, нужно делать более адаптируемыми.

⚙️ Физическая архитектура – модули и взаимодействие между ними – микросервисы, базы данных, кэши, API, фреймворки и т.д. Здесь нужно опираться на то, насколько конкретный инструмент соответствует бизнес-потребностям, и ресурсам бизнеса и команды.

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

Сложность самих решений можно представить как спектр между local и global. Нужно стремиться к тому, чтобы решения были локальными. Если в будущем окажется, что решение больше не актуально, изменить небольшую часть системы существенно проще, чем переписать все.

Научитесь принимать правильные архитектурные решения в масштабах команды или всей организации на курсах [Технический Лидер] и [Solution Architecture in the Wild]. Записывайтесь на следующий поток!

Вчера прошел четвертый H&S Conclave на тему "Минусы и оверхэды микросервисов — как с ними бороться?"

🎞 Запись доклада уже доступна на нашем ютуб канале

👉 Также хотим напомнить, что вы тоже можете стать спикером на нашем мероприятии. Заполняйте анкету на сайте и мы свяжемся с вами, чтобы обсудить формат и тему.  Публичные выступления это не только крутая прокачка софт-скиллов, но и отличная возможность выбрать тему, которая вас волнует и углубить свои знания, подготовив полезный доклад для сообщества 🙌