Разработка стратегии развития разработчиков — это сложный, но необходимый процесс, который требует внимательного подхода к каждому члену команды. Тимлиду важно не только заинтересоваться развитием кадров, но и активно участвовать в этом процессе, делегируя обучение, если необходимо. Учитывая индивидуальные и организационные потребности, а также особенности каждого разработчика, можно создать эффективную стратегию, которая поможет компании достичь своих целей и обеспечить рост сотрудников. Еженедельные встречи тет-а-тет помогут своевременно корректировать курс и адаптировать подход к развитию в зависимости от конкретных потребностей и обстоятельств.

#стратегияРазвития #коммуникация #команда

Сложности тимлидерства: личностное и карьерное развитие

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

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

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

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

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

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

Список обязанностей тимлида:

1. Делегирование и контроль выполнения задач

2. Кодревью и поддержание стандартов кодирования

3. Обучение и менторинг команды

4. Планирование спринтов и управление задачами

5. Управление командной динамикой и решение конфликтов

6. Коммуникация и представление команды перед стейкхолдерами

7. Управление техническим долгом и качеством кода

8. Мотивация команды

9. Анализ производительности и отчетность

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

Ранее мы говорили про эмоциональную составляющую при постановке целей, и это вызвало некоторое недоумение в комментариях.
❓ Важно понимать: эмоции играют ключевую роль в управлении командой. 😌

🔸 Пример: Одной лишь эмпатией можно сделать общение, постановку задач и проверку кода более человечными. Это помогает создать приятную атмосферу и добиться большей вовлеченности команды. 📈 Эмпатия, правильная интонация и уважительное отношение к мнению каждого сотрудника позволяют значительно улучшить взаимодействие внутри команды.

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

🎯 Вывод: Мы, как разработчики, понимаем, что выучить синтаксис языка программирования — это лишь верхушка айсберга. Для эффективной работы нужны и знания архитектуры, алгоритмов, серверов — всего того, чего нет в обучающих книгах по языкам программирования. Так и здесь — психология общения, как ты говоришь, как к тебе относятся — это критически важные навыки для тимлида, но к сожалению этого нет в основном багаже знаний. Это берется из житейского опыта, навыков коммуникации и еще других не связанных с работой областей.

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

#Психология #УправлениеКомандой #Эмпатия #Эмоции #Программирование #Тимлид

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

Читаю "Deep Work" Кэла Ньюпорта 📖

Я удивлен, что в книге Deep Work Кэл Ньюпорт основной упор делает на борьбу с электронной почтой и отвлекающими письмами, хотя на борьбу с социальными сетями он написал отдельную книгу Digital Minimalism. Однако, Кэл называет глубокую работу экономическим преимуществом 21 века. 📊

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

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

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

#DeepWork #CalNewport #ГлубокаяРабота #Продуктивность #Фокус #Эффективность #DigitalMinimalism

Перекос навыков тимлида и что с этим делать 🚀

Я уже говорил об этом в предыдущем посте, и повторюсь: перекос в одну из областей навыков может стать причиной для изменений. ⚖️ Может быть, вам нравится учить, делать код-ревью, или просто программировать. Если вам и вашему работодателю комфортно с вашими «хотелками», вы продолжаете работать вместе. Если нет — начинаются трения, проблемы, буллинг, и возникают мысли о смене работы.

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

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

🙋‍♂️ Но вот в чём дело: бизнесу, конечно, удобно, что вы делаете свою текущую работу хорошо. Но как только вы начинаете думать о том, что вам действительно нравится, это работает на пользу и вам, и бизнесу. 📈 Если вы хотите расти в сторону менеджмента — отлично, это выгодно для бизнеса. Но если вы, например, увлечены разработкой ядра Linux или обожаете оптимизировать алгоритмы, это тоже ваш путь к успеху. ✨

Представьте: вы нашли место, где вашу любовь к оптимизации и пространственной/временной сложности считают ценным навыком — бизнес тоже будет в восторге от ваших решений. 🧠 А если вы решите развиваться в управлении — это также пойдёт на пользу как вам, так и бизнесу, который получит сильного лидера. 💼 В итоге, независимо от того, что вам нравится — программирование, алгоритмы или менеджмент, важно, чтобы ваш путь приносил выгоду вам в первую очередь. А затем и бизнес вас полюбит. ❤️

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

#НавыкиТимлида #КарьерныйРост #ПерекосНавыков #СофтСкиллы #ХардСкиллы #Менеджмент #Баланс

Эффективная коммуникация: избегая ловушек недопонимания 🧩

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

"Эффект испорченного телефона" — так я называю ситуацию, когда моя идея проходит через несколько фильтров и в итоге искажается. Чтобы этого избежать, я стараюсь максимально четко формулировать задачи для своей команды C++ разработчиков.

Почему это важно? Потому что:

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

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

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

Сначала может показаться, что детальное описание задачи занимает слишком много времени. Но с опытом это становится естественной частью процесса лидерства в IT. 🏆

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

#Тимлид #УправлениеКомандой #C++ #ЭффективнаяКоммуникация

Если вы хотите управлять командой так, чтобы программисты с удовольствием пожали вам руку, а заказчик был доволен результатом, важно выбрать подходящую стратегию управления. Эта стратегия должна быть не просто набором инструментов или техник, а отражением ваших целей и ценностей как лидера.
Когда я думаю об управлении, мне вспоминаются книги вроде тех, что пишет Фридман. Но я не представляю себя на месте жёсткого управленца, который завтра увольняет кого-то или требует переделки работы в экстренном порядке. Да, я замечаю ошибки в коде, вижу, где кто-то что-то упустил, но моя цель не в том, чтобы загнать команду в угол.
Я не топ-менеджер и даже не совсем обычный менеджер. Для меня важно создать условия, в которых каждый сотрудник может раскрыть свой потенциал. Одному нужно время подумать над задачей, другому — пространство без моего постоянного контроля, потому что он держит на себе половину проекта. Третий, хоть и пришёл недавно, уже исправил взаимодействия между слоями приложения, что требует серьёзной вовлечённости.
Если начать гнать их, выстраивать жесткие дедлайны и превращать команду в армию обезьян, разве не перегорят они к послезавтра? Руководство — это баланс между результатом и поддержкой команды, между требованиями и доверием. Управлять значит не просто контролировать, но и помогать каждому в команде чувствовать себя нужным и ценным.
#Тимлид #УправлениеКомандой #Баланс #Менеджмент

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

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

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

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

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

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

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

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

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

#Баланс #стратегияРазвития #Выгорание #ВераВСебя

Что бесит в IT? Давайте обсудим!
Привет, друзья!
Сегодня хочу поднять тему, которая наверняка близка каждому, кто работает или интересуется IT. Часто в нашей сфере накопилось столько моментов, которые выводят из себя: бесконечные совещания, бюрократические проволочки, неинтуитивные системы, а иногда и неожиданные баги, которые портят весь день.
Что именно раздражает вас в IT?
Может, это постоянные изменения в технологиях? Кого-то бесит плохой код.
Или бесконечные митинги и отчёты, отнимающие время на реальную работу?
А что насчёт сложных процессов внутри компании, когда кажется, что правила постоянно меняются без объяснения причин?
Поделитесь своими историями и мыслями в комментариях! Ваш опыт может не только стать поводом для обсуждения, но и помочь найти пути для улучшения нашей ежедневной работы.
Давайте вместе сделаем IT-сферу чуточку комфортнее и эффективнее!
Жду ваших откликов!

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

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


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

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

Я понял это после одного случая… Мне попался баг в котором только одна ветвь программы работала всегда, а другая почему-то нет. У меня две платформы: x86 и arm. На x86 было все работало как часы, а на arm баг воспроизводился. Я убил день на то, чтобы его исправить. И потом случайно увидел, что в начале метода bool ничем не инициализируется. И почему-то на arm это инициализировалось мусором, получалось true. Я в отладчике только заметил это под конец дня. Это было печально.

Но самое досадное оказалось, когда после запуска clang-tidy подчеркнул эту строку.

А ты пользуешься статическим анализом? Или “надеешься на лучшее”?

Как я пытался понять, что делает Qt Creator через SSH и почему это было больно, но интересно

Ситуация простая.

Qt Creator собирает проект не локально, а на отдельной build-машине и оттуда достает готовые файлы. Всё через SSH.
Нажал кнопку — и готово.
Только я больше не хочу делать это вслепую. Нужно собрать скрипт для раннера, чтобы запускать svace.

Мне нужно было понять: что именно он отправляет на машину? Какие команды, какие флаги, и как?
Причина — банальна.
Нужно встроить в билд шаг svace и отправлять на анализ. Локально всё чисто. На удалёнке — туман.
А qtCreator — не особо болтлив.

Как я это решал:

Первая идея
Поставить strace:
strace -s 512 -ff -e trace=open,openat,execve
Запустил Creator через него.
Посыпались системные вызовы. Что-то явно происходило и вызывалось. Но в какой то момент я понял, что так мне не найти команды ssh.
Не поймал суть.

Вторая идея
Включил консольный вывод самого Qt Creator (у всех qt программ можно управлять псевдонимами вывода).
Пустота. Там не логируется ssh адаптер.

Дальше — tcpdump.
Но SSH — зашифрован и есть IdentityFile. Пакеты ловятся, но смысла в них — ноль.
А мне нужно было понять, что он реально делает, а не просто "куда-то идёт".

Осталась мысль про mitmproxy.
Где-то читал, что ssh можно через прокси настроить в qtcreator .
Если бы получилось — можно было бы смотреть логи общения.
Пока не сделал.

И последняя, отчаяннаямысль:
Исходники Qt Creator. Или — ghidra/IDA.
Патчить его поведение. Переопределить аргументы, с которыми он запускает ssh, добавить -vvv.
Такое уже делал с библиотекой которая в qDebug() сыпала мусором. Я просто nop (not an operation) покрыл эти места и пропатчил либу.

На крайний случай — просто пересобрать с нужными debug-выводами.

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

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

А как бы действовали вы?
Есть способы проще? Или тоже лезете во внутренности, если нужно?

Буду рад любым дерзким, или скучным идеям!

Что на самом деле делает руководителя эффективным: взгляд Щедровицкого.
Введение к серии постов по лекциям Г. П. Щедровицкого Оргуправленческое мышление.
#книги #щедровицкий

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

Георгий Петрович Щедровицкий — философ и методолог, один из первых в СССР, кто попытался описать управление не через иерархию, а через мышление. Его лекции — это попытка понять, как мыслит руководитель, и что отличает управленца от исполнителя.

📘 Его книга «Оргуправленческое мышление: идеология, методология, технология» — это не учебник и не инструкция. Это стенограмма курса, который Щедровицкий читал для управленцев в Минатоме в начале 80-х. Его стиль — сложный, живой, временами резкий. Но каждое рассуждение выводит к практическим вопросам: кто управляет, зачем и как?

Вот несколько причин, почему к этой книге стоит вернуться именно сегодня:

🔹 1. Процедура вступления в должность
Щедровицкий показывает, как от первых шагов нового руководителя зависит логика всей его последующей работы. Это не бюрократическая формальность — это акт мышления.
«Процедура вступления в должность — не формальность.
От того, как вы выстраиваете первые шаги, зависит вся логика управления. Не цепочка решений, а цепочка смыслов.»

🔹 2. Понятийный аппарат
В книге разбираются ключевые управленческие понятия: «цель», «проблема», «деятельность», «объект». Они заданы не формально, а как рабочие инструменты мышления.

«Если вы думаете, что просто ставите задачу — вы уже в мышлении.
Вопрос — какого уровня и масштаба?»

🔹 3. Проектная логика
Мышление — это инструмент сборки команды. Вопрос не «кто что делает», а какую структуру мышления вы создаёте между людьми. Курс особенно актуален для тех, кто собирает проектные команды или работает в изменяющихся условиях. Щедровицкий задаёт вопросы, которые обычно не ставят — но без которых система не собирается.

🔹 Системный подход. Управление как система
Управление — это не серия решений. Это мышление, которое удерживает противоречия и приводит разнородное к целому.

«Система управления не может быть проще той системы, которую она управляет.»
Это базовая логика Щедровицкого — и причина, почему он до сих пор цитируется в МВА-программах.


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

📚 Книга написана живым разговорным языком — это стенограмма лекций.
В этих постах получится передать только небольшую сухую часть идей — тезисы, фрагменты. Но основное — примеры, схемы, логика развёртывания мыслей — остаются в книге.
Если вас зацепит хотя бы один пост — найдите издание, возьмите на ЛитРес, или просто зайдите в библиотеку. Эти лекции точно стоят времени.


🗂 Поэтому:
☑️ Либо найдите печатное издание.
☑️ Либо оформите бесплатный доступ через ЛитРес по читательскому билету.
☑️ Либо отложите посты, но потом обязательно прочтите оригинал.


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

Услышал фразу:

Ты не можешь управлять штормом, но ты можешь настроить паруса.

Захотелось ее слышать во варианте:

Ты не можешь управлять штормом, если это не webstorm, или другое ПО jetbrains