Ребята из MoscowPython выложили видео моего доклада о том, как мы в ГдеМатериале поддерживаем качество кода:

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

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

Тот же принцип и на работе — если вы с коллегами что-то решили, то нужно либо это сделать, либо решить заново. Сомневаться по пути — глупо: только силы потратите.

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

Этого не будет. Если такие ребята где-то и существуют, то странно, что мы нанимаем их, а не они — нас.

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

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

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

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

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

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

Это — заметка для программистов. Если вы менеджер — почитайте версию для менеджеров.

Многие ребята, выбирая инструменты для нового проекта, начинают строить длинные таблицы, сравнивая фичи. Серьёзно обсуждают, что лучше — SFC во vue ил и CSS Modules в реакте.

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

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

Искать ответы на эти вопросы поможет интуиция, reddit и Google Trends. И да, если вы выбираете фреймворк для фронтенда, то берите любой — всё равно протухнет через год.