Здравствуйте, Артём, Вы писали:
Аё>С моим бывшим подчинённым уже был разговор и была PIP-ка. По итогу, он начал исправляться, и я сказал типа траектория правильная, чел хороший, оставим. Потом начался проектик с фичей непростой- я не смотрел за той фичей, но дал этого чела чтоб пилил гуй. Со стороны было видно, что "shit show" но я же дартантян типа нечего нагнетать. Да там неадекватно оценили гуй в "2 дня" хотя хз что там делать и как. Ну потратил бы 1 -2 недели в сумме, переключаясь на другие таски, пока бекендеры с бизнес аналистом на фиче запутались или не предоставили нужных данных для изменений в гуе. Но нет, потратил 3 мес, у деливери менелжера стало жим жим за сроки (изначально запас был конский), чтобы я включился и что-то сделал. В итоге зарелизили эту фичу в срок, но ценой подключения на гуй 2 бекендеров. Ну я там тоже чуть подфиксилпару мелких багов, пока у чела были длинные праздники.
Начну с того, что сроки — это, вообще, отдельная песня, особенно если задача нестандартная, которую раньше не решали. Terra incognita с огромными белыми пятнами. Если же типовая, рутинная, то спору нет. А так написать клон яндекса вполне могут оценить и в две недели. И раньше на электронных биржах так и оценивали, что интересно. Да и некоторые топы вполне тоже так могут и сейчас — они же не программисты, или давно потеряли связь с программированием. Это о сроках.
Второе. Почему ты о срыве сроков узнал не на второй или третий день, а только потом? Ты не контролировал?
Третье. А человеку под силу была задача? Может быть, ему лучше было дать другую?
Ну, ладно. Сделал и сделал. Теперь у тебя есть опыт
Здравствуйте, Артём, Вы писали:
S>>А вот это прям внезапно! Строки-то он наверняка на собеседовании успешно разворачивал, а в реальной работе что-то пошло не так? Аё>Разворачивал успешно. В работе мог над таской (тикетом) сидеть 2 дня там, где другой программист за полдня закрывал. Код писал нормальный.
А ты имел с ним какой-то разговор про это до этого?
Ну, то есть, рассказать ему на 1:1 что так и так, у тебя чувак проблемы с перформансом, и прям серьёзные проблемы, что случилось, почему так?
Ну, как-то сначала попробовать выправить ситуацию, до увольнения.
Здравствуйте, Артём, Вы писали:
Аё>Доводилась ли вам быть инициатором увольнения коллеги (6 лет вместе на одном проекте, ставил ему задачи в последние 4 года), с которым были нормальные отношения?
И вообще, знаешь, Тёма! Когда ты становишься начальником своего друга, или наоборот, ты становишься подчиненным своего бывшего друга, то дружбе приходит конец. По крайней мере, равноправия уже не будет. Будет что-то другое, но не дружба, не старые добрые приятельские отношения. Будет что-то другое. Просто так устроена жизнь. И переломить тенденцию бывает сложно (но возможно).
Ладно! То, что ты переживаешь — это хорошо. По-человечески хорошо, но начальником с этой чертой быть трудно (есть одно исключение — о нем ниже). Может быть, и к лучшему.
Что касается исключения. Умение сопережевать необходимо в коллективе творческих людей. Там без этого нельзя. Но у вас, наверное, больше бизнес, чем творчество.
Здравствуйте, Sharov, Вы писали:
S>PS: Не понял о чем речь -- о выживании откуда то сильных программистов (увольнение) или речь о жизни сильных S>путем увольнения слабых. Заголовок, конечно, мастрески составлен, понимай как хочешь.
У нас нет stack ranking- т.е. квоты на увольнение. Иногда происходит увольнение за перфоманс, после PIP. В данном случае оставили чела после PIP, и он вскоре расслабился, фича заняла намного дольше в итоге. Это повлияло на всех участников фичи (KPI).
Здравствуйте, Артём, Вы писали:
Аё>Разворачивал успешно. В работе мог над таской (тикетом) сидеть 2 дня там, где другой программист за полдня закрывал. Код писал нормальный.
ну вот смотри — я тут ковырялся с багой — самописный ланчер процессов — починить велосипед — дело получаса
но заменить самопомисный велосипед на буст процесс и обложить тестами — дело недели а то и больше
к тому же сам буст у нас не пользуется и его использование надо продавить
как поступил бы хороший программист?
или допустим — я могу сделать починку в течении получаса и тупо залить в гит ... а могу еще полдня погонять — работает ли ( причем втрую часть никто не увидит что я это делал)
значит впустую время провел, с точки зрения начальства
хотя разок сталивался и с такой ситуацией как у тебя — человек месяц или больше чинил багу — полез уже в системные библиотеки под мак
хотя она чинилась не таким уж страшным воркэраундом за полдня ... хотя программист был хороший
Здравствуйте, mukos, Вы писали:
M>ну вот смотри — я тут ковырялся с багой — самописный ланчер процессов — починить велосипед — дело получаса M>но заменить самопомисный велосипед на буст процесс
Переписать то, что работает- значит наплодить пачку новых багов. Кроме того, что проехать катком по самолюбию автора того вклосипеда. Одно дело, когла тебе дали задачу добавить фичу запуска процессов и ты выбрал буст вместо велосипеда& твоё право. И совсем другое- когда нужно поправить одну строчку и покрыть регрессионным тестом на тои конкретно corner case
Update
M>или допустим — я могу сделать починку в течении получаса и тупо залить в гит ... а могу еще полдня погонять — работает ли ( причем втрую часть никто не увидит что я это делал)
значит впустую время провел, с точки зрения начальства
Тупо залил и не погонял "исправлено ли" — такое у нас мягко говоря, не приветствуется и это повод для воспитательной беседы. Если у тебя начальство не понимает смысла проверять собственные изменения- ну не знаю. Может быть, ты зря наговариваешь на них?
Здравствуйте, Артём, Вы писали:
Аё>Здравствуйте, mukos, Вы писали:
M>>ну вот смотри — я тут ковырялся с багой — самописный ланчер процессов — починить велосипед — дело получаса M>>но заменить самопомисный велосипед на буст процесс Аё>Переписать то, что работает- значит наплодить пачку новых багов. Кроме того, что проехать катком по самолюбию автора того вклосипеда. Одно дело, когла тебе дали задачу добавить фичу запуска процессов и ты выбрал буст вместо велосипеда& твоё право. И совсем другое- когда нужно поправить одну строчку и покрыть регрессионным тестом на тои конкретно corner case
отчасти согласен, но есть такое слово рефакторинг
и если есть возможность повыбрасывать 3-4 файла самописного велосипеда и использовать код который оттестирован тысячами, если не миллионами программистов
и сделать код чище и понятнее для следующих программистов.
Да есть риск внесения новых багов, но и есть риск еще не обнаруженных багов в существующем — и опять придется ковырять этот велосипед.
... хотя может и пойду по первому пути — во первых не вижу энтузиазма со стороны начальства по поводу буста
а во вторых — на мне висит еще пачка достаточно суровых багов, которые надо до осени починить
Здравствуйте, mukos, Вы писали:
M>отчасти согласен, но есть такое слово рефакторинг
Есть, и работает в обе стороны.
M>и если есть возможность повыбрасывать 3-4 файла самописного велосипеда и использовать код который оттестирован тысячами, если не миллионами программистов M>и сделать код чище и понятнее для следующих программистов.
Буст Чище и понятнее Эти 2 понятия не уживаются в одном предложении.
M>Да есть риск внесения новых багов, но и есть риск еще не обнаруженных багов в существующем — и опять придется ковырять этот велосипед.
Да я согласен, что либа из буста если популярная, то явные баги поправлены и нет смысла изобретать велосипед с кривыми колёсами. Так не всегла бывает- либа может существовать, но оставляет желать лучшего в плане производительности например, или её экстра фичи, которые тормозят и не используются на проекте- дают повод для велосипеда.
M>... хотя может и пойду по первому пути — во первых не вижу энтузиазма со стороны начальства по поводу буста
Если ты уверен, что лиьа из буста в перспективе сократит расходы на поддержание велосипеда- обоснуй это с цифрами.
Возьми историю тикетов (git log в помощь), сколько суммарно было часов потрачено на починку того, что просто работает в бусте, добавь "и тут мы сразу кросс платформа, не нужно будет переписывать повторно" и замени.
Допустим, вместо 30 минут, ты вернулся через 3 дня, заменил велосипед на буст, все старые юнит тесты, интеграционные проходят, и да бонус- починен тот баг из тикета. Я бы такое перечислил в годовом перфоманс ревью, как пример хорошести этого программиста.
Но если вместо 30мин ты просидел 3 недели и вернулся ни с чем- тут уж принимай правила игры. Риск он такой- бывают выигрыши и бывают поражения.
M>а во вторых — на мне висит еще пачка достаточно суровых багов, которые надо до осени починить
Если эти суровые баги растут из велосипеда и пепестанут существовать от буста- это веский довод в пользу рефакторинга. Главное, чтобы в сумме estimates по всем этим багам ты не превысил в разы время и не оказалось, что ничего не починено.
Afterthought
К бусту полярные мнения, кто-то любит, кто-то ненавидит и ставит явный запрет на буст в полиси. Может быть, стоит поискать маленькую библиотечку с требуемой функциональностью, которая не тянет тонны зависимостей? На ёлку залезть и не бодаться про буст.
тут можно много чего сказать, но чтобы ты понял глубину глубин
— только в прошлом году у них появился гит, и только с моим приходом в этом году у них появились юнит тесты и cicd
Здравствуйте, velkin, Вы писали:
V>И дальше традиционные вопросы. Какова вероятность, что уволив кого-то с опытом 4-6 лет, с улицы где "за забором стоит очередь" придёт кто-то лучше? Не затребует ли новый сотрудник в новых экономических реалиях бОльшую зарплату, чем уволенный? Во сколько вообще обойдётся найм нового сотрудника, ведь "ошибаться" с наймом можно снова и снова, а кто-то тратит на это время? И более того, опытность новому сотруднику придётся набирать заново.
Это традиционные "мечты" программистов. В любой более-менее большой компании ни один менеджер так не думает. Это образ мыслей только самих разработчиков и собственников маленьких бизнесов.
Здравствуйте, Skorodum, Вы писали:
V>>И дальше традиционные вопросы. Какова вероятность, что уволив кого-то с опытом 4-6 лет, с улицы где "за забором стоит очередь" придёт кто-то лучше? Не затребует ли новый сотрудник в новых экономических реалиях бОльшую зарплату, чем уволенный? Во сколько вообще обойдётся найм нового сотрудника, ведь "ошибаться" с наймом можно снова и снова, а кто-то тратит на это время? И более того, опытность новому сотруднику придётся набирать заново. S>Это традиционные "мечты" программистов. В любой более-менее большой компании ни один менеджер так не думает. Это образ мыслей только самих разработчиков и собственников маленьких бизнесов.
Здравствуйте, Sharov, Вы писали:
V>>>И дальше традиционные вопросы. Какова вероятность, что уволив кого-то с опытом 4-6 лет, с улицы где "за забором стоит очередь" придёт кто-то лучше? Не затребует ли новый сотрудник в новых экономических реалиях бОльшую зарплату, чем уволенный?
S>>Это традиционные "мечты" программистов. В любой более-менее большой компании ни один менеджер так не думает. Это образ мыслей только самих разработчиков и собственников маленьких бизнесов.
S>А как думает менеджер?
Экономические реалии не новые- только добавляется новостей об очередном массовом сокращении. С разморозкой.
В нынешних реалиях почти каждого, включая меня, можно заменить на не хуже и при этом со скидкой.
Здравствуйте, Артём, Вы писали:
Аё>Экономические реалии не новые- только добавляется новостей об очередном массовом сокращении. С разморозкой. Аё>В нынешних реалиях почти каждого, включая меня, можно заменить на не хуже и при этом со скидкой.
Здравствуйте, Marty, Вы писали:
M>А чего ж не меняют?
Intel notified Oregon workforce officials earlier this week of plans to lay off more than 500 workers. But a revised tally, made public by the state Friday evening, raised the total to nearly 2,392. That makes the layoff among the biggest in state history.
But Oregon is Intel’s largest site anywhere. The company had 20,000 employees in Washington County at the start of the week, even after eliminating 3,000 jobs there last year through layoffs and buyouts.
Здравствуйте, Артём, Вы писали:
S>>А как думает менеджер? Аё>Экономические реалии не новые- только добавляется новостей об очередном массовом сокращении. С разморозкой. Аё>В нынешних реалиях почти каждого, включая меня, можно заменить на не хуже и при этом со скидкой.
Вообще говоря новые. И по сути идет ковидовая коррекция, когда набирали как не в себя.
Человек работает более 5 лет, а может и более 10 лет, мотивирован. Как его можно не хуже заменить со
скидкой? На долгосроке год-два -- возможно. А вот здесь и сейчас -- маловероятно. И да, я учел ai инструменты.
Здравствуйте, Sharov, Вы писали:
S>А как думает менеджер?
Циничнее и прагматичнее: проблемы компании это возможности для менеджера. Менеджеры, как и политики, думают не о том, как решить проблему, а о том, как использовать ее для увелечения своего влияния. Как говорил Черчиль:
Политик должен уметь предсказать, что произойдет завтра, через неделю, через месяц и через год. А потом объяснить, почему этого не произошло.
Здравствуйте, Skorodum, Вы писали:
S>>А как думает менеджер? S>Менеджеры, как и политики, думают не о том, как решить проблему, а о том, как использовать ее для увелечения своего влияния.
Звучит настолько же достоверным обобщением как и "программисты усложняют код и не пишут комментариев для обеспечения job security", имхо.
Здравствуйте, Артём, Вы писали:
Аё>Доводилась ли вам быть инициатором увольнения коллеги (6 лет вместе на одном проекте, ставил ему задачи в последние 4 года), с которым были нормальные отношения?
Аплодирую твоему начальству. Другой бы сказал — не могу увольнять, у меня с ним отношения норм, увольняйте сами. А вот ты всегда готов грести за них любое говно. Ну и прикольно было узнать, что в твое понятие "нормальные отношения" входит турнуть кого-то при случае. У тебя с бабой твоей тоже небось нормальные отношения .
Здравствуйте, so5team, Вы писали:
S>Звучит настолько же достоверным обобщением как и "программисты усложняют код и не пишут комментариев для обеспечения job security", имхо.
Это, конечно же, крайний случай, использованный для того, чтобы сдвинуть "среднее по больнице" подальше от предположений, что менеджер может переживать от том "Во сколько вообще обойдётся найм нового сотрудника". Не будет никакой менеджер так переживать, как бы программистам этого не хотелось. И как аргумент для повышения ЗП это не работает.
Здравствуйте, Skorodum, Вы писали:
S>>Звучит настолько же достоверным обобщением как и "программисты усложняют код и не пишут комментариев для обеспечения job security", имхо. S>Это, конечно же, крайний случай, использованный для того, чтобы сдвинуть "среднее по больнице" подальше от предположений, что менеджер может переживать от том "Во сколько вообще обойдётся найм нового сотрудника". Не будет никакой менеджер так переживать, как бы программистам этого не хотелось. И как аргумент для повышения ЗП это не работает.
Вообще-то это часть работы менеджера -- смотреть за тем, во что обходится убыль/прибыль личного состава. Как частный случай -- контроль за величиной bus factor-а.
Грубо говоря, если из команды выбывают навсегда пара-тройка ключевых разработчиков, то это становится проблемой менеджера, т.к. затыкание "дыр" в личном составе неизбежно скажется на сроках/стоимости.
Чище и понятнее 
