Вторжение Дартаньяна

Добрый день.
Моя тема в чем-то похожа на тему со «стажировкой с говнокодерами», но с немного другой стороны. Работаю уже какое-то время в «старом-продуктовом-стартапе». Я тех-лид в маленькой и не очень квалифицироанной комманде. Компания не очень богата, и инженеры в основном середняки. Несколько пришло с Куа и студентов. У многих это первый пром. проект, Да и что говорить, что у меня самого опыта на тек. технологии-языке не очень много (1 год), хотя есть опыт в других проектах и т.п. Я могу еще сказать что наш код\уровень не выбивается с «общебольничного». Проект идет. Без фейлов с соблюдение сроков, без особых стрессов, учим джунов и т.п. Делаем рефактор часто в т.ч. MVP->BetterSolution->BetterThanBetterSolution. Такое себе болотце. Со своими радостями и горестями.

Теперь к теме топика. «Определили» к нам нового кодера. Типа оверквалифайед для той тимы кто его собеседовал, а нам мол помощь будет. Парень резкий (и умный). В курс дела входил не долго, стонал (натурально), а на второй неделе заявил что все ему по тек. солюшену ясно и начал коммитить и слать пулреквесты. В пул. реквестах меняется все:
— либы
— устоявшиеся методы обработки ошибок
— метод и глубина репортинга
вот реально 90% файла красные при диффе.

А сегодня не понятный ему фрагмент кода просто выкинул нах. А там бизнес логика условная. Попытались поговорить, так у него выплеснулось:
и это не то, и то не то, и вообще вся структура говно. Разве что про то что «вот вы все говно» не сказал вслух. По тех. части он возможно и прав, натыкал носом меня смачно. Но есть некоторые вещи которые если и менять (особенно работающие), то по всему проекту, а не только фрагментарно. Т.е. было работающее но не оптимально, мы меняем на работающее оптимально в 20% вхождений. Т.о. после пул реквеста — мы получим две версии одного и того-же. Ошибку о том что «не понял и выкинул» не признал. Коммуницировать апфронт инициативы отказывается (типа я пул. реквест создал — теперь ваше дело понимать о чем я хотел сказать). Я вот прямо читаю в его глазах «вы все гондурасы, а я Дартаньян». Вот теперь не знаю, как поступить. У кого были такие ситуации — дайте совет.

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Лучшие комментарии пропустить

Увольняй. Это джун-переросток.
Мало знать как выглядят лучшие практики, нужно ещё понимать что есть ценность продукта, когда она нужна, и что на самом деле продаётся.

Он готов НАЧАТЬ И ЗАКОНЧИТЬ это дело. Уверен, что нет. Коммитить когда риск и седые волосы у кого-то другого — любому джуну подвластно. А вот ДОПИЛИВАТЬ всё это до стабильного продакшена, который должен работать, и не только когда его админ наблюдает — вот в чём зрелость кодера.

Иными словами, ответственность, ответственность, и ответственность.

PS. Всегда говорил и буду говорить: перестаньте избегать конфликтов, а в стартапах — в особенности. Лучше провести 100 конфликтов и выйти с продуктом, чем натянуть отношения и устроить 1 эффектный разрыв с потерей всех инвестиций времени и денег. Особенно времени.

Пример: у меня сейчас в руках стратап, у которого пулл-реквестов перевалило за сотню, и багов было столько же. Сейчас баг остался всего 1, а пул-реквестов как и прежде куча. Но проект живой, и приносит денежку, и почти не падал. И вот только теперь будем готовы расширяться. Однако нанимать будем не кодера, а продажника и саппорт.
Выгода? Низкие расходы, практически никаких стычек, мало времени на отношения — больше на работу. Да, это тоже риск. Но для стартапа куда легче рискнуть недопродажами, чем разорвать из средины.

Смотри в чём проблема: Один человек демотивирует всю команду. В результате работает он один, затраты на всех, до конца он дело не доведёт. Почему не доведёт? Да потому что в идеях всё намного проще, чем когда его начинаешь претворять в жизнь. А реальный мир отмазки «почему не работает» слушать не будет. Есть что продавать — продаёшь, нечего продать — принимай претензии, а клиенты уходят к конкуренту.

Решение проблемы только одно: учитесь конфликтовать, учитесь противопоставлять ИНТЕРЕСЫ. Давайте друг другу понять, что уважаете друг друга, но ваши ресурсы не безграничны. А как раз наоборот, очень ограничены. И попытка сказать «это не мои проблемы» — означает настроить против себя команду, которая наоборот, готова решать все проблемы и добиваться совместного успеха.

Успех приходит не к умным. Это результат работы.

Напишите плиз название галеры, где простой грамотный гребец уже получает клеймо overqualified, а погонщик не может решить элементарный вопрос в команде без привлечения консилиума с DOU

Yevgeniy Shpika пишет:

Все время сталкиваюсь с ситуацией когда программисты не понимают специфику работы над кодом стартапа который стал бизнесом. За последнюю неделю раз 10 об этом разговаривал, сейчас вот на ДОУ срачик про д’Артаньяна завелся. Чувствую надо TLDR написать :)

Обычно история начинается когда стартап нащупал бизнес модель, превратился в бизнес и у него начали появляться деньги на расширение/улучшение. В этот момент компания нанимает какого нибудь квалифицированного чувака, который как-бы должен порешать технические проблемы — сделать все красиво и разобраться с техническим долгом который накопился за время поиска бизнес модели. И тут начинается самое интересное.

Приходит гуру-д’Артаньян который вырос в теплом ламповом окружении энтерпрайз/аутсорс проектов, уделял 50, а то и все 70, процентов своего времени самообучению. Он абсолютно точно знает как все делается правильно. И видит он перед собой продукт который сделан из говна и палок. Говно! Палки! Так же нельзя! Оно же завтра развалится! Вы все дебилы! Кто это вообще писал?! Это проще выкинуть чем переписать! В общем, сплошные максимы с ультиматумами.

Самая большая проблема в том что наш д’Артаньян не понимает что так сделано не случайно, так сделано специально. Sic!

По факту, 80-90%(а иногда и все 100%) кода, который производит стартап в первые пару лет своего существования, прийдется выбросить в мусорку. И люди которые работают над этим продуктом очень хорошо знают об этом. Они пробуют сделать очень большое количество очень разных вещей и практически все эти вещи прийдется выбросить — они не взлетели. Есть 5-10% полезной функциональности и культурный слой. Но этот культурный слой тоже нельзя просто выбросить, кто-то из пользователей продукта этим пользуется. Отломав, казалось бы, никому не нужную и непонятную кнопочку вполне можно поломать весь бизнес кому нибудь в солнечной Калифорнии. Те стартапы которые делают все правильно, с технической точки зрения, обычно не доживают до момента когда они могут нанять д’Артаньяна.

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

Peace!

Очень часто встречающаяся проблема — никто не хочет рабираться в чужом коде — все хотят его по быстрому переписать. За такое надо сразу бить по рукам — это не профессионализм.

Официально запретите ему рефакторинг: пусть старается заимплементить фичу как можно меньшим изменением кода.

Аргументация: тестов нет, в проекте он недавно — а значит может поломать то, что не понял или понял неправильно. Это раз.

Люди привыкли, что знают как все устроено, и просто так переписывать работающий код (даже если он его улучшает) — это снизить эффективность работы остальной команды.

За выпиливание кода дать по голове. И очень плохо, что он этого не признал. Т.е. вероятно повторение проблемы. Удалять можно только тот код, который на 100% понимаешь. Пусть расскажет, что делал выпиленный код

Вот пусть полгодика поработает, а затем уже можно и порефакторить.

Прощаться. Чем раньше тем лучше. Способность работать в команде и следовать правилам ценнее технических навыков. Бо последгние нарабатываются, а дартаньизм только лечить и то трудно и больно.

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

ИМХО,

д’Артаньян
ов надо увольнять, хорошего из этого не выйдет.

Это еще хорошо, что у вас через PR, а не на прямую изменения комитятся :)
Используйте этого Д’Артаньяна себе в пользу. Вы — лид, вы принимаете долгосрочные решения. А он вас прямо раскритиковал. Это нормально, что вы чего-то не знаете, ваша работа не только в технологиях разбираться, но и рулить. Вы работаете как команда. Каждый силен в чем-то своем.
Смотрите, как такие ситуации решаются в больших компаниях, где все процессы настроены и работают.
Посадите его писать план улучшения проекта, road map перехода на новые, более выгодные/современные технологии. Т.е. не создавать PR, там где ему _кажется_ надо по-другому, а создавать сначала план, с разбивкой на тикеты, с обоснованием выбора той или иной технологии. Этот план проверяется командой и утверждается. На тикеты из этого плана выделяется не все рабочее время Д’Артаньяна, а Х часов в неделю, утвержденных начальством. Потому что эта работа хоть и нужна, но не несет напрямую пользу бизнесу. Это не новый функционал, а профилактика, которая важна, но не должна занимать все время, например 20% от всех задач на проекте.
А там смотрите по ситуации. Или он вольется и будет приносить пользу не разрушительно, а так, как вам надо. Или сольется, потому у таких товарищей часто потребность быстро показать какие они крутые и ткнуть носом других, а план писать — это долго и там вздыхать надо будет по другому поводу :)

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

Вообще да, практика показала, что такие молодцы приходят, все разваливают и быстро уходят, оставляя после себя руины и кучу всего непонятного, что остальным разгребать.
Такие молодццы наиболее полезны в полу\самостоятельно педаленьи новой фичи, модуля или аппликухи, которые с основным кодом вообще никак не связанны.

Такие молодцы полезны везде, если уметь ими пользоваться.

«Руководить — это значит не мешать хорошим людям работать» (Капица). А всякие хреновые начальники, которые трусятся за свое кресло, нанимают подчиненных еще хуже и выживают талантливых, чтобы не подсидели.

«Прихожу, смотрю код не делает ничего полезного. Выкидываю непонятный кусок кода. Оставшийся код продолжает не делать ничего полезного, но... минус одна проблема :)»

А если серьезно: дали гиперактивного чувака, который технически круче — пользуйтесь. Пока что вы обиженно смотрите на первое настоящее код ревью своего кода. В плане: не тогда когда обученный вами джун говорит «вроде все ок, мержуй», и не когда архитектор которого со всех сторон дергают, с мыслью «пока работает, хай работает, если шо потом перефигачим» говорит «ок, все нормально, продолжайте в том же духе». Тем более:

MVP->BetterSolution->BetterThanBetterSolution
хай пилит MVP, по определению это что-то новое, ваши хатки не поломает, захотите — доделаете/переделаете, при этом может чему и сами научитесь.

Як на мене — головна ідея в тому, що потрібно бути командою перш за все. До ідей, які йдуть у розріз ( більша частина пулл ріквеста — червона) потрібно підходити спільно. Це все на рівні психології, і напряму задіває професійні якості інших людей. Де гарантія того, що саме його коміти — не «гамно»? Він точно не може сказати, а інші не раді, що до таких глобальних речей лізуть без їхнього відома. Тому і назріває конфлікт. Потрібно сісти, обговорити проблеми і спільно дійти до рішення. Ніхто не ідеальний і сприймати критику завжди добре. І тоді всім буде ok. А на рахунок цього чувака можу сказати, що з такими замашками він показує себе як людину, яка невзмозі розвиватись команді — а це одне з найбільших проблем. ІМХО, якщо вона портить колектив і атмосферу на проекті — такі елементи не повинні впливати на команду. В тімки врешті решт є свій лідер, який відповідає за проект і останнє слово за ним.

Напишите название вашего модного старпапа, пожалуйста.

Разок сроки завалит и дойдет, главное чтобы не на Вашем продукте.

Нормально всё чувак вам распедалил. Зачем было писать фуфло? Ваша и вина. Скажите спасибо, что товарищ не бросил всё и помогает вам поправить.

А если учесть что чувак:
— не внимательный к деталям
— склонен к «act first, think later»
— не способен придерживаться плана\скоупа работ
— не способен строить коммуникации на базовом уровне и убедить в своей правоте \ принять чужую \ найти компромиссную точку зрения
— проблемный в общении, с непомерным ЧСВ и порой скатывается до еле прикрытого хамства
— менеджмент (персональный и технический составляющие) такого человека в итоге обходится дороже двух новичков, хотя предполагалось что он сможет «контрибютить с порога».

По-прежнему будете считать результаты «педалирования такого чувака» полезными ?
И по поводу фуфла. Вот завтра придет «будуший автор Фейсбука» в проект и скажет, что все что «не руби» — то фуфло, побежите за ним переписывать .net код ? У нас был такой кейс. Харизматичный лидер повел за собой. Потом гуру свалил, и тима осталась с микросервисом на руби и годом работы на руках среди зоопарка других технологий на остатках .net монолита

— не внимательный к деталям
— склонен к «act first, think later»
Это его минусы, но, я бы не сказал, что это что-то уникальное. Это можно воспитать.
не способен придерживаться плана\скоупа работ
Правильно построить процесс — это задача двух сторон. Учитвыая, что он недавно пришёл, то тот факт, что он не выдерживает план, это вполне нормально. В незнакомом (а ещё я так понял и плохо написанном) проекте выдержать план можно, если только сам его писал.
не способен строить коммуникации на базовом уровне и убедить в своей правоте \ принять чужую \ найти компромиссную точку зрения
Это вообще звучит как «надо услышать Донбасс». Я так понял, в этом пункте вы просто уязвлены, что конкретно вашу точку зрения (не факт, что 100% верную) он не принял беззаговорочно.
— проблемный в общении, с непомерным ЧСВ и порой скатывается до еле прикрытого хамства
Это вообще ваше личное мнение. Я уверен, что такое можно про любого человека сказать в разных обстоятельствах. Я знал кучу добрейших людей, которых обстоятельства доводили чуть ли не до швыряния стульями. Учитывая какая у вас атмосфера рабочая, я думаю, что надо спасибо эту человека сказать, что он ещё держится. Может вы просто не хотели найти общий язык с ним?
менеджмент (персональный и технический составляющие) такого человека в итоге обходится дороже двух новичков
Нанимайте двух новичков. Какая проблема? Только потом за ведение вашего проекта вы будете платить такие деньги, что вам эти новички в страшном сне будут сниться.
хотя предполагалось что он сможет «контрибютить с порога».
Ой, ну вот это вообще финал. Мне уже потихоньку раскрываются детали работы в вашей компании. Предполагалось что человек начнёт сразу делать важные и ценные изменения в вашем проекте? Вот так со старта, не зная проекта? Не зная специфики вашего проекта, а я так понял, что она у вас есть.

Ох был я таком проекте один раз, с таким вот как вы руководителем тоже. Каждый день на daily митинге у нас натурально была война по каждому вопросу. И то не так, и то не туда, а у нас тут так, а ты то. И часов перебрал. В общем, проклял всё на свете.

Мой вам совет, просто договоритесь с этим человеком о спокойном расставании. Я вижу, что вы свои взгяды менять не собираетесь, он тоже не гнётся. Зачем друг друга мучать? Берите себе юниоров и лепите из них кого хотите под себя.

Представьте, вы приглашаете к себе в гости человека, с которым только познакомились, а он начинает переставлять все вещи у Вас дома ибо «не по фэншую». Ваша реакция?

Ну смотря какая ситуация )))) Например если такая — www.youtube.com/watch?v=wWmRTjLRMfU то молча слушайте и беспрекословно выполняйте каждую команду ! Особенно если ограничены временем )

Более верная аналогия — вы вызвали сантехника, устранить проблему, а хлещет так что вы уже по пояс в говне. Но запрещаете ему применить трос для прочистки труб (мы так не работаем) и использовать каустическую соду для удаления засора в трубах — только вантуз и молитвы духу Agile. Реакция нормального сантехника?

Нет ты совсем не прав. Главное свойство стартапа это быстрый рост и прибыльность. Если этого нет и бизнес недоволен абсолютно неважно насколько пофеншую все сделано. В любом деле важен успех правильно? Разработчик со свободного рынка как пришел так и уйдет а стартап останеться на руках создателей. Не нравится фреймворк? Не технологично все сделано? Внезапно захотел переделать все под себя? Все это для меня как для разработчика понятно но все-таки это не правильно и к стартапам неприменимо. Характерно что позиция очень многих разработчиков противоречит например лекциям в стенфорде где опытные стартаперы и менеджеры учат как делать правильно

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

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

А люди которые делали проект до вас не профессионалы? Вы не забывайте что кроме вас в команде такие же разработчики и многие не хуже вас. В итоге вы приходите и начинаете критиковать других людей в команде, считаете их ниже себя но все равно пришли работать в эту команду. Проблемы конешно есть и люди это понимают но если бизнес начал тонуть то это как минимум значит что проблема это не разработчиков а отдела продаж. Разработчик делает и доводит до работающего продукта а будут ли за это платить деньги достаточные для устойчивого роста это вопрос только к менеджерам

Нужно внимательнее читать комментарий на который отвечаете.
Все еще не читатель? Не надо додумывать и мне приписывать какую-то ересь:
А люди которые делали проект до вас не профессионалы? Вы не забывайте что кроме вас в команде такие же разработчики и многие не хуже вас. В итоге вы приходите и начинаете критиковать других людей в команде, считаете их ниже себя но все равно пришли работать в эту команду.
Я писал про технический долг и вопиющие проблемы, которые надо устранять (откачивать говно) пока не поздно. Проблема — код, а не люди. Не надо судить меня по себе.
Разработчик делает и доводит до работающего продукта а будут ли за это платить деньги достаточные для устойчивого роста это вопрос только к менеджерам
Вначале проекта когда пишут с нуля так и есть, но без устранения технического долга время имплементации растет в сказочной прогрессии: фичу на день можно приделывать неделю, потом месяц, потом полгода, а потом все развалится.

Но я ваш менеджерский подход понял: «Корову надо меньше кормить и больше доить »

Все еще не читатель? Не надо додумывать и мне приписывать какую-то ересь:
ну вот видите вы критикуете не поняв.
Почему-то только в ИТ считается нормой вмешиваться в работу профессионала (который получает за это деньги), это я про бизнес. К хирургам или там слесарям никто не вмешивается в их работу, им платят деньги, они решают проблемы. Меня эта тенденция по вмешательству в ИТ неприятно удивляет
к вам в работу лезут ТАКИЕ ЖЕ разработчики это скорее консилиум настоящих профи хирургов а не люди случайные которые мешают вам работать. Остальные ваши аргументы очевидные и я с ними согласен
Но я ваш менеджерский подход понял: «Корову надо меньше кормить и больше доить »
ну не правда я не говорил такого и в корни не согласен
к вам в работу лезут ТАКИЕ ЖЕ разработчики это скорее консилиум настоящих профи хирургов а не люди случайные которые мешают вам работать.

хех, лезут есстественно. Зато как линяют ( ! ) при проявлении первых негативных последствиях консилиумных решений ))) И массовая амнезия как явление вовсе не миф. И вообще «мы ж коллективно решение принимали» методом среднего арифметического. И вообще не помним ибо «давно было, а мы так скраю координировали» ...

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

Более верная аналогия
Нет , это менее верная аналогия. Автор написал
Проект идет. Без фейлов с соблюдение сроков,
Делаем рефактор часто в т.ч. MVP->BetterSolution->BetterThanBetterSolution
Это не значит
а хлещет так что вы уже по пояс в говне
а как раз больше похоже на
Представьте, вы приглашаете к себе в гости человека, с которым только познакомились, а он начинает переставлять все вещи у Вас дома ибо «не по фэншую». Ваша реакция?

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

Вы его же за этом и позвали вообще-то. Зачем звали-то тогда?

конечно волнует, я пригласил его подобрать шторы в тон обоям, а не стены двигать.

Нормальный оформитель интерьеров -должен предложить, как минимум 3 варианта.
Начиная от бюджетного -подобрать просто цвет обоев, и заканчивая перепланировкой квартиры и подборкой мебели и стиля..
Если вы будете ему затыкать рот, уважающая себя специалист -развернется и уйдет.
А заткнет рот и будет раболепно вас слушать только гастербайтер, или как тут называют специалист с «опытом», заробитчанин, который " уже умеет" молчать в тряпочку..

Так у вас гардины разваливаются, штукатурка со стены сыпется, отверстия в стене просвелить невозможно под новые гардины. Что ж вы хотели?

Я прекрасно знаю этот подход у хитрожопых манагеров. Отдать проект дешевым юниорам, они его будут убивать годами, а потом пригласить сеньора, чтобы он «баги пофиксил». Когда сеньор предоставляет программу модернизации проекта, то владелец обсирается от объёмов. Так нехрен было угаживать проект.

Вы как мою команду последний месяц описываете

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

Если вкратце, то главное резюме: надо было выявить засранца раньше. А именно:
— надо было настоять на интервью в комманде, а не доверять результатам коллег.
— если уже просмотрели вы.щика, то с первых дней пытаться понять чем дышит человек, а не кивать головой на высокопарный бред на стендапе. Мой личный урок — не стесняться микроменеджить даже гонористого синьора. Как говорил мне когда-то один ПМ: — Доверие надо заслужить (мне тогда обидно было)
— обнаружив проблему не стесняться эскалировать, а не пытаться списать все «ну он может новый, опять недопонял что ему уже 3 раза говорили»
— привлечь 3-ю сторону на эскпертизную оценку раньше, не пытаться решить «по-хорошему», «не травмировать», не списывать на недостатки понимания языка, не боятся выглядеть глупо с «устаревшими и не <looks shiny=»"> пассажами в коде«.
— минизировать временные потери комманды, лимитированием времени и определением майлстоунов. Как-то так.

Кстати, сегодня получил от топ-техник-персоны компании ревью архитектуры: «well crafted solution», Масштабируется, версионируется, модулируется. Кстати на этом он и «спалился». Я в этом «бизнесе» уже более 10 лет и переел собак достаточно всех мастей. Внутри код не всегда лаконичен (опыта 1 год), но это специфика таких проектов, их делаешь сателитами главных игроков. К тому-же «ненакрученый кодстайл» я считаю допустимой ценой за легкую читаемость в проекте где много джунов. Я даже нашел доклад по нашей проблеме на одной из свежих топ-конференций, где в предлагаемом солюшене совпало реально более 90%. Вообщем за архитектуру я был уверен, а он не меняя тона переходил с микронападок на общесистемный уровень.

Кстати и на микроуровне не все гладко было. Нашел в реквестах д’Артаньяна еще один фрагмент с удалением условной логики, при рефвкторе на «новую сервисную либу». Это больше утвердило меня во мнении, что зуд в точке был первичным, а не просто наивное стремление к прекрасному. Да и стар он был как для юнца. Или хитер чрезмерно (тут я не уверен), в любом случае выпадал из «известных паттернов» разработчиков, чем дурачил всех вокруг.

Вы как лид тут виноваты полностью, и этим постом это просто подтвердили... это же просто супер история. Сначала пришел кто то кричал что он мега умен... но вот в конце спринта, смотрите как я его победил. Полный бред

Да конечно, что виноват. Копнуть чуть глубже на собесе — не было повода для истории вообще.

Ура-а-а-а! Ви захистили своє право гавнокодити і надалі!
А Дартанян піде тепер працювати на який-небудь Епл чи Гоголь, напише чергову вбивцю Фейсбука, а співпрацю із вами буде згадувати як непорозуміння чи поганий сон.
І ніколи й нікому не буде розказувати цієї історії, як його занесло працювати на говнокантору.
Бо буде реально стрьомно про таку помилку говорити.

Та да, Трупы единорогов уже складывать некуда. “Як подумаю, так зразу багатію”. А если серьезно, я поделился своим опытом, прошу не обижаться если кто-то узнал в истории себя. И не торопитесь с навешиванием ярлыков. Такие люди полезны, и многие отмечали, что могут быть использованы, будучи направленными и контролируемыми. Но для этого нужно быть способным к коммуникациям. Мне неравнодушные коллеги больше импонируют (сам такой), поэтому думаю понятно разачарование комманды, когда вместо увлеченного и граммотного сотрудника получили неадеквата. В той или иной мере было перепробовано почти все указнное здесь, но человек просто не реагирует, в конце концов приходит письмо: please stop working on his PR’s от не выдержавшего PO. Всем добра

хорошо бы в этой истории услышать всех а не только вашу отфильтрованую информацию. В итоге как вы утверждаете «сениор» внезапно таковым не оказался и позволял себе коммитить баги. В вашей ситуации остались недовольны и он и команда разработки и тот кто находит деньги под все это. Было бы нечесно винить только одного

Я тех-лид в маленькой и не очень квалифицироанной комманде. Компания не очень богата, и инженеры в основном середняки
вы ожидали что человек будет прислушиватся к вашему мнению если вы сами считаете что не умеете программировать и унижаете своих колег?
напише чергову вбивцю Фейсбука

Не напише. Бо там вміння зробить щось _працююче_ стоїть над всіма планами зламать і збудувать з нуля.

Бо буде реально стрьомно про таку помилку говорити.

Буде стрьомно, але не тому.
Якось в нашій техпідтримці працював дуже норовистий хлопчина, який одного разу доводив клієнту, що той неправий, хоча сам був винний, і на пряме питання «Ви що, говорите, що я збожеволів?» відповів «так».
Більше він роботи тут не найшов, і зараз щось робить у Москві ;)

Кстати, сегодня получил от топ-техник-персоны компании ревью архитектуры: «well crafted solution», Масштабируется, версионируется, модулируется.
CEO одного крутого стартапа звонит CTO другого крутого стартапа и спрашивает — «Что нам задали по математике?»

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

не стесняться микроменеджить даже гонористого синьора.
Доверие надо заслужить
я считаю допустимой ценой за легкую читаемость в проекте где много джунов
Охренительно.
не стесняться микроменеджить даже гонористого синьора.
Вот это кстати оч зря.

Вы не сработаетесь. Уволится или вы уволите.

Я вот в роли дартаньяна тоже бываю. Попал в говноконтору, случайно. Даже 4 месяца проработал. Разошлись в полном недоумении. Они небось меня тупым еще считают. Но ТАКОЙ АД в коде, что не передать. В 10-тки раз кода больше, чем должно быть. Даже самая мелкая задачка перерастала в проекты с сотнями строк кода у них. Не поверите, даже то, что я переписывал в ОДНУ СТРОЧКУ, там могло быть на несколько сотен.

Меня наняли как крутого программиста, который там что-то сделает. Я честно пытался, но такое же отношение как у вас. Попытки микроменеджмента. «Мы всегда так делали и значит так правильно».
Вот у вас там в списке написано, что

— устоявшиеся методы обработки ошибок
чего? У вас язык с эксепшинами работает? И есть свои устоявшиеся методы обработки ошибок???
За такое расстрел на месте. Без следствия.

Ушел оттуда. Пошел в другую контору. Тоже говнокод, хотя чуть лучше. Тут не сопротивлялись, за пару месяцев просто нафиг выкинул практически всё с сервера, переписал. И внезапно! Разработка раз в 20 по скорости увеличилась. Баги исчезли.
то, что писали пару лет неправильно, оказалось гораздо выгоднее переписать. За этот год я сделал НАМНОГО больше, чем если бы я поддерживал старые подходы.

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

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

Но вы не сработаетесь скорее всего.

Что сказать. Перед тем как увольнять, я бы сделал отдельный бранч под этого парня и скал бы ему. Дружище, ты в этом бренче можешь менть всё что хочешь, рефакторь себе, удаляй код, делай как хочешь — вот тебе полная свобода. А я приду к тебе в конце месяца и мы посмотрим, что ты там накодил. Ну и действительно, сделать code reivew. Посмотреть сломает он его окончательно, или там будут какие то здравые мысли. Ну и дальше уже смотреть по ситуации.

Да, какой из этого профит... Да профит таков, что если там будут зравые мысле и человек дейсвительно, славный малый, то такими кардами не разбрасываются... Нужно возможно сделать под него отдельную ветку, что бы он занимался скажем архитектурными вопросами, ну и естественно потом мержил свой код в основную ветку и потом всё работало... Тогда он вохможно сможет вытнянуть проект на новый уровень ну или не справится и тогда ему (для его же блага) лучше подальше от Вашего проекта бежать, на нормальный проект, где он сможет стать профи и работать через несколько лет в каком нить Google или создать свой стартап (ну если он действительно умный как Вы говорите). А вы пилите себе свою «какашку» и кормитесь с этого. Как то так ИМХО )

Хороший метод, только пусть делает бесплатно. А если понравится то заплатить.
А то ты так легко деньгами компании швыряешься.

А то ты так легко деньгами компании швыряешься.
Ну просто автор топика как бы написал:
Типа оверквалифайед для той тимы кто его собеседовал, а нам мол помощь будет. Парень резкий (и умный).
Ключевые слова: оверквалифайед и умный.

Если бы эти слова не прозвучали, я ему не дал бы ни цента, пока толком его не прособеседовал, понял уровень, сделал бы несколько спринтов по неделе — две максимум.
И что бы он после каждого делал демо. А там будет видно, бесплатно или нет. Просто если человек грамотный, и действительно дело говорит, а главное «правильно» дело делает, то за бесплатно может не согласиться, или вообще обидеться.
Я бы по крайней мере, если бы мне сказали после собеседования (поняв что я например нормальный девелопер) — поработай ка парень на шуру, оттуда свинтил бы без объяснений в 99% случаев.

За бесплатно никто не согласится, кроме откровенно отчаянно ищущих работу, а такие практически никогда не нужны.

Мне кажется таких людей вообще нанимать в команду нельзя. Вся команда разбежится. Вполне может неплохо быть нанять контрактором на решение конкретной проблемы.

Мне кажется таких людей вообще нанимать в команду нельзя. Вся команда разбежится. Вполне может неплохо быть нанять контрактором на решение конкретной проблемы.
Что же это за комманда, которая разбежится из-за одного дева ?
Думаю нет. Думаю будет разговор у них, и либо дартаньян им объяснит на пальцах, что мол ребята, я больше понимаю чем Вы и сможет это аргуменированно объяснить. И ка крезультат образуется новая структуа комманды, в которой появится архитект.
Либо комманда этого товарища не примет так сказать. И попросит идти куда подальше.
Ну а дальше уже вопрос менеджмента, как это всё разрулить, кого куда перевести и т.д.
Так вот мего синьор дев завалил меня письмами по поводу того что у него солюшн не компилится, он не знает в чем причина и тд, в итоге этот олень потратил неделю на установку новой студии (хотя мог просто локально закомментить 3 куска кода). я тогда о**ел
Я скорее ох*еваю с тех, кто бросает солюшен, который не компилится. Как такое вообще допустимо?
Я скорее ох*еваю с тех, кто бросает солюшен, который не компилится. Как такое вообще допустимо?

Один из всех не проапгрейдился.
Но тут такой вопрос — было ли «сверху» сказано апгрейдиться (а с учётом тонкостей VS это может быть длительным и болезненным процессом). Если да — его вина, что протормозил, если нет — скорее руководства.

Бардак дело обычное. Мест без бардака не бывает

как-то пришлось мне юзать С#6 фичу по стринг интерполяции
Боюсь даже подумать как бы вы проект написали, пацыки, если б не было этой фичи из шестой версии языка. Уууу ...
этот олень
Когда заходишь на английский форум и задаешь вопрос — тебе долго и тщательно отвечают и советуют.
Когда задаешь вопрос на израильском форуме — тебе отвечают вопросом.
Когда задаешь вопрос на русском форуме — тебе долго и нудно разъясняют, какой ты мудак.

Если конфликт длится менее месяца, то попробуй делегировать часть tech-lead полномочий. Тем более, что его квалификация как тех специалиста выше твоей и любого другого коллеги из команды. Убедись перед этим, что остальные считают его профессионалом. Разреши ему принимать архитектурные решения, инициировать рефакторинг, если надо — таскай на обещение с product owner или менеджерами. С этими правами придут обязанности, которые он должен подвердить вслух и письменно (почта). Уж какие это обязанности, ты и сам отлично понимаешь )

Если конфликт тлеет давно, или человек г-ный сам по себе и не готов принимать ответственность за свои действия — увольняй

Хай тести напише на старий код, потім рефакторить. Інакше як ви будете знати що новий код працює так само як і старий?

Интересное видео на частично похожую тему:

Александр Соловьев ’Как modnaKasta трансформировалась’
www.youtube.com/watch?v=WssdWSbAPKE

Yevgeniy Shpika пишет:

Все время сталкиваюсь с ситуацией когда программисты не понимают специфику работы над кодом стартапа который стал бизнесом. За последнюю неделю раз 10 об этом разговаривал, сейчас вот на ДОУ срачик про д’Артаньяна завелся. Чувствую надо TLDR написать :)

Обычно история начинается когда стартап нащупал бизнес модель, превратился в бизнес и у него начали появляться деньги на расширение/улучшение. В этот момент компания нанимает какого нибудь квалифицированного чувака, который как-бы должен порешать технические проблемы — сделать все красиво и разобраться с техническим долгом который накопился за время поиска бизнес модели. И тут начинается самое интересное.

Приходит гуру-д’Артаньян который вырос в теплом ламповом окружении энтерпрайз/аутсорс проектов, уделял 50, а то и все 70, процентов своего времени самообучению. Он абсолютно точно знает как все делается правильно. И видит он перед собой продукт который сделан из говна и палок. Говно! Палки! Так же нельзя! Оно же завтра развалится! Вы все дебилы! Кто это вообще писал?! Это проще выкинуть чем переписать! В общем, сплошные максимы с ультиматумами.

Самая большая проблема в том что наш д’Артаньян не понимает что так сделано не случайно, так сделано специально. Sic!

По факту, 80-90%(а иногда и все 100%) кода, который производит стартап в первые пару лет своего существования, прийдется выбросить в мусорку. И люди которые работают над этим продуктом очень хорошо знают об этом. Они пробуют сделать очень большое количество очень разных вещей и практически все эти вещи прийдется выбросить — они не взлетели. Есть 5-10% полезной функциональности и культурный слой. Но этот культурный слой тоже нельзя просто выбросить, кто-то из пользователей продукта этим пользуется. Отломав, казалось бы, никому не нужную и непонятную кнопочку вполне можно поломать весь бизнес кому нибудь в солнечной Калифорнии. Те стартапы которые делают все правильно, с технической точки зрения, обычно не доживают до момента когда они могут нанять д’Артаньяна.

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

Peace!

Можно было сократить до 1-й строки: «хавайте шо дают, я начальник, ты — дурак. Греби в говне, а разгребать даже не смей».

в продуктовом стартапе должна быть обратная совместимость: изменять сигнатуры нельзя
то что вы говнокодите это ваш провтык
чувак делает все правильно: он не ломает вам репо — он делает пулл реквесты — ваше дело, что в них поменять

Подивитися по коментарям, та тут більшість пропонують звільнити людину )
Дуже дивно, насправді. По нормльному, було б добре почути і сторону того програміста, але і з існуючої інформації можна сказати наступне: ...

Работаю уже какое-то время в «старом-продуктовом-стартапе». Я тех-лид в маленькой и не очень квалифицироанной комманде.
Хоч проект старий, але стартап і команда не велика. Можна зробити висновок, що проект не занадто великий розростись встиг (скажем, менше, ніж ERP для невеликого банку).
В курс дела входил не долго, стонал (натурально), а на второй неделе заявил что все ему по тек. солюшену ясно
Два тижні — це не так мало. З наявної інформації про проект, можна зробити припущення, що і за менший проміжок часу можна було створити уявлення про основні речі, які треба знати про проект.
По тех. части он возможно и прав, натыкал носом меня смачно.
Тобто ви погоджуєтеся з великою кількістю його тез. Тобто людина знає про що говорить.
Но есть некоторые вещи которые если и менять (особенно работающие)....
Не забувайте, що людина нова і може не знати де у вас там що використовується в деталях.
Ви ж рев’ю робите — тут ваша задача тикнути носом.
В пул. реквестах меняется все ...
Просто так люди не генерять 100500 стрічок коду, щоб виправити несправедливість цього світу.
Тобто людина загорілася ідеєю зробити проект кращим.
----------
В результаті маємо команду яка не хоче порушувати свій звичний режим життя, і людину, яка готова міняти весь світ)

Ви самі визнали, що людина знає свою роботу. Як думаєте, що простіше:
1. Направити роботу енергійного новачка в корисне русло і навчити його працювати в команді.
чи
2. Виростити з крутого командного гравця з досвідом хіба що верстки, адекватного програміста?

Як на мене, виростити талановитого програміста — в рази важче.

З очевидних рішень:
1. Чому він взявся за рефакторинг всього і вся? Ви ж керуєте процесом? Ви давали йому задачу? Ви впевнені, що він її може зробити? Він її зробив?

2. Якщо проопнує рефакторити, то вимагайте рефакторинг одним пулреквестом і фітчу іншим пулреквестом.

3. Вимагайте цілісності змін. Якщо рефакторинг, то чогось невеликого, але від А до Я і по всьому проекту і відправляйте на доробку поки є хоча б одна помилка. Якщо фітча, то працювати має ідеально і завжди (аля на всіх >1% браузерах і мобілках, якщо це веб, наприклад).

4. У вас є місця в проекті, які давно хотілося переробити, але всім ліньки? Дайте йому задачу це дослідити, запропонувати рішення і реалізувати його. Очевидно, що запропоноване рішення варто попросити його представити перед усією командою і біля дошки, запропонувати критику, при потребі краще рішення, хай захистить свій варіант. Ну і про рев’ю не забувайте.

5. В нього є бажання змінити лібу? Вам шкода чи як? Тільки запропонуйте це робити по одній лібі, окремими пулреквестами, з аргументацією чого нова ліба краща і з порівнянням з всіма іншими лібами які роблять цю ж задачу. Запропонуйте йому захистити своє рішення перед командою біля дошки. Намагайтеся уникати аргументів аля «довго переписувати», так як переписувати буде ж саме він.

Взагалі, не бійтеся змін, в стоячій воді риба не виросте.

мне тоже кажется что здесь больше написана ситуация о стонущем говно менеджере (который это писал) чем о «Д’Артаняне»

Прізвище Дартаняна не Іванов?

Д’артаньяна часом не Александром звать? :)

Шарль Ожье де Бац де Кастельмор

Был когда-то похожий случай, не совсем, конечно, но в чем-то близкий. Был у меня девелопер, толковый, но всегда с кучей идей, как улучшить, ускорить, оптимизировать, рефакторнуть и пр. Всегда готовый — если его не держать в узде — вот как выкинуть часть кода, ненужного или не оптимального с его точки зрения, но часто — без анализа и понимания глубины вносимых изменений. .
В один момент, при его очередной «грандиозной идеи по переделке и улучшению всего и вся» — я сказал «Дружище — вот есть срок. Я готов рискнуть — ты меняй все что хочешь, реализовывай свои супергениальные идеи. Но имей ввиду, если к сроку не будет 100% работоспособной и надежной версии, если проект упадет хоть раз на „старых частях“ — заказчик попросту работу не примет, этап не закроет, денег не переведет. А все эти финансовые потери, связанные с твоей самодеятельностью, я вычту из твоей зарплаты. Готов?». И вы знаете — попустило.

Да увольте его и все. Не умеет чувак в команде работать

Уже. Потому что «Hire people, not skills.» Теперь я думаю что это могла быть и многоходовочка. Релокейтили его издалека, а прощание не было для него новостью. Теперь вопрос как не вляпаться в будущем.

Грамотно написать вакансию. И вот тут уж без говнотекста про дружный коллектив.

Старайтесь беседовать с людьми идущими в Вашу команду. Если внешний кандидат — интервьюируйте, если внутренний... всё равно поговорите... и не только с ним, но и с теми от кого его к вам переводят. Смотрите не только на технические скилы, но и на то, сможете ли с ним работать. Супер психолога при этом из себя строить не надо, просто смотрите на него как на человека а не набор скилов.

Ну и если такой попался — постараться направить его деятельность с определённое упорядоченное русло, об этом тут много писали.

У чувака то, что психологи называют синдромом эмоционального выгорания в фазе деперсонализации. Деперсонализация — проявляется в эмоциональном отстранении и безразличии, формальном выполнении профессиональных обязанностей без личностной включенности и сопереживания, а в отдельных случаях — в негативизме и циничном отношении. На поведенческом уровне «деперсонализация» проявляется в высокомерном поведении, использовании профессионального сленга, юмора, ярлыков.

Александр, вы могли бы мне поставить диагноз по фотографии? (фотография слева от этого сообщения)

коротко: Криштиану Роналду в одесском Черноморце

навчить всіх на траву падати від пориву вітру)?

Это вы с Селезневым перепутали)

Этому в секции футбола учат. Я серьёзно ;-)

Саме тому я й не люблю футбол. Противно дивитись на таке: www.youtube.com/watch?v=HgPUXJSi2f4

У ДАртаньяна вроде как девизом было «один за всех и все за одного», т.е. работа в команде.
А судя по контексту тут получается один против всех с целью доказать свою неповторимую гениальность :)))
Не умение работать в команде + банально быть человеком и понимать что нужно делать = жирный минус в репу такому кандидату.
Если он такой тугой, что разговоры с тобой, как лидом и оунером продукта на него никак действуют, то вывод банально очевиден.
Думает обычно та голова, которая терпит убытки :)

Ну «я д’Артаньян, а все кругом...» это не из книги, это из анекдота :).

Ну у некоторых и работа то ли из книги, то ли из анекдота :)))))

Все достаточно ... ну не просто, а известно как :)
(а) Для любой коммерческой программы: лучше условный «говнокод», который работает и удовлетворяет клиентов-заказчиков, чем добрые намерения, которые крешат аппликуху. У Саттера-Александреску это формулируется так: Correct is better than fast. Simple is better than complex. Clear is better than cute. Safe is better than insecure. Мне особенно третий принцип нравицца, и применительно к Вашему случаю тоже. Лично через это прошол, когда жил только с продаж своего продукта: человек, из-за гениальности которого продукт упал у половины пользователей, долго не задержался :(
(б) Выход на новый уровень, инвестиции в качество кода — вопрос, который манагер должен ставить заказчику (ну, или тому, кто бабло дает) хотя бы время от времени, и для этого д’Артаньян Вам не нужен.

Т.е. было работающее но не оптимально, мы меняем на работающее оптимально в 20% вхождений.
ИМХО не совсем так. Проверенный код, работающий не оптимально, вы меняете на непроверенный, необкатанный, работающий лучше ... а через года 2-3 ситуация возможно и повторится. Это опять-таки надо предусматривать в архитектуре проекта и в Ваших сношениях с баблодателем.
А сегодня не понятный ему фрагмент кода просто выкинул нах.
а вот за это — штраф, и не в 100 уе, а минимум в 500. ОбЪясните ему, что он рискует совсем не своим баблом и не только своей репутацией, а всего тима и всей которы. Если очень умный и очень хочется — вперед, пусть продает квартиру-машину, берет кредит в банке под расстрельные проценты, заколотит свою контору и там уже рискует выбрасывать кусок непонятного кода.
...нам мол помощь будет.
Кстате, если дейсно «в помощь», а не на горячую вакансию — лучше всего договориться с заказчиком, и пусть Ваш д’Артаньян в отдельном бранче (если такое возможно) колбасит новую архитектуру, либы и пр. методы. Судьбу в команде и его вознаграждение напрямую увяжите с результатом колбасни, если имеете такие полномочия.
а вот за это — штраф
а вот это Head of Department из ссср

зато мазги проветривает на раз-два ;) а где Вы кстати в совке штрафы видели?

а где Вы кстати в совке штрафы видели?
погуглил, пишут были

а почему штрафы — это фича совка? тож пишут? Как правило, считаецца, что это кровосиси-буржуи штрафуют бедных работяг там, в гейропе и пиндосии, а за совка премии и прогрессивки давали :)

Сложно сказать без конкретных примеров, если что-то можно «взять и просто выкинуть» то это уже о многом говорит. Тем не менее, если это на самом деле не так, то у вас просто очень хреновая организация труда и QA в первую очередь, но эт так везде, и отнюдь не всегда мешает релизить какие либо продукты, хоть и посредственного качества. Моя любимая цитата в таких случаях «Это Перспективный маркетинг Бесперспективных продуктов», или «Наше дело сделать, а как продать — уже есть кому заморочиться». По этому при принятии каких либо решений, особенно что касается рефакторинга, нужно понимать и оценивать краткосрочные и долгосрочные риски... Одно дело взять и переписать, другое дело взять и переписать на стильную/модную/молодёжную библиотеку, у которой ещё 100500 раз API поменяется и зависимости будут отваливаться, как оно всегда и бывает, например, при работе с Ruby и Node.js.

От лица человека, работающего как «хрен с горы» во всех проектах, могу сказать что когда человек входит в ваше положение, готов делится своим опытом для достижения поставленных целей, он, делясь своим опытом, приумножает не только существующий, но и позволяет расти коллективу в целом и формировать коллективную мотивацию.

Другое дело что если он ведёт себя как «Д’артаньян»: вот, я сделал как оно должно быть по книжке, а вы как хотите так и разбирайтесь, таким образом он показывает свою неготовность не только опытом делится, но и не преследует какой либо конкретной цели при разработке продукта, кроме личных психологических компенсаций. Грубо-говоря, «попуская вас», он «поднимает» в своих глазах себя же... Быстрее всего у человека уже была в жизни травма, когда кто-то его разок, или два, или три, на место ставил, а напряжение осталось, — надо его на ком-то компенсировать, иначе кризис начнётся.

Нужно понимать, что коллективы не бабульки в автобусе, которым нужно доехать от пункта «АЪ» до пункта «БЭ», их нужно взращивать, у них тоже есть своя мотивация, и отнюдь не так уж и много людей мотивируют деньги. О деньгах расскажу чуть далее. Коллективы не набираются со всяких залётных индивидуумов, которые магическими образами пекут вундервафли и продают их за несуразные шекели — так бывает только в сказках. Коллективы формируются и растут, у всех есть своя индивидуальная мотивация, и не всегда она совместима с окружающими. Так как у нас напрочь отсутствует индивидуальный подход, как и Agile в определении существующего манифеста, так у нас и отсутствует понимание о здоровых коллективах, и всех возможных проявлениях «клиники».

Вот программистами здоровые люди в нашем невротизированном социуме не стают, обычно намеренно уходят при непризнании окружающими и желании что либо созидать вместо махания лопатой. Очень редко когда программистами становятся ради денег. Но, как показывает практика, войти в положение ближнего, поделиться опытом, и задумываться о личностном и профессиональном развитии, обилие «травм детства» не позволяет. Человек «застревает» где-то в 18-24 летнем возрасте на многие десятилетия, не только у программистов оно так.

Естественно если это «школьник» мозгом — ему проще разбрасываться и тыкать всех в ихнее дерьмо. Вместо того что бы оценить цели и задачи проекта, оценить сроки, бюджет и существующие возможности и принять взвешенное, обоснованное и бескомпромиссное решение. Если с существующими ресурсами и подходами проект разработать не реально, то нужно набраться смелости что бы это признать, порезать функционал по существующим приоритетам и все таки выкатиться что бы получить хоть какую-то прибыль.

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

Теперь поговорим о деньгах.
Даже если ваша особь знает и умеет много всякого, но работает сугубо ради денег, иначе зачем ей с вами возится и над вами измываться, кроме как удовлетворения своих извращённых потребностей и развлечения мозговых тараканов, то последнее что её будет интересовать это успешность или провал проекта — ей главное процесс затягивать и получать деньги, за этот некачественный процесс разработки. Моя любимая цитата в этом плане: «Смотри, вот если проект умрёт — я потеряю деньги, потому что некому будет мне платить. Вот если проект запустится и будет успешен — я тоже потеряю деньги, потому что вместо меня наймут кого-то поумнее и местного в Штатах».

В общем, нужно разобраться в вашей мотивации, и мотивации существующих разработчиков — потом принимать соответствующее решение и организовывать процесс разработки должным образом.

Как лучше организовать процесс — можем обсудить детальнее в скайпе.

P.S. ИМХО Рефакторинг без тестов — бег по минному полю, Д’Артаньянов, за подобное, надо детотворных органов лишать.

Ruby
стильную/модную/молодёжную библиотеку
Для хипстеров руби это уже давно легаси.

Как будто кого-то волнует, что там для хипстеров легаси, а что — нет :)

Хипстеры очень активно пишут блогпосты и часто являются лидерами мнений. Большинство девелоперов часто принимают на веру, то что написанно на Dzone/blogger/medium, прямо как (пост)советские бабушки верят тому, что сказали по телевизору.

Большинство девелоперов часто принимают на веру, то что написанно на Dzone/blogger/medium, прямо как (пост)советские бабушки верят тому, что сказали по телевизору

Точнее и не скажешь. А еще хуже, если верят маркетинговому буллшиту на сайтах создателей новых фреймворков / технологий.

А еще хуже, если верят маркетинговому буллшиту на сайтах создателей новых фреймворков / технологий
Это еще не так плохо, самое ужасное это когда менеджеры поддаются маркетинговому буллшиту, которого кстати, на порядок больше. Взять тех же проповедников и тренеров по скраму, более безполезных существ в нашей отрасли найти сложно.

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

Мне кажется, что с позиции техлида тут решение очевидно — уволить парня, потому что он не на своем месте в вашей команде.

А вот с точки зрения менеджмента я бы задался вопросами: какие риски у проекта без рефакторинга? какая мотивация у продакт оунера? у команды? какая мотивация у данного разработчика? хватит ли запал довести рефакторинг до конца? какая глобальная цель и ценность этого рефакторинга? может ли этот разработчик лидить команду? быть ее частью?

И возможно уволил бы техлида и заменил его дартаньяном, если он карьерно стремится в сторону лидинга.

кратко: «увольте кого-нибудь» :)

Уточню: это первая версия коммента. Захотелось крови))

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

ты неправильно читал топик, у них нет никого кто понимает что происходит, единственный программист тс, да и тот с текущими технологиями еле знаком, взяли типа который лучше всех их вместе взятых, ясное дело что они не понимают что он делает, они так или иначе все угробят сами, с переделкой есть шанс, даже если провал — ну закроются чуть раньше, студенты хоть сессию без запар сдадут

Я могу еще сказать что наш код\уровень не выбивается с «общебольничного». Проект идет. Без фейлов с соблюдение сроков, без особых стрессов, учим джунов и т.п. Делаем рефактор часто в т.ч. MVP->BetterSolution->BetterThanBetterSolution.

ну откуда ты в этом уверен, ты же самый опытный с годом опыта, а что за опыт до этого ты не рассказываешь, мож для года опыта все и норм выглядит

Расказывает.

хотя есть опыт в других проектах и т.п.

сколько лет и в качестве кого? мож он админом до этого был на проекте

так а чо, он делает пул реквесты — а вы их не принимайте. пишите комменты. не будет исправлять — игнорьте реквест. подергается немного, пошипит, постонет, и со временем станет ручным, послушным, удобным для галеры.

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

К сожалению, осознание этого феномена приходит с реальным опытом. Жизненным и профессиональным. К еще к большему сожалению — приходит не ко всем. И уж совсем печально, это то, что тот к тому оно не приходит — никогда никаких проблем не ощущает. Эффект Даннинга-Крюгера в чистом виде, увы.

Если много времени, пускай вояет тесты, а потом уже рефакторит. Причем отдельными комитами))

Прощаться. Чем раньше тем лучше. Способность работать в команде и следовать правилам ценнее технических навыков. Бо последгние нарабатываются, а дартаньизм только лечить и то трудно и больно.

Бо последгние нарабатываются
Это не так это одна из особенностей
в маленькой и не очень квалифицироанной комманде
в которой именно «последние» вырождаются и переходят в техническое болото о чём и пишет ТС.

Здесь вопрос вот в этом «а зачем?»

«Определили» к нам нового кодера. Типа оверквалифайед для той тимы кто его собеседовал, а нам мол помощь будет.

Здесь уже есть варианты в основном политические и зависящие в основном от верхних политик от того же продакт-овнера в случае ТС. Если кратко и обобщать то «маленькое техническое болотце» имеет свойство только расти и расширяться в т.ч. по вертикали и чисто технически очень часто технического в нём ничего делать и не надо «всё само растёт и продаётся давайте наймём ещё 2-х продажников и прожект-менеджера» как написали ниже и это таки работает это факт. Прецеденты же «вбрасывания в болото» в основном случайны в случае ТС (здесь обобщение) даже не «в основном» но полностью случайны как сложившиеся одновременно факторы «а давай наймём вот подходящий помощь будет» чисто фактора наличия человека и одновременного просветления кого-то из топов «надо бы наше болото как-то вытягивать вообще-то» только «решения» здесь никогда не стратегические но исключительно «просветления» «а давайте наймём спеца» «а давайте заведём гит» «а давайте проведём тренинг».

Вопрос в том «а зачем?» что конкретной цели в этом нет отсюда и конфликт.

ЗЫ: а что человек наопытный так опыт будет проявляться по-другому а именно в забивании в формальном делании как сказал насяльника в последующем сваливании в виду бессмысленности чего-либо на текущем проекте. Именно это есть реальный софт-скилл а не «планомерная война с ветряными мельницами» с «мельницами» ещё можно а с «болотом» никто не воюет там совсем другие практики по вытаскиванию.

ЗЫ: и таки да таким людям там делать нечего в любом случае.

Прощаться с самым компетентным коллегой? Может добавить ему ответсвенности и поучиться у него самому?

Он НЕ является компетентным. В данном случае ему как раз не хватает командных и лидерских компетенций. Из-за этого он НЕ может усилить команду. У меня был в карьере такой случай — взяли технически грамотного но абсолютно не командного человека. Очень долго и болезненно уходили его. Это если по-менеджерки :).
А елси на пальцах — эрудиция не равна интеллекту. См. Вассермана :).

не сильно ли глубокий анализ по описанию от одной стороны?)

а) если бы человек хорошего технического уровня имел нужные компетенции то поста бы не было. Вот просто бы не было :).
б) имел удовольствие видеть подобную ситуацию. Почти один в один (ну правда чел не был самым крутым технически это да).

а) если бы человек хорошего технического уровня имел нужные компетенции то поста бы не было. Вот просто бы не было :).
ошибочное суждение, правильное, если бы тса все устраивало, то поста бы не было
б) имел удовольствие видеть подобную ситуацию. Почти один в один (ну правда чел не был самым крутым технически это да).
а это называется «я ошпарился чаем, теперь пью только воду»

Если бы человек был компетентным то ТС бы все устраивало. Потому что бы тогда это чел ПРАВИЛЬНО бы работал и с ТС и с другими КОЛЛЕГАМИ по команде. А получается не умеет. Так понятно?
Ну и чайка, водички и молока я уже попил по жизни...

Если бы человек был компетентным то ТС бы все устраивало. Потому что бы тогда это чел ПРАВИЛЬНО бы работал и с ТС и с другими КОЛЛЕГАМИ по команде. А получается не умеет. Так понятно?
ты берешь за основу что тс прав и все правильно понимает, а на это шанс 50%, итого все что ты говоришь верно с вероятностью подбрасывания монетки

Ну во первых мы ж на брудершафт не пили, правда? Это раз.
Два. Еще раз — если бы новичок имел компетенции командной работы и лидерства ожидаемые от зрелого человека конфликта бы не возникло от слова совсем.

Ну во первых мы ж на брудершафт не пили, правда? Это раз.Два.
это раз два три, выканье в украине и россии при личной встрече гражданину от 13 лет, в америке юканье, в интернете тыканье
Еще раз — если бы новичок имел компетенции командной работы и лидерства ожидаемые от зрелого человека конфликта бы не возникло от слова совсем.
нет, берем любого вредного чувака и к нему приставляем другого, который делает не точно так же, первый не доволен — инфа 100%

Ну, если быть абсолютно точным, то английское «you» — это «вы» (второе лицо множественного числа). То, что англичане и американцы даже к собаке обращаются на «Вы» не означает, что мы все должны друг к другу обращаться на «ты».
И, кстати, то чего многие не знают, но слово «thou» (ты) в английском языке сохранялось при обращении Богу и кроме того, используется в разговорном языке на севере Англии и Шотландии, а также кое-где в США.
Так что не стоит «тыкание» обосновывать незнанием английского.

наоборот только, это бог к человеку на ты обращается во всей библии.

’Thy will be done’ например — это как раз обращение человека к богу, а не наоборот.

а) если бы человек хорошего технического уровня имел нужные компетенции то поста бы не было. Вот просто бы не было :).
Суть поста в том, что у лида отбирают кормушку более умные и одаренные. Лиду это разумеется не нравится и он сопротивляется.

Какую кормушку и почему Вы думаете что отбирают?
PS
Никогда не считал ТЛ завидной позицией, особенно в условиях продуктовой компании.

Лиды получают з/п больше чем девелоперы. Ваш К.О.

Ну и поскольку лид не может обратно деградировать в девелопера, то дальше либо другой проект (повезло) либо увольнение (неповезло)

Лиды получают з/п больше чем девелоперы. Ваш К.О.

ЛОЛ. Нет. Это не так. Пишу как чел кот-й как это и решал/решает :).


Ну и поскольку лид не может обратно деградировать в девелопера, то дальше либо другой проект (повезло) либо увольнение (неповезло)
Почему деградировать? Не, если ЧСВ распухло то да. Но никакой деградации нет.
Лиды получают з/п больше чем девелоперы. Ваш К.О.
наркоман что ли?) с каких это делов мелкий менеджер получает больше? половина тимлидов с трудом мидлы
Ну и поскольку лид не может обратно деградировать в девелопера, то дальше либо другой проект (повезло) либо увольнение (неповезло)
а зачем программистом было становиться тогда вообще? сразу на тимлида и поехали, у меня знакомый — полгода джава джун потом тимлид, через год тимлид в лидерах рынка, или как бармен — верстку покрутил пару месяцев и менеджером стал
а зачем программистом было становиться тогда вообще? сразу на тимлида и поехали, у меня знакомый — полгода джава джун потом тимлид, через год тимлид в лидерах рынка, или как бармен — верстку покрутил пару месяцев и менеджером стал
Серьезно?? У вас тимлид не принимает решений и не несет ответственности за разработку??

Или вы типа хотите сказать, что лид не архитектор? Только зачем тогда нужен лид?

Серьезно?? У вас тимлид не принимает решений и не несет ответственности за разработку??
меня лид не программист, несет такую же как и все остальные участники команды и имеет равные права со всеми остальными участниками команды

была работа где лид был учредителем и он решал, потому что это тупо его продукт, была работа где лиду свесили права свыше, потому что руководство совковое привыкло к взаимоотношениям начальник && дурак, был лид программист на языке, который в проекте не использовался, был лид, который не выражал особенно своего мнения типа «делай как угодно лишь бы заказчику нравилось»

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

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

Да не прислушивайтесь :). Я высказал свое мнение и все.

а с чего вы взяли что он компетентен? в той или иной степени даже у трейни есть компетенция. но судя по описанию в посте у него явно не хватает технических компетенций чтобы делать то что он пытается, иначе бы этого поста не было

Такой вывод я сделал для себя из строк

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

и из описания скорее всего следует обратное, когда человек только пришел, и начинает вносить большие изменения в проект — то с вероятностью в 95% он даже не твердый мидл если что.

Парню очевидно не хватает опыта работы именно в этом проекте и именно с этой командой, вот и позволяет себе лишнего. Если с ним наладить коммуникацию
согласен на 100%
Человек мотивирован, хочет и умеет что-то менять, не хватает тормозов чтобы не наломать дров. Думаю команда в этом может ему помочь.
это тоже можно использовать

Многие некомпетентные начальники боятся компетентных подчиненных как огня. «А вдруг подсидит?» — думает он (судят по себе). Уж лучше будем барахтаться в болоте с послушными, но глупыми подчиненными. А от такого человека на всякий случай стоит избавиться.

Также добавляется факт, что если разница в знаниях существенная, то текущему лиду и остальным джунам сложнее контролировать процесс, понимать код в новых пулл-реквестах и давать адекватный фидбек. Ну удалил чел код, создал пулл реквест... Не в мастере же он его удалил? Напиши комментарий, типа "какой теперь код отвечает за ..."(описание функционала удаленного кода). Правило обязательное заведите, что минимум 2-3 человека должны заапрувить пулл-реквест перед мерджем. За мердж собвственных пулл реквестов бить по рукам, или настроить репу так что у каждого дева локально форк проекта с которых создаются пулл реквесты, которые в сам проект мёржить может только лид. Ну и да, хотите безопасный рефакторинг — покройте важные места сначала тестами.

Способность работать в команде и следовать правилам ценнее технических навыков.
Совок как он есть.

Ну да, ну да :).
Еще ватником надо обозвать. Или вышиватником — это тоже модно.

Этот человек не может быть по-настоящему опытным, если такое творит.

Мне кажется, если вы очень быстро не приведете его в чувство или уволите, то он создаст вам море проблем.

Что-то пошел поток комментариев с переходом на личности. Я не буду отвечать на них. Для тех кто не внимательно читает повторю — он выкидывает «не понятную ему логику». Рефакторит все что надо и не надо. Также приводил линк на Фаулера. Взятая наугад функция — возвращает разный результат в вариантах «до» и «после» изменений. Что то в адекватности его все больше сомнений.

он выкидывает «не понятную ему логику»
Тогда возникает вопрос кто на самом деле в этой ситуации д’Артаньян, а кто — «гвардеец кардинала»
Взятая наугад функция — возвращает разный результат в вариантах «до» и «после» изменений.
Тестов нет? Или человек коммитит невзирая на такие условности как падающие тесты?

Был у нас подобный «оптимизатор». То шото выпилит «ненужное», то движок БД сменит, то индексы накуячит на все таблицы подряд, шоп быстрее было типа, после чего проект ложился нах (хорошо, что он не был в продакшене). Причём при общении создает впечатление очень умного парня, величает себя естественно синьором и хочет овердокуя бабла, токо хер пойми за что.
А у Д’артаньяна похоже синдром человека впервые прочитавшего фаулера. Причем он его прочитал всего 1 раз и то невнимательно, ибо фаулер в каждой главе толдычит про тесты по 100500 раз. Чувак паходу джун-выепщик

ну вообще рефакторинг проводит лучше по частям, а не все сразу. установите стандарты/процесс вместе с этим товарищем. и если чтото меняется в проекте то должны быть очень везкие обоснования, а не потому что технологии используемые на проекте больше не модные

У вас год опыта работы на этом языке и вы техлид??? + кучка джунов. Наговнокодили все вместе там ого-го. Пришел грамотный чувак и это разгребает и вы недовольны? Ну наймите еще 1 джуна, а лучше 5 толковых менеджеров.

У куа на галерах это вообще норм практика. Годик кнопки успешно потыкал, важный вид поделал и всё, лид на проекте :)

Лучше еще одного грамотного чувака, который делает рефакторинг бизнес логики без тестов, не имеет опыта реальной разработки и с софт скилами == 0.

Что ж вы пишите код так что человеку проще его выбросить нах?

Дартаньяна

д’Aртаньяна

да-да, а еще три других гопника и де Тревилем во главе :)

Чувак, ваш стартап-продукт отобьет инвестиции в зависимости от ваших действий. Вам же самим должно быть виднее что проще по деньгам, времени, ресурсам и прочим факторам. Увольнять и тянуть самим либо вместе с ним. Если _ВЫ САМИ_ не можете определить как _ВАМ_ лучше, то вам врядли кто поможет советом с форума ))) разве что это сбор альтернативных точек зрения и мониторинг «опыта» подобных ситуаций ...

все тоже самое можно было делать без срача и лучше разруливать
попробовать еще чтото дать намекнуть на то что надо комуницироват в процессе
если изменений не будет — гнать

Увольняй. Это джун-переросток.
Мало знать как выглядят лучшие практики, нужно ещё понимать что есть ценность продукта, когда она нужна, и что на самом деле продаётся.

Он готов НАЧАТЬ И ЗАКОНЧИТЬ это дело. Уверен, что нет. Коммитить когда риск и седые волосы у кого-то другого — любому джуну подвластно. А вот ДОПИЛИВАТЬ всё это до стабильного продакшена, который должен работать, и не только когда его админ наблюдает — вот в чём зрелость кодера.

Иными словами, ответственность, ответственность, и ответственность.

PS. Всегда говорил и буду говорить: перестаньте избегать конфликтов, а в стартапах — в особенности. Лучше провести 100 конфликтов и выйти с продуктом, чем натянуть отношения и устроить 1 эффектный разрыв с потерей всех инвестиций времени и денег. Особенно времени.

Пример: у меня сейчас в руках стратап, у которого пулл-реквестов перевалило за сотню, и багов было столько же. Сейчас баг остался всего 1, а пул-реквестов как и прежде куча. Но проект живой, и приносит денежку, и почти не падал. И вот только теперь будем готовы расширяться. Однако нанимать будем не кодера, а продажника и саппорт.
Выгода? Низкие расходы, практически никаких стычек, мало времени на отношения — больше на работу. Да, это тоже риск. Но для стартапа куда легче рискнуть недопродажами, чем разорвать из средины.

Смотри в чём проблема: Один человек демотивирует всю команду. В результате работает он один, затраты на всех, до конца он дело не доведёт. Почему не доведёт? Да потому что в идеях всё намного проще, чем когда его начинаешь претворять в жизнь. А реальный мир отмазки «почему не работает» слушать не будет. Есть что продавать — продаёшь, нечего продать — принимай претензии, а клиенты уходят к конкуренту.

Решение проблемы только одно: учитесь конфликтовать, учитесь противопоставлять ИНТЕРЕСЫ. Давайте друг другу понять, что уважаете друг друга, но ваши ресурсы не безграничны. А как раз наоборот, очень ограничены. И попытка сказать «это не мои проблемы» — означает настроить против себя команду, которая наоборот, готова решать все проблемы и добиваться совместного успеха.

Успех приходит не к умным. Это результат работы.

Напишите плиз название галеры, где простой грамотный гребец уже получает клеймо overqualified, а погонщик не может решить элементарный вопрос в команде без привлечения консилиума с DOU

Ну все, набежали Д,артаньяны :-)

там же написано

Работаю уже какое-то время в «старом-продуктовом-стартапе». Я тех-лид в маленькой и не очень квалифицироанной комманде. Компания не очень богата, и инженеры в основном середняки.
при чем тут галера? тут модный стартап!
«старом-продуктовом-стартапе»
тут модный стартап!
Старомодный

Такое бывает, когда работал на проектах с одной архитектурой (условно «хорошей» для дева) и приходишь на другой проект, где все иначе и тебе не сразу понятно почему так. Ведь мозги уже привыкли к предыдущему проекту(-ам). Сразу начинается стресс и метание молниями как все хреново сделано и как можно сделать лучше (точнее, как он привык делать).
Если вам нравятся идеи вашего Дартаньяна и он хорошо их аргументирует, не вижу смысла ему сопротивляться. Инициативу нужно поощрять, но делать это правильно — сразу объясните где заканчивается его область действий и куда лезть нельзя, пока что. Отведите ему одну часть кода, пусть проанализирует как можно сделать/переделать лучше для проекта ее, приведет достаточно аргументов о пользе такой работы и вперед, пусть работает. И так далее в таком же темпе. Если у человека сейчас есть запал, его нужно направить в правильное русло. В любом случае со временем замахается переписывать и его пыл устаканиться. Главное — контролируйте, что бы его инициативы шли только в пользу для проекта, команды и держались под вашим контролем.

Да как-бы и нет возражений по поводу улучшений как таковых, если бы они делались с коммуникацией «до того», а не «после». Прислушивался бы он к приоритетам задач, не стеснялся приходить с вопросами. Мне как-то на голову не налазит, что можно вот так вот прийти и начать всех лечить напалмом. У меня в детстве даже как-то тренинг был на галере (даже на двух лидерах) по поводу «терпимого отношения» к разным коммандам. Мне казалось что сейчас даже в универах учат основы этики. Не ожидал как-то такого обладателя звездатого резюме.

Сделал паузу, послал на разговор «продукт овнера», вернулась она озадаченной: «ему не нравится ничего, вины за собой не чуствует. » Услышан ли мессейдж — посмотрим

Странный подход — он что, должен чувствовать вину... Направьте его энтузиазм в нужное русло. Не стоит бояться конкуренции — чувак реально может вам что то дать, а вы его сломать хотите...

Однажды к нам на галеру взяли типа, который после старта на проекте начал на все плеваться, говорить что кругом говнокод, надо все переписать и.т.п. Еще он часто говорил типа, а вот у Фаулера на такой-то странице написано, что так делать нельзя, а Макконел говорит делать так, а у вас все не так. Тимлид на это возражал в духе: «заткн и делай, что говорят, тебе платят деньги за работу, а не за 3.14-здеж». В итоге после испыталки послали его нах и комманда вздохнула с облегчением.

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

Это вопрос к менеджменту зачем его к вам приставили.
Улучшить код? Старая кодобаза может и плохая, но работает. Пускай форкает и переносит фичи по одной.
Вас научить? Пускай напишет документ «Как надо» и предъявляет команде.
Поломать проект? Тоже юмор.

тех лид с годом опыта и кучка студентов это жесть, конечно...
ну вообще все достаточно странно, у чувака просто нет задач и он делает то что ему нравится :)
похоже что тут два пути:
1) он делает что делает и все принимается, а там будет либо хорошо либо плохо, смотря что он делает
2) его увольняют или ему запрещается делать то что он делает и он увольняется сам

есть третий вариант где он говнокодит как все, но нафиг так жить, он деградировать пришел что ли к вам?
вообще лучше чтобы он все переписал, но если он лох, то проекту конец, а т.к. он оверквалифаед для вашей фирмы, то понять что он таки умет делать не получилось, так что кот в мешке

Есть два варианта:
1. Почитать Макиавелли. Как раз ваш случай.
2. Убиться апстену, не будете больше говнокода разводить.

Сходіть з ним на пиво, поговоріть за життя, познайомтесь, зрозумійте, що він за людина, а він нехай зрозуміє вас. По можливості, візьміть команду, нехай всі перезнайомляться і почнеться якась мінімальна повага, вам, як ліду, важливо вибудувати відносини.
Якщо ви й самі розумієте, що більшість інженерів далеко не найвищої кваліфікації, а проект не першої свіжості, то тут всім треба йти на компроміси, десь костилі поставити, десь за джуном код поправити, десь говнокод лишити. Аби вся команда це розуміла і ставилася з розумінням, то треба вибудувати відносини.
Є й інший підхід, робіть все по процесах, строго розбийти зони відповідальності, не дозволяти нікому комітити без вашого рев"ю, в разі будь яких конфліктів писати листа на менеджера.
Думайте, як вам простіше і краще.

Очень часто встречающаяся проблема — никто не хочет рабираться в чужом коде — все хотят его по быстрому переписать. За такое надо сразу бить по рукам — это не профессионализм.

Официально запретите ему рефакторинг: пусть старается заимплементить фичу как можно меньшим изменением кода.

Аргументация: тестов нет, в проекте он недавно — а значит может поломать то, что не понял или понял неправильно. Это раз.

Люди привыкли, что знают как все устроено, и просто так переписывать работающий код (даже если он его улучшает) — это снизить эффективность работы остальной команды.

За выпиливание кода дать по голове. И очень плохо, что он этого не признал. Т.е. вероятно повторение проблемы. Удалять можно только тот код, который на 100% понимаешь. Пусть расскажет, что делал выпиленный код

Вот пусть полгодика поработает, а затем уже можно и порефакторить.

Если пользы меньше чем напрягов то уволить.

Так ни одного айтишника в компании не останется. Так что придется искать подход...

в компании не останется
Останется. И даже наоборот. Обратный эволюционный процесс точно такой же процесс как и вообще.

Подписаться на комментарии