Сферическое программирование в вакууме

[beldmit]

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

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

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

Тезис второй.
Не все OpenSource-проекты одинаково полезны. При попытках отправить патч в различные я наблюдал 4 позиции

1. Принять патч после переписки. Самая простая и понятная.
2. Принять патч к сведению, через какое-то время выпустить новую версию, в котором интерфейс, предложенный в патче, будет переименован нафиг.
3. Не принимать патч, но реализовать свой, дающий тот же функционал. Патч в этом случае используется как ТЗ/основа для ТЗ.
4. Разработчик в гибернации, на патчи не реагирует.

Желающие сами могут сделать вывод о продуктивности посылки патча.

Тезис третий, главный.
От программиста на работе требуется писать поддерживаемый код. Потому что времена солистов, к счастью, прошли. Поэтому вопросы на собеседованиях "Что означает это выражение - переменную или функцию" для меня имеют один однозначный ответ: "Автора этой строчки надо уволить нафиг". Да, и к большинству нестандартных и к половине высокоуровневых идиом это тоже относится - код, написанный человеком, перечитавшим Александреску, в отличие от кода человека, остановившегося на Саттере или Мейерсе, скорее всего к поддержке непригоден.

А от веб-программистов разумно требовать хотя бы структуру нижележащей базы. Потому как из этого можно понять степень ясности мышления.

Comments

[vitus_wagner]

Интересно, Дим, что ты сейчас работаешь руководителем проекта, и рассматириваешь процесс скорее с точки зрения нанимаемого, а мы с Раном работаем программистами, и рассматриваем процесс скорее с точки зрения нанимателя. Ну и с теорией вероятности у тебя некоторые сложности. Впрочем, ты за время работы в Криптокоме по-моему ни разу внутрь криптоалгоритмов не лазил. И образование у тебя не естественно-научное, поэтому со статистикой там было плохо.

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

Давай разберемся со шляпами

[beldmit.livejournal.com]

Сразу замечу: у меня нигде образцы кода не требовали, а где требовали - туда не взяли (один раз было), но работаю же. И код мой работает.

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

Второй - он в тезисы попал зря. Это иллюстрация к соотношению жизни и модели.

А третий тезис - он с точки зрения что программиста-коллеги, что руководителя. Собственно, ради него все и написано.

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

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

А теперь прикинь сам - какой объем кода надо для этого представить и проанализировать. А отсеять можно проще - предъявив кусок кода на разбор и объяснение.

Re: Давай разберемся со шляпами

[vitus_wagner]

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

А теперь прикинь сам - какой объем кода надо для этого представить и проанализировать. А отсеять можно проще - предъявив кусок кода на разбор и объяснение.

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

Re: Давай разберемся со шляпами

[beldmit.livejournal.com]

Да. В таком виде это совершенно верно, и похоже на 3-й дополнительный показатель. Ничем не хуже, скажем, предыдущих мест работы.

[arilou]

Насчёт ошибок нанимателя: мне показалось, или ты тут сознательно исходишь из одномоментного и трудноотменяемого решения о принятии? Т.е. попросту не берёшь в расчёт испытательный срок?

[http://users.livejournal.com/_ltt_/]

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

За время испытательного срока плохой программист получает зарплату, которая не окупается его трудом.
За время испытательного срока хороший программист, вместо которого взяли плохого, находит себе другую работу и перестаёт быть доступным для найма (либо его надо перекупать, увеличивая ФОТ).
После увольнения плохого программиста, не прошедшего испытательный срок, руководителю опять приходится заниматься поисками работников и собеседованиями, отнимая время от собственно руководства разработкой...

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

[arilou]

Да не, понятно, что лучше сразу взять хорошего, и что взятый плохой сколько-то ресурсов "отъест".
Однако, если есть сильные сомнения в нём - можно начать с небольших задач, чтобы коммиты были часто - и посмотреть, что он делает в реальных условиях (а не что он предоставит на показ - тоже есть разница).
С испытательного срока можно выкинуть, не дожидаясь окончания.

[a-orlov.livejournal.com]

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

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

[beldmit.livejournal.com]

Угу. Единственный кусок кода в "Мастерхосте", написанный полностью мной - это переписанная с нуля система, разработанная изначально именно таким человеком.

[arilou]

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

[a-orlov.livejournal.com]

Так в том-то и проблема, что узнать, как поведет себя слон в посудной лавке, можно только заведя слона в посудную лавку.

[dph.livejournal.com]

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

Кстати, я на собеседовании вообще не прошу показать код - нужные мне навыки проверяются совсем другим способом.

[beldmit.livejournal.com]

Ну вот, посмотри. Зашедшие в этот пост наниматели высказались за мою позицию. А особенности сабмита патчей в OpenSource никто так и не оспорил.