о программировании
Jan. 25th, 2008 01:11 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
avvaВчера разговорился с коллегой из отделения Гугла в одной европейской стране. Он жаловался, что трудно найти инженеров - кандидатов, которые хотя бы как-то подходили, почти нет. Я спросил, в чем дело, и он объяснил, что выпускники университетов в его стране обычно считают, что писать код - ниже их достоинства, и что вообще "карьера" несовместима с такими занятиями; они хотят быть не то мелкими начальниками, не то "архитекторами". Им прямо в университете, дескать, так и говорят: получите свою степень магистра - больше вам программки писать не придется. Конечно, с работой в Гугле это все никак не сочетается.
У нас в Израиле тоже есть схожие проблемы, хоть и не в таких масштабах. Время от времени попадаются кандидаты, которые не просто не могут написать простой код на бумаге (не могут-то многие), но еще и возмущаются тем, что от них этого просят. Однажды кандидат долго расспрашивал меня, просто не желая поверить, что так может быть: "неужели меня, после PhD и постдока, посадят писать код, как какого-то мальчишку? Должны же у вас быть какие-то должности типа архитектора или системного аналитика! Нет, ну я могу писать код, но я этого не делал много лет и не в этой области лучше всего проявляются мои способности".
В Гугле все инженеры пишут программы, включая любого рода тим-лидеров, включая и ученых, нанятых на ставку "research scientist". Нет никаких "архитекторов" и "аналитиков", которые сами думают, а код за них пишут другие. Те же люди, которые придумывают дизайн какой-то системы, вместе с другими ее воплощают.
Я, кстати, не уверен, что так лучше. Мне лично такое порядок работы очень по душе, но я не готов заявить, что он объективно приводит к лучшим результатам, чем более иерархичное устройство с "архитекторами". Несоменно, есть места и есть обстоятельства, где такое устройство очень хорошо работает. Но я лично не хотел бы быть "архитектором".
У нас в Израиле тоже есть схожие проблемы, хоть и не в таких масштабах. Время от времени попадаются кандидаты, которые не просто не могут написать простой код на бумаге (не могут-то многие), но еще и возмущаются тем, что от них этого просят. Однажды кандидат долго расспрашивал меня, просто не желая поверить, что так может быть: "неужели меня, после PhD и постдока, посадят писать код, как какого-то мальчишку? Должны же у вас быть какие-то должности типа архитектора или системного аналитика! Нет, ну я могу писать код, но я этого не делал много лет и не в этой области лучше всего проявляются мои способности".
В Гугле все инженеры пишут программы, включая любого рода тим-лидеров, включая и ученых, нанятых на ставку "research scientist". Нет никаких "архитекторов" и "аналитиков", которые сами думают, а код за них пишут другие. Те же люди, которые придумывают дизайн какой-то системы, вместе с другими ее воплощают.
Я, кстати, не уверен, что так лучше. Мне лично такое порядок работы очень по душе, но я не готов заявить, что он объективно приводит к лучшим результатам, чем более иерархичное устройство с "архитекторами". Несоменно, есть места и есть обстоятельства, где такое устройство очень хорошо работает. Но я лично не хотел бы быть "архитектором".
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2008-01-26 08:01 am (UTC)кто пишет GUI на моем или более высоком
уровне. Просто по тех характеристикам того
что я делал.
no subject
Date: 2008-01-26 02:34 pm (UTC)no subject
Date: 2008-01-26 03:11 pm (UTC)-- IMHO, о паттернах нормльный разработчик вообще
не должен думать, но очень полезно знать антипаттерны.
----------
Учитываются следующие характеристики (в порядке важности):
1. Юзабилити (визуальный дизайн тоже очень важен,
штука выглядит как сделанная на флеше).
2. Легкость внесения измерений в существующий
код -- она много от чего завистит, от декомпозиции
прежде всего. Например, программа о которой идет речь
имеет четкое заделение на фронтэнд и бэкэнд,
и бэкэндов было написано 2: одни использующий
HSQL (оказался слишком медленным и имел другие
недостатаки), другой использует специально разработанный
формат файлов.
3. Способность реально работать на разных платформах.
4. Низкие аппаратные требования.
5. Оъем кода для раелизации данного
набора функций -- чем меньше тем лучше,
естественно.