о программировании

[avva]

Вчера разговорился с коллегой из отделения Гугла в одной европейской стране. Он жаловался, что трудно найти инженеров - кандидатов, которые хотя бы как-то подходили, почти нет. Я спросил, в чем дело, и он объяснил, что выпускники университетов в его стране обычно считают, что писать код - ниже их достоинства, и что вообще "карьера" несовместима с такими занятиями; они хотят быть не то мелкими начальниками, не то "архитекторами". Им прямо в университете, дескать, так и говорят: получите свою степень магистра - больше вам программки писать не придется. Конечно, с работой в Гугле это все никак не сочетается.

У нас в Израиле тоже есть схожие проблемы, хоть и не в таких масштабах. Время от времени попадаются кандидаты, которые не просто не могут написать простой код на бумаге (не могут-то многие), но еще и возмущаются тем, что от них этого просят. Однажды кандидат долго расспрашивал меня, просто не желая поверить, что так может быть: "неужели меня, после PhD и постдока, посадят писать код, как какого-то мальчишку? Должны же у вас быть какие-то должности типа архитектора или системного аналитика! Нет, ну я могу писать код, но я этого не делал много лет и не в этой области лучше всего проявляются мои способности".

В Гугле все инженеры пишут программы, включая любого рода тим-лидеров, включая и ученых, нанятых на ставку "research scientist". Нет никаких "архитекторов" и "аналитиков", которые сами думают, а код за них пишут другие. Те же люди, которые придумывают дизайн какой-то системы, вместе с другими ее воплощают.

Я, кстати, не уверен, что так лучше. Мне лично такое порядок работы очень по душе, но я не готов заявить, что он объективно приводит к лучшим результатам, чем более иерархичное устройство с "архитекторами". Несоменно, есть места и есть обстоятельства, где такое устройство очень хорошо работает. Но я лично не хотел бы быть "архитектором".

Comments

[neatfires.livejournal.com]

Программирование может быть интеллектуальной профессией, а может быть конвейерным трудом. Чтобы решить, как отбирать людей, нужно ответить на два вопроса.

Во-первых, какой вид программистов нужен фирме вообще и на конкретную должность? Я считаю, что ответ на этот вопрос менее очевиден, чем кажется: даже если данный конкретный проект не требует семи пядей во лбу, есть много других причин нанять хакера, а не code monkey. Например, если в фирме/отделе вообще нужны одаренные сотрудники (хакеры), то нужно учесть, что им гораздо больше понравится работать в среде других хакеров, чем кодообезьян. Их высокая концентрация обеспечит престиж фирмы и желание квалифицированных кадров у вас работать. Способность того или иного программиста перейти на более трудный проект в будущем тоже определяется его - не нахожу подходящего слова, скажем - развитием. Изобретательный человек часто сможет додуматься до такой возможности автоматизировать рутинную работу, о которой вы и не подозревали и тем самым сократит срок разработки. Взаимная помощь, которую хакеры оказывают друг другу вне рамок проекта, - там, где один застрянет, другой додумается мгновенно. В итоге приходим к выводу, что нанимать ограниченных людей следует либо в условиях, когда штат уже оккупирован прочным контингентом торчковолосиков (http://en.wikipedia.org/wiki/Pointy_Haired_Boss) и прочих бездарей, либо в фирме, ориентирующейся на низкое качество продукции, либо условиях острого недостатка в финансах.

Во-вторых (возвращаюсь к теме), есть ли критерий для оценки всех тех качеств, которые требуются для того, чтобы программист смог приносить все те плюшки, о которых я распространился в предыдущем параграфе? Я думаю, что он есть, и очень простой: сообразительность и любознательность в заданной области и ее основах. Вот и получается, что правильный хакер в обязательном порядке будет соображать в алгоритмике, как основе всех прикладных веток программирования, и в нескольких/многих конкретных прикладных областях.