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

[beldmit]

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

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

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

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

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

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

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

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

Comments

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

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

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

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

[arilou]

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