Вот значит как да? Думал все так просто будет? Действительно, каков шанс того, что лицо, о котором говорят прочтет это все?
Мне не приятно, мне очень не приятно, учитывая то, что я вкалываю за двоих, так мной еще и не довольны?
Я молчал только потому, что думал, что мы — друзья, коллеги, которые помогают друг другу.
И да, после того, как ты правишь мой код, я правлю твой код и молчу о том, какой же он мерзкий.
N> Постепенно я пришёл к мысли, что его деятельность не продвинет вперёд данное направление. Равно как и другие направления в его компетенции. Мой начальник сказал, что если мы не сработались, то выход один -- уволить. Более того, мы должны это сделать, если уверены в отсутствии пользы от данного сотрудника. Также меня заверили, что процедура простая и от меня требуется только вердикт.
Главный навык бизнесмена/начальника — умение увольнять людей без душевного трепета. Тренируй, если хочешь идти по этой линии. Тем более, тебе предлагают комфортный вариант — "только скажи, а уволим мы сами".
N> Однако я в сомнениях. Смущает то, что программист этот вроде бы не лишён ни ума, ни любознательности, ни интереса к работе.
Нафига тебе его любознательность, тебе надо, чтобы он нормальный код в срок выдавал. Если за полгода (или сколько там) не нашли общего языка и не сработались — нечего дальше экспериментировать, ничего уже не изменится, кроме несущественных деталей.
Здравствуйте, naec, Вы писали:
N>Здравствуйте, white_znake, Вы писали:
_>>Ох боже мой... как вы стали начальником-то???
N>До скрама типа не было жизни на земле?
Да жизнь была и до скрама. Сейчас мы пользуемся клавиатурами для ввода текста а раньше все было на перфокартах, а жизнь была, предпочтете перфокарты клавиатуре? Ладно, это сарказм
Технологии управления проектами совершенствуются не потому, что менеджеры захотели создать свои "фишечки", а потому, что процесс производства ПО, автомобилей, самолетов и т.д. — усложняется,
поэтому и появляются новые технологии управления проектами. Кстати, канбан был придуман и внедрен на тойте, а не в софтварной конторе.
Я хоть и не экстрасенс, но по приведенным вами фактам, можно сказать, что у вас огромная проблема именно в управлении процессом разработки, потому что, когда человек пишет 8 000 строк кода и заливает их в репазиторий и ни кто не знает как работает этот код — это плохо.
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, white_znake, Вы писали:
_>>P.S. Не то может оказаться, что у вас довольно-таки хороший программист, но у вас просто хреново поставлен процесс разработки. MM>На мой взгляд, процесс никак не может быть связан с умением решать задачу, потому что данный момент целиком и полностью отдается программисту.
Да ну??? Т.е. наличие/отсутствие достоверной документации на модули и классы, наличие/отсутствие блочных тестов, наличие/отсутствие автоматический приемочных тестов и отдела тестирование,
наличие/отсутствие эволюционного процесса разработки, когда крупные задачи реализуются не большими и контролируемыми итерациями — все это не влияет на конечный результат работы программиста???
Если вы так думаете, то надеюсь, что вы не работаете менеджером проекта и ведущим разработчиком
Здравствуйте, white_znake, Вы писали:
MM>>На мой взгляд, процесс никак не может быть связан с умением решать задачу, потому что данный момент целиком и полностью отдается программисту. _>Да ну??? Т.е. наличие/отсутствие достоверной документации на модули и классы, наличие/отсутствие блочных тестов, наличие/отсутствие автоматический приемочных тестов и отдела тестирование, _>наличие/отсутствие эволюционного процесса разработки, когда крупные задачи реализуются не большими и контролируемыми итерациями — все это не влияет на конечный результат работы программиста???
Тюююю, полегче. Это все внешнее, это все окружает программиста между написанием кода. Умение решать задачу к этому никак не относится. Например, есть у меня блок try/catch. Я беру и перечисляю в catch все мыслимые и немыслимые исключения. Большинство из них никогда не сработают, и это точно лишнее бесполезное нагромождение в коде. Ну и как процессы такое отловят?
_>Если вы так думаете, то надеюсь, что вы не работаете менеджером проекта и ведущим разработчиком
Ну, слава богу, это не вам решать.
N>Полноценный опыт управления группой у меня небольшой, не покидают сомнения. Я лично нанимал этого человека и к увольнинию душа не лежит.
В какой то момент надо просто забить на потраченные силы и время, на то что подумают люди и зафиксировать потери. Примириться с этим и подумать что делать. Смотри на факты а не "куда душа лежит". Пост имеет значительную эмоциональную окраску. Всё грустно, трогательно и в сомнениях.
Я вижу две проблемы:
1. Отсутствие отлаженного механизма разработки. Почти всем странно видеть сообщение про коммиты в 8к строк. Эта проблема номер раз. Какой то режим ручного контроля и отсутствие количественных оценок результатов работы.
2. Плохая работа коллеги. Если человек умеет что то делать, то он будет делать это вопреки всем орг. трудностям при наличии мотивации.
Если время терпит, то я бы начал с п. 1. При хорошей организации процесса халявщики сразу сами соскакивают, т.к. становиться ясно что либо работаешь, либо палишься.
Здравствуйте, Ромашка, Вы писали:
N>>На следующий день он говорит, что проблему решил и в ветке появляется патч в 8 тысячи строк. Р>Мужик, тут 99.999% не напишут 8 000 строк за один день.
Сынок, если ты мастера копипаста 80 левела не видел, то считай ничего ты не видел, ага. особенно на С#, такие знаешь, затейники встречаются.
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, white_znake, Вы писали:
MM>>>На мой взгляд, процесс никак не может быть связан с умением решать задачу, потому что данный момент целиком и полностью отдается программисту. _>>Да ну??? Т.е. наличие/отсутствие достоверной документации на модули и классы, наличие/отсутствие блочных тестов, наличие/отсутствие автоматический приемочных тестов и отдела тестирование, _>>наличие/отсутствие эволюционного процесса разработки, когда крупные задачи реализуются не большими и контролируемыми итерациями — все это не влияет на конечный результат работы программиста??? MM>Тюююю, полегче. Это все внешнее, это все окружает программиста между написанием кода. Умение решать задачу к этому никак не относится. Например, есть у меня блок try/catch. Я беру и перечисляю в catch все мыслимые и немыслимые исключения. Большинство из них никогда не сработают, и это точно лишнее бесполезное нагромождение в коде. Ну и как процессы такое отловят?
В общем приведенный вами пример с плохим кодом, решается путем обязательного ревью кода, без ревью кода — задача не может быть завершенной (при чем задача не должна быть на 8 000 строк кода).
"Порка" кода нужна не для того, что бы показать тому кого "порят", что он дурак, а для того, что бы он сильнее интегрировался в коллектив и старался работать как того желает коллектив.
Если человек не идиот, то он подстраивается под правила команды. Так что либо новичок идиот (тогда кто его такого нанимал?), либо процесс поставлен так, что новичку сложно влиться в команду.
Для вашего примера можно настроить FxCop на стороне сервера CI и/или добавить инспекцию после сборки, и такой код не пройдет инспекцию.
При чем, тот пример, который вы привели, не может сказать ни чего плохого о разработчике, т.к. он использует legacy code от низкоуровневых модулей, который может быть плохо документирован и разработчик может быть не уверен вылезет или нет какой-нибудь MySuperException при вызове метода из низкоуровневого модуля.
Здравствуйте, alzt, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Есть два мнения по этому поводу. G>>1) В бизнесе нет личных проблем, есть системные. То есть надо построить систему таком образом, чтобы этот, положительный во всех смыслах, человек просто не мог так сделать или простор его действий был гораздо ниже. В вашем случае нужна формальная процедура code-review, желательно чтобы она сопровождалась статическим анализом кода и сбором метрик. G>>Плохой код всегда сыпется на метриках и статическом анализе, какими бы умозаключениями его не пытались обосновать. A>А что за метрики? можно поподробнее?
Цикломатическая сложность, связность классов.
Желательно считать удельные метрики.
Если есть оценка объема задачи, то можно считать плотность кода.
Здравствуйте, white_znake, Вы писали:
_>... потому что, когда человек пишет 8 000 строк кода и заливает их в репазиторий и ни кто не знает как работает этот код — это плохо.
это личная ветка, ревью происходит перед слиянием её с мастером. Данное изменение уже никогда туда не попадёт.
Здравствуйте, -n1l-, Вы писали:
N>Действительно, каков шанс того, что лицо, о котором говорят прочтет это все?
Я подумал, что лицу это прочесть даже полезно, хороший шанс увидеть ситуацию чужими глазами. В работе важен результат, а не вовлечённость. Бывает и так, что твоих усилий в принципе недостаточно. Ещё работа не социальный клуб, считать коллег друзьями это ошибка (да, они улыбаются, спрашивают как дела, но на самом деле им неинтересно).
Не стоит мою маленькую работу над ошибками превращать в трагикомедию. Как только я понял, что никакого проку от дальнейшего сотрудничества не будет, вопрос был решён. Этот топик посвящен другому и по объективным причинам не мог повлиять на моё решение. Что до эмоций, то нет развития без неприятно. Небольшой запас злости пригодится в будущих боях.
Здравствуйте, TimurSPB, Вы писали:
TSP>...Смотри на факты а не "куда душа лежит". Пост имеет значительную эмоциональную окраску.
Пост написан на эмоциях вскоре после увольнения. Все логические доводы были уже приведены, вердикт вынесен. Думаю решение было принято верное, но осталось ощущение, что до этого нельзя доводить.
Ещё оказалось очень неприятно изгонять человека из группы. Вот уж никак не ожидал, учитывая уверенность в правильности решения. Прямо "Преступление и наказание" какое-то, отсюда и душизмы. По смыслу пост касался именно пяти вопросов безотносительно данного сотрудника. Прошу простить, что ввёл всех в заблуждение мнимой подвешенностью вопроса. ИМХО без этого обсуждалось бы нечто другое, менее конструктивное.
Здравствуйте, 0x7be, Вы писали:
0>По мне так тут речь идет не только и не столько о технических навыках, сколько о самоорганизации, методике работы, навыках problem-solving`а. Судя по описаню, ты хочешь сеньора, поскольку планируешь делегировать задачи на высоком уровне, а тут junior to midlevel.
Хаха, узнаю себя на своем втором месте работы Только там они знали кого берут, чувака с дипломом месячной давности, курсами и двумя месяцами работы за спиной. А так тоже самое — модуль на плюсах, я единственный исполнитель, очень стараюсь, переписываю, переписываю, переписываю, но все равно падает. Никто даже не попытался помочь разобраться и исправить. В итоге, они считают, что уволили, но я о своем желании уйти заявил на несколько секунд раньше Чувствую ли я себя виноватым — ни разу, зато считаю, что поимел очень важный, пусть и негативный опыт.
Здравствуйте, naec, Вы писали:
N>т.е. 1 должно работать правильно, 2 должно быть очень читабильно и только 3 по возможности оптимально
А вот тут не соглашусь. Буквально из последнего — самописная ОRM, которая может транслировать код в SQL Server и Оракл, с сиквелем проблем нет, все работатет четко, код и там и там работает, все читаемо и закоментировано, но вот проблема — тормозит безбожно, до такой степени, что работа с приложением и Ораклом в качестве бд становится мучением. Так что, имхо, без п.3 п.1 существовать не может.
а компенсацию там в виде 5 окладов выплатили? А то так очень удобно ведь получается, человек приходит в группу, тратит свои силы и время, даже сверхурочно, месяц, два, три, проходит испытательный срок и так далее. А затем "по прихоти" его выкидывают, получается есть ошибка менеджера который не разглядел, не нашел подход. Думаю многие бы из вас не взялись за проект если бы знали, что есть такая вероятность, пусть даже незначительная, какой смысл работать "с душой" если в любой момент могут попросить. Да и в моей практике был один тимлид, пришел, начал говорит о некомпетентности команды, некоторые уволились, затем он начал копать под техдира, но все эти подковерные игры закончились его изгнанием.
On 23.07.2013 14:23, white_znake wrote:
> Если вы так думаете, то надеюсь, что вы не работаете менеджером проекта > и ведущим разработчиком
И зря. Чаще всего именно такие люди и работают менеджерами проектов.
Здравствуйте, gandjustas, Вы писали:
G>Цикломатическая сложность, связность классов. G>Желательно считать удельные метрики.
А какие инструменты позволяют считать подобные метрики?
Здравствуйте, alzt, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Цикломатическая сложность, связность классов. G>>Желательно считать удельные метрики. A>А какие инструменты позволяют считать подобные метрики?
Мне б в своё время кто так намекнул бы 
Только там они знали кого берут, чувака с дипломом месячной давности, курсами и двумя месяцами работы за спиной. А так тоже самое — модуль на плюсах, я единственный исполнитель, очень стараюсь, переписываю, переписываю, переписываю, но все равно падает. Никто даже не попытался помочь разобраться и исправить. В итоге, они считают, что уволили, но я о своем желании уйти заявил на несколько секунд раньше 
