Здравствуйте, sharpman, Вы писали:
S>Здравствуйте, Homunculus, Вы писали:
Начальниками за то платят, чтоб это разруливали.
S>Тогда усложним задачу: коллега лижет начальству или способен заболтать уши новомодной чепухой и начальство будет на его стороне. Что делать?
Встречный вопрос — а почему вы против "новомодной чепухи"? Иногда это именно то, чего не хватает проекту. Вообще для того, чтобы понять, а нужны ли эти новые фичи, новые тесты, новая "чепуха", надо собрать статистику и доказать свою точку зрения на основе данных, а не в виде "мое слово против твоего" или "раньше работало так". Имплементируем обе фичи или оба теста, делаем бенчмарк, и смотрим, что работает быстрее, легче поддерживать, удобнее релизить и т.д.
А делать выводы на основе "оно последние 5 лет работало, поэтому продолжаем" — не аргумент.
Рабочий пример. В команде был программист, 12 лет в компании, знал определенные библиотеки, поддерживал старые приложения. Начали писать более современный сайт + бэкенд переделывать постепенно, предложили ему поучиться, упирается, мол, я поддерживаю то, что уже работает, это новое мне не надо. Предложили тесты пописать, опять своё — я этот фреймворк не знаю, зачем вы меня туда тянете. Фактически,замкнутое сознание (fixed mindset). В результате из-за нежелания учиться + идти в ногу с командой его уволили, старые приложения переписали, все остались в плюсе, кроме него.
Не всегда стоит настраивать на "my way or highway"...
Сначала лично обсудить, если доводы одной стороны не приняты другой стороной, то решать через вышестоящих в иерархии. Начальниками за то платят, чтоб это разруливали.
$>Здравствуйте, gandjustas, Вы писали:
G>>Поговорить. Возможно я что-то не знаю.
$>Коллега пытался объяснить, но путается в показаниях. Сделал пару докладов по неведомой ###не. Не убедил.
Значит ты его не понял. Или не захотел понимать.
G>>Разговаривать. Если нет консенсуса, то привлекать третью сторону (начальника).
$>Начальник зааппрувил пул-реквесты коллеги.
Значит начальник его понял.
G>>$>Дискас. G>>Смысл? Ответ очевиден.
$>Что делать?
Учиться слушать.
$>Дискас.
Большинство вопросов выглядит как в твой уютненький мирок ворвался какой-то выскочка и без проса и благословения начал предлагать "новшества". Т.е. не видно, чтобы ты хотел обсудить техническую сторону вопроса.
А так обычно обсуждаем с коллегами, пытаемся найти компромисс по подходам. Потом, если что зовём лесника и он выбирает куда нам идти дальше.
M>Рабочий пример. В команде был программист, 12 лет в компании, знал определенные библиотеки, поддерживал старые приложения. Начали писать более современный сайт + бэкенд переделывать постепенно
Рабочий пример. В компании был программист (ваш покорный слуга), поддерживал старые приложения. Пришёл новый начальник, создал "второй ит-отдел" из 4 человек и начал всё переписывать на питон. Я пытался объяснить, что кода много, и он запутанный (писала куча народа, уже давно уволившегося), что всё работает 16-18 часов в сутки, что работа идёт с деньгами, что мелкая ошибка может привести к приличному ущербу... короче, через 8 месяцев начальника уволили т.к. он обещал за полгода всё переписать, но не переписал.
Да, потом пришёл ещё один инноватор ("доделывать дело раз уж начали"), но я уволился т.к. весь этот цирк — довольно нервный (куча инцидентов, и каждый раз приходится доказывать, что виноваты инноваторы, а не я и "мой старый код").
M>Начали писать более современный сайт + бэкенд переделывать постепенно, предложили ему поучиться, упирается, мол, я поддерживаю то, что уже работает, это новое мне не надо. Предложили тесты пописать, опять своё — я этот фреймворк не знаю, зачем вы меня туда тянете. Фактически,замкнутое сознание (fixed mindset). В результате из-за нежелания учиться + идти в ногу с командой его уволили, старые приложения переписали, все остались в плюсе, кроме него.
Могу лишь позавидовать грамотности руководства и правильной направленности.
В реальности же зачастую у таких gatekeepers, которые "давно сидят", может быть довольно много влияния, и они способны утопить очень много здравых начинаний.
Здравствуйте, L.K., Вы писали:
S>>Тогда усложним задачу: коллега лижет начальству или способен заболтать уши новомодной чепухой и начальство будет на его стороне. Что делать?
LK>Если спор не принципиален — выполнять указания начальства. LK>В противном случае — увольняться.
А почему отсутствует вариант — объяснить начальству, что новомодная херота сперва проходит период хайпа, потом период разочарования и только после этого становится применима в производстве?
Объяснить в том контексте, что хайп вокруг новомодных вещей поднимается ради того, чтобы найти дурачков, готовых вложиться своими деньгами и разочароваться.
— Коллега предложил улучшение, как он считает, но вы несогласны, что это улучшение кто-то просил, и вообще.
— Коллега саботирует ваш PR, просит переделать на, как он считает, более правильный дизайн. Но у вас всё и так работает.
— Коллега ставит в известность о новых требованиях к юнит тестам в одностороннем порядке, по надуманным поводам- у вас все юнит тесты и так работали и вообще, у вас опыт юнит тестов больше.
— Коллега под предлогом фичи затащил какую-то неведомую ###ю, взрывающую вам мозг, отличающуюся от привычного вам кодописательства.
Менять подходы к собеседованию, о чем тут уже многократно говорилось. Описываемые проблемы взаимодействия в команде типичны для тех мест, куда набирали олимпиадников или вынуждали решать задачки на интервью.
А с конкретными эпизодами-перлами уже нанятых людей — разбираться исходя из обстоятельств, а не сценариев. Идёт ли речь о заказной разработке под одного-двух заказчиков(аутсорц классически) или же решение внутри интернет-компании а-ля амазон/фейсбук/гугл или же данный проект является программным продуктом для b2b-сегмента.
$>- Коллега предложил улучшение, как он считает, но вы несогласны, что это улучшение кто-то просил, и вообще.
Поговорить. Возможно я что-то не знаю.
$>- Коллега саботирует ваш PR, просит переделать на, как он считает, более правильный дизайн. Но у вас всё и так работает.
Поговорить. Возможно я что-то не знаю.
$>- Коллега ставит в что-то не знаюо новых требованиях к юнит тестам в одностороннем порядке, по надуманным поводам- у вас все юнит тесты и так работали и вообще, у вас опыт юнит тестов больше.
Поговорить. Возможно я что-то не знаю.
$>- Коллега под предлогом фичи затащил какую-то неведомую ###ю, взрывающую вам мозг, отличающуюся от привычного вам кодописательства.
Поговорить. Возможно я что-то не знаю.
$>Что вы будете делать?
Разговаривать. Если нет консенсуса, то привлекать третью сторону (начальника).
Здравствуйте, $$, Вы писали:
А>- Коллега под предлогом фичи затащил какую-то неведомую ###ю, взрывающую вам мозг, отличающуюся от привычного вам кодописательства. А>Что вы будете делать? А>Дискас.
Артем, это ты пытаешься понять со стороны других программистов тот твой выверт годовалой (ЕМНИП) давности, когда ты самовольно начал писать на функциональном языке вместо Джавы?
Здравствуйте, Codealot, Вы писали:
A>>Главное, чтобы была бумажка, чтобы подтереть задницу. Если ты не работаешь в большой компании типа сбера, или у тебя начальство ну хоть немного разбирается и не собирает как ты бумажки, то твоя позиция выглядит так, что "мне всё равно, главное, что потом будет на кого свалить".
C>Моя позиция — каждый должен отвечать за свои косяки. C>А тебе, похоже, эта идея не нравится?
Есть позиция, что главное — интересы компании, а есть — главное, чтобы я не оказался крайним. Мне больше нравится первая.
Наличие справки "что я не виноват" никак не добавляет тебе полезности.
Здравствуйте, alzt, Вы писали:
A>Есть позиция, что главное — интересы компании, а есть — главное, чтобы я не оказался крайним. Мне больше нравится первая.
Без лохА и жизнь плоха.
Или, возможно, тебе больше нравится первая позиция, только когда это ничего не стоит тебе лично?
$>Коллеге дали задание дофиксить баг, ну т.е. оно при corner case выстреливает. Чел медитировал пару дней, решил что надо рефакторить 3 класса, и это заодно исправит ошибку. Указал ему строчку, что там написать и баг был бы исправлен. На следующий день этот чел выкатил свой рефакторинг вместо фикса одной строчки, который походу откатил другие фиксы месячной давности и откатил юнит тесты (!) на тех фиксах. Потому, что он посчитал их "ненужными". Ну и в итоге пришлось самому эту строчку поправить.
$>Результат: на исправление 1 строчки бага потрачено 2 человекодня этого чела и еще 2 часа моего и других участников на обсуждения и пререкания.
$>Как сделать, чтоб в будущем такая ситуация не повторялась?
1. Одна цель у одного диффа. Никогда не паковать несколько независимых изменений в один дифф.
2. Сменить работу на более адекватную.
Здравствуйте, Homunculus, Вы писали:
H>Сначала лично обсудить, если доводы одной стороны не приняты другой стороной, то решать через вышестоящих в иерархии. Начальниками за то платят, чтоб это разруливали.
Тогда усложним задачу: коллега лижет начальству или способен заболтать уши новомодной чепухой и начальство будет на его стороне. Что делать?
.
Пессимисты говорят, что хуже быть не может,
а оптимисты всегда уверены, что — может!
Здравствуйте, sharpman, Вы писали: S>Тогда усложним задачу: коллега лижет начальству или способен заболтать уши новомодной чепухой и начальство будет на его стороне. Что делать?
Делать что должно, вести себя достойно и будь что будет.
$>- Коллега ставит в известность о новых требованиях к юнит тестам в одностороннем порядке, по надуманным поводам- у вас все юнит тесты и так работали и вообще, у вас опыт юнит тестов больше.
Поставить заказчика/руководителя перед стоимостной оценкой, что из сделанного вами сломается и за сколько пустой работы надо будет заплатить реальными деньгами, "только чтобы этому модно-молодёжному было хорошо почесать его чувство доминирования".
LK>>Если спор не принципиален — выполнять указания начальства. LK>>В противном случае — увольняться.
A>А почему отсутствует вариант — объяснить начальству, что новомодная херота
Потому что в условии задачи было:
коллега лижет начальству или способен заболтать уши новомодной чепухой и начальство будет на его стороне.
$>- Коллега предложил улучшение, как он считает, но вы несогласны, что это улучшение кто-то просил, и вообще.
$>- Коллега саботирует ваш PR,
хз где вы работаете с такими коллегами, у меня за 10 лет(линукс,ядро, небольшие коллективы) такого ни разу не было. бывает с тим-лидом не во всем согласны, т.к. у всех свои предпочтения, но ответственность на нем, и лично я ограничиваюсь изложением своих аргументов. гумантарии-фронтендщики наверное более склонны к конфликтам, чтож пусть страдают.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
ЭФ>Жалкое оправдание своей неспособности переподготавливать кадры. ЭФ>Если был подробный и детальный обучающий курс, не было бы никаких проблем.
это тебя там описывают? иначе почему откуда такая уверенность, что не было бы. встречал таких упёртых-приросших, как описано выше
Здравствуйте, L.K., Вы писали:
LK>>>Если спор не принципиален — выполнять указания начальства. LK>>>В противном случае — увольняться.
A>>А почему отсутствует вариант — объяснить начальству, что новомодная херота
LK>Потому что в условии задачи было:
LK>
коллега лижет начальству или способен заболтать уши новомодной чепухой и начальство будет на его стороне.
Не учитывается вариант, что «начальника» будет на его стороне лишь до того момента, пока не предприняты соответствующие меры — не сказано то, что должно прозвучать?
Это позиция затравленного раба или идиота.
Обсуждать имеет смысл то, каким образом получить должный «managing up».
А>- Коллега предложил улучшение, как он считает, но вы несогласны, что это улучшение кто-то просил, и вообще.
Подумал бы насколько это вообще адекватная реакция с моей стороны. Если улучшение действительно что-то улучшает, то подумать что же со мной не так, и почему я начал изображать из себя собаку на сене. Иначе выяснить у оппонента почему он считает это улучшением.
А>- Коллега саботирует ваш PR, просит переделать на, как он считает, более правильный дизайн. Но у вас всё и так работает.
Выяснить чем этот дизайн лучше того который есть. В вопросе слишком сферическая формулировка. Может ты зашорился, а в диффе у тебя скопился говнокод. Ведь для этого PR и существуют.
А>- Коллега ставит в известность о новых требованиях к юнит тестам в одностороннем порядке, по надуманным поводам- у вас все юнит тесты и так работали и вообще, у вас опыт юнит тестов больше.
Хз что тут вообще можно ответить без конкретики. Нужен арбитраж от человека видящего ситуацию.
А>- Коллега под предлогом фичи затащил какую-то неведомую ###ю, взрывающую вам мозг, отличающуюся от привычного вам кодописательства.
Узнать у коллеги почему именно так сделал. Или ты боишься вступить с ним в дискуссию потому, что он станет считать тебя тупым, потерять вес? Без конкретного примера сложно говорить в ту или другую сторону.
А>Что вы будете делать? Дискас.
Вот это самое и лучше делать. Вероятно привлечь третью сторону – не обязательно одного человека. Обсудить подходы. Вы же команда, а не стадо обезьян
Здравствуйте, gandjustas, Вы писали:
G>Поговорить. Возможно я что-то не знаю.
Коллега пытался объяснить, но путается в показаниях. Сделал пару докладов по неведомой ###не. Не убедил.
G>Разговаривать. Если нет консенсуса, то привлекать третью сторону (начальника).
Начальник зааппрувил пул-реквесты коллеги.
G>$>Дискас. G>Смысл? Ответ очевиден.
Что делать?
$>- Коллега предложил улучшение, как он считает, но вы несогласны, что это улучшение кто-то просил, и вообще.
$>- Коллега саботирует ваш PR, просит переделать на, как он считает, более правильный дизайн. Но у вас всё и так работает.
$>- Коллега ставит в известность о новых требованиях к юнит тестам в одностороннем порядке, по надуманным поводам- у вас все юнит тесты и так работали и вообще, у вас опыт юнит тестов больше.
$>- Коллега под предлогом фичи затащил какую-то неведомую ###ю, взрывающую вам мозг, отличающуюся от привычного вам кодописательства.
Здравствуйте, L.K., Вы писали:
LK>Рабочий пример. В компании был программист (ваш покорный слуга), поддерживал старые приложения. Пришёл новый начальник, создал "второй ит-отдел" из 4 человек и начал всё переписывать на питон. Я пытался объяснить, что кода много, и он запутанный (писала куча народа, уже давно уволившегося), что всё работает 16-18 часов в сутки, что работа идёт с деньгами, что мелкая ошибка может привести к приличному ущербу... короче, через 8 месяцев начальника уволили т.к. он обещал за полгода всё переписать, но не переписал.
LK>Да, потом пришёл ещё один инноватор ("доделывать дело раз уж начали"), но я уволился т.к. весь этот цирк — довольно нервный (куча инцидентов, и каждый раз приходится доказывать, что виноваты инноваторы, а не я и "мой старый код").
С какого языка или фреймворка переписывали на питон?
Так то мне нравится питон и для обсчета финансов ведь там готовые и оттестированные библиотеки, плюс отвязываемся от платформы. Не возникало желания поддержать инноватора, помочь make things happen?
Здравствуйте, _ABC_, Вы писали:
_AB>Артем, это ты пытаешься понять со стороны других программистов тот твой выверт годовалой (ЕМНИП) давности, когда ты самовольно начал писать на функциональном языке вместо Джавы?
$>Дискас.
Да это вообще идеально! примеры правильной работы, когда люди договариваются.
Бывает сложнее:
— Коллега не предложил улучшение, а сразу его внедрил. Вы осознаете проблемы в 'улучшении', когда вылазят баги и Вам их править.
— Коллега написал новый модуль проекта в своем стиле с модным дизайном. Убедил начальника, что так надо.
— Коллеги, добавлявшие раньше 'свои' модули, поступали аналогично.
— Коллега затащил неведомую ###ю, которая роняет дебаггер. Переписать никто не даст тк все работает и уже в проде.
— Коллега-программист — математик (а так-то хороший человек). И Вам править его код.
— Коллега — он же заказчик, он же разработчик, пишет код криво, критикует Ваш код, жалуется Вашему начальнику.
$>- Коллега предложил улучшение, как он считает, но вы несогласны, что это улучшение кто-то просил, и вообще.
$>- Коллега саботирует ваш PR, просит переделать на, как он считает, более правильный дизайн. Но у вас всё и так работает.
Если улучшение объективно и измеримо решает какие-то проблемы, его стоит внедрять, если оно решает будущие проблемы, его стоит внедрить в будущем. За неоднократные конфликты на стилистической почве есть шанс вылететь, что у одной, что у другой стороны.
$>- Коллега ставит в известность о новых требованиях к юнит тестам в одностороннем порядке, по надуманным поводам- у вас все юнит тесты и так работали и вообще, у вас опыт юнит тестов больше.
Юнит тесты и их формат обычно продукт договоренности команды (иначе без большой палки не работает). За попытки поставить что-то в одностороннем порядке вылетает первая сторона, за саботаж договоренностей второая.
$>- Коллега под предлогом фичи затащил какую-то неведомую ###ю, взрывающую вам мозг, отличающуюся от привычного вам кодописательства.
$>Что вы будете делать?
Документация. Любой редактор сейчас позволяет документировать и вставлять схемы прямо на ходу или поддерживать актуальный мд.
Артемка, детский сад со временем жизни что первой, что второй стороны в разработке — от двух недель до месяца.
$>Что вы будете делать?
Разрешение конфликтов — это прямая и одна из главных обязанностей тимлидов. Соответственно единственна возможность — это сообщить о проблеме непосредственному руководителю и в этом случае это будет проблема непосредственного руководителя. Соответственно если у тебя конфликт с юниором, он фигачит мкдоды на тысячи строк с 20 уровнями вложенностями и отказывается править — объясняешь ситуацию и будет проведена беседа. Соответственно проблемный товарищь либо будет тебя слушать, либо будет ротация и с товарищем пересекаться перестанете, а нет пересечений — нет проблем.
Это в случае, если твой непосредственный начальник на твоей стороне. В случае, если у тебя разногласия с начальством, выхода по большому счету 2 — либо увольняешься ты, либо увольняется начальник. Я кстати был в такой ситуаации, уволился начальник, а не я, но на моей стороне был начальник начальника и конфликт был между начальством, а не мной, я просто остался при своем мнении а не начал прогибаться под начальника. С текущим вообще все идеально, взаимопонимание с полуслова — он понимает почему я так делаю, мне даже объяснять ничего не надо, я понимаю почему он принимает такие решения, мне тоже объяснять не надо, крайне приятно так работать. Ну а когда мнения расходились, я предупреждал, что будут проблемы и решение не сработает, соответственно проходит несколько лет, начальник понимает, что его решение было ошибочным и все приходит к моему решению.
Смешно то, что текущее место работы — это просто абсолютный максимум конфликтов, которые я когда либо встречал. Я встречал даже доносы моего начальника на начальника начальника, адресованному самому главному, такой капец редко когда встречается. В самом начале сам думал об увольнении, идиотизм был полнейший, но в конце концов все стало вполне приемлемо и комфортно.
PS Если что, clojure у нас не под запретом . А я изначально стоял за то, чтоб под конкретные задачи использовался максимально подходящий для их решения инструмент. 3 года потребовалось чтоб добиться этого. Но самое смешное, что сейчас большинство может просто охренеть от того, какой свободы для разработчиков удалось добиться и какого мегаконсервативного заказчика удалось пробить на магаэкзотику, не могу к сожалению говорить об этом, но кое кто, о ком точно никто никогда не подумает, и кто в России на слуху, де факто круче Тинькова со scala. Под экзотикой я даже не clojure и elm понимаю . Хоть там и маразмов от безопасников хватает, и это реальные маразмы, но по языкам программирования палок ни малейших.
$>- Коллега предложил улучшение, как он считает, но вы несогласны, что это улучшение кто-то просил, и вообще.
пишите ему — не согласен потому что в PR comment ...
$>- Коллега саботирует ваш PR, просит переделать на, как он считает, более правильный дизайн. Но у вас всё и так работает.
всё и так работает и так работает не вариант. вы должны обосновать свой дизайн. и коллега должен.
$>- Коллега ставит в известность о новых требованиях к юнит тестам в одностороннем порядке, по надуманным поводам- у вас все юнит тесты и так работали и вообще, у вас опыт юнит тестов больше.
дискуссия оффлайн
$>- Коллега под предлогом фичи затащил какую-то неведомую ###ю, взрывающую вам мозг, отличающуюся от привычного вам кодописательства.
откомментиться надо что это и почему. обязательно обоснуйте почему вам это не нравится
G>>Разговаривать. Если нет консенсуса, то привлекать третью сторону (начальника).
$>Начальник зааппрувил пул-реквесты коллеги.
$>Что делать?
Уйти в отказ по своим задачам, "коллега сломал, коллега пусть и чинит, сам покрасовался на копейку а другим испортил на рубль"?
Во всяком случае, пусть начальник заведёт отдельный таск "переделки для совместимости с ломающими нововведениями коллеги" за отдельные жопочасы.
$>- Коллега предложил улучшение, как он считает, но вы несогласны, что это улучшение кто-то просил, и вообще.
Каков ваш статус? Оба синьеры? Если равноправные статусы, вы выкладываете свои технические аргументы вышестоящему начальству, и оно уже решает исходя из конкретных производственных нужд и приоритетов (не всегда видных программистам).
$>- Коллега саботирует ваш PR, просит переделать на, как он считает, более правильный дизайн. Но у вас всё и так работает.
"Все и так работает" — не очень аргумент. При каких условиях работает? Пройдет ли верификацию на определенном этапе цикла разработки? Пройдет ли валидацию системы у заказчика? М.б. на горизонте будет расширение функционала, и его проще делать, если заранее усложнить систему, вводя доп. абстракции и проч. Сколько времени займет это улучшение, и есть ли это время? Куча факторов, и в каждом конкретном случае может быть свое оптимальное решение.
$>- Коллега ставит в известность о новых требованиях к юнит тестам в одностороннем порядке, по надуманным поводам- у вас все юнит тесты и так работали и вообще, у вас опыт юнит тестов больше.
Какие именно требования к юнит-тестам? Я видел "юнит-тесты", которые были на страницу каждый, с кучей ассертов и экспектов (и автор, видимо, вообще не понимал разницу между двумя), I/O в реальную ФС... их надо было выкинуть и переписать заново. По-хорошему, там надо было и продакшн код делапшеизировать сначала, но времени на это не было.
$>- Коллега под предлогом фичи затащил какую-то неведомую ###ю, взрывающую вам мозг, отличающуюся от привычного вам кодописательства.
$>Что вы будете делать?
Буду писать в ревью, построчно, что не так, и как надо бы переделать. Если нетривиальный коммит или потенциальная правка, созвонюсь с коллегой, чтобы обсудить, что и почему.
G>Значит ты его не понял. Или не захотел понимать. G>Значит начальник его понял. G>Учиться слушать.
Это нефальсифицируемые условия без чётких критериев выполнения.
Здравствуйте, Osaka, Вы писали:
G>>Значит ты его не понял. Или не захотел понимать. G>>Значит начальник его понял. G>>Учиться слушать. O>Это нефальсифицируемые условия без чётких критериев выполнения.
Какой вопрос такой и ответ.
Здравствуйте, Osaka, Вы писали:
O>Уйти в отказ по своим задачам, "коллега сломал, коллега пусть и чинит,
Коллега починил все существующие юнит тесты, которые сломались под ужесточенными требованиями. Но для всех новых юнит тестов в будущем, поставил условие в eslint. Соответственно, новые юнит тесты будут ломаться, если не соблюдать ужесточенные требования. А это лишние строчки кода, которые лень писать.
E> Но самое смешное, что сейчас большинство может просто охренеть от того, какой свободы для разработчиков удалось добиться и какого мегаконсервативного заказчика удалось пробить на магаэкзотику
Спасибо, такие как ты никогда не оставят нас без куска хлеба!
"Здесь использовалось 100500 разных технологий, модных 20 лет назад. Написано демократичной командой в стиле кто-во-что-горазд и кто-как-умеет. Нужно 100500 часов времени(и столько же денег) на переписывание."
И правильно! Пусть жадные буржуи делятся с народом!
Здравствуйте, namespace, Вы писали:
N> "Здесь использовалось 100500 разных технологий, модных 20 лет назад. Написано демократичной командой в стиле кто-во-что-горазд и кто-как-умеет. Нужно 100500 часов времени(и столько же денег) на переписывание."
А как нужно,
"Здесь использовалась 1 технология, модная на заре ЭВМ. Написано командой фанатиков в стиле "как бы чего не вышло". Нужно починить считыватель перфокарт из музея, чтобы понять, как это работает, но уже и схемы считывателя перфоракт не осталось.
$>- Коллега саботирует ваш PR, просит переделать на, как он считает, более правильный дизайн. Но у вас всё и так работает.
Пусть обоснует письменно, чем конкретно этот дизайн более правильный. Если из-за него потом возникнут проблемы, тыкать его носом.
$>- Коллега под предлогом фичи затащил какую-то неведомую ###ю, взрывающую вам мозг, отличающуюся от привычного вам кодописательства.
Пусть обоснует письменно, зачем нужна эта неведомая фигня. Все баги из-за этой фигни вешать на него, а также тыкать его носом.
Ну или он натыкает тебя носом, если прав он, а не ты. Но тут уж придется пойти на риск.
Кроме того, крайне желательно, чтобы было нормальное разделение кода на подсистемы. Когда любой может вломиться в чужой код и всё загадить, а потом кому-то другому придется разгребать — не есть правильно.
N>$>Дискас. N>Да это вообще идеально! примеры правильной работы, когда люди договариваются.
N>Бывает сложнее: N>- Коллега не предложил улучшение, а сразу его внедрил. Вы осознаете проблемы в 'улучшении', когда вылазят баги и Вам их править.
Почему вам? На стэндапе говоришь, что есть такой-то баг, особо не вникал, но вроде как связан с фичей 'улучшение'. Все. Адекватные скрум мастера назначат этот тикет на коллегу. Адекатные коллеги (внедрившие 'улучшение') сами выступят и попросят назначить тикет на себя. N>- Коллега написал новый модуль проекта в своем стиле с модным дизайном. Убедил начальника, что так надо.
А в чем проблема? N>- Коллеги, добавлявшие раньше 'свои' модули, поступали аналогично.
А в чем проблема? Если у вас есть гайдлайны, то ссылаетесь на них. Если гайдлайнов нет, то каждый волен поступать как хочет. N>- Коллега затащил неведомую ###ю, которая роняет дебаггер. Переписать никто не даст тк все работает и уже в проде.
Когда успел? Один наворотил делов, а на следующий день у всей команды не работает дебаггер и все молчат, так что ли? N>- Коллега-программист — математик (а так-то хороший человек). И Вам править его код.
На стэндапе говорим, что наш текущий тикет тесно связан с кодом коллеги-математика (не буквально, конечно, а просто говорим "код связан с модулем Х", при этом кому надо, тот помнит, кто наворотил этот модуль Х). И что мы потратим некоторое время на рефакторинг. Все.
Другой вопрос, как код коллеги-математика прошел через все код-ревью и т.д... N>- Коллега — он же заказчик, он же разработчик, пишет код криво, критикует Ваш код, жалуется Вашему начальнику.
Аутсорс, я так понимаю? Риски большие, так что консультируемся со своим начальником перед каждым ответным действием по этому вопросу. Иначе можно потерять заказчика, и при этом остаться виноватым в этом
Здравствуйте, student__, Вы писали:
__>$>- Коллега предложил улучшение, как он считает, но вы несогласны, что это улучшение кто-то просил, и вообще.
__>Каков ваш статус? Оба синьеры? Если равноправные статусы, вы выкладываете свои технические аргументы вышестоящему начальству, и оно уже решает исходя из конкретных производственных нужд и приоритетов (не всегда видных программистам).
Какой статус? Если люди работают друг с другом то статус свой знают, и знают кто что стоит. Равноправия не будет, но и какого-то превосходства тоже.
Для начальства это будет выглядеть так, что опять эти дебилы поцапались друг с другом, решают с какой стороны яйца бить.
Начальство часто решит не из-за каких-то только ему видных соображений, а из-за недостатка информации или просто лени, выберет случайным образом.
Я, например, обычно сразу обоих детей наказываю, и мне пофигу кто из них первый начал.
__>$>- Коллега под предлогом фичи затащил какую-то неведомую ###ю, взрывающую вам мозг, отличающуюся от привычного вам кодописательства. __>$>Что вы будете делать?
__>Буду писать в ревью, построчно, что не так, и как надо бы переделать. Если нетривиальный коммит или потенциальная правка, созвонюсь с коллегой, чтобы обсудить, что и почему.
Это в теории. А по факту даже в тех компонентах, в которых хорошо разбираешься, делать ревью это очень трудоёмкое занятие. Поэтому часто оно делается очень поверхностно. А если разбираешься в компоненте плохо (а такое часто), то в серьёз делать ревью как-то самонадеянно.
Здравствуйте, Codealot, Вы писали:
C>$>- Коллега саботирует ваш PR, просит переделать на, как он считает, более правильный дизайн. Но у вас всё и так работает.
C>Пусть обоснует письменно, чем конкретно этот дизайн более правильный. Если из-за него потом возникнут проблемы, тыкать его носом.
Главное, чтобы была бумажка, чтобы подтереть задницу. Если ты не работаешь в большой компании типа сбера, или у тебя начальство ну хоть немного разбирается и не собирает как ты бумажки, то твоя позиция выглядит так, что "мне всё равно, главное, что потом будет на кого свалить".
A>Я, например, обычно сразу обоих детей наказываю, и мне пофигу кто из них первый начал.
Т. е. жертва виновата, что сопротивлялась хулигану? А потом они удивляются, почему в стране одни овощи.
$>Что вы будете делать?
постараюсь оставить личное, я/он нравиться/не нравится хороший/плохой и быть конструктивным
свернуть все в коммерческую сторону. это не твой домашний проект, это работа.
клиенты платят за продукт/сервис/услугу и оплачивают труд разработчиков.
будь добр обоснуй в цифрах почему штука которую ты задумал/сделал окупиться и за какое время.
есть и другие варианты
-мы выплачиваем технический долг
при этом очень желательно проиллюстрировать что в этом месте у нас новые требования/баги которые дорого было фиксить
-мы делаем RnD, фиг знает что из этого выйдет
опять же как результат — рассказать всем получилось/нет, какие выводы
если коллега не в состоянии рассуждать на таком уровне — пойти к непосредственному начальству
тема разговора: коллега мешает работать, ты не понимаешь что он делает, он объяснить не может.
$>Сценарии:
$>- Коллега предложил
$>- Коллега саботирует
$>- Коллега ставит
$>- Коллега под предлогом
$>Что вы будете делать?
К тимлиду! Или к тому, кто там у вас ответственный за то, чтобы всё летало и не падало.
У вас там, похоже, нет ни правил, ни гайдлайнов. Либо на них давно забили. Фигачите каждый кто на что горазд. Вот и результат.
Здравствуйте, Osaka, Вы писали:
A>>Я, например, обычно сразу обоих детей наказываю, и мне пофигу кто из них первый начал. O>Т. е. жертва виновата, что сопротивлялась хулигану? А потом они удивляются, почему в стране одни овощи.
Это люди, которые друг друга очень хорошо знают, и им ещё долго жить вместе. Так что пусть учатся договариваться.
A>>>Я, например, обычно сразу обоих детей наказываю, и мне пофигу кто из них первый начал. O>>Т. е. жертва виновата, что сопротивлялась хулигану? А потом они удивляются, почему в стране одни овощи. A>Это люди, которые друг друга очень хорошо знают, и им ещё долго жить вместе. Так что пусть учатся договариваться.
Сами договариваться не научаются. Детские коллективы, предоставленные самим себе, самоорганизуются в обезьянью кастовую иерархию (нижестоящий всегда виноват и не имеет права даже подавать голос, вышестоящим его можно и нужно гнобить и мучить). lurkmore.to/Школьная_иерархия
Без приучивания к справедливости (справедливым вершением суда взрослыми) она сама в головах возникает у подавляющего меньшинства детей, и переучить остальную стаю бабуинов к нормам солидарного общества они не в силах. Особенно в условиях противоправного давления взрослых.
Здравствуйте, Osaka, Вы писали:
O>Сами договариваться не научаются. Детские коллективы, предоставленные самим себе, самоорганизуются в обезьянью кастовую иерархию (нижестоящий всегда виноват и не имеет права даже подавать голос, вышестоящим его можно и нужно гнобить и мучить). lurkmore.to/Школьная_иерархия O>Без приучивания к справедливости (справедливым вершением суда взрослыми) она сама в головах возникает у подавляющего меньшинства детей, и переучить остальную стаю бабуинов к нормам солидарного общества они не в силах. Особенно в условиях противоправного давления взрослых.
Здравствуйте, alzt, Вы писали:
A>Какой статус? Если люди работают друг с другом то статус свой знают, и знают кто что стоит. Равноправия не будет
Тогда и проблемы нет. Синьер решил, делаем так-то и сяк-то, потому что ... и точка.
> но и какого-то превосходства тоже.
Тут не о превосходстве речь ("ваше превосходительство"), а о решении спорной ситуации.
A>Для начальства это будет выглядеть так, что опять эти дебилы поцапались друг с другом, решают с какой стороны яйца бить. A>Начальство часто решит не из-за каких-то только ему видных соображений, а из-за недостатка информации или просто лени, выберет случайным образом.
Технические специалисты — это не макаки, которые что-то там шлепают по клавиатуре, которым просто даешь еду, и в результате на выходе добавочная стоимость. Это люди, обычно взрослые, и у них есть свое мнение, в особенности в области своей профессии, и грамотный менеджер всегда будет учитывать их технические аргументы. Но не всегда они имеют решающий вес. Например, одно техническое решение может быть грамотнее другого в плане более грамотной архитектуры или более эффективных алгоритмов, но все это может быть не очень важно, например, по сравнению с возможностью вендор-локинга, который позволяет осуществить реализация другого технического решения. А технарям эти соображения могут быть вообще недоступны, т.к. бизнес-стратегия не их дело.
A>Я, например, обычно сразу обоих детей наказываю, и мне пофигу кто из них первый начал.
Почему вы думаете, что это адекватная аналогия? Такой подход может работать в случае с гребцами на галере или иными рабами на каменоломне, но не с квалифицированными специалистами.
A>Это в теории. А по факту даже в тех компонентах, в которых хорошо разбираешься, делать ревью это очень трудоёмкое занятие. Поэтому часто оно делается очень поверхностно. А если разбираешься в компоненте плохо (а такое часто), то в серьёз делать ревью как-то самонадеянно.
Да, разумеется, каждое ревью может отличаться по глубине анализа. В иных пулл-реквестах знаний ревьюера может хватать разве что для комментариев о стиле кодирования, ну там, переменная криво названа и т.п. И такие ревью тоже полезны. По-моему, с этим никто и не спорил.
Здравствуйте, $$, Вы писали:
>- Коллега предложил улучшение, как он считает, но вы несогласны, что это улучшение кто-то просил, и вообще.
Непонятно, что значит "это улучшение кто-то просил, и вообще"
>- Коллега саботирует ваш PR, просит переделать на, как он считает, более правильный дизайн. Но у вас всё и так работает.
Саботирует это твоя интерпретация каких то действий.
"И так всё работает" — это никогда не было аргументом. Это самое минимальное требование к любому решению.
А вот дальше надо выбрать то, что будет лучше вписываться в выбраный подход. Как у вас выбирается решение?
Итого — неясно, в чем же саботаж, не ясно, откуда взят "правильный дизайн" ?
>- Коллега ставит в известность о новых требованиях к юнит тестам в одностороннем порядке, по надуманным поводам- у вас все юнит тесты и так работали и вообще, у вас опыт юнит тестов больше.
"и так работали" — не аргумент
"опыт больше" — тоже не аргумент
Что за требования, что значит "одностороннем порядке" ?
>- Коллега под предлогом фичи затащил какую-то неведомую ###ю, взрывающую вам мозг, отличающуюся от привычного вам кодописательства.
Здесь какое то эмоциональное описание какой то неизвестной ситуации.
>Что вы будете делать? >Дискас.
Судя по тому, что ты пишешь, тебя не очень заботит, понимают ли тебя другие и понимаешь ли ты других. Похоже, что правильно только твоё мнение
Здравствуйте, alzt, Вы писали:
A>Главное, чтобы была бумажка, чтобы подтереть задницу. Если ты не работаешь в большой компании типа сбера, или у тебя начальство ну хоть немного разбирается и не собирает как ты бумажки, то твоя позиция выглядит так, что "мне всё равно, главное, что потом будет на кого свалить".
Моя позиция — каждый должен отвечать за свои косяки.
А тебе, похоже, эта идея не нравится?
Коллеге дали задание дофиксить баг, ну т.е. оно при corner case выстреливает. Чел медитировал пару дней, решил что надо рефакторить 3 класса, и это заодно исправит ошибку. Указал ему строчку, что там написать и баг был бы исправлен. На следующий день этот чел выкатил свой рефакторинг вместо фикса одной строчки, который походу откатил другие фиксы месячной давности и откатил юнит тесты (!) на тех фиксах. Потому, что он посчитал их "ненужными". Ну и в итоге пришлось самому эту строчку поправить.
Результат: на исправление 1 строчки бага потрачено 2 человекодня этого чела и еще 2 часа моего и других участников на обсуждения и пререкания.
Как сделать, чтоб в будущем такая ситуация не повторялась?
Здравствуйте, mik1, Вы писали:
M>1. Одна цель у одного диффа. Никогда не паковать несколько независимых изменений в один дифф. M>2. Сменить работу на более адекватную.
Ну, можно поспособствовать смене этого коллеги
Работа мне нравится.
$>Коллеге дали задание дофиксить баг.
$>Как сделать, чтоб в будущем такая ситуация не повторялась?
О как! У вас там bullying цветет! Для начала, стоит ответить на вопросы:
Почему исходный баг был недофикшен тем, кто его делал? (может быть масса причин)
Почему этот случай отдали новому разработчику, а не тому, кто делал фикс?
Почему ты сам не взял этот баг, если там нужно было пофиксить всего одну строчку?
Пути решения задачи обсуждались при назначении? Если да, почему не договорились до консенсуса? Если нет, почему еще не проводите planning pocker?
Теперь почему bullying и как это могло выглядеть с другой стороны (с точки зрения того коллеги). У вас есть какой-то модуль отвратительного качества. Там баги и после фиксов появляются новые. Т.е. уже несколько уровней костылей и подпорок. История это подтверждает — фиксер предыдущего бага так его до конца и не смог пофиксить. Коллега посмотрел на все это безобразие и заменил все это разваливающееся строение нормальной (концептуально простой) моделью, в которой исходный класс багов просто не возможен. Очень часто тесты при этом действительно страдают — потому что тестируют не пойми что, а не контракты (которых вообще нет, что и является причиной плодящихся багов). А потом пришла команда, откатила все и все-таки добавила костыли.
А вообще — тяжелая у вас атмосфера там в коллективе . Похоже, кто громче кричит — тот и прав.
M> Почему исходный баг был недофикшен тем, кто его делал? (может быть масса причин) M> Почему этот случай отдали новому разработчику, а не тому, кто делал фикс? M> Почему ты сам не взял этот баг, если там нужно было пофиксить всего одну строчку? M> Пути решения задачи обсуждались при назначении? Если да, почему не договорились до консенсуса? Если нет, почему еще не проводите planning pocker? M>
M>Теперь почему bullying и как это могло выглядеть с другой стороны (с точки зрения того коллеги). У вас есть какой-то модуль отвратительного качества. Там баги и после фиксов появляются новые. Т.е. уже несколько уровней костылей и подпорок. История это подтверждает — фиксер предыдущего бага так его до конца и не смог пофиксить. Коллега посмотрел на все это безобразие и заменил все это разваливающееся строение нормальной (концептуально простой) моделью, в которой исходный класс багов просто не возможен. Очень часто тесты при этом действительно страдают — потому что тестируют не пойми что, а не контракты (которых вообще нет, что и является причиной плодящихся багов). А потом пришла команда, откатила все и все-таки добавила костыли.
Наверное, именно так видит ситуацию тот коллега: куча кода отвратительного качества, который он не в состоянии понять. Поэтому он, вместо того, чтобы попытаться разобраться, предлагает выбросить непонятные ему фичи. Которые там появились не на пустом месте- это улучшательства для скорости, исправления багов и т.д. Потом ему показывают точку, куда надо вставить 1 строку кода, и даже шлют ему патч, ему остаётся только проверить, что проблема исправлена, и обновить юнит тесты. Но наш дартаньян просто уверен, что его рефакторинг нужен, и старательно выносит мозг нескольким людям. В итоге главный на проекте закрывает его PR. Но он опять открывает тот PR, о котором его никто не просил, и по поводу которого ему 2 более старших людей сказали, что это не нужно и фактически регрессия.
M>А вообще — тяжелая у вас атмосфера там в коллективе . Похоже, кто громче кричит — тот и прав.
Вот что делать с такими упёртыми людьми? Это только у русскоговорящих такое встречается- никогда не видел китайцев или индусов, которые мало того, что что-то не понимают, упрямо предлагают это выбросить.
$>Наверное, именно так видит ситуацию тот коллега: куча кода отвратительного качества, который он не в состоянии понять. Поэтому он, вместо того, чтобы попытаться разобраться, предлагает выбросить непонятные ему фичи. Которые там появились не на пустом месте- это улучшательства для скорости, исправления багов и т.д.
Тоже вариант. А с другой стороны (авторов кода) там напоминалки есть о том, что и зачем? Те же performance tradeoffs обычно оформляются в виде комментария. Правки багов — сложный вопрос. Желательно — минимум оставить комментарий. Без таких подсказок при чтении кода не ясно, специально ли код такой или предыдущий автор писал его в бреду и стоит улучшить. Еще интересно, как задачи распределялись, когда правился изначальный баг т.е. знала ли вся команда про него или только отдельные разработчики.
$>Потом ему показывают точку, куда надо вставить 1 строку кода, и даже шлют ему патч, ему остаётся только проверить, что проблема исправлена, и обновить юнит тесты.
Тикет на что был? На "вставить строчку и посмотреть, работает ли оно"? Или "исправить баг"? Это две разные постановки задачи. Что должен делать разработчик, если вдруг выяснится, что проблема не исправлена? Можно же было поставить задачу.
$>Но наш дартаньян просто уверен, что его рефакторинг нужен, и старательно выносит мозг нескольким людям. В итоге главный на проекте закрывает его PR. Но он опять открывает тот PR, о котором его никто не просил, и по поводу которого ему 2 более старших людей сказали, что это не нужно и фактически регрессия.
Ну... Ты же не ответил на вопросы, которые заоверквотил. А там могли быть намеки на то, что "предыдущий разработчик не справился, может ты сможешь?". Если это регрессия (и можно показать в приложении) — это же прекрасно. Можно показать на проблему и попросить так больше не делать в дальнейшем.
И еще один момент. А где были 2 более старших людя, когда ставили ему задачу и не сказали про наличие "улучшательств скорости и исправления багов"? Я не знаю как у вас в команде, а у нас постановка нужного контекста — прямая обязанность старших. Они должны следить, кто что знает а что — еще не знает. Проблема коммуникации — это всегда проблема двух сторон. И начинать ее исправление надо с себя.
$>Вот что делать с такими упёртыми людьми?
Обидно? Не признает он рангов в вашей неформальной иерархии?
Решать просто — давать им такие задачи, где упорство будет полезно? Т.е. что-нибудь сложное и достаточно изолированное, где они могут копать. Дальше смотреть по ситуации. Если справился — отлично, и дальше давать сложные задачи. Не справился — есть формальный повод уволить. А баги пусть правят те, кто их сделал. Или доводить задачу до конца — не царское дело?
$>Это только у русскоговорящих такое встречается- никогда не видел китайцев или индусов, которые мало того, что что-то не понимают, упрямо предлагают это выбросить.
Я индуса упертого и эгоцентричного встречал. Все разные. А у вас отбор перекошен. Вы алгоритмы (разворот списка) спрашиваете. Это сразу смещает вашу выборку на те страны, где на алгоритмы делается фокус в обучении. Плюс всякие участники (тем более победители) hackerrank и прочих имеют самомнение — они "уже добились". А добились они в том числе и за счет упорства. Если не нравится текущая ситуация — отбирайте по умению слушать постановку задачи. Это легко делается в процессе обычного интервью. Может, вам interview training нужен?
Здравствуйте, maxkar, Вы писали:
M>Без таких подсказок при чтении кода не ясно, специально ли код такой или предыдущий автор писал его в бреду и стоит улучшить
Похоже ты тоже из рода дартаньянов.
M> Еще интересно, как задачи распределялись, когда правился изначальный баг
Блин там у ангулара нужно дернуть detectChanges, потому что ngZone не контролирует и не знает, что вернулся ответ от бекенда. Так просто. Но наш дартаньян стремится всё переписать на собственное видение ситуации.
. А я изначально стоял за то, чтоб под конкретные задачи использовался максимально подходящий для их решения инструмент. 3 года потребовалось чтоб добиться этого. Но самое смешное, что сейчас большинство может просто охренеть от того, какой свободы для разработчиков удалось добиться и какого мегаконсервативного заказчика удалось пробить на магаэкзотику, не могу к сожалению говорить об этом, но кое кто, о ком точно никто никогда не подумает, и кто в России на слуху, де факто круче Тинькова со scala. Под экзотикой я даже не clojure и elm понимаю 
. Хоть там и маразмов от безопасников хватает, и это реальные маразмы, но по языкам программирования палок ни малейших.
