Ад

ссылко
>>Я считаю, что если пришел человек с 10+ годами работы, ничего ему давать не надо. Он притащит своего кода горы и расскажет как и что и почему он там писал.
>Ммм... а хто мне даст "свой" код кому-то показывать? Код программерам не принадлежит.

Я не понимаю, где и кем работают все эти люди. Кодеры на конвеере, вместе с индусами, что ли?
Ладно, понимаю, на крупной конторе код может быть заныкан. Другое дело что в 99% случаев он и так нахер никому не нужен, кроме аудита на предмет консультации заказчика "послать их подальше, пока ЭТО не внедрили".

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

Строки обратить на собеседовании вам сложно? А лямбд не хотите ли

Тогда к вам придут они.
И будет плач и скрежет зубовный и будете вы обращение строк на собеседовании как манну небесную вспоминать.

Медицинское

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

Рекомендуемая к прочтению шиза

97 things programmer should know

И еще, оттуда же:

97 Things Every Software Architect Should Know:

Часто заказчики в качестве требований к проекту выдвигают то, что, как им кажется, является жизнеспособным решением их проблемы. В качестве примера, ставшего классическим, можно привести историю, которую рассказал Harry Hillaker, ведущий разработчик самолета F-16 Falcon. Их команде было поручено разработать самолет, летающий со скоростью, в 2-2.5 раз выше скорости звука. Тогда, а возможно, и сейчас, это весьма нетривиальная задача, особенно если при этом требуется построить дешевый и легкий самолет. Вы же, наверное, помните, что аэродинамическое сопротивление увеличивается в четыре раза при увеличении скорости в два, и понимаете, как этот факт влияет на вес самолета.

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

Этот урок стоит использовать и в разработке программного обеспечения. Задавая клиенту вопрос о том, для чего ему нужна желаемая функциональность или требование, проектировщик может увидеть реальную, настоящую проблему, и возможно, найти более лучшее и дешевое решение, чем предлагаемое клиентом. Фокусировка на реальных потребностях к тому же упрощает приоритизацию – наиболее важное для решения реальной задачи становится двигателем для проектирования.


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