VD>Сформулируем вопрос так. Считаете ли вы, что лучше брать на работу посредственных программистов и решать проблемы их массой и применением примитивных технологий дабы не перегружать их мозг.
Эффективность той или иной группы разработки оценивается при помощи так называемых метрик. Они в считанных конторах считаются, и могут быть разные даже для разных офисов одной конторы, даже при одинаковых технологиях. Этакая выраженная в числовой форме совокупность оценки завершённых проектов на ревью, прибыли с проекта, текучки кадров, оценок полученных на ревью самим разработчикам, и т.п. Мне довелось работать только в паре контор где эти самые метрики считали — обычно считают прибыль с человеко-часа.
Так вот, там где метрики считали, получалось что проекты с супер-спецами, или хотябы очень-спецами — по итогам пары-тройки лет и нескольких проектов — существенно выгоднее, но их настолько же сложнее администрировать, планировать, оценивать и т.п. И прибыльность таких проектов — штука прыгающая. То неожиданная сверхприбыль, то вылазят за бюджет. Прибыльность посредственностей — прогнозируема, по сути главное точно оценить сколько часов они будут лячкать говнокод, досыпать поправочных кэфов на сёрфинг интернетов, тестирование, отладку и т.п., и получаешь точную цифру, которую в конце проекта с удовлетворением вписываешь в отчёты, дескать во как круто оценили, погрешность минимальная. И это — ни с кем не советуясь, без всяких прототипов и пилотных проектов, в общем всё тупо и просто. В итоге с посредственностями конторе проще прогнозировать дебет/кредит.
Ну и если у конторы нет нормального оценщика — тогда со спецами им вообще тяжело, потому как в такой ситуации они в оценке полагаются на слова лишь самого исполнителя, а эта цифра от реальной может раза в 3 в любую сторону отличаться легко. В такой ситуации найти хорошего оценщика догадываются единцы, а остальные гордо объявляют своим кредо ставку на простые проекты и массу простых программистов.
Ну и соответственно я, после того как на метриках прочухал это, занимаюсь проектами со спецами — там интереснее и процент идущий в карман с завершённых проектов выше.
M>Из двух десятков человек при наличии времени почти в полтора часа, с возможностью пользоваться инетом, задачу решили на сто процентов... 1 человек. Еще один решил ее на 90%. Остальные не решили ее даже близко.
Это не говорит о том что все программисты тупые, это говорит лишь о том что ваши вакансии интересны именно таким людям, и процедуры отсеивания резюме и телефонного интервью поставлены крайне плохо. Тут надо не программистов ругать, а эйчар или кто там у вас делает их работу.
Здравствуйте, RonWilson, Вы писали:
RW>реалии таковы, что где-то это работает а где-то нет. пример: контора А, не абстрактная т.е. она была и есть в Москве занимается прямо скажем говнокодированием, код туп, прост даже для посредственных студентов и контора не боится ухода "звезды" коих не так много. Где-то мелькало, то ли у Спольски то ли еще у кого, что MS тоже не берет звезд в плане массового набора и код пишется без выворотов аля boost или нутро ротора. Мне кажется, что дело не в тупом примении принципа "навалимся массой", а в грамотном архитекторе и вообще руководителях проектов, иначе ни звезды, ни масса не в состоянии работать как часы и вообще хоть что-то делать совместно
На счет МС, мне достоверно известно, что там работает не один очень достойный программист.
Что до архитекторов... а они что не программисты? Думаешь можно заниматься архитектурой не садясь за компьютер?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Отладка кода вдвое сложнее, чем его написание. Так что если вы пишете код настолько умно, насколько можете, то вы по определению недостаточно сообразительны, чтобы его отлаживать.
T>— Brian W. Kernighan.
Я ему всегда не доверял.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mamut, Вы писали:
M>Изначально неверный вопрос, получившийся из неверной предпосылки. Других программистов просто *нет*. Это — реальность, данная нам в ощущениях. На работу приходится брать не то, чтобы хорооших, а хотя бы посредственных, потому что других просто нет.
А себя ты каким считаешь?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, vitasR, Вы писали:
D>>Если вы не можете объяснить пятилетнему ребенку, чем вы занимаетесь, значит вы занимаетесь не тем. (С) Р.Фейнман.
R>а вот интересно, как сам г-н Фейнман обьяснял 5 летнему ребенку интегралы по траекториям, которыми занимался?
А кто скзал, что он это сделал? Он просто понял, что занимается не тем.
Попробуй сам объяснить ребенку интегралы и тоже поймешь, что занимаешься не тем (фигней).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hi_octane, Вы писали:
_>Ну и соответственно я, после того как на метриках прочухал это, занимаюсь проектами со спецами — там интереснее и процент идущий в карман с завершённых проектов выше.
Интересно... что это один из немногих ответов хоть как-то по делу. Почему-то всех прет отвечать на другие вопросы (не заданные мной) или сразу говорить что постановка вопроса некорректна.
А я правильно понял, что ты и есть этот самый оценщик?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vitasR, Вы писали:
R>причем, ведь есть такая порода "гуру", люди которые сверху вниз на всех остальных смотрят и учат всех жить. Они умудряются делать даже простые вещи сложно (а то ж какой он иначе гуру?), при этом они вполне могут быть реально умными и продвинутыми. вот от таких надо держаться подальше, себе дороже будет. т.е. должен быть профи, а не гуру. как-то вот так.
Это самая худшая из всех возможных катастроф. Банда из 1000 индусов — ничто по сравнению с одним таким "гуру"
Здравствуйте, VladD2, Вы писали:
VD>Сформулируем вопрос так. Считаете ли вы, что лучше брать на работу посредственных программистов и решать проблемы их массой и применением примитивных технологий дабы не перегружать их мозг.
Я не то чтобы совсем согласен, но рациональное зерно есть. Давай уточним несколько моментов:
Менеджмент нужен в любом случае, вне зависимости от уровня программистов. Это накладные расходы, которые надо понести вне зависимости от того гении у тебя работают или идиоты. Если даже в проекте сплошь гении, нужны PM и Архитектор, и т.д.
Задача менеджемента — добиться цели. Один из основных методов — минимизация рисков. Следовательно, менеджмент даже с гениями обращаеться как с идиотами. Не потому что они идиоты, а потому что это минимизирует риски. Никто не станет основывать успешность разработки на знаниях идиота, поэтому на знаниях гения её тоже не стоит основывать.
Дублирование снижает риски. Лучше нанять не одного гения, а двух средних программистов, но точно знать с увольнением/болезнью любого их них проект не загнётся.
Идеальное качество недостижимо, приемлемое для продажи и конкурентной борьбы — вполне.
Большинство архитектурных решений уже хорошо описано и требует не творчества, а грамотного применения. Большинство программ не являются инновационными и продаются в сегменте рынка существующем годы, архитектура флагманских продуктов более или менее известна.
Обучаемость ограничена. Использование чего-либо за пределами мейнстрима это всегда накладные расходы на обучение нового сотрудника и не всегда обучение завершается успешно.
Если всё вышеперечисленное верно, а оно как правило верно, то лучше нанять среднячков, лучше использовать только мейнстрим. Всё равно менеджмент построен исходя из предположения о возможном увольнении и внезапно обнаружившейся недостаточной квалификации. Если эти риски уже учтены в структуре управления, и если их надо учитывать даже с гениями, то зачем нанимать гениев?
Давай я приведу простой пример. Вот у тебя есть винчестеры. Есть за 50$ но они сбоят каждые 10000 часов и работают со скорость 1000 IOPS. А есть за 500$, но они работают 20000 часов и их скорость 2500IOPS. Какие винчестеры лучше использовать если тебе нужно иметь 25000 IOPS? Конечно первые! Да, чтобы добиться 25000 IOPS нужно 25 первых винчестеров и 10 вторых. Но это не вся картина. 25000 IOPS в течение 20000 часов это 50 первых винчестеров и 10 вторых. Но это так же 2500 USD и 5000 USD. А результат одинаковый.
Я не случайно упомянул узлы компьютера, а не что-то одушевлённое. Никаких персоналий в правильном менеджменте нет. То что крутую задачу нельзя решить средствами обезьянок это правда. Но разве для того чтобы написать ПО нужно чтобы каждая обезьянка хорошо понимала всё решение? А что тогда делает архитектор? Нет, обезьянки не придумают решение, но зато реализуют, а большего и не надо.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Mamut, Вы писали:
M>>Изначально неверный вопрос, получившийся из неверной предпосылки. Других программистов просто *нет*. Это — реальность, данная нам в ощущениях. На работу приходится брать не то, чтобы хорооших, а хотя бы посредственных, потому что других просто нет.
IT>А себя ты каким считаешь?
Здравствуйте, hi_octane, Вы писали:
M>>Из двух десятков человек при наличии времени почти в полтора часа, с возможностью пользоваться инетом, задачу решили на сто процентов... 1 человек. Еще один решил ее на 90%. Остальные не решили ее даже близко.
_>Это не говорит о том что все программисты тупые, это говорит лишь о том что ваши вакансии интересны именно таким людям, и процедуры отсеивания резюме и телефонного интервью поставлены крайне плохо. Тут надо не программистов ругать, а эйчар или кто там у вас делает их работу.
У нас нет телефонного интервью, потому что для этого просто нет времеи, увы. Резюме мы и так отсеиваем.
Здравствуйте, VladD2, Вы писали:
VD>В последнее время все чаще слышу мнения в которых есть одно общее зерно — хороших программистов трудно найти, они хотят много денег, легко уходят... по этому мы берем на работу плохих программистов за меньшие деньги, но в больших количествах и наш софт должен писаться так, чтобы эти плохие программисты могли понять код. А раз так, то мы не можем использовать сложные решения поднимающие эффективность программиста.
VD>Я, честно говоря, с этим мнением в корне не согласен, так как усложнение задачи делает проект просто не подъемным для "простых программистов". Но вопрос не в этом. Меня интересует, какая часть посетителей данного форума придерживается тех же взглядов?
VD>Сформулируем вопрос так. Считаете ли вы, что лучше брать на работу посредственных программистов и решать проблемы их массой и применением примитивных технологий дабы не перегружать их мозг.
Изначально в вопросе непонятен один момент — что имеется в виду под "примитивными технологиями"? Технологиями организации труда или технологий, применяемых в написанных решениях? Я начал отвечать, исходя из первого, и уже в процессе ответа понял, что ты скорее всего имел в виду второе. Прошу всё-таки говорить более определёнными терминами.
По организации — если мы берём посредственных программистов, наоборот, их надо обставить технологическими средствами так, чтобы они хоть что-то внятное выдавали. Все стандартные IDE'шные фишки им должны быть максимально доступны. Далее, крайне важна организация труда — то есть все стандартные приёмы из XP/Agile/etc. типа парного программирования и TDD должны применяться по максимуму. Плохой программист — часто плохой по внутренней дисциплине, а не по уровню развития и знания технологий.
А вот сокращать уровень, необходимый для вхождения в конкретную технологию, может иметь смысл, но не более чем до определённого предела, который часто совсем рядом. Иначе оно просто не будет толком работать. Это касается и алгоритмических основ, и внешних технологий. С другой стороны, намеренное усложнение тоже обычно не имеет смысла.
Вообще, мне кажется, чаще всего дело не в уровне, а в устоявшихся привычках. Не могу подобрать аналогов из виндового мира, но представим себе проект, например, который лучше всего было бы писать на Django, но в наличии только взвод кодеров на PHP. Или Си вместо Эрланга для задачи, которую лучше всего уложить на обмен сообщениями между группой мелких процессов. Если бы тот кодер учился тому, что нужно, с самого начала, он бы в лёгкую вошёл в тему, но ему будет проблемой именно освоение нового средства, даже если оно в разы проще и удобнее.
А собственно уровень устройства технологии — он обычно может быть очень легко инкапсулирован в глубинах реализации.
Так я таки понял, что ты имеешь в виду, или (как обычно) будем ещё сотню сообщений уточнять термины?
Отладка кода вдвое сложнее, чем его написание. Так что если вы пишете код настолько умно, насколько можете, то вы по определению недостаточно сообразительны, чтобы его отлаживать.
T>— Brian W. Kernighan.
Забавная максима, но сильно несправедливая. Она обычно имеет смысл в обстановке, где тяжело с отладкой и диагностировать приходится по косвенным признакам — например, такое бывает с крэшами ядра. Далее, непонятно, что значит "настолько умно, насколько можете" — имеется в виду только собственный ум или можно использовать также вложенное другими в используемые средства? Например, если я применяю valgrind для проверки корректности работы с динамической памятью и вообще с указателями, я поступаю на пределе собственного ума или я всё-таки сумел подключить коллективную мудрость коллег?
Здравствуйте, VladD2, Вы писали:
VD>В последнее время все чаще слышу мнения в которых есть одно общее зерно — хороших программистов трудно найти, они хотят много денег, легко уходят... по этому мы берем на работу плохих программистов за меньшие деньги, но в больших количествах и наш софт должен писаться так, чтобы эти плохие программисты могли понять код. А раз так, то мы не можем использовать сложные решения поднимающие эффективность программиста.
Я чет не понял, как это? Код должен писаться так, чтобы он должен был пониматься любым, легко, с бодуна и через год. Вся сложность должна быть инкапсулирована в либах, куда плохие заглядывать не будут, они должны тупо их использовать! Вот за счет либ и нужно поднимать эффективность программиста. В либах внутри сложность может быть нетривиальная, но внутрь мало кто лазит, а основной код должен читаться как английский текст, быть без подводных камней (а какие подводные камни есть — там комментирии здоровенные должны быть). Потому какие проблемы то, не пойму — нормальные либы с удобным использованием пишите, а низкоквалифицированные пусть их используют и не задумываются, и наступит счастье.
Здравствуйте, VladD2, Вы писали:
VD>Я, честно говоря, с этим мнением в корне не согласен, так как усложнение задачи делает проект просто не подъемным для "простых программистов".
Не согласен. Усложнение задачи всего-лишь повышает нагрузку на архитекторов проекта, которые должны более эффективно декомпозировать сложные задачи в группу простых, легко выполнимых обычным программистом среднего уровня или даже ниже.
Здравствуйте, ArtDenis, Вы писали:
AD>Не согласен. Усложнение задачи всего-лишь повышает нагрузку на архитекторов проекта, которые должны более эффективно декомпозировать сложные задачи в группу простых, легко выполнимых обычным программистом среднего уровня или даже ниже.
Что в пределе ведет к команде состоящей сплошь из "архитекторов" (высококвалифицированных программистов)
Здравствуйте, VladD2, Вы писали:
_>>Ну и соответственно я, после того как на метриках прочухал это, занимаюсь проектами со спецами — там интереснее и процент идущий в карман с завершённых проектов выше. VD>Интересно... что это один из немногих ответов хоть как-то по делу. Почему-то всех прет отвечать на другие вопросы (не заданные мной) или сразу говорить что постановка вопроса некорректна.
ясен пень, никто не хочет работать с плохими сотрудниками или писать очередной helloworld..
но что делать?. сложных интересных задач на всех не хватает, а бессмысленно повышать сложность только ради ласкания своего чсв глупо..
поэтому на работе работаем с кем придётся (кто способен решить задачу), а для наколенных прожектов уже можно искать спецов.. или скорее участвовать в проектах спецов..
Здравствуйте, Mamut, Вы писали:
M>Здравствуйте, hi_octane, Вы писали:
M>>>Из двух десятков человек при наличии времени почти в полтора часа, с возможностью пользоваться инетом, задачу решили на сто процентов... 1 человек. Еще один решил ее на 90%. Остальные не решили ее даже близко.
_>>Это не говорит о том что все программисты тупые, это говорит лишь о том что ваши вакансии интересны именно таким людям, и процедуры отсеивания резюме и телефонного интервью поставлены крайне плохо. Тут надо не программистов ругать, а эйчар или кто там у вас делает их работу.
M>У нас нет телефонного интервью, потому что для этого просто нет времеи, увы. Резюме мы и так отсеиваем.
проще приглашать человека в офис, чем поговорить с ним по телефону?
Здравствуйте, adontz, Вы писали:
A>Я не случайно упомянул узлы компьютера, а не что-то одушевлённое. Никаких персоналий в правильном менеджменте нет. То что крутую задачу нельзя решить средствами обезьянок это правда. Но разве для того чтобы написать ПО нужно чтобы каждая обезьянка хорошо понимала всё решение? А что тогда делает архитектор? Нет, обезьянки не придумают решение, но зато реализуют, а большего и не надо.
Всё таки до обезьянки надо донести как цель её локальной задачи, так и более глобальную цель. Зачем? А чтоб была обратная связь архитектора/etc с тем кто его писанину использует. Те кому пофиг сделают как сказали, а кому не пофиг может чего полезного выдадут.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Если нам не помогут, то мы тоже никого не пощадим.
