Очень давно писал про вопрос-индикатор на собеседованиях «Два раза вовремя или один раз правильно?».

Профессионала от непрофессионала отличает способность держать слово.
В разработке это чаще всего это — выдерживание сроков плюс качественный результат. Да, иногда важнее сроки, а иногда — качество (это важно выяснять заранее, если не удается обеспечить оба показателя). Но не одно без другого.

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

Если человек постоянно называет сроки, а потом они постоянно съезжают, человек — балабол (человек, дающий пустые обещания). Постоянно подводит, верить ему — нельзя.

Работать с такими не хотят. Промоутить таких не хотят. С таким работают, с отношением «так уж и быть» — просто терпят.

Почему так?
Да если до сих пор не очевидно, по тому, что на твоем слове я даю свои обещания.
А на моих обещаниях дает свое слово мой шеф. А уже на них и владелец компании.
Поэтому когда/если, это все начинает сыпаться, все бегают с «раскаленной кочергой». Потому что если не деливеришь то, что обещал — вся компания пойдет с рынка.

Короче, когда работаешь — будь молодцом!

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

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

У меня есть несколько историй.

Колян, просто Колян

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

Уволил я его тогда по правилам «учить-лечить-мочить», после того как он второй раз уехал в отпуск, не залив в репозитарий изменения, которые команда от него ждала.

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

Так что Колян делал это, еще тогда, когда это не стало мейнстримом.

Рома Звезда

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

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

Даня Халява

Даниил, молодой, талантливый студент, прошел интервью у рекрутера, у технического менеджера команды и меня на позицию Manual QA. Рассказал, что пару лет работал в беттинге, но не захотел переходить на новый проект по моральным принципам.
Очень быстро думал. Ответил на массу заковыристых вопросов, о том как тестировать финансовые приложения, великолепно разложил все корнер-кейсы по представленным примерам. Показал свой годовалый профиль на leet-code с кучей решенных задач. Порадовались, что наконец-то пришла свежая кровь (зумер!) с головой на плечах.

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

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

Денис-Тройничок

Денис — зрелый разработчик, пришел на собеседование к нам, объясняя тем, что не сработался с коллегами в каком-то НИИ. Плюс вел курсы по программированию в ВУЗе. Наше собеседование прошел на высоком уровне и достаточно легко, очень понравился команде. За месяц вкатился в сложный проект, закрыл пять задач среднего размера. А потом позвонил мне и сказал что увольняется, т. к. не вытягивает. Оказалось, что он не уволился не только с предыдущей работы, выходя к нам. Он не уволился и с еще более ранней компании, т. е. у парня было три работы! :-)

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

Из моих наблюдений, как можно выявлять людей, которые работают на двух работах

1. Необъяснимое снижение (или изначально низкий) перформанс — долгие сроки исполнения, низкое качество работы

2. Непостоянная доступность — пропадает на долгие периоды, недоступен для звонков, не отвечает на срочные вопросы, чего раньше не было

3. Нестандартное время активности и использование рабочих инструментов — раннее утро/поздний вечер/выходные/ вне рабочего времени

4. Перекрёстные чаты — ошибки пересылок сообщений, то, что должно было быть переслано в одну компанию, отправляется в другую. Или не тем людям/не в те чаты.

5. Странное поведение на созвонах — например, трудно выглядеть адекватным находясь сразу на двух коллах

6. Снижение вовлеченности — меньший интерес к проектам, избегание доп обязанностей, не участие в обсуждениях

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

Когда работа на две компании всё же может быть приемлемой и этичной

1. Если сотрудник открыто информирует обе компании о своих намерениях работать в фулл-тайм или частично в двух местах и получает разрешение от обеих. У нас было несколько случаев, когда хорошие специалисты «уходили за мечтой» в другие компании, при этом оставаясь парт-таймить у нас. И да, их новая компания была изначально в курсе этих договоренностей.

2. Фриланс или парт-тайм занятость могут быть этичными и приемлемыми если не страдает производительность. Я иногда нанимаю парт-таймить скучающих сениоров на мидловые задачи на короткой, проектной основе.

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

Чего делать с «волками» и как от них защищаться?

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

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

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

4. Использовать тайм-трекеры, просить фиксировать время работы над задачами и отслеживать активность вне рабочих часов (в рабочих чатах, таск-трекерах, репозиториях, серверах).

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

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

7. Некоторые компании ввели запрет на удаленную работу. Работать из офиса на сторонние проекты — крайне сложное мероприятие.

Последствия работы на две компании

Вообще, рисков и последствий может быть множество, как для компаний, так и для сотрудника, который выбрал совмещать работу.

— Юридические (нарушения условий договора, конфликт интересов между компаниями)
— Риски по достижению долгосрочных целей компании (если спец сфокусирован на сторонней работе, а не на интересах работодателя)
— Влияние на командную работу (коллегам, возможно, придется компенсировать недостаток вовлеченности сотрудника)
— Возможные последствия для карьеры и репутации специалиста (ладно я про них просто так написал, а мог бы и ссылки на Linkedin приложить)
— Качество жизни (может просто не остаться времени на личную жизнь, семью или отдых)
— Выгорание и стресс (в следствие невозможности поддерживать здоровый work-life balance)

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

Есть два вида ошибок.

1. Ошибки инноватора.
Когда ошибка, это обратная связь на проверку гипотезы.
«Не ошибается только тот, кто ничего не делает» — отсюда.
Здесь ошибки ожидаемы и приемлемы и должны превращаться в lessons learned.

"Failure is an option here. If things are not failing, you are not innovating enough" — Elon Musk pic.twitter.com/5tc7yGFAOd

— Curiosity (@MAstronomers) September 20, 2024

2. Ошибки плохого исполнения (Bad execution).
Например, не сданная вовремя платёжка или отчет. Не сделанный или не проверенный бекап. Там, где нет неизвестности и ожидается безупречное исполнение.
Здесь ошибки неприемлемы.

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

— Что делать?
— Выяснить причину.
— Как?
— Спросить человека напрямую!

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

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

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

Если не хочет (!) — выяснить в чем причина и найти способ чтобы сам захотел.

Вопрос со звездочкой, кстати. Что нужно, чтобы сотрудники сами хотели?

Наконец-то встретил баг на фронтенде, который привел к потерям в $$.

На скриншоте рост костов за Google Cloud Storage за одну неделю.

На одном из проектов предварительный кост за Google Cloud вырос в четыре раза.

Выяснилось: криво поставленный скрипт продуктовой аналитики на сервисе с огромным траффиком вызывал множественные повторные загрузки огромного числа файлов из Google S3.

Недавно слушал аудиокнигу “самостоятельные дети”, она начинается с очень интересного раздела про стресс.

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

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

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

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

Это очень коррелировало с теми вещами которые я до этого писал про выгорание (Burnout).

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

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

Как-нибудь я расскажу о совершенно лютом проекте, на котором весь менеджмент и команда разработки набрала в среднем +15-20 кг, заедая стресс.
Проект был крутой, с агрессивными сроками, огромным количеством фич и высокими рисками.

Полезные ссылки
Тест Бойко (Диагностика уровня эмоционального выгорания)

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

Бывает удобно, когда нужно быстро пофиксить баг и вернуться.

1. Способ через git stash

Если вы внесли изменения в вашем рабочем каталоге и хотите переключиться на другую ветку без коммита, вы можете использовать `git stash`. Это временно сохранит ваши изменения и очистит рабочий каталог.

Вот шаги:

1. Сохраните изменения с помощью stash:

git stash

2. Переключитесь на другую ветку:

git checkout [имя_ветки]

3. Если вы захотите вернуть свои изменения на текущей ветке, используйте:

git stash apply

Если у вас несколько сохраненных изменений в stash, вы можете увидеть список всех stash с помощью:

git stash list

И применить конкретный stash с помощью:

git stash apply stash@{номер}

Учтите, что `git stash apply` применяет изменения, но оставляет их в stash. Если вы хотите применить изменения и удалить их из stash, используйте:

git stash pop

2. Способ через git worktree

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

1. Добавление новой рабочей директории для другой ветки

Например, вы работаете над функцией в ветке `feature-x`, но вам также нужно срочно внести изменения в `master`.

git worktree add ../worktree-master master

Это создаст новую рабочую директорию `worktree-master`, где активной будет ветка `master`.

2. Создание новой ветки в новой рабочей директории

Если вы хотите начать работу над новой функцией и хотите, чтобы у нее была своя рабочая директория:

git worktree add ../worktree-feature-y feature-y

Если ветка `feature-y` еще не существует, она будет создана автоматически.

3. Просмотр списка рабочих директорий

git worktree list

Это покажет вам все текущие рабочие директории и их связанные ветки.

4. Удаление рабочей директории
   Если вы закончили работу в дополнительной рабочей директории и хотите ее удалить

rm -rf ../worktree-feature-y
git worktree prune

Здесь мы сначала удаляем директорию, а затем говорим Git очистить устаревшие рабочие директории с помощью команды `prune`.

3. Самый не технологичный способ: сделать клон проекта в соседней дирректории

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

1. Интересный факт, что в 12 принципах лежащих в основе Agile, пункт про техническое совершенство идет четверым с конца. Даже развернулась небольшая дискуссия в Linkedin на этот счет.

Если читать их по порядку, может сложиться представление, (в духе манифеста) что несмотря на то, что мы ценим нижние 4 пункта, верхние четыре мы ценим все-таки больше. Так ли это?

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

(попалась картинка в тему)

2. Agile Manifesto очень гибко обходит вопросы сроков и бюджетирования, так что вот два обоснованных мнения на этот счет от ChatGPT:

A. While there is value in meeting deadlines, we value technical excellence more.

By emphasizing technical quality, we ensure the foundation for resilient and adaptable solutions. A fixation on deadlines might risk the integrity and sustainability of our work. We believe that by striving for excellence today, we reduce the risk of future setbacks and rework, leading to better outcomes in the long run. Even in the face of time constraints, our commitment to quality remains paramount.

B. While there is value in technical excellence, we value meeting deadlines more.

In a rapidly evolving environment, delivering on our commitments in a timely manner ensures trust, momentum, and immediate value. Technical quality is vital, but we believe that it should not compromise our ability to meet the expectations set with our stakeholders. Balancing excellence with timeliness, we ensure both immediate impact and a foundation for continuous improvement. In our journey, the punctuality of our deliveries stands at the forefront.

На моем опыте, у бизнеса и технических команд возникает конфликт интересов в точке соблюдения сроков и обеспечения качества кодовой базы. В случае работы по итерациям, обязательство заделиверить что-то в конце спринта — это компромисс между поставкой ASAP (в интересах бизнеса) и бесконечным доведением до идеала (в интересах технических команд).

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

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

Здесь две проблемы:

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

2. Так как из скейтборда невозможно сделать самокат, а из самоката невозможно сделать велосипед, как и из велосипеда невозможно сделать автомобиль — предполагается что результаты предыдущей работы выбрасываются и новый этап начинается с нуля. Так не бывает, обычно весь импрувмент как раз и строится на основе предыдущих разработок (привет легаси!)

Мы всегда идем от автомобиля. Он должен быть самым простым, хоть как повозка на колесах, но это всегда автомобиль, на каждом шаге.
Вот правильная картинка про Agile:

Reference: Allen Houb

Наткнулся на блестящий комментарий к видео с беседой о проблемах скрам и том почему аджайл все-таки не работает. Если нет времени смотреть все 1.5 ч интервью:

Большинству компаний не нужна гибкость, им нужен водопад с высокой пропускной способностью. Они уже определились с объемом работ, сроками и ресурсами. Они просто думают, что Agile каким-то волшебным образом повысит производительность (и винят разработчиков, когда это не происходит).

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

Ссылка на хабр: 20 лет проблем приема платежей