По моему безнадежных нет, просто нужно уметь их грамотно применять.
Кодер — должен кодировать — соответсвенно четкая постановка задачи на входе A на выходе B шаг вправо — попытка к бегству.
Очень нужен в команде человек который умеет быстро и красиво что-нибудь сваять, чтобы закрыть на время вопрос. Не верю, что таких задач у Вас не бывает.
Тот кто умеет лечить — должен лечить, только пусть он лечит не Вас а заказчика, иногда и это полезно.
Некоторые отлично работают дома, некоторым свобода противопоказана, люди настолько разные...
Если у меня проблемы с каким либо сотрудником, я в первую очередь ищу в этом свою вину, как руководителя, знал кого брал на работу, знал что надо будет воспитывать.
А по поводу приема на работу, мне кажеться, Вам нужно самим понять кого Вы хотите найти, попробуйте описать свой рабочий процесс, и выявить требования к участникам этого процесса. Затем останется придумать как эти требования проверить, когда они определены это не так и сложно.
Как ни странно, но в последнее время я все меньше уделяю внимания к профессиональным требованиям, мне гораздо важнее чтобы человек был нормальный, а с остальным разберемся.
Re[8]: Приём на работу студентов. Как обнаружить безнадежных
Здравствуйте, Lloyd, Вы писали:
L>Причем тут распределенные VCS?
Поясняю. Есть фича на несколько тысяч строк и две недели. Коммитить несобирающийся или незаконченный код в корень VCS считается моветоном достойным канделябра. По-хорошему, надо бы на каждую такую фичу выделять ветку, вести разработку в ней, а затем мержить, но "классические" VCS порождают такой геморрой с мерджем веток, что на это часто забивают. Особенно если фича требует рефакторинга. Отсюда и получаются коммиты в несколько тысяч строк. В принципе, распределенные VCS спасли бы гиганта мысли, но эксперементировать с принципиально другой VCS среди проекта может обойтись слишком дорого.
Re[9]: Приём на работу студентов. Как обнаружить безнадежных
Здравствуйте, Miroff, Вы писали:
M>Поясняю. Есть фича на несколько тысяч строк и две недели. Коммитить несобирающийся или незаконченный код в корень VCS считается моветоном достойным канделябра. По-хорошему, надо бы на каждую такую фичу выделять ветку, вести разработку в ней, а затем мержить, но "классические" VCS порождают такой геморрой с мерджем веток, что на это часто забивают. Особенно если фича требует рефакторинга. Отсюда и получаются коммиты в несколько тысяч строк. В принципе, распределенные VCS спасли бы гиганта мысли, но эксперементировать с принципиально другой VCS среди проекта может обойтись слишком дорого.
И все таки это скорее дао рефакторинга и дзен TDD. Тогда не будет вставать вопрос про несобирающийся код, пусть там даже VSS используется. А коммиты/чекины, каждый из которых прост, понятен и преследует одну простую и понятную (промежуточную) цель — это же наслаждение для взора, можно прямо с логов отчеты генерировать о проделанной работе. Дзен же TDD в том, чтобы писать тестопригодный код, даже если написание тестов не предусмотрено процессом (и такое бывает).
Re[9]: Приём на работу студентов. Как обнаружить безнадежных
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, Lloyd, Вы писали:
L>>Причем тут распределенные VCS?
M>Поясняю. Есть фича на несколько тысяч строк и две недели. Коммитить несобирающийся или незаконченный код в корень VCS считается моветоном достойным канделябра.
Коммитить несобирающийся или незаконченный код считается моветоном вне зависимости от того, распределенная VCS или нет
M>По-хорошему, надо бы на каждую такую фичу выделять ветку, вести разработку в ней, а затем мержить, но "классические" VCS порождают такой геморрой с мерджем веток, что на это часто забивают.
А что за геморой? Использовали ветки, вроде никакого гемороя замечено не было.
M>В принципе, распределенные VCS спасли бы гиганта мысли, но эксперементировать с принципиально другой VCS среди проекта может обойтись слишком дорого.
В чем заключалось бы спасение? В чем в данном случае принципиальные отличия между распределенной и не-распределенной VCS?
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[10]: Приём на работу студентов. Как обнаружить безнадежны
Здравствуйте, Lloyd, Вы писали:
M>>По-хорошему, надо бы на каждую такую фичу выделять ветку, вести разработку в ней, а затем мержить, но "классические" VCS порождают такой геморрой с мерджем веток, что на это часто забивают. L>А что за геморой? Использовали ветки, вроде никакого гемороя замечено не было.
А в каких VCS? В SVN/CVS/боже_упаси_VSS объединение сделано через Ж. Хотя, в SVN1.5 это исправили.
M>>В принципе, распределенные VCS спасли бы гиганта мысли, но эксперементировать с принципиально другой VCS среди проекта может обойтись слишком дорого. L>В чем заключалось бы спасение? В чем в данном случае принципиальные отличия между распределенной и не-распределенной VCS?
Разработчик делает локальные коммиты в процессе работы, которые сохраняются в его собственный репозиторий. Ну и в конце работы над фичей — все изменения из локального репозитория сливаются в общий.
Sapienti sat!
Re[11]: Приём на работу студентов. Как обнаружить безнадежны
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Lloyd, Вы писали:
M>>>По-хорошему, надо бы на каждую такую фичу выделять ветку, вести разработку в ней, а затем мержить, но "классические" VCS порождают такой геморрой с мерджем веток, что на это часто забивают. L>>А что за геморой? Использовали ветки, вроде никакого гемороя замечено не было. C>А в каких VCS? В SVN/CVS/боже_упаси_VSS объединение сделано через Ж. Хотя, в SVN1.5 это исправили.
TFS
M>>>В принципе, распределенные VCS спасли бы гиганта мысли, но эксперементировать с принципиально другой VCS среди проекта может обойтись слишком дорого. L>>В чем заключалось бы спасение? В чем в данном случае принципиальные отличия между распределенной и не-распределенной VCS? C>Разработчик делает локальные коммиты в процессе работы, которые сохраняются в его собственный репозиторий. Ну и в конце работы над фичей — все изменения из локального репозитория сливаются в общий.
И в чем принципиальное отличие от ветки?
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re: Приём на работу студентов. Как обнаружить безнадежных?
Здравствуйте, жертва мехмата, Вы писали:
ЖМ>Последний вариант для компании — это убытки (рабочее время наставников-профи стоит дорого, реальная работа по проекту замедляется). ЖМ>Вопрос — какие могут быть эффективные методы раннего обнаружения таких нерадивых стажеров? Важно при этом не отсеять перспективный вариант. Были у нас такие, кто сразу честно говорил, что ничего не знает, но руки чешутся работать. Через некоторое время вырастали до приемлемого уровня. Какие вопросы им задавать, какие испытания устраивать? Или же у всех такая беда?
На собеседовании это сделать невозможно, но увидеть через 1-2 месяца — вполне. И мы не пускаем студентов сразу в разработку — это может очень плохо кончиться. Поподробнее могу в личку написать, если интересно.
Здравствуйте, жертва мехмата, Вы писали:
ЖМ>Тест на эрудированность у нас есть. Но блин почти никто не в состоянии нормально ответить на вопрос "что такое СУБД?", "чем занимается аналитик?". Начинаются сочинения на свободную тему, хорошо поржать можно. Я уже не знаю, таблицу умножения что ли у них надо спрашивать. Какие были вопросы в вашем тесте на эрудицию?
Вот хочу спросить.
1. А когда вы были студентом, вы знали ответ на вопрос "чем занимается аналитик?"?
2. Сколько нужно времени среднестатистическому студенту, чтобы узнать чем занимается аналитик.
Кстати, а чем у вас занимается аналитик?
Re[2]: Приём на работу студентов. Как обнаружить безнадежных
Здравствуйте, Она На Нас Ий, Вы писали:
TG>>а по теме вспомнил интересную статистику по кибернетическим кафедрам лучших вузов москвы ( хотя думаю в МГУ и МФТИ дела обстоят лучше, но тоже не все идеально). Так вот из 50-60 человек, сдающих различные лабы(в тои числе и домашки) в виде программ (хотя более уместно называть их прогами, до уровня настоящих программ явно такие поделки не тянут) реально все сами пишут только 3-6 человек, остальные просто копируют с мелкими изменениями.
ОНН>Т.е. 3-6 человек коряво "изобретают велосипед", не смущаясь и не отвлекаясь на всякие там книжки, накопленный опыт, вылизанные десятилетиями patterns ОНН>А остальные учатся тому, как должно быть, т.е. качественному Rapid Application Development (RAD) c использованию best practices — копипастят, а может даже и генерируют, вылизанные куски кода (в соответствии с определенными best practices)
Я с тебя просто балдею.
Ты в школе то же все домашние задания списывал?
И объяснял это обучением Rapid Application Development'у?
Что касается паттернов то они годны только для фраз типа: "Отрефакторил проект. Выкинул синглетоны. Прикрутил IoC. Жить стало легче."
А тех кто проектирует паттернами нужно отстранять от разработки за профнепригодность.
За копипаст нужно вобще мочить. За исключением тех случаев когда высока вероятность того что код в ближайшее время очень сильно изменится.
А самое веселье для копипастеров начинается тогда когда скопипастить неоткуда. Ну не написали еще нужный код.
А для того чтобы сгенерировать код нужно сначала на DSL написать то из чего его будут генерировать.
А для этого нужно сначала сделать DSL.
А сделать DSL это задачка не для копипастеров.
Да и далеко не весь код можно генерить.
ЖМ>>Последний вариант для компании — это убытки (рабочее время наставников-профи стоит дорого, реальная работа по проекту замедляется). ОНН>Это просто неправильно распланированный проект. В планы любого проекта должны закладываться риски и обучение ... а для средних и больших проектов — расширение-набор и обучение нулевых "студентов", предварительное изучение (если не разработка) общих стилей, принятых в компании ОНН>Я думаю, что даже, если собирать в новую команду одних гуру, то всё равно нужно время на разработку, изучение и привыкание к общим стилям и стандартам. Тоже работа "замедляется"
Гуру договорятся за несколько дней.
А в фразе на которую ты отвечаешь говорят о людях которые вобще не способны что-то сделать. Те на них можно потратить хоть год времени, а пользы не будет.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[12]: Приём на работу студентов. Как обнаружить безнадежны
Здравствуйте, Lloyd, Вы писали:
C>>А в каких VCS? В SVN/CVS/боже_упаси_VSS объединение сделано через Ж. Хотя, в SVN1.5 это исправили. L>TFS
А могу я с этим твоим TFS работать без подключения к серверу? Взять ноут, выехать на природу...
А можно организовать работу в удаленном офисе так чтобы она не зависила от скорости или вобще наличия коннекта к центральному офису?
А как у него с распределенной мультимастер репликацией?
C>>Разработчик делает локальные коммиты в процессе работы, которые сохраняются в его собственный репозиторий. Ну и в конце работы над фичей — все изменения из локального репозитория сливаются в общий. L>И в чем принципиальное отличие от ветки?
В распределенных VCS каждый коммит ветка.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, PKz, Вы писали:
PKz>1. А когда вы были студентом, вы знали ответ на вопрос "чем занимается аналитик?"? PKz>2. Сколько нужно времени среднестатистическому студенту, чтобы узнать чем занимается аналитик.
Мне четырех лет на специальности «Системный анализ и управление» пока не хватило, чтобы узнать, чем же я занимаюсь.
До последнего не верил в пирамиду Лебедева.
Re[13]: Приём на работу студентов. Как обнаружить безнадежны
Здравствуйте, WolfHound, Вы писали:
C>>>А в каких VCS? В SVN/CVS/боже_упаси_VSS объединение сделано через Ж. Хотя, в SVN1.5 это исправили. L>>TFS WH>А могу я с этим твоим TFS работать без подключения к серверу? Взять ноут, выехать на природу... WH>А можно организовать работу в удаленном офисе так чтобы она не зависила от скорости или вобще наличия коннекта к центральному офису? WH>А как у него с распределенной мультимастер репликацией?
Это и есть обещанный "геморрой с мерджем веток"?
C>>>Разработчик делает локальные коммиты в процессе работы, которые сохраняются в его собственный репозиторий. Ну и в конце работы над фичей — все изменения из локального репозитория сливаются в общий. L>>И в чем принципиальное отличие от ветки? WH>В распределенных VCS каждый коммит ветка.
То есть если я локально сделал 10 коммитов, то будет 10 веток? Ты это серьезно?
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[12]: Приём на работу студентов. Как обнаружить безнадежны
Здравствуйте, Lloyd, Вы писали:
L>И в чем принципиальное отличие от ветки?
Реализовано это именно как ветка. Собственно, в распределенных VCS всё представлено ветками. Результат bzr checkout ‹url› — ветка, общий репозиторий — тоже ветка, результат bzr branch ‹откуда-то› ‹куда-то› — тем более ветка. Можно обновить свою ветку, сделав ее копией другой ветки (bzr pull), можно учесть изменения других веток (bzr merge). (Можно s/bzr/hg/g, у Mercurial основной интерфейс такой же точно.)
Разница в том, что при использовании SVN или другой классической VCS есть централизованный репозиторий, и создание ветки — серверная операция. Коммиты — тоже. В то же время распределенные VCS позволяют коммитить в свою ветку, создавать локальные ветки, и вести прочую работу, не засоряя сервер кодом, который даже не компилируется. А когда всё будет готово, можно с легкостью сделать bzr push в центральный репозиторий. Опять же, push можно делать в любую ветку. Например, в ветку того, кто ведет code review.
До последнего не верил в пирамиду Лебедева.
Re[13]: Приём на работу студентов. Как обнаружить безнадежны
Здравствуйте, Roman Odaisky, Вы писали:
L>>И в чем принципиальное отличие от ветки?
RO>Реализовано это именно как ветка. Собственно, в распределенных VCS всё представлено ветками. Результат bzr checkout ‹url› — ветка, общий репозиторий — тоже ветка, результат bzr branch ‹откуда-то› ‹куда-то› — тем более ветка. Можно обновить свою ветку, сделав ее копией другой ветки (bzr pull), можно учесть изменения других веток (bzr merge). (Можно s/bzr/hg/g, у Mercurial основной интерфейс такой же точно.)
А если нет отличий от ветки, то куда девается "геморрой с мерджем веток"?
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[3]: Приём на работу студентов. Как обнаружить безнадежных
Здравствуйте, WolfHound, Вы писали:
WH>Что касается паттернов то они годны только для фраз типа: "Отрефакторил проект. Выкинул синглетоны. Прикрутил IoC. Жить стало легче." WH>А тех кто проектирует паттернами нужно отстранять от разработки за профнепригодность.
Почему?
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[14]: Приём на работу студентов. Как обнаружить безнадежны
Здравствуйте, Lloyd, Вы писали:
L>>>TFS WH>>А могу я с этим твоим TFS работать без подключения к серверу? Взять ноут, выехать на природу... WH>>А можно организовать работу в удаленном офисе так чтобы она не зависила от скорости или вобще наличия коннекта к центральному офису? WH>>А как у него с распределенной мультимастер репликацией?
L>Это и есть обещанный "геморрой с мерджем веток"?
На вопросы ответь.
Ибо если он все это не может то гемор будет по люблому.
Хотябы из-за тормозов на удаленные вызовы. Это даже если предположить что сеть хорошо работает.
L>То есть если я локально сделал 10 коммитов, то будет 10 веток? Ты это серьезно?
Да.
А в чем проблема?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: Приём на работу студентов. Как обнаружить безнадежных
Здравствуйте, Lloyd, Вы писали:
WH>>Что касается паттернов то они годны только для фраз типа: "Отрефакторил проект. Выкинул синглетоны. Прикрутил IoC. Жить стало легче." WH>>А тех кто проектирует паттернами нужно отстранять от разработки за профнепригодность. L>Почему?
Даже не знаю как на этот вопрос можно цензурно ответить.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Приём на работу студентов. Как обнаружить безнадежны
Здравствуйте, Lloyd, Вы писали:
L>А что за геморой? Использовали ветки, вроде никакого гемороя замечено не было.
Мерждить ветку в транк можно только один раз. После этого классическая VCS "забывает" о мердже и в следующий раз предлагает опять разрешить кучу невнятных конфликтов, причем разрешить руками. Аналогично, мерджить по частям неудобно, потому что легко забыть что уже смерджено, а что еще нет. В распределенных VCS с этим получше. Тот же git отслеживает ближайшего общего родителя для файла в ветке и в транке и сдвигает его после мерджа. Плюс branch, merge и rebase операции в классических VCS довольно медленные. По крайней мере в CVS и SVN.
Re[2]: Приём на работу студентов. Как обнаружить безнадежных
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, жертва мехмата, Вы писали:
ЖМ>>Какие вопросы им задавать, какие испытания устраивать? Или же у всех такая беда?
M>Моя статистика, в которой у меня нет оснований сомневаться, говорит мне, что на группу в 30 студентов: M>* 0-2 -- годятся в программисты M>* 5-10 -- годятся во вспомогательные рабочие (тестеры, сисадмины, техписатели) M>* прочие годятся только чтобы торговать телефонами в киоске
У меня в группе из тех, кто остался к 5 курсу работают программерами все! (11 или 12 человек)
3 отчислили.
Учился я в СПбГПУ (Политех), Физико-механический факультет, кафедра "прикладная математика"
Кстати, начиная с 4 курса нам давали именно программерские дисциплины. (Теория алгоритмов, комп. графика, выч. геом. и пр.)
IMHO, ваша статистика не совсем верна.
Re[15]: Приём на работу студентов. Как обнаружить безнадежны
Здравствуйте, WolfHound, Вы писали:
L>>>>TFS WH>>>А могу я с этим твоим TFS работать без подключения к серверу? Взять ноут, выехать на природу... WH>>>А можно организовать работу в удаленном офисе так чтобы она не зависила от скорости или вобще наличия коннекта к центральному офису? WH>>>А как у него с распределенной мультимастер репликацией?
L>>Это и есть обещанный "геморрой с мерджем веток"? WH>На вопросы ответь.
Ага, разбежался. Ты сначала прочти про что ветка, а потом пыхти.
L>>То есть если я локально сделал 10 коммитов, то будет 10 веток? Ты это серьезно? WH>Да. WH>А в чем проблема?
