Maxim89
@Maxim89
Scala developer, Docker fan

Что делать когда коллеги уровнем ниже?

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

Как бы вы пытались выйти из этой ситуации?
Как мне кажется самое простое решение это найти другое место работы и оставить проект на растерзание, но это уход от проблемы, а не ее решение. К тому же на новой работе может быть такая же ситуация.
Буду рад услышать ваш опыт, советы.
  • Вопрос задан
  • 4425 просмотров
Пригласить эксперта
Ответы на вопрос 19
@amambaru
Кто сказал что они ниже уровнем?
Эффект Даннинга — Крюгера
Программеру всегда трудно вникнуть в чужой код - это не зависит от квалификации того, кто кодировал.
Возможно что даже и они более квалифицированы - просто давным-давно забили на перфекционизм, а из вас он еще прет из за юнешеского максимализма.
А может и вы правы.

Тут дело не в квалификации, а в мотивации и организации процесса.
Скажем, мне доводилось работать в команде, где в git пропускали всего по 200 строчек изменений за раз. И эти строчки обязательно должны были пройти через стандартизованное форматирование и линтеры (статические анализаторы) - иначе их git выплевывал. Это вынуждало программистов писать более менее приемлимо - коллег код меньше раздражал.
Ответ написан
Mesuti
@Mesuti
Senior HTML developer (c)
Что делать когда коллеги уровнем ниже?
1. Не зазнаваться. На каждого умного найдется еще умнее.
2. Если кривые программисты подставляют тебя и мешают работать- поговори с руководством, типа не могу с ними и выделите независимую зону работы.
3. Если хотите что-то поправить у программиста, обсудите с ним, объясните почему так будет лучше. Возможно Вы просто правите и коллега расценивает это как вторжение и унижение его профессионализма.
\\\
Мне кажется проблема не в уровне знаний, в организации работы.
Ответ написан
mitaichik
@mitaichik
Сталкивался с таким 2 раза. Оба раза пытался объяснить, донести, книги приносил, лекции читал. В ответ - то же самое что и у вас - агрессия, не понимание, безразличие. Оба раза на долго в таких компания не задерживался.

Мои выводы таковы. Во первых - принять тот факт, что в любой профессии, имхо, 1% гениев, 5-10% процентов профессионалов (тех кто реально увлечен, повышает свои навыки, читает тонны книг, изучает новые технологии), для остальных - это не более чем работа.

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

Что касается попыток исправить ситуацию : Необходимо вводить общепринятые практики - ввод стандартов кодирования, написание тех документации, вывод каких-то общих компонентов в либы, заставлять сотрудников выступать перед коллективном с лекциями по различным аспектам программирования (что сами разобрались в вопросе), код-ревью, CI и прочее. Необходимо чтоб они сталкивались с хорошим кодом, и видели что их работу можно сделать гораздо проще.
Но главное - инициатива должна исходить от тимлида (хотя это не гарантия успеха). Если хотите - попробуйте убедить его в необходимости перемен. Но если он сам этого не осознает - дело труба, особенно если вы новичок в коллективе.

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

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

Но самый главный вопрос в вашей ситуации - зачем вам все это? Незря же есть поговорка: умный в гору не пойдет - умный гору обойдет. Скорее всего, у вас ничего не получиться (особенно если коллектив состоявшийся). Если думаете что есть шанс получить какой-то профит (стать тим-лидом, получить овердофига к зарплате) - можно. Но скорее всего вас просто пошлют куда подальше, ваша лояльность к компании исчезнет, и в итоге вы уволитесь. Не лучше ли сразу уйти в компанию своего уровня? Вы пишете что это не решение проблемы а уход от нее. Но нужно понимать что это не ваша проблема. А решать чужие проблемы часто выходит себе дороже.
Ответ написан
uvelichitel
@uvelichitel
habrahabr.ru/users/uvelichitel
Что делать когда коллеги уровнем ниже?

Блистать
Ответ написан
@McBernar
Если вы их руководитель и объективно более опытный, чем они — что мешает вам их заменить на других людей?
Ответ написан
drno-reg
@drno-reg
см не кратко
могу уверенно сказать, что это проблема воспроизводиться не только в группах людей, которые занимаются разработкой. Очень часто наблюдаю, раньше почему-то этого не видел, как коллеги работая в одном и том же подразделении начинают пытаться учить других как делать. На мой взгляд здесь две стороны медали, первая - когда тот кого ты пытаешься образумить ничего не хочет менять, потому что ваше обучение выводит его из зоны комфорта и он всячески пытается вернуться обратно, вторая сторона как вы пытаетесь подать что-то новое, если с позиции - твой уровень ниже и смотри как это нужно делать, то реакция их понятна. На мой взгляд если вы не занимаете уровень лидера этой команды, то вы рискуете стать белой вороной и в конечном итоге если не найдете поддержки так все и останется в лучшем случае в худшем будет спровоцирован конфликт и команда "дружно" исключит нарушителя зоны комфорта. Можно попытаться конечно занять роль информационного лидера и тогда команда будет обращаться к вам сама за советами а как и что лучше сделать, НО тут есть другая сторона - кто везет на том и едут. В общем есть конечно еще вариант о котором писали другие - стать их руководителем официально и навести порядок как вы считаете нужным.
Ответ написан
Sanes
@Sanes
!
Работать и не душу терзать переживаниями. Это же работа, а не клуб по интересам.
Ответ написан
Jump
@Jump
Системный администратор со стажем.
А проблема есть вообще?

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

Другое дело, когда это создает проблемы компании, снижается эффективность - тогда нужно брать грамотного руководителя, который нормально поставит рабочий процесс и будет мотивировать соблюдать стандарты.
Ответ написан
Bandicoot
@Bandicoot
Backend-разработчик (PHP)
Лучше уйти оттуда, работа с более слабыми сделает вас слабее. Нужно напротив, самому быть слабым игроком в команде
Ответ написан
@nick32
Валите от туда. У сильных колег всегда можно чему-то научится, а это никогда не будет лишним.
Ответ написан
@AnneSmith
самая ленивая
зависит от условий работы: если зарплата и остальные бенефиты вас устраивают, то можно постепенно взять командование парадом на себя, в результате или вы зарекомендуете себя как более квалифицированного профессионала и получите повышение или получите полезный опыт, чтобы претендовать на более высокие позиции в других компаниях

используйте их, чтобы потренировать свои лидерские качества
Ответ написан
@asd111
Если я правильно понимаю то речь идет не столько о внешнем оформлении кода сколько о том как именовать функции и переменные и как распределить код с точки зрения ООП ?

Вам нужно составить code style guide и в нём описать правила оформления кода как вы их видите, включая примеры названий переменных и функций(например мне нравится under_score. а другим CamelCase) и примеры плохого кода из вашего проекта на ваш взгляд.

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

Code style guide это довольно распространенная практика например вот набор code style guide от google для разных языков https://github.com/google/styleguide
Ответ написан
@d-stream
Готовые решения - не подаю, но...
Как мне кажется самое простое решение это найти другое место работы и оставить проект на растерзание, но это уход от проблемы, а не ее решение
В мире и интернете всегда кто-нибудь неправ. Но это совсем не повод не спать =)
Ответ написан
begemot_sun
@begemot_sun
Программист в душе.
Выход: стать главным и диктовать им свои условия. Но только тут есть другая проблема, кто-то из них может стать главным, тогда для вас будет "привет болото".
Если вы имете уже главного, то стоит ему объяснить почему тут плохо, а почему у вас хорошо.
Не поймет. Хз что делать.

Что делать когда коллеги уровнем ниже? - я там тоже самое по моему написал.
Ответ написан
Стать главным над ними, и отдать всех коллег на повышение квалификации, например отправите их всех выучить Pure C, это поднимает дисциплину
Ответ написан
angrySCV
@angrySCV
machine learning, programming, startuping
Ну это неизбежно, мир такой какой он есть, он не совершенен и ты вынужден работать с тем что есть, большинство разработчиков которые доступны вашей компании скорее всего посредственности. Важно даже имея посредственных разработчиков, создавать стоящий, конкурентоспособный продукт.
Ну а куда ты думаешь уйти где такого не будет? Это везде, включая топовые компании (у которых слишком сложные и большие продукты, чтоб быть во всех деталях высокого качества).
Ответ написан
tsklab
@tsklab
Здесь отвечаю на вопросы.
Были попытки также переписать мною важные части системы и показать как можно решить эту задачу лучше, но со временем все возвращается к прежнему состоянию.
Я делал то же самое, но свои правки писал как комментарии. Со временем они стали восприниматься как должное (изменения вносились в код). Правда это привело к "Можно спросить?".
Ответ написан
dummyman
@dummyman
диссидент-схизматик
Конретно перечисленные вами проблемы можно решить наняв на работу или обозначив из нынешних работников project leaderа. Этот сотрудник должен быть в курсе всех тонкостей проекта на всех его уровнях и может назначить задание наиболее компетентному в сфере разработчику или ответить на все вопросы по заданию разработчику, у которого не достаточно компетентности, при этом других разработчиков тупо не оказалось под рукой.

Причем, одно из главных свойств project leaderа - способность принимать дальновидные решения по спорным вопросам. Для этого, необходим его объективный взлгляд на проект. Соответственно, для сохранения объективности взгляда project leaderу запрещается коммитить собственный код в проект. Ведь, ни для кого не секрет, любой человек/программист/разработчик будет считать свой код главнее, чем код других коллег, - что несомненно утрачивает объективность в принятии решений в спорных ситуациях. То есть, project leader должен быть, как судья в суде, слепым к неотносящимся к делу факторам, и его решения не должны быть навязаны заинтересованными в личной выгоде исполнителями.
Ответ написан
Andrey_Pletenev
@Andrey_Pletenev
Pletenev.com
Наглядный пример того, что подход "владение кодом" - зло. Еще веселее будет, когда один или несколько из них уволятся, а остальные не знают "их" кода.
Предложите остальным объединиться и сообща решить, кто из вас будет техлидом. Если ни у одного из вас нет достаточного авторитета, постарайтесь достучаться с этим до руководства. Пусть назначит вас или поставит стороннего. Если руководство окажется глухо, то вам решать: постепенно получать доверие и авторитет у коллег или уйти в другую команду.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы