Хороший парень, плохой код: доброта дороже денег?
Привет, Хабр!
Сегодня о тимлидском-наболевшем. Вот представьте, образовалась перед вами дилемма: есть в команде специалист, который по человеческим качествам — просто душка, но его скорость и качество работы вызывают желание спрятаться под стол и тихонько поплакать. Как быть? Открыть курсы медитации для успокоения нервов или все-таки признать, что бизнес — это не благотворительный фонд? Предлагаю обсудить. И, чтобы было по-честному, взглянем на ситуацию с двух сторон: со стороны тимлида, который вроде как не очень хочет быть гадом распоследним и обижать хорошего человека, и со стороны разработчика, который, мягко скажем, звезд с неба не хватает. Постараемся использовать здравый смысл и не забыть о человечности.
Начнем с горькой правды. Бизнес есть бизнес, а не GitHub-репозиторий с открытым кодом (удивительно, да?). Так что придется признать очевидное: как бы ни было важно создавать дружелюбную атмосферу в команде, не стоит забывать о главной цели любого IT-бизнеса — пилить фичи, релизить продукты и, в конце концов, зарабатывать деньги! Конечно, позитивная атмосфера в коллективе важна, но еще есть такие штуки, как KPI и ROI.
Робин Гуд наоборот
Представьте, что вы — суперпонимающий, эмпатичный тимлид. У вас возникает соблазн оставить этого неэффективного разработчика просто потому, что он хороший человек. Но вот в чем загвоздка: по сути, вы будете платить ему из денег, заработанных его коллегами, теми, кто действительно выкладывается, фигачит овертаймы и вносит свой вклад в успех проекта. Такой вот странный сценарий Робина Гуда, только он отбирает у работящих, чтобы отдать… ну, не очень работящим.
Давайте начистоту: поделились бы вы своими кровно заработанными? Как бы вы себя чувствовали, если бы часть вашей заслуженной премии пошла на покрытие работы того, кто не оправдывает ожиданий? Вряд ли вы бы оценили такой подход по достоинству.
Рефакторинг или исключение?
Прежде чем принимать радикальные решения, важно пригласить разработчика на откровенный разговор. Обсудите причины его неэффективности и попытайтесь найти пути решения проблемы вместе. Возможно, ему требуется дополнительное обучение, более четкие задачи или просто поддержка и мотивация. Открытый диалог и готовность помочь могут стать ключом к повышению эффективности и сохранению ценного члена команды.
Если же это не помогло, вариантов два:
Рефакторинг. Скорректировать зарплату разработчика в соответствии с его реальным вкладом. Это может показаться жестким, но это способ сохранить справедливость и обеспечить всем соответствующее вознаграждение.
Исключение. Оно же — увольнение. Возможно, это наилучший выход как для компании, так и для самого сотрудника. Он сможет найти работу, которая лучше соответствует его навыкам, а команда — повысить свою эффективность.
Впрочем, бывают и ситуации, когда такой неэффективный сотрудник может оказаться »душой команды» — тем, кто создает позитивную атмосферу, поддерживает коллег, помогает разрешать конфликты и просто поднимает всем настроение. В таких случаях его вклад выходит за рамки выполнения задач и оказывает положительное влияние на общий психологический климат и продуктивность. Его увольнение может негативно сказаться на мотивации и сплоченности команды, поэтому важно взвесить все «за» и «против» перед принятием решения.
Вывод: найдите баланс между эмпатией и реальностью. Удерживать человека на позиции, где он не может реализовать свой потенциал, — это медвежья услуга. Важно быть человечным, но бизнес-решения (и решения тимлида) в конечном итоге должны основываться на том, что лучше для компании и ее сотрудников в целом. Если разработчик не справляется, помогите ему найти свой путь, даже если он лежит за пределами вашей компании.
Отладка карьеры
А что делать, если вы и есть тот самый неэффективный разработчик? Что если это ваш код больше похож на абстрактное искусство, а дедлайны вызывают панические атаки? Не спешите удалять свой профиль на GitHub, давайте сначала попробуем во всем разобраться.
Баг в системе: поиск причин
Признание — первый шаг к исцелению (или хотя бы к пониманию).
Первым делом нужно найти корень зла, то есть причину неэффективности. Может, вы — fullstack-разработчик, но ваш stack переполнен прокрастинацией? Тогда придется включить самоконтроль и научиться тщательно распределять время для работы и для отдыха. А как у вас дела с синтаксисом? Может, опечатки в вашем коде плодятся с такой скоростью, что позавидуют тараканы на кухне? В этом случае стоит подружиться с линтерами и статическими анализаторами. Или, допустим, вы любите все усложнять? Сбавляйте обороты, простота — залог успеха. Используйте проверенные решения и пишите понятный код, который не вызовет у коллег нервный тик.
Патчим карьеру: от багов к фичам
Разговор с тимлидом — не допрос с пристрастием, а возможность получить обратную связь.
Так вот, сначала обдумайте сами, обо что вы постоянно спотыкаетесь, а потом открыто и честно поговорите с вашим руководителем. Это вообще не страшно, тимлид — ваш союзник. Расскажите о своих трудностях, будь то прокрастинация, запутанный код или сложности с пониманием задач. Вместе вы сможете найти решение: возможно, вам нужен ментор, который поделится опытом и поможет разобраться в тонкостях разработки. А может, вам не хватает знаний в определенной области и стоит пройти дополнительное обучение или онлайн-курс. Иногда достаточно просто получить более четкие инструкции и задачи, чтобы начать двигаться к цели.
Но не ждите, что тимлид будет водить вас за ручку и решать все проблемы. Проявите инициативу. Изучайте новые технологии, участвуйте в опенсорс-проектах, посещайте митапы и конференции, общайтесь с коллегами, расширяйте свой кругозор. Покажите, что вы готовы вкладываться в свое развитие.
И, конечно, учитесь принимать критику. Воспринимайте ее не как личное оскорбление, а как возможность для роста. Внимательно выслушайте замечания тимлида и коллег, проанализируйте свои ошибки и сделайте выводы. Даже самые опытные разработчики не застрахованы от промахов, главное — уметь их исправлять и учиться на своих ошибках. И перестаньте уже бояться code review. Вас там не съедят, это лишь возможность пообщаться с коллегами и обменяться опытом.
К вышеперечисленному, пожалуй, еще стоит добавить пару моментов: документация и тесты.
Первое — это (без шуток) спасение для будущих поколений (и для вас самих через месяц). Пишите понятные комментарии, описывайте архитектуру и логику кода, чтобы потом не тратить часы на расшифровку собственных иероглифов.
Второе — это то, что поможет избежать факапов. Пишите unit-тесты, интеграционные тесты, E2E-тесты — в общем, тестируйте все, что можно протестировать, чтобы быть уверенным в качестве своего кода.
Ну и, конечно, экспериментируйте. Пробуйте новые языки, фреймворки, инструменты. Кто знает, может, вы откроете для себя новую страсть или найдете более эффективный способ решения задач.
А если все вышеперечисленное не помогло… Что ж, задумайтесь: может, вы просто не на своем месте? Возможно, стоит сменить специализацию и найти другой путь в мире разработки (или где-то еще)?
Итак, мы провели сеанс психотерапии на тему «Неэффективный разработчик», посмеялись, поплакали и, надеюсь, сделали для себя полезные выводы. Бизнес есть бизнес, а KPI и дедлайны — не пустые слова. Но даже тут есть место для человечности и взаимопонимания.
Ну, а чтобы сбить градус драматизма, предлагаю пройти шуточный тест и узнать, какой вы единорог разработчик.
Тест: «Мастер прокрастинации или повелитель багов?»
Этот тест поможет определить, кто вы в мире разработки: мастер прокрастинации и чемпион по написанию запутанного кода, или же вы все-таки иногда работаете. Отвечайте честно, ведь только так вы сможете узнать всю правду о своих навыках (или их отсутствии).
1. Какой из этих языков программирования вы считаете самым сложным?
a) Brainfuck (да, это настоящий язык!)
b) Ассемблер
c) JavaScript (шутка, ха-ха)
d) Язык моего коллеги, который пишет код, понятный только ему
2. Что вы делаете, когда сталкиваетесь с багом?
a) Гуглю ошибку, копирую первый ответ со StackOverflow и молюсь, чтобы сработало
b) Плачу
c) Обвиняю во всем библиотеки или фреймворки
d) Убеждаю себя, что это фича, а не баг
3. Как выглядит ваш рабочий стол?
a) Чистый и организованный (ну-ну…)
b) Как будто по нему прошелся ураган
c) Завален пустыми чашками из-под кофе и банками от энергетиков
d) Там живет семья пауков, и я уже дал (-а) им имена
4. Что вы делаете в первую очередь, когда приходите на работу?
a) Проверяю почту и мессенджеры
b) Открываю соцсети
c) Иду за кофе (и, возможно, не возвращаюсь)
d) Пытаюсь вспомнить, какой сегодня день недели
5. Сколько вкладок открыто в вашем браузере прямо сейчас?
a) Меньше 10 (вы точно разработчик?)
b) От 10 до 50
c) Больше 50, но меньше 100
d) Браузер уже кричит о помощи, а я открываю всё новые вкладки
6. Как вы называете свои переменные?
a) Четко и понятно, с использованием осмысленных имен
b) a, b, c, d… (иногда забываю, что значит «a»)
c) Использую имена своих бывших
d) Даю им смешные названия, чтобы хоть как-то себя развлечь
7. Что вы делаете, когда дедлайн уже горит?
a) Спокойно заканчиваю работу, ведь я всё спланировал (-а) заранее
b) Впадаю в панику и пишу код с бешеной скоростью
c) Прошу о помощи коллег
d) Начинаю искать новую работу
8. Как вы относитесь к тестированию?
a) Это важная часть процесса разработки
b) Тестирование? Не, не слышал (-а)
c) Пусть тестировщики этим занимаются
d) Надеюсь, что код заработает сам собой
9. Как часто вы делаете коммиты?
a) Регулярно, с подробным описанием изменений
b) Когда уже совсем стыдно за количество несохраненного кода
c) Раз в месяц, и то, если вспомню
d) Что такое коммиты?
10. Какая ваша любимая функция в IDE?
a) Автодополнение
b) Отладчик
c) «Найти и заменить»
d) «Копировать» и «Вставить»
Больше ответов «a»: Разработчик-единорог
Вы существуете? Серьёзно? Чистый код, организованный рабочий стол и планирование — всё это про вас. Возможно, вы тайный агент из будущего, посланный, чтобы показать нам, как надо работать. Или вы просто очень хорошо умеете притворяться.
Больше ответов «b»: Кодоборец
Вы — представитель самого распространенного вида разработчиков. Вы умеете писать код, иногда даже хороший, но не без помощи Stack Overflow и кофеина. Дедлайны — ваш вечный враг, а рабочий стол — поле битвы между порядком и хаосом. Но главное — вы не сдаетесь и продолжаете совершенствоваться (когда есть время).
Больше ответов «c»: Инженер Хаоса
Ваш девиз: «Работает? Не трогай!». Дедлайны? Пффф. Тестирование? А зачем? Вы пишете код в состоянии потока (или паники), питаетесь энергетиками и свято верите, что все баги — это фичи. Ваш рабочий стол — портал в другое измерение, а в коде черт ногу сломит. Но, как ни странно, всё как-то работает.
Больше ответов «d»: Квантовый программист
Кто вы? Откуда? И как вы вообще сюда попали? Возможно, вы — гений, который видит мир кода иначе, чем все остальные. А может, вы просто заблудились и случайно оказались за компьютером. В любом случае, ваш подход к разработке — загадка, окутанная тайной.
Независимо от результата, помните: главное — получать удовольствие от своей работы (или хотя бы от процесса её откладывания). А совершенству, как известно, нет предела!
