A>Я, например, обычно сразу обоих детей наказываю, и мне пофигу кто из них первый начал.
Т. е. жертва виновата, что сопротивлялась хулигану? А потом они удивляются, почему в стране одни овощи.
$>Что вы будете делать?
постараюсь оставить личное, я/он нравиться/не нравится хороший/плохой и быть конструктивным
свернуть все в коммерческую сторону. это не твой домашний проект, это работа.
клиенты платят за продукт/сервис/услугу и оплачивают труд разработчиков.
будь добр обоснуй в цифрах почему штука которую ты задумал/сделал окупиться и за какое время.
есть и другие варианты
-мы выплачиваем технический долг
при этом очень желательно проиллюстрировать что в этом месте у нас новые требования/баги которые дорого было фиксить
-мы делаем RnD, фиг знает что из этого выйдет
опять же как результат — рассказать всем получилось/нет, какие выводы
если коллега не в состоянии рассуждать на таком уровне — пойти к непосредственному начальству
тема разговора: коллега мешает работать, ты не понимаешь что он делает, он объяснить не может.
$>Сценарии:
$>- Коллега предложил
$>- Коллега саботирует
$>- Коллега ставит
$>- Коллега под предлогом
$>Что вы будете делать?
К тимлиду! Или к тому, кто там у вас ответственный за то, чтобы всё летало и не падало.
У вас там, похоже, нет ни правил, ни гайдлайнов. Либо на них давно забили. Фигачите каждый кто на что горазд. Вот и результат.
Здравствуйте, Osaka, Вы писали:
A>>Я, например, обычно сразу обоих детей наказываю, и мне пофигу кто из них первый начал. O>Т. е. жертва виновата, что сопротивлялась хулигану? А потом они удивляются, почему в стране одни овощи.
Это люди, которые друг друга очень хорошо знают, и им ещё долго жить вместе. Так что пусть учатся договариваться.
A>>>Я, например, обычно сразу обоих детей наказываю, и мне пофигу кто из них первый начал. O>>Т. е. жертва виновата, что сопротивлялась хулигану? А потом они удивляются, почему в стране одни овощи. A>Это люди, которые друг друга очень хорошо знают, и им ещё долго жить вместе. Так что пусть учатся договариваться.
Сами договариваться не научаются. Детские коллективы, предоставленные самим себе, самоорганизуются в обезьянью кастовую иерархию (нижестоящий всегда виноват и не имеет права даже подавать голос, вышестоящим его можно и нужно гнобить и мучить). lurkmore.to/Школьная_иерархия
Без приучивания к справедливости (справедливым вершением суда взрослыми) она сама в головах возникает у подавляющего меньшинства детей, и переучить остальную стаю бабуинов к нормам солидарного общества они не в силах. Особенно в условиях противоправного давления взрослых.
Здравствуйте, Osaka, Вы писали:
O>Сами договариваться не научаются. Детские коллективы, предоставленные самим себе, самоорганизуются в обезьянью кастовую иерархию (нижестоящий всегда виноват и не имеет права даже подавать голос, вышестоящим его можно и нужно гнобить и мучить). lurkmore.to/Школьная_иерархия O>Без приучивания к справедливости (справедливым вершением суда взрослыми) она сама в головах возникает у подавляющего меньшинства детей, и переучить остальную стаю бабуинов к нормам солидарного общества они не в силах. Особенно в условиях противоправного давления взрослых.
Здравствуйте, alzt, Вы писали:
A>Какой статус? Если люди работают друг с другом то статус свой знают, и знают кто что стоит. Равноправия не будет
Тогда и проблемы нет. Синьер решил, делаем так-то и сяк-то, потому что ... и точка.
> но и какого-то превосходства тоже.
Тут не о превосходстве речь ("ваше превосходительство"), а о решении спорной ситуации.
A>Для начальства это будет выглядеть так, что опять эти дебилы поцапались друг с другом, решают с какой стороны яйца бить. A>Начальство часто решит не из-за каких-то только ему видных соображений, а из-за недостатка информации или просто лени, выберет случайным образом.
Технические специалисты — это не макаки, которые что-то там шлепают по клавиатуре, которым просто даешь еду, и в результате на выходе добавочная стоимость. Это люди, обычно взрослые, и у них есть свое мнение, в особенности в области своей профессии, и грамотный менеджер всегда будет учитывать их технические аргументы. Но не всегда они имеют решающий вес. Например, одно техническое решение может быть грамотнее другого в плане более грамотной архитектуры или более эффективных алгоритмов, но все это может быть не очень важно, например, по сравнению с возможностью вендор-локинга, который позволяет осуществить реализация другого технического решения. А технарям эти соображения могут быть вообще недоступны, т.к. бизнес-стратегия не их дело.
A>Я, например, обычно сразу обоих детей наказываю, и мне пофигу кто из них первый начал.
Почему вы думаете, что это адекватная аналогия? Такой подход может работать в случае с гребцами на галере или иными рабами на каменоломне, но не с квалифицированными специалистами.
A>Это в теории. А по факту даже в тех компонентах, в которых хорошо разбираешься, делать ревью это очень трудоёмкое занятие. Поэтому часто оно делается очень поверхностно. А если разбираешься в компоненте плохо (а такое часто), то в серьёз делать ревью как-то самонадеянно.
Да, разумеется, каждое ревью может отличаться по глубине анализа. В иных пулл-реквестах знаний ревьюера может хватать разве что для комментариев о стиле кодирования, ну там, переменная криво названа и т.п. И такие ревью тоже полезны. По-моему, с этим никто и не спорил.
M>Начали писать более современный сайт + бэкенд переделывать постепенно, предложили ему поучиться, упирается, мол, я поддерживаю то, что уже работает, это новое мне не надо. Предложили тесты пописать, опять своё — я этот фреймворк не знаю, зачем вы меня туда тянете. Фактически,замкнутое сознание (fixed mindset). В результате из-за нежелания учиться + идти в ногу с командой его уволили, старые приложения переписали, все остались в плюсе, кроме него.
Могу лишь позавидовать грамотности руководства и правильной направленности.
В реальности же зачастую у таких gatekeepers, которые "давно сидят", может быть довольно много влияния, и они способны утопить очень много здравых начинаний.
Здравствуйте, $$, Вы писали:
>- Коллега предложил улучшение, как он считает, но вы несогласны, что это улучшение кто-то просил, и вообще.
Непонятно, что значит "это улучшение кто-то просил, и вообще"
>- Коллега саботирует ваш PR, просит переделать на, как он считает, более правильный дизайн. Но у вас всё и так работает.
Саботирует это твоя интерпретация каких то действий.
"И так всё работает" — это никогда не было аргументом. Это самое минимальное требование к любому решению.
А вот дальше надо выбрать то, что будет лучше вписываться в выбраный подход. Как у вас выбирается решение?
Итого — неясно, в чем же саботаж, не ясно, откуда взят "правильный дизайн" ?
>- Коллега ставит в известность о новых требованиях к юнит тестам в одностороннем порядке, по надуманным поводам- у вас все юнит тесты и так работали и вообще, у вас опыт юнит тестов больше.
"и так работали" — не аргумент
"опыт больше" — тоже не аргумент
Что за требования, что значит "одностороннем порядке" ?
>- Коллега под предлогом фичи затащил какую-то неведомую ###ю, взрывающую вам мозг, отличающуюся от привычного вам кодописательства.
Здесь какое то эмоциональное описание какой то неизвестной ситуации.
>Что вы будете делать? >Дискас.
Судя по тому, что ты пишешь, тебя не очень заботит, понимают ли тебя другие и понимаешь ли ты других. Похоже, что правильно только твоё мнение
Здравствуйте, alzt, Вы писали:
A>Главное, чтобы была бумажка, чтобы подтереть задницу. Если ты не работаешь в большой компании типа сбера, или у тебя начальство ну хоть немного разбирается и не собирает как ты бумажки, то твоя позиция выглядит так, что "мне всё равно, главное, что потом будет на кого свалить".
Моя позиция — каждый должен отвечать за свои косяки.
А тебе, похоже, эта идея не нравится?
Здравствуйте, Codealot, Вы писали:
A>>Главное, чтобы была бумажка, чтобы подтереть задницу. Если ты не работаешь в большой компании типа сбера, или у тебя начальство ну хоть немного разбирается и не собирает как ты бумажки, то твоя позиция выглядит так, что "мне всё равно, главное, что потом будет на кого свалить".
C>Моя позиция — каждый должен отвечать за свои косяки. C>А тебе, похоже, эта идея не нравится?
Есть позиция, что главное — интересы компании, а есть — главное, чтобы я не оказался крайним. Мне больше нравится первая.
Наличие справки "что я не виноват" никак не добавляет тебе полезности.
Здравствуйте, alzt, Вы писали:
A>Есть позиция, что главное — интересы компании, а есть — главное, чтобы я не оказался крайним. Мне больше нравится первая.
Без лохА и жизнь плоха.
Или, возможно, тебе больше нравится первая позиция, только когда это ничего не стоит тебе лично?
Коллеге дали задание дофиксить баг, ну т.е. оно при corner case выстреливает. Чел медитировал пару дней, решил что надо рефакторить 3 класса, и это заодно исправит ошибку. Указал ему строчку, что там написать и баг был бы исправлен. На следующий день этот чел выкатил свой рефакторинг вместо фикса одной строчки, который походу откатил другие фиксы месячной давности и откатил юнит тесты (!) на тех фиксах. Потому, что он посчитал их "ненужными". Ну и в итоге пришлось самому эту строчку поправить.
Результат: на исправление 1 строчки бага потрачено 2 человекодня этого чела и еще 2 часа моего и других участников на обсуждения и пререкания.
Как сделать, чтоб в будущем такая ситуация не повторялась?
$>Коллеге дали задание дофиксить баг, ну т.е. оно при corner case выстреливает. Чел медитировал пару дней, решил что надо рефакторить 3 класса, и это заодно исправит ошибку. Указал ему строчку, что там написать и баг был бы исправлен. На следующий день этот чел выкатил свой рефакторинг вместо фикса одной строчки, который походу откатил другие фиксы месячной давности и откатил юнит тесты (!) на тех фиксах. Потому, что он посчитал их "ненужными". Ну и в итоге пришлось самому эту строчку поправить.
$>Результат: на исправление 1 строчки бага потрачено 2 человекодня этого чела и еще 2 часа моего и других участников на обсуждения и пререкания.
$>Как сделать, чтоб в будущем такая ситуация не повторялась?
1. Одна цель у одного диффа. Никогда не паковать несколько независимых изменений в один дифф.
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 не контролирует и не знает, что вернулся ответ от бекенда. Так просто. Но наш дартаньян стремится всё переписать на собственное видение ситуации.
