life.developer

Метод «Википедии»

Документируй каждый косяк коллеги в корпоративном конфлюенсе/вики. Создай целый раздел «Ошибки Васи из DevOps». Добавляй скриншоты, временные метки, свидетелей. Через год у тебя будет целая энциклопедия непроверенных данных коллеги. Новые сотрудники оценят твою дотошность.

Техника «Zoom-бомбинга»

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

Стратегия «Технического долга»

Любой конфликт переводи в плоскость архитектуры. Спор о дедлайнах? «Это всё из-за легаси кода предыдущего разработчика». Проблемы в команде? «Нужен рефакторинг всех процессов».

Приём «Героического непонимания»

Получил непонятную задачу? Ни в коем случае не спрашивай сразу у автора. Минимум три дня думай, строй гипотезы, изучай код. Пиши в общий чат: «JIRA-555. Кто-нибудь понимает, о чём вообще речь?» Создавай техдолг, рефакторь смежные модули. И только когда дедлайн завтра утром – пиши аналитику в 19:00: «А можно уточнить требования?» Геройство налицо!

Метод «Фронт vs Бэк войны»

Любая ошибка в приложении, выявленная тестировщиком – повод для эпической битвы. Фронт: «По ручке приходит 500, фронт не меняли, проблема в вашем API». Бэк: «С фронта не тот параметр, локально всё корректно работает». Переписка на 50 сообщений в общем чате вместо пятиминутного созвона. В итоге виноват оказывается аналитик, который криво заполнил БД.

Приём «Дискорд-драмы»

Создавай отдельные каналы для обсуждения конфликтов. #олег-опять-косячит, #мишины-багрепорты, #почему-вася-не-отвечает. Добавляй туда всех, кроме главного героя. Пусть узнаёт о проблемах через @Here уведомления.

Метод «Code Review мести»

Блокируй все пулл-реквесты «врага» из принципа. «Тут не хватает комментария в 47-й строке», «переменная X недостаточно выразительна», «этот метод нарушает принципы SOLID». За месяц такой работы коллега научится писать идеальный код или уволится. Да и как он посмел за один коммит править менее 50 файлов?

Стратегия «Эмодзи-войны»

Общайся исключительно реакциями в чате. На предложения коллеги – 👍, на его вопросы – 🙄, на отчёты – 💩. Когда он взорвётся и напишет длинное сообщение, отвечай одним 🤷‍♂️.

Приём «Баг-репорта возмездия»

Создавай отдельную задачу в Jira на каждую мелочь. Опечатка в кнопке? Задача. Текст сдвинулся на пиксель? Критический баг. Неправильный цвет иконки? High priority! Вместо «исправь букву в слове» пиши подробный баг-репорт с шагами воспроизведения и скриншотами.

Тактика «Git-археологии»

Копайся в истории коммитов коллеги за последние два года. «А помнишь, как ты в 2022-м писал это говно?», «Вот твой коммит от марта – там та же ошибка». Превращай каждый code-review в расследование прошлых грехов.

Приём «Стендап-киллера»

На дейликах задавай коллеге «уточняющие» вопросы на 15 минут. «Я ничего не понял», «Покажи на своём экране», «А можешь подробнее про блокеры?». А если надо решить любой вопрос – зови всех в голос, всю команду из 20 человек.

Стратегия «Dependency hell»

Обновляй зависимости в общих проектах без предупреждения. Зачем кому-то знать о твоих планах? Пусть лучше за собой следят.

Техника «Документация-призрак»

Зачем создавать подробную документацию в README? Кому надо и так всё знает. А новичкам здесь не рады. Комментарии пишут только те, у кого память плохая, а у тебя всё и так в голове. Только бы не уходить в отпуск…

Стратегия «Публичного позора»

Выкладывай скриншоты переписки с коллегами в LinkedIn или Пикабу. «Посмотрите, как со мной общается тимлид», «Вот так у нас принимают код», «Ну не дура ли?». Добавляй хештеги #токсичнаяIT #плохойменеджмент #ColdplayGate. Пусть вся индустрия знает, какие у тебя нерадивые коллеги.

Метод «Биоритм-анархиста»

Если ты жаворонок или «биг босс» – планируй все важные встречи на 18:00. Сова? Настаивай на дейлике в 8 утра. «У меня пик продуктивности именно в это время». Пусть остальные подстраиваются под твой уникальный режим.

Стратегия «Собеседование саботажа»

Опаздывай на 10 минут без предупреждения. Сиди в телефоне, пока кандидат рассказывает о себе. Задавай вопросы не по теме: «Расскажите, что означает каждая буква в SOLID?» Потом жалуйся, что хороших разработчиков не найти. «Молодёжь пошла не та, не хотят работать».

Техника «Пятничного релиза»

Выкатывай в продакшн в 18:00 пятницы. Пусть пользователи сами разберутся с новыми багами. А если что-то упадёт – дежурный разработчик потренируется в стрессоустойчивости. Особенно эффектно перед Новым Годом, когда решаете всё же выкатить долгожданный релиз в этом году.

Удачи в карьере и меньше багов под килем!

Недавно на работе разгорелся жаркий спор. Двое наших разработчиков сцепились из-за выбора библиотеки для работы с датами в монорепе на js. Один был фанатом Luxon, утверждая, что она идеально подходит для сложных задач с датами и временем. Второй клялся, что Date-fns – в это лучший выбор, потому что она лёгкая, быстрая и позволяет использовать только нужные функции, не раздувая проект.

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

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

Разрешение конфликта

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

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

В таких случаях я обычно:

• Развожу спорщиков по разным проектам

• Или принимаю сам решение какую технологию использовать далее

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

Мотивация-шмотивация

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

1. Деньги-деньги, решают многое. Сюда же незапланированные премии.

2. Повышение должности сотрудника (иногда даже без повышения зарплаты, не везде корректно настроены грейды). Был «разработчик», стал «Ведущий разработчик», потом «Старший разработчик» и т.д.

3. Обновляешь ноутбук работнику. Иногда для сотрудника это долгожданное обновление, и это очень повышает его мотивацию и лояльность к компании (ну или к тому, кто её выбил).

4. Про лишние дни отдыха тоже понятно.

5. Оплата билетов на конференции по IT-тематике (а они не всем по карману сейчас), покупка лицензий на удобный софт.

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

Этих пунктов может быть ещё очень много, везде индивидуально.

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

Если есть чем поделиться, как вас мотивировали - прошу в комментарии.

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

Кстати, термин «servant leadership» ввёл в 1970-х годах Роберт Гринлиф в своём эссе «Слуга как лидер». Он работал топ-менеджером в AT&T, и я понял то же, что и он, только спустя полвека.

Статья – чисто моё мнение и видение ситуации исходя из опыта. В роли тимлида я руководил различными командами: от 1 разработчика до группы из 20 человек (разработчики, тестеры, аналитики).

НАЧАЛО ПУТИ: ОТ ОДНОГО РАЗРАБА ДО ДВАДЦАТИ

Когда я дорос до тимлида, я попал в классическую ловушку. Думал: «Ну всё, теперь я главный, буду раздавать указания и следить за их выполнением». Но реалии были таковыми, что выполнять задачи – это полдела, а вот делать их эффективно – это надо попотеть и примерить на себя роли психолога, «старшего товарища» и лидера, которому доверяют коллеги, кто может свободно общаться с начальством о нуждах команды. По сути, такое связующее звено между эффективной командой и заказчиками. Это и есть суть servant leadership – служить команде, а не командовать ею.

Эту-то эффективность и надо выстраивать тимлиду, приводя команду к максимальной точке эффективности. Микроменеджмент долой!

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

АВТОМАТИЗАЦИЯ РУТИНЫ

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

Дальше берусь за GitLab (а в основном его сейчас используют) – включил линковку задач Jira с MR, проверки code style (линтер + SonarQube), запуск тестов. Также, MR проверяется в полуавтоматическом режиме с помощью AI.

Для тестировщиков будет удобным настроить систему логирования ошибок в проде – Sentry.

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

Таким образом, команда получила больше времени на то, что действительно важно – на написание кода. И, хочу заметить, что всё это должен проконтролировать тимлид (ну и техлид, если имеется).

ЗАЩИТА КОМАНДЫ ОТ НАЧАЛЬСТВА

Отдельная история – это утилиты для сбора статистики по работе сотрудников. Начальство любит цифры, и мы их должны предоставить. Вместо того, чтобы заставлять разработчиков писать отчёты – обычно автоматизируются выгрузки отчётов о закрытых задачах, времени их выполнения в разрезе по каждому разработчику. Всё это можно настроить через Jira API, либо платные плагины. Получилось «два в одном»: менеджмент доволен красивыми графиками, а команда не отвлекается на отчётность.

РИТУАЛЫ БЕЗ ФАНАТИЗМА

Насчёт стандартного набора тимлида: дейлики, ретро, планирование с Planning Poker. Главное – не переусердствовать. Всё для команды, а не команда для процессов. Если какая-то практика не работает, меняем или убираем.

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

Также хорошей практикой будет совместный поход в бар/квест с коллегами.

SCRUMBAN КАК КОМПРОМИСС

Насчёт методологий – никто в чистом виде их не использует. Обычно в моей практике получается так называемый Scrumban – помесь Scrum и Kanban. Почему? Потому что чистый Scrum слишком жёсткий для фронтенда (особенно когда постоянно прилетают «горящие» задачи), а чистый Kanban не особо предназначен для планирования.

Scrumban даёт гибкость Kanban с планированием из Scrum. Команда может быстро реагировать на изменения, но при этом не теряет фокус на основных целях спринта.

ВСЁ ВЫШЕ И ВЫШЕ И ВЫШЕ…

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

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

Разбор ошибок с командой – всё это делается на общих встречах, а частные проблемы разбираются один на один (не при всех).

ПОЧЕМУ ЭТО РАБОТАЕТ

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

Плюс, такой подход снимает множество конфликтов. Команда понимает, что тимлид – это не «надсмотрщик», а партнёр, который помогает решать проблемы и защитит, если необходимо.

ЗАКЛЮЧЕНИЕ

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

Servant leadership – это не про мягкотелость или попустительство. Это про создание условий для максимальной продуктивности команды. И да, иногда приходится быть жёстким – но всегда в интересах команды, а не для демонстрации власти.

Если ты ещё не в деле – попробуй этот подход. Возможно, твоя команда станет не только эффективнее, но и счастливее. А счастливые разработчики пишут лучший код.

PS: Я не описал здесь про решение конфликтных ситуаций, но это тоже надо уметь делать деликатно. О чём будет одна из последующих статей.

Эту и другие мои статьи можно всегда обсудить тут «Life Developer. Статьи»

Привет! Хочу поделиться открытием, которое изменило моё отношение к работе. Оказывается, моя «странная» привычка отвлекаться на что-то фоном – вроде фильмов, серфинга по статьям или похода на кухню за кофе – на самом деле имеет научное обоснование. Возможно, далее ты узнаешь и себя.

ЧУТЬ ПОЯСНЕНИЯ

«Когнитивная недогрузка» – состояние, когда мозг получает недостаточно стимулов для полной загрузки. Исследования* показали: когда нам скучно, мозг начинает искать дополнительные источники информации. То есть чем больше ты погружаешься в задачу – тем сложнее уже тормозить во время вынужденных пауз и твой мозг «ищет топливо» для дальнейшей эффективной работы без остановки.

У программистов это особенно выражено. Запустил сборку – сиди «тупи» 3 минуты. Отправил вопрос в рабочий чат – ждёшь ответ. Думаешь над архитектурой – процесс небыстрый. В эти моменты часть мозга «простаивает» и требует загрузки.

МОЙ СЛУЧАЙ

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

Сначала думал, что это просто плохая привычка. Потом прочитал про когнитивную недогрузку и понял – это особенность работы моего мозга. Это объясняется нехваткой дофамина: мозг ищет дополнительные источники стимуляции. Дефицит дофамина затрудняет сосредоточение на рутинных задачах и приводит к быстрой потере интереса.

КАК ПРОЯВЛЯЕТСЯ У МЕНЯ

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

Из-за этого, кстати, уже было недовольство начальства, когда приходилось работать в офисе. Со стороны кажется, что моё основное занятие за компом – это просмотр фильмов, хоть это совсем и не так. Тем более, что результаты работы, наоборот, были одни из лучших.

КАК НА СЧЁТ МУЗЫКИ?

Хороший вопрос. Пробовал музыку – не то. Мне нужен именно визуальный ряд, чтобы занять «простаивающую» часть мозга. Плюс, с YouTube я могу параллельно что-то новое узнать из последних тенденций IT в мире (привет TED).

ЧТО ГОВОРИТ НАУКА

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

Кто-то крутит спиннер, кто-то жуёт жвачку, кто-то листает соцсети. Главное – найти свой способ «догрузить» мозг, не мешая основной работе.

* см. работу «Malleable attentional resources theory» от Young & Stanton, 2002г.

А как ты справляешься с паузами в работе?  Что делаешь, пока ждёшь компиляцию кода?

Эту и другие мои статьи можно всегда обсудить тут «Life Developer. Статьи»

ГОДЫ СТРАНСТВИЙ

Дальше понеслось: десктопные приложения на C# WPF, перехват хуков Windows API, бэкенд, фронтенд, базы данных – что угодно, лишь бы работало. С упоением ждал новых версий технологий, чтобы попробовать их новые фишки.  PostgreSQL, MSSQL, MySQL, Redis, MongoDB – всё перепробовал. Параллельно с этим хочешь не хочешь, но изучаешь, как не только «переустановить винду», но и поднять с нуля БД, что прописать в реестр и как создать сервер для сайта. Был универсальным солдатом: утром фиксишь баг в API, днём рисуешь новую форму на фронте, вечером оптимизируешь запросы к базе.

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

КАРЬЕРНЫЕ КАЧЕЛИ

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

Тимлид – это когда ты должен быть на связи 24/7. Суббота, воскресенье, утро 1 января – не важно. «Можешь быстро посмотреть?», «А как ты думаешь?», «А почему не работает?». И вроде бы статус высокий, зарплата больше но кайфа от работы меньше. Да, ты как небольшой руководитель стараешься всё автоматизировать, все процессы работы твоих сотрудников – от Jira правил до автопроверки кода и выкладки Docker-контейнеров на стенд. Но при этом теряешь контроль над самым важным элементом – кодом проекта.

ПРОЗРЕНИЕ

И тут до меня дошло: я программист, чёрт возьми! Мне больше нравится решать задачи кодом, а не людьми. Мне нравится видеть, как оживает интерфейс, как оптимизированный алгоритм работает в разы быстрее. Мне НЕ нравится объяснять в пятый раз, почему нужно не просто «добавить кнопочку» из задачи, а и предугадать к чему это добавление может привести (в том числе намёк в сторону тестов кода).

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

ВЫВОД

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

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

Парень ушёл в глубокое погружение. Через неделю он не просто решил задачу – он подготовил презентацию, где объяснил всю цепочку от клика пользователя до рендера компонента. И знаешь что? Я сам узнал пару новых моментов.

Оказалось, когда готовишься объяснить что-то другому, мозг включается в режим "а точно ли я это понимаю?". Начинаешь копать глубже, искать логику там, где раньше просто запомнил как шаблон.

«Эффект Фейнмана» в действии

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

И что ты думаешь? Команда стала прокачиваться и задачки стали закрываться ещё быстрее? Нет! Но мы стали работать на одной волне (в разрезе технологий). Каждый стал применять новые знания в своей части проекта (а не по одиночке) и код проектов стал структурированнее, а задачи выполняться качественнее.

Почему это работает

Дело в том, что наш мозг – ленивая штука. Он отлично умеет создавать иллюзию понимания. Читаешь документацию, киваешь: "Да, логично". А потом садишься объяснять коллеге и понимаешь, что у тебя в голове каша. А такое даже часто всплывает на собеседованиях, когда ты уже с пелёнок используешь технологию, а как объяснить это – теряешься.

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

Практический совет

Не жди, пока станешь 100% гуру в технологии. Изучил основы – поделись с джунами. Разобрался с новой фичей – расскажи коллегам. Даже если знаешь тему на 60%, объяснение поможет тебе самому разобраться ещё больше в этой технологии.

Заключение

Самое интересное, что этот принцип работает везде, не только в IT. Хочешь лучше понять архитектуру приложения? Объясни ее новичку. Изучаешь новый фреймворк? Напиши туториал.

Преподавание – это не про то, что ты уже знаешь. Это про то, что ты узнаёшь в процессе. Ну и ещё это отличный способ прокачать свои soft skills.

Не стесняйся делиться знаниями! Твой мозг скажет тебе спасибо, а коллеги – спасибо за лишний час без работы. Удачи!