Представьте ситуацию. Вы и Ваш лидер работаете над улучшением производительности определенного компонента. После двух дней работы Вы и лидер получаете одинаковый по производительности результат, но разные методы решения. Причем Вы закончили на пол дня раньше, чем лидер. У лидера в коде есть несколько грубых нарушений рекомендаций, а у вас нет. Чтобы быть точнее, лидер допустил следующие нарушения:
1. Есть два метода которые должны возвращать одно и тоже значение. Один "быстрый", а другой "медленный". Если вызвать "быстрый" метод не в том месте где надо или не в нужной последовательности, можно получить некорректное значение. Пользователь класса должен знать внутринности класса, чтобы не наступить на эту граблю.
2. Один из методов выдает кусок состояния класса наружу по ссылке, что нарушает инкапсуляцию и не позволит в будущем изменять внутринности этого класса.
Понятно, что проблема в пункте один гораздо хуже, чем в пункте два. Тем не менее, пункт два тоже добавляет элемент гниения кода, а вам не все равно.
Что делать?
1. Забыть о своем решении.
2. Убедить лидера, что Ваше решение лучше, тем самым рискуя нарушить суббординацию и выглядеть угрожающе для лидера.
Как в рекурсивной шутке: лидер должен программировать лучше вас исходя из его статуса. Если это не так, смотри предыдущее предложение.
3. Подключить других программистов. Начать обсуждение. Может иметь катастрофические последствия в политическом смысле.
Здравствуйте, greenpci, Вы писали:
G>Как в рекурсивной шутке: лидер должен программировать лучше вас исходя из его статуса. Если это не так, смотри предыдущее предложение.
Ммм, а вы уверены, что всё так печально с вашим лидом? Просто вот из опыта не могу вспомнить ни одного случая, когда непосредственный начальник "обижался" на комментарии к коду. Более того, как правило, мои руководители программировали не сильно лучше меня (при том, что я сам тот ещё безалаберный кумар). Да и сейчас люди в моей команде порой могут делать вещи гораздо быстрее и качественнее меня самого. Лидер — это ж не про кодерские скиллы, а про намного большее.
Вопросов два на самом деле:
* с какого вы вдвоем решали одну и туже проблему и не общались два дня?
* это у вас в конторе все боятся лиду/начальнику слово лишнее сказать?
Вобщем по нормальному ситуации такой не должно было и возникнуть, раз вы вместе решали задачу вместе должны и придти к общему решению. Если ты заинтересован в результате и не хочешь ссорится с лидом попроси его объяснить преимущества его решения и выскажи свои опасения насчет нарушений.
Но раз вы в процессе не общаетесь то и в конце смысла нет.
Здравствуйте, greenpci, Вы писали:
G>2. Убедить лидера, что Ваше решение лучше, тем самым рискуя нарушить суббординацию и выглядеть угрожающе для лидера. G>Как в рекурсивной шутке: лидер должен программировать лучше вас исходя из его статуса. Если это не так, смотри предыдущее предложение.
Я б сделал так (и ни раз делал).
— Проанализировать своё решение.
— Обсудить своё и решение лидера вместе.
— Высказать, чем твоё решение лучше/правильнее.
— Если лидер не выдерживает критики и всё равно считает, что он прав (и твоё решение явно лучше) -> он самодур и нужно искать другую работу / переводиться в другой отдел.
— Бывает так, что начальника устраивает это решение, и тогда ты соглашаешься, но ставишь галочку мол "ты сам так захотел".
— Мы все люди и даже лидеры могут иногда предлагать не совсем верное решение.
Здравствуйте, El Camino Real, Вы писали:
ECR>Ммм, а вы уверены, что всё так печально с вашим лидом? Просто вот из опыта не могу вспомнить ни одного случая, когда непосредственный начальник "обижался" на комментарии к коду. ...
да, на комментарии никто не обижается. В данном случае, нужно заменить решение начальника своим решением полностью. Это не просто комментарии, к сожалению. Там сама архитектура класса другая. Подход другой.
Здравствуйте, GarryIV, Вы писали:
GIV>* с какого вы вдвоем решали одну и туже проблему и не общались два дня?
Работали в разные смены. Проблема была оговорена перед концом смены лидера. Далее программист решил проблему, работая, пока лидера не было. Когда лидер вернулся, лидер продолжил свое решение.
GIV>* это у вас в конторе все боятся лиду/начальнику слово лишнее сказать?
комментарий, замечание, ошибка это нормально и приветствуется, но когда вот возьми мое решение и выкинь свое, есть сомнения.
GIV>Вобщем по нормальному ситуации такой не должно было и возникнуть, раз вы вместе решали задачу вместе должны и придти к общему решению. Если ты заинтересован в результате и не хочешь ссорится с лидом попроси его объяснить преимущества его решения и выскажи свои опасения насчет нарушений.
боюсь, что преимуществ нет. Если начать разговор, то лидера будет легко убедить и решение программиста будет использовано.
GIV>Но раз вы в процессе не общаетесь то и в конце смысла нет.
Скажем так, человека недавно выдвинули на позицию лидера, он пока еще не научился хорошо делегировать. Думаю, научится со временем.
Здравствуйте, greenpci, Вы писали:
G>Что делать?
G>1. Забыть о своем решении.
G>2. Убедить лидера, что Ваше решение лучше, тем самым рискуя нарушить суббординацию и выглядеть угрожающе для лидера. G>Как в рекурсивной шутке: лидер должен программировать лучше вас исходя из его статуса. Если это не так, смотри предыдущее предложение.
G>3. Подключить других программистов. Начать обсуждение. Может иметь катастрофические последствия в политическом смысле.
Забыть о данном решении.
Чтобы ситуация не повторилась в будущем, внедрить процесс code review.
Здравствуйте, UVV, Вы писали:
UVV>- Если лидер не выдерживает критики и всё равно считает, что он прав (и твоё решение явно лучше) -> он самодур и нужно искать другую работу / переводиться в другой отдел.
Думаю, что убедить лидера можно, но затаит ли он обиду / страх, не понятно. Короче, может выйти себе дороже.
UVV>- Мы все люди и даже лидеры могут иногда предлагать не совсем верное решение.
согласен. Такая ситуация, когда два человека работают над одной и той же проблемой без делегирования, очень редка. У меня в жизни такое было считанные разы. Лучше, конечно, этого не допускать. Поэтому и спрашиваю здесь, что проблема редкая.
Здравствуйте, gyraboo, Вы писали:
G>Забыть о данном решении. G>Чтобы ситуация не повторилась в будущем, внедрить процесс code review.
А чем код ревью поможет? Он же делается уже после реализации задачи. Ну посмотрят эти два сотрудника на код, выяснится, что программист выполнил задачу лучше и получится противоположное тому, что ты сказал "забыть о данном решении".
Здравствуйте, greenpci, Вы писали:
G>Представьте ситуацию. Вы и Ваш лидер работаете над улучшением производительности определенного компонента. После двух дней работы Вы и лидер получаете одинаковый по производительности результат, но разные методы решения. Причем Вы закончили на пол дня раньше, чем лидер. У лидера в коде есть несколько грубых нарушений рекомендаций, а у вас нет. Чтобы быть точнее, лидер допустил следующие нарушения:
А как вообще получилось, что в одной команде два человека одновременно и независимо делают одно и то же?
Здравствуйте, greenpci, Вы писали:
GIV>>* с какого вы вдвоем решали одну и туже проблему и не общались два дня?
G>Работали в разные смены. Проблема была оговорена перед концом смены лидера. Далее программист решил проблему, работая, пока лидера не было. Когда лидер вернулся, лидер продолжил свое решение.
А лидер, когда вернулся и продолжил, был уже в курсе, что вы все сделали?
G>комментарий, замечание, ошибка это нормально и приветствуется, но когда вот возьми мое решение и выкинь свое, есть сомнения.
Я бы на месте лидера не переживал, что кто-то сделал лучше меня. Но переживал бы, что кто-то из нас зря потратил время из-за организационного бардака.
G>боюсь, что преимуществ нет. Если начать разговор, то лидера будет легко убедить и решение программиста будет использовано.
Здравствуйте, greenpci, Вы писали:
Pzz>>А лидер, когда вернулся и продолжил, был уже в курсе, что вы все сделали?
G>да, был в курсе, но решил продолжить работать над своим решением. Сказал, что его решение заменит решение программиста.
Вот так вот, имея перед собой готовое решение, сел допиливать свое? И как он это объяснил?
Здравствуйте, greenpci, Вы писали:
G>Я, как программист, потребовал бы показать код. Код говорит о человеке больше, чем любые мнения. Но, к сожалению, код показать нельзя.
Естественно и имел в виду экспертное мнение третих лиц о вашем с лидом коде. Пока что были предоставлены минусы кода лида, но ничего не сказано о другой версии кода. Может там еще больше минусов, которые не видно вам как автору.
Х — хороший программист. М — мудрый лидер. Думаю, вся история была такова:
X несколько месяцев перед этим косячил со сроками и с лишними вопросами.
Неделю обсуждали конкретно эту фичу, но Х тупил и был занят другими делами (например своими).
Наконец "задачу сформулирвали", то есть фактически поставили ребром вопрос,
что хватит тупить и тянуть, задача должна быть решена кровь из носа.
М в курсе что ему прийдётся отвечать за результат.
Тут ему подсовывают какую-то поделку, стопроцентно непродокументированную,
там ещё что-нибудь отдельный момент особо кривой, а что-то непонятно сделано.
При этом у М в голове есть решение, за которое он отвечать готов.
Ну он берет и пишет результат наверняка.
Тут прибегает Х, который уже и раньше достал лида,
но репутацию ему лид создал что "всех достал", чему есть подтверждения от других членов команды,
и Х снова начинает качать права, мол "М — твой код неправильный".
Вообще от такого Х надо избавляться, мешает работать нормальным людям типа М.
А Х — тряпка, если бы он хоть что-нибудь умел делать,
у него уже была бы своя компания. А пока ему даже ничего серьезного поручить нельзя.
Здравствуйте, mogikanin, Вы писали:
M>Естественно и имел в виду экспертное мнение третих лиц о вашем с лидом коде. Пока что были предоставлены минусы кода лида, но ничего не сказано о другой версии кода. Может там еще больше минусов, которые не видно вам как автору.
ТС везде найдет неприятность, раздует до размеров слона и будет наслаждаться страданиями. Вместо того, чтобы восхититься гениальностью решения тим-лидера (эльфинг вкусен!), и попутно добавить ему идею, как устранить дупликат переменной состояния и закрыть доступ к деталям реализации, ТС пытается найти повод, чтоб не выбрасывать свой код.
Да и сейчас люди в моей команде порой могут делать вещи гораздо быстрее и качественнее меня самого. Лидер — это ж не про кодерские скиллы, а про намного большее.
