Здравствуйте, snaphold, Вы писали:
S>Какое правильное поведение тимлида в плане контроля работы? S>Часто код синьор непонятен и кажется сложным. S>Вопрос: как бы вы себя вели в роли тимлида?
А он непонятен потому, что он пользуется такими технологиями, которых никто другой не знает или он просто пишет так запутанно?
обычно чем лучше программист, тем более понятный код он способен писать
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, Qt-Coder, Вы писали:
S>>обычно чем лучше программист, тем более понятный код он способен писать
QC>Необязательно, уровень абстрактного мышления может быть выше. Например, он пишет все на шаблонах.
Это как раз первый случай, использует технологии, которые другие не знают. В таком случае всем придется изучать шаблоны (а он должен аргументированно доказать, что с ними лучше/быстрее/качественнее)
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, Sshur, Вы писали:
S>Это как раз первый случай, использует технологии, которые другие не знают. В таком случае всем придется изучать шаблоны (а он должен аргументированно доказать, что с ними лучше/быстрее/качественнее)
С чего это он должен чего-то кому-то доказывать? Если есть задание написать на С++ он на нем и пишет.
Здравствуйте, snaphold, Вы писали:
S>Начальство тимлида не меняет.
А зачем его менять? Мне кажется ему не обязательно быть самым умным везде.
S>Какое правильное поведение тимлида в плане контроля работы?
Что такое "правильное"? Правильность может быть разная с точки зрения бизнеса, успешности проекта в целом, сохранения работы и т.п.
S>Часто код синьор непонятен и кажется сложным. S>Вопрос: как бы вы себя вели в роли тимлида?
Попросил бы объяснить и немного поднатаскать команду по новым подходам. Потому что в будущем этот код придется поддерживать другим членам команды. Плюс высока вероятность, что этот сильный синьор когда-нибудь уйдет.
Здравствуйте, Qt-Coder, Вы писали:
QC>Здравствуйте, Sshur, Вы писали:
S>>Это как раз первый случай, использует технологии, которые другие не знают. В таком случае всем придется изучать шаблоны (а он должен аргументированно доказать, что с ними лучше/быстрее/качественнее) QC>С чего это он должен чего-то кому-то доказывать? Если есть задание написать на С++ он на нем и пишет.
ну если ты пишешь сложнее, чем можно написать, то должна быть причина, а не просто "давайте используем все возможности языка, можно же". например, преждевременная оптимизация и овер дизайн.
но это все чисто умозрительные рассуждения, надо конкретные случаи смотреть.
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, msorc, Вы писали:
M>Здравствуйте, snaphold, Вы писали:
S>>Начальство тимлида не меняет. M>А зачем его менять? Мне кажется ему не обязательно быть самым умным везде.
встает вопрос почему синьор не тимлид?
S>>Какое правильное поведение тимлида в плане контроля работы? M>Что такое "правильное"? Правильность может быть разная с точки зрения бизнеса, успешности проекта в целом, сохранения работы и т.п.
правильность в плане сохранения статуса и успешности проекта
S>>Часто код синьор непонятен и кажется сложным. S>>Вопрос: как бы вы себя вели в роли тимлида? M>Попросил бы объяснить и немного поднатаскать команду по новым подходам. Потому что в будущем этот код придется поддерживать другим членам команды. Плюс высока вероятность, что этот сильный синьор когда-нибудь уйдет.
проект сам по себе не требует сложных вещей. тестов тоже нет.
люди не знают про монады (я к примеру) и им это сложно.
M>>Попросил бы объяснить и немного поднатаскать команду по новым подходам. Потому что в будущем этот код придется поддерживать другим членам команды. Плюс высока вероятность, что этот сильный синьор когда-нибудь уйдет.
S>проект сам по себе не требует сложных вещей. тестов тоже нет. S>люди не знают про монады (я к примеру) и им это сложно.
т.е, он сует функциональный подход везде ?
ну и есть такое понятие. как Bus Factor. Надо обеспечить, чтобы он был больше 1.
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, snaphold, Вы писали:
S>Какое правильное поведение тимлида в плане контроля работы? S>Часто код синьор непонятен и кажется сложным. S>Вопрос: как бы вы себя вели в роли тимлида?
Я бы не стал меряться линейками, всенародно признал бы его круть и попытался бы контролировать результат работы, а не манеру написания кода. Затем, подключил бы кого-нибудь в пару к синьеру, чтобы он не был единственным носителем знаний. Объяснив это минимизацией общих и его же рисков. Спокойно уйти в отпуск на 2-3-4 недели — тоже чего-то стоит.
Ну и, как уже верно подметили, это отличный повод подтянуть общий уровень команды.
Здравствуйте, snaphold, Вы писали:
S>встает вопрос почему синьор не тимлид?
Как уже ответили может хуже разбираться в предметной области. Может хуже выполнять руководящие функции или не хотеть этим заниматься.
M>>Попросил бы объяснить и немного поднатаскать команду по новым подходам. Потому что в будущем этот код придется поддерживать другим членам команды. Плюс высока вероятность, что этот сильный синьор когда-нибудь уйдет.
S>проект сам по себе не требует сложных вещей. тестов тоже нет. S>люди не знают про монады (я к примеру) и им это сложно.
Попросил бы его поделиться знаниями перед командой и мной об этих монадах, преимуществах такого подохода. И раз пришел такой умный человек, то можно и тесты начать писать
Здесь как раз по-моему лид и должен проявить себя, сгладить как-то неровности в навыках.
Если синьор будет выделываться и не захочет делиться знаниями, объяснять или писать попроще, то это — проблема. Потом код будет тяжело поддерживать, так как он будет единственных, кто что-либо понимает.
В общем тест на вменяемость синьора и способность лида налаживать работу команды.
Если дело совсем плохо, может быть даже синьора лучше убрать с проекта.
Здравствуйте, snaphold, Вы писали:
S>Приходит в проект сильный программист (синьор). S>Сильней тимлида по знаниям. S>Начальство тимлида не меняет.
S>Какое правильное поведение тимлида в плане контроля работы? S>Часто код синьор непонятен и кажется сложным. S>Вопрос: как бы вы себя вели в роли тимлида?
Тимлид или архитектор? Раздавать таски и контролировать их выполнение особых технических знаний не требует. Код непонятный или сложный — задавать вопросы, пока не станет понятно или пока код не будет переписан на более понятный вариант. Ревью кода у вас есть же?
Если архитектор, то не мешать ему проявлять инициативу. Единственное, нужно следить, чтобы любая проявленная инициатива была поддержана или хотя бы понята хотя бы половиной команды.
Есть особый случай: когда тимлид — упертый тупой баран. Но в этом случае проблемы тоже нет — серьор скоро уйдет сам.
Видел такую ситуацию со стороны. Пришёл человек, написал код на С++ на бусте и прочих шаблонах. Этот код потом поддерживать было очень сложно. В конце концов наняли другого крутого чувака, тот вроде разобрался, дописывал, но потом тоже ушёл (в гугл) и опять та же проблема встала. Компания была не очень большой и технологичной и крутым чувакам видимо в ней скучно было, ну и предполагаю, что платили им сильно выше рынка. Другие программисты там писали тоже на С++, но на "простом", Си с классами, как говорится, у них проблем с кодом не было. В квалификации "крутых" программистов я усомниться не могу, они действительно крутые, но всё же ситуация получалась именно такой. Хотя я не был в том проекте, так, со стороны слышал, возможно особых проблем и не было, но маты были В общем моё имхо, надо или платить таким людям сильно выше рынка и быть готовым найти им не менее крутую замену или быть готовым к тому, что код окажется трудноподдерживаемым или заставлять их писать по какому-то кодстайлу "для дураков" (но тогда им будет скучно и они могут уйти раньше времени).
Здравствуйте, snaphold, Вы писали:
s> S>>Начальство тимлида не меняет. s> M>А зачем его менять? Мне кажется ему не обязательно быть самым умным везде. s> встает вопрос почему синьор не тимлид?
На мой взгляд — сеньор и типлид — это разные вещи.
Первый разработчик, второй командир.
У первого может просто не быть нужных административных навыков.
Здравствуйте, Qt-Coder, Вы писали:
QC>Здравствуйте, Sshur, Вы писали:
S>>Это как раз первый случай, использует технологии, которые другие не знают. В таком случае всем придется изучать шаблоны (а он должен аргументированно доказать, что с ними лучше/быстрее/качественнее) QC>С чего это он должен чего-то кому-то доказывать? Если есть задание написать на С++ он на нем и пишет.
Потому что с его кодом придется работать не только ему. И если уровень в команде низкий, надо это учитывать. Не использовать шаблоны вообще это конечно за гранью, но какой-нить зубодробительный аналог мпл скопипасченый с александреску (был у меня такой коллега) надо и правда обосновывать.
Здравствуйте, Qt-Coder, Вы писали:
QC>Здравствуйте, Sshur, Вы писали:
S>>Это как раз первый случай, использует технологии, которые другие не знают. В таком случае всем придется изучать шаблоны (а он должен аргументированно доказать, что с ними лучше/быстрее/качественнее) QC>С чего это он должен чего-то кому-то доказывать? Если есть задание написать на С++ он на нем и пишет.
Code review для синьоров отменили? Если никто в команде не может отревьюить его код, то кто-то в этой тройке явно лишний (такой код, такой сеньор или такая команда)
