Readability кода в Google

В Google есть интересная практика, направленная на повышение читаемости кода – readability reviews. Каждый pull request ревьюится не только связанными с конкретным компонентом людьми, но и как минимум одним экспертом в языке, на котором написан код. Эксперт в этом контексте – инженер, который хорошо знает лучшие практики конкретного языка, рекомендуемые паттерны, принятые в компании стиль кода и список библиотек.

С одной стороны, такой процесс добавляет жуткой бюрократии – вместо обсуждения действительно полезных вопросов, вы будете зарубаться с незнакомым вам человеком о том, насколько правильно названа какая-то переменная (намеренно утрированный кейс, я предполагаю, что такие вещи все-таки на уровне линтера закрываются). Но с другой стороны, в том числе благодаря этому подходу Google получает похожие друг на друга кодовые базы вне зависимости от конкретного отдела и продукта. А, значит, переход людей между проектами становится значительно проще.

🪚 Инструменты тимлида

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

✅ Таск-трекеры
Лидером оказался Todoist. Но как по мне, без разницы что использовать и вообще я цели на месяц веду снаружи, а тут операционные проекты, которые я делаю прямо сейчас.

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

📝 Заметки
Всех обошел Obsidian. Если кто не в курсе, это маркдаун-редактор с плагинами. При помощи него можно сделать собственный репозиторий знаний а-ля маленькую Википедию.

Тоже им пользуюсь, но считаю, что только для лидских задач этот инструмент – оверкилл.

Возможно вам надо вести карточки сотрудников, проекты, ну может какие-то общие мысли. Из-за того, что структура заранее известна, можно обойтись даже Apple заметками.

Еще в пуле инструментов оказались:
- Confluence. Ну а почему бы не держать доку и рабочие заметки в одной системе?
- Miro. Медитировать над организационной структурой в нем намного удобнее, чем в том же мардаун-файле. Отдельный плюс – удобство шаринга и совместной работы

🎯 Фокусировка
Часть ребят использует технику Pomodoro с фокусировкой интервалами 25-45 минут.

Приложений и физических трекеров – бесконечность.

Сам комбинирую технику с режимом “Do not disturb”. Мне помодорки помогают в двух случаях:
- Сфокусировано поработать
- Стартануть неприятное дело, которое прокрастинирую. Спустя одну-две помодорки разгоняешься и уже идет с удовольствием

✉️ Почта / мессенджеры
Планирую написать “Новейшие правила деловой переписки”. В ней будет одна страница, в которой будет капсом: не читать почту.

У нас есть корпоративный мессенджер, туда сам залезаю раз в неделю.

Я шел от идеи “если ответить на сообщение спустя час – мир не рухнет”, и вот что со мной стало… Если что, про почту наброс, туда залезаю тоже раз в неделю.

Страдают только финансовые аналитики, которые подбивают ФОТ раз в квартал и пишут письма, а когда реакции нет – пытаются догнать в корпоративном мессенджере. Но в остальных 99% случаев все работает прекрасно.

Основная переписка команд происходит в телеге. Знаю, что некоторые заводят отдельные аккаунты. Мне хватает папки.

📅 Календарь
Тут вообще скучно. День, а лучше два без встреч. Забитый час каждый день под обед.

Встречи по возможности перевожу в переписку.

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

—

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

Если есть мегатулзы неупомянутые выше, делитесь 😉

#тимлидство

Как повышать людей в корпорациях

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

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

В статье дают несколько советов, как жить в таких условиях:

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

Как помогать людям меняться

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

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

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

Знания-Ответственность-Полномочия

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

Always do Extra

Представьте, что вы делаете какую-то задачу, и она заняла у вас на 20% меньше времени, чем вы хотели на нее потратить. В этот момент у вас появляется следующая развилка:

1. Не делать ничего
2. Взять следующую задачу (doing more work в оригинальной статье)
3. Сделать текущую задачу лучше (doing extra work)

Отличие второго и третьего пункта в том, что выполнение задач на потоке – это обычная работа, то, что от вас ожидается. Выполнение extra work – возможность самому придумать цель, которая одновременно и проекту поможет, и прокачает какие-то ваши скиллы и знания. А заодно еще и поможет превысить ожидания и в каких-то случаях создать вау-эффект.

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

Self-hosted альтернативы инструментам Atlassian

Я пропустил новости про уход из России Atlassian стека. Если вас это коснулось, в статье рассказывают про альтернативы, которые можно поднять у себя на сервере.

Что использовать вместо Jira:
👉Plane
👉Redmine
👉Tuleap

Что использовать вместо Confluence:
👉Outline
👉Bookstack
👉Docuwiki

Что использовать вместо Trello:
👉Mattermost Boards
👉Logseq
👉Kanboard

Если вы можете порекомендовать другие аналоги – делитесь в комментариях!

Как построить доверие в общении

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

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

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

Как создавать дисфункции, пытаясь их устранить

Ох, какая же вредная статья! Начинается все клево – автор рассказывает про то, что на все проблемы обязательно надо смотреть системно, не бросаться тушить пожары сломя голову, а искать взаимосвязи в системах. А решение – составлять специальные Dysfunction Maps.

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

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

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

Признаки хорошей стратегии

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

А вообще, лучше всего прочитайте "Good strategy, bad strategy" Румельта. Не расскажет, как именно надо составлять стратегию, но хорошо натренирует нейроночку на то, чтобы распознавать плохую.

Как организовать one day offer event

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

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

Как ментальное состояние руководителя влияет на команду

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

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

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

Как продавать техдолг

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

Помимо этого, в статье есть еще несколько советов по продаже техдолга:

👉Обосновывая инвестиции во внутренний тулинг, сразу продумайте ответы на вопросы про ожидаемый возврат инвестиций и то, как вы будете оценивать адопшн. Можно посмотреть на фреймворк продаж MEDDIC.
👉Инвестиции в отказоустойчивость проще всего обосновать через SLO.
👉Инвестиции в переписывание кода обосновывайте через оценку того, когда вы сможете доставить результаты рефакторинга до прода, улучшение читаемости и поддерживаемости кодовой базы, экономию времени или решение проблем ближайшего будущего.

Ошибки в переговорах о зарплате

В статье разбираются две частые ошибки, их последствия и способы их избежать:

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

Проблемы лишних абстракций во фреймворках

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

Ключевая цитата: "Frustration happens when the developer is unable to use their existing skills or feels disproportionally punished for doing it their way instead of your way".