Здравствуйте, netch80, Вы писали:

N>Изначально в вопросе непонятен один момент — что имеется в виду под "примитивными технологиями"?

Расшифрую — не использование Nemerle

Здравствуйте, VladD2, Вы писали:

VD>Мэйнстрим == манки-драйвен-девелопмент?
Неплохой наброс, сравнить основную массу людей-программистов с обезьянами-программистами. Люди == обезьяны?

VD>Сформулируем вопрос так. Считаете ли вы, что лучше брать на работу посредственных программистов и решать проблемы их массой и применением примитивных технологий дабы не перегружать их мозг.

Переформулирую вопрос в ответ. Я считаю, что на работу надо брать _необходимых_и_достаточных_ программистов и решать с применением _необходимых_и_достаточных_ технологий. И уважать большинство и его мнение, без попыток унижения. Проблема поиска _необходимых_и_достаточных_ ресурсов основная проблема эффективности. (Инфа 100%, только что сам придумал). Развешивание провокационных ярлыков не сильно помогает в этом поиске. Помогают как уже говорилось, например: интуиция, согласование "интерфейсов" программных и вербальных между "типа-крутыми" и "типа-не-крутыми", метрики и тп.
Привет от мейнстрима. И не стоит нас сравнивать с "примитивными приматами с не технологичными палками-копалками в руках"!

M>Во-первых, любая контора берёт ЛУЧШИХ, но чтобы они писали в пределах корпоративной культуры и архитектуры. Во-вторых, нет таких коллективов, где нет хороших прогеров. Они составляют "мозг проекта", а вокруг них можно нанимать хоть негров — они одинаково эффективно решат _разложенные_по_полочкам_ задачи. Не надо думать, что проекты — это сплошь шахматы и ребусы, подавляющая их часть — РУТИНА, оформленная в красивые модули и стрелочки.
Прежде всего хотелось бы отметить что за любой корпоративной структурой стоят либо экономика, либо предпочтения/знания конкретных людей. К тому же эта логика не объясняет контор в которых "эти треугольные скобочки" (дженерики, C#2), запрещены корпоративным стандартом. Даже для лидов. Просто потому что у них ставка на студентов, по $400 за пучок, и на соответствующие задачи.

M>Ясный код понимаем любым. Плохой не понимаем даже специалистами. Так что нет "специального кода для обезьян" — есть "обезьяний код".
Не надо общих фраз про любых. У меня есть кусок чисто математического кода, который совершенно прост, нет ни однй иерархии, ни одного даже виртуального метода. Чисто 5-мерные массивы туда-сюда, и операции все простейшие. Ясный, простой код на уровне как раз простого C. Хрен поймёт человек без ТЗ, сопровождающих док-файлов, и файлов матлаба. Профильное образование — обязательно. И дальше упростить некуда...

M>Можем, но только решения, проверенные практикой. Опять же, повторюсь: НЕТ столько головоломок, сколько немерлисты хотят решить своими макросами — и без немерли, и даже без жабы/сишарпа писались многомиллионные проекты НА ПРОСТОМ СИ — _тем_ танцорам язык не мешал. Почему? Потому что "эффективность — она в головах", а не синтаксисе.
Опять красочно, но что-то не вяжется с реальностью. Я помню проекты 10 летней давности. Редактор DSL-скрипта с подсветкой синтаксиса, автокомплитом и хелпом тогда был задачей на человеко-год и выделялся в отдельный проект. Сейчас это 3 недельки, параллельно с самим DSL и простеньким отладчиком. Эффективность — она скорее в голове * интструмент. Приблизительный пруф — рассмотрим пределы: голова 0, инструмент 100% — результат 0. Голова 100% инструмента нет вовсе — результат тот же 0.

M>Для этого есть "мозг проекта", но и тут выплывает ещё один плюс "средних решений" — они _понимаемы_всеми_ членами команды, т.е. имеем бенефит коллективного разума. Более того — "средние решения" легче модернизировать в силу их "незаумности".
Что такое средние решения? Как меняется со временем мощность среднего решения? Какой график зависимости экономической эффективность команды от выбранного среднего решения? Для .NET стоит ли выбирать за среднее C#1, C#2, 3 или 4?

M>Среди профи и бизнесменов — 100%.
Вот так, опять за всех и бескопромисно. Даже не 99.95? Жаль только Ericsson который выдумывал заумный Erlang явно от недостатка профи и бизнесменов в топ-менеджменте.

Кустари оперируют понятиями "а помните у нас ведущий уволился, и потом никто там ничё три месяца не понимал, а найти того кто бы понял мы не могли". А профи и бизнесмены — такими вещами как риски и оценки. Разработка $x, замена ключевых разработчиков $y, опоздание с выходом на рынок (вылет за дедлайн) $z, спрыгивание клиента из-за подковёрных интриг $t, и т.п. И это всё в табличку по технологиям.
Ты же старательно завышаешь одни риски, и понижаешь значимость других. И при этом совершенно серьёзно говоришь за 100% профи и бизнесменов.

Здравствуйте, 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. А результат одинаковый.

Я не случайно упомянул узлы компьютера, а не что-то одушевлённое. Никаких персоналий в правильном менеджменте нет. То что крутую задачу нельзя решить средствами обезьянок это правда. Но разве для того чтобы написать ПО нужно чтобы каждая обезьянка хорошо понимала всё решение? А что тогда делает архитектор? Нет, обезьянки не придумают решение, но зато реализуют, а большего и не надо.

Здравствуйте, VladD2, Вы писали:

VD>Сформулируем вопрос так. Считаете ли вы, что лучше брать на работу посредственных программистов и решать проблемы их массой и применением примитивных технологий дабы не перегружать их мозг.

На всех контрактах, где мне довелось поработать тут, видел одну и ту же картину — пара-тройка сильных контракторов ваяют каркас приложения, ключевые компоненты и библиотеки, армия быдлокодеров...ммм...быдлокодит всё остальное. Вскоре после запуска проекта в продакшен контракторы успешно сваливают, а вместо них нанимают ещё кучку пермщиков-быдлокодеров (ибо никакой более-менее вменяемый спец не пойдёт на саппорт продукта, да и бабки там обычно дают не большие). Вся эта куча народу настраивает много слоёв подпорок, костылей и "хаков", каждое последующее изменение обходится дороже предыдущего, и в итоге в один прекрасный момент менеджеру приходит мысль, что "переписать всё нах" будет дешевле. С этим "открытием" манагер идёт к экзекутивам — разумеется, изрядно приправив его красивыми графиками, идущими в небеса, обещаниями всеобщего счастья — те утверждают бюджет, всю эту армию разгоняют, нанимают контракторов и новых быдлокодеров и...goto в начало поста.
Вот такие дела...

Здравствуйте, VladD2, Вы писали:

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

VD>Сформулируем вопрос так. Считаете ли вы, что лучше брать на работу посредственных программистов и решать проблемы их массой и применением примитивных технологий дабы не перегружать их мозг.
Нет.
Подобным образом мыслят только временщики, которым главное СЕЙЧАС бабла срубить. Они не думают о ДЕЛЕ, они не умеют (и не хотят) "выращивать" дело...

Здравствуйте, VladD2, Вы писали:

VD>В последнее время все чаще слышу мнения в которых есть одно общее зерно — хороших программистов трудно найти, они хотят много денег, легко уходят... по этому мы берем на работу плохих программистов за меньшие деньги, но в больших количествах и наш софт должен писаться так, чтобы эти плохие программисты могли понять код. А раз так, то мы не можем использовать сложные решения поднимающие эффективность программиста.

VD>Я, честно говоря, с этим мнением в корне не согласен, так как усложнение задачи делает проект просто не подъемным для "простых программистов". Но вопрос не в этом. Меня интересует, какая часть посетителей данного форума придерживается тех же взглядов?

VD>Сформулируем вопрос так. Считаете ли вы, что лучше брать на работу посредственных программистов и решать проблемы их массой и применением примитивных технологий дабы не перегружать их мозг.

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

От этого возникает проблема: удержать первоклассного спеца на унылом проекте очень сложно. Мотивация деньгами работает до определенного предела, давать ему вольности "переписать все" — контрпродуктивно.

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

Получается такой замкнутый круг: хреновые специалисты создают неинтересные проекты, неинтересные проекты не позволяют нанять и удержать хороших специалистов.

Здравствуйте, VladD2, Вы писали:

VD>Сформулируем вопрос так. Считаете ли вы, что лучше брать на работу посредственных программистов и решать проблемы их массой и применением примитивных технологий дабы не перегружать их мозг.

Monkey-driven development (когда управляют приматы), равно как и development done by monkeys (когда они программируют), неизбежно приводит к одному и тому же результату: к созданию и накоплению технического долга. Со временем это приводит к наложению проблем друг на друга до тех пор, пока поддержка и развитие имеющегося кода не становится попросту невозможной.

Это годится для одноразовых проектов. Фьючерсы на односолодовый виски там для трейдеров на коленке посчитать. Или игру написать. Для проектов, жизненный цикл которых превышает одну итерацию это смертельно.

T>

Отладка кода вдвое сложнее, чем его написание. Так что если вы пишете код настолько умно, насколько можете, то вы по определению недостаточно сообразительны, чтобы его отлаживать.
T>— Brian W. Kernighan.

Так вот почему многие настаивают что пошаговый отладчик не нужен!

Здравствуйте, VladD2, Вы писали:

VD>Сформулируем вопрос так. Считаете ли вы, что лучше брать на работу посредственных программистов и решать проблемы их массой и применением примитивных технологий дабы не перегружать их мозг.

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

VD>Сформулируем вопрос так. Считаете ли вы, что лучше брать на работу посредственных программистов и решать проблемы их массой и применением примитивных технологий дабы не перегружать их мозг.

Эффективность той или иной группы разработки оценивается при помощи так называемых метрик. Они в считанных конторах считаются, и могут быть разные даже для разных офисов одной конторы, даже при одинаковых технологиях. Этакая выраженная в числовой форме совокупность оценки завершённых проектов на ревью, прибыли с проекта, текучки кадров, оценок полученных на ревью самим разработчикам, и т.п. Мне довелось работать только в паре контор где эти самые метрики считали — обычно считают прибыль с человеко-часа.

Так вот, там где метрики считали, получалось что проекты с супер-спецами, или хотябы очень-спецами — по итогам пары-тройки лет и нескольких проектов — существенно выгоднее, но их настолько же сложнее администрировать, планировать, оценивать и т.п. И прибыльность таких проектов — штука прыгающая. То неожиданная сверхприбыль, то вылазят за бюджет. Прибыльность посредственностей — прогнозируема, по сути главное точно оценить сколько часов они будут лячкать говнокод, досыпать поправочных кэфов на сёрфинг интернетов, тестирование, отладку и т.п., и получаешь точную цифру, которую в конце проекта с удовлетворением вписываешь в отчёты, дескать во как круто оценили, погрешность минимальная. И это — ни с кем не советуясь, без всяких прототипов и пилотных проектов, в общем всё тупо и просто. В итоге с посредственностями конторе проще прогнозировать дебет/кредит.

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

Ну и соответственно я, после того как на метриках прочухал это, занимаюсь проектами со спецами — там интереснее и процент идущий в карман с завершённых проектов выше.

Здравствуйте, denisko, Вы писали:

D>Если вы не можете объяснить пятилетнему ребенку, чем вы занимаетесь, значит вы занимаетесь не тем. (С) Р.Фейнман.

а вот интересно, как сам г-н Фейнман обьяснял 5 летнему ребенку интегралы по траекториям, которыми занимался?

ну а по сути вопроса... фиг его знает... тут из серии анекдота про Адама, который, когда пошел в среднюю райскую школу, получил задание на дом написать два сочинения: одно для Б-га какими люди должны быть, второе, для дьявола, какими они будут.

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

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

Здравствуйте, WolfHound, Вы писали:

A>>Тут речь шла о том что большая часть работы рутина.
WH>Рутина она по тому что вместо шагающего экскаватара используют палки копалки.

Если тебе надо выкопить двести семьдесят одно мелких отверстий разной формы, то экскаватор тебе не поможет. Ирония в том, что автоматизация бизнес-процессов штука неавтоматизируемая, потому что процессы, как правило, исторически через жопу.

Здравствуйте, VladD2, Вы писали:

VD>Сформулируем вопрос так. Считаете ли вы, что лучше брать на работу посредственных программистов и решать проблемы их массой и применением примитивных технологий дабы не перегружать их мозг.

Обычно фирмы берут лучших из тех что удовлетворяют условиям (приоритет условий может чуток меняться):

1 есть на рынке труда в конкретном регионе
2 имеют интерес к той области, которой занимается фирма
3 владеют нужной технологией на уровне не ниже требуемого для проекта
4 подходят под вилку ЗП которую определяет владелец фирмы или кастомер или вписываются в бюджет проекта
5 вписываются в коллектив
6 могут быть найдены в разумное время
7 могут быстро обучаться
8 знаю иностранный язык на уровне не ниже требуемого по проекту
9 имеют возможность ездить в командировки

Всех делов — получить многокомпонентную оценку, отранжировать N-кандидатов и взять n-наилучших, (N > n). Но часто оказывается, что m (N>m>n) имеют провальный уровень по одной из оценок. Как решить проблему найма ?

очевидно — забивать на некоторые пункты. Смотрим, на что можно забить, а на что нельзя забить

1. нет
2. да
3. да
4. нет
5. нет
6. нет
7. да
8. нет
9. нет

Собственно это всё. Другое решение — перебраться в другой регион, где будут другие кастомеры, другие проекты, большая/меньшая ЗП и тд.

Итого — если фирма не может сменить кастомера, регион, то приходится брать из тех, кто просто приходит на собеседование

Т.е. тупо — работать с теми, кто есть, а не ждать волшебника в голубом вертолете.

A> из двухсот кошек одного льва не сделаешь

Только из 200 кошек и можно гарантированно сделать одного льва.
Но для этого должна быть система обучения, которая стоит денег.
Если же зааутсорсить эту функцию во внешний мир и набирать готовых специалистов,
то можно достигнуть двух целей:
1) обеспечить независимость бизнеса от ухода разработчиков
2) избежать издержек на систему обучения

Здравствуйте, vitasR, Вы писали:

D>>Если вы не можете объяснить пятилетнему ребенку, чем вы занимаетесь, значит вы занимаетесь не тем. (С) Р.Фейнман.

R>а вот интересно, как сам г-н Фейнман обьяснял 5 летнему ребенку интегралы по траекториям, которыми занимался?

А кто скзал, что он это сделал? Он просто понял, что занимается не тем.

Попробуй сам объяснить ребенку интегралы и тоже поймешь, что занимаешься не тем (фигней).

Здравствуйте, VladD2, Вы писали:

VD>В последнее время все чаще слышу мнения в которых есть одно общее зерно — хороших программистов трудно найти, они хотят много денег, легко уходят... по этому мы берем на работу плохих программистов за меньшие деньги, но в больших количествах и наш софт должен писаться так, чтобы эти плохие программисты могли понять код. А раз так, то мы не можем использовать сложные решения поднимающие эффективность программиста.
Я чет не понял, как это? Код должен писаться так, чтобы он должен был пониматься любым, легко, с бодуна и через год. Вся сложность должна быть инкапсулирована в либах, куда плохие заглядывать не будут, они должны тупо их использовать! Вот за счет либ и нужно поднимать эффективность программиста. В либах внутри сложность может быть нетривиальная, но внутрь мало кто лазит, а основной код должен читаться как английский текст, быть без подводных камней (а какие подводные камни есть — там комментирии здоровенные должны быть). Потому какие проблемы то, не пойму — нормальные либы с удобным использованием пишите, а низкоквалифицированные пусть их используют и не задумываются, и наступит счастье.

Здравствуйте, fddima, Вы писали:

F>билды WiX 3 beta в своё время были полностью неработоспособными — знаю на практике.
Ох больная тема. Мы тут в одном проекте WIX оставили только в одном примитивнейшем сетапе, который тупо файлы в папку копирует + пару значений в реестр.
А для основного продукта оказалость проще написать свой инсталлер, бо заимелись при каждом апгрейде на следующую версию обходить заморочки MSI.

Здравствуйте, VladD2, Вы писали:

VD> хороших программистов трудно найти, они хотят много денег, легко уходят... по этому мы берем на работу плохих программистов...

Во-первых, любая контора берёт ЛУЧШИХ, но чтобы они писали в пределах корпоративной культуры и архитектуры. Во-вторых, нет таких коллективов, где нет хороших прогеров. Они составляют "мозг проекта", а вокруг них можно нанимать хоть негров — они одинаково эффективно решат _разложенные_по_полочкам_ задачи. Не надо думать, что проекты — это сплошь шахматы и ребусы, подавляющая их часть — РУТИНА, оформленная в красивые модули и стрелочки.

VD> наш софт должен писаться так, чтобы эти плохие программисты могли понять код.

Ясный код понимаем любым. Плохой не понимаем даже специалистами. Так что нет "специального кода для обезьян" — есть "обезьяний код".

VD> А раз так, то мы не можем использовать сложные решения поднимающие эффективность программиста.

Можем, но только решения, проверенные практикой. Опять же, повторюсь: НЕТ столько головоломок, сколько немерлисты хотят решить своими макросами — и без немерли, и даже без жабы/сишарпа писались многомиллионные проекты НА ПРОСТОМ СИ — _тем_ танцорам язык не мешал. Почему? Потому что "эффективность — она в головах", а не синтаксисе.

VD>Я, честно говоря, с этим мнением в корне не согласен, так как усложнение задачи делает проект просто не подъемным для "простых программистов".

Для этого есть "мозг проекта", но и тут выплывает ещё один плюс "средних решений" — они _понимаемы_всеми_ членами команды, т.е. имеем бенефит коллективного разума. Более того — "средние решения" легче модернизировать в силу их "незаумности".

VD> Но вопрос не в этом. Меня интересует, какая часть посетителей данного форума придерживается тех же взглядов?

Среди профи и бизнесменов — 100%. Это _требования_рынка_, а не похоть ленивых прогеров. "Для себя" можно хоть брэйнфакать, но для бизнеса нужны надёжные средства.

Здравствуйте, _d_m_, Вы писали:

___>Очередной мля непризанный гений. Я таких нах увольняю. Нафиг мне человек супер-пупер прогер, если на него нельзя положится — он ломает все планы. Толку от его гениальности — если он завалит проект по срокам, т.е. в итоге результат 0.

Что значит "положиться"?
Ты ему называешь сроки и он не выполняет?
Или ты спросил у него о сроках, он сказал и не выполнил в срок?
Недооценка постоянная? Если да, то почему ты её не учитываешь?
Если сроки называются исполнителями от фонаря, то почему не пытаешься в причинах разобраться? Может недостаток информации или слишком общее\слишком расплывчатое задание?

Я понимаю проблемы могут быть когда работа удаленная, но когда человек сидит рядом, в том же офисе, то всегда можно поговорить и выяснить причины.

Здравствуйте, VladD2, Вы писали:

VD>В последнее время все чаще слышу мнения в которых есть одно общее зерно — хороших программистов трудно найти, они хотят много денег, легко уходят... по этому мы берем на работу плохих программистов за меньшие деньги, но в больших количествах и наш софт должен писаться так, чтобы эти плохие программисты могли понять код. А раз так, то мы не можем использовать сложные решения поднимающие эффективность программиста.

VD>Я, честно говоря, с этим мнением в корне не согласен, так как усложнение задачи делает проект просто не подъемным для "простых программистов". Но вопрос не в этом. Меня интересует, какая часть посетителей данного форума придерживается тех же взглядов?

VD>Сформулируем вопрос так. Считаете ли вы, что лучше брать на работу посредственных программистов и решать проблемы их массой и применением примитивных технологий дабы не перегружать их мозг.

Изначально в вопросе непонятен один момент — что имеется в виду под "примитивными технологиями"? Технологиями организации труда или технологий, применяемых в написанных решениях? Я начал отвечать, исходя из первого, и уже в процессе ответа понял, что ты скорее всего имел в виду второе. Прошу всё-таки говорить более определёнными терминами.

По организации — если мы берём посредственных программистов, наоборот, их надо обставить технологическими средствами так, чтобы они хоть что-то внятное выдавали. Все стандартные IDE'шные фишки им должны быть максимально доступны. Далее, крайне важна организация труда — то есть все стандартные приёмы из XP/Agile/etc. типа парного программирования и TDD должны применяться по максимуму. Плохой программист — часто плохой по внутренней дисциплине, а не по уровню развития и знания технологий.

А вот сокращать уровень, необходимый для вхождения в конкретную технологию, может иметь смысл, но не более чем до определённого предела, который часто совсем рядом. Иначе оно просто не будет толком работать. Это касается и алгоритмических основ, и внешних технологий. С другой стороны, намеренное усложнение тоже обычно не имеет смысла.

Вообще, мне кажется, чаще всего дело не в уровне, а в устоявшихся привычках. Не могу подобрать аналогов из виндового мира, но представим себе проект, например, который лучше всего было бы писать на Django, но в наличии только взвод кодеров на PHP. Или Си вместо Эрланга для задачи, которую лучше всего уложить на обмен сообщениями между группой мелких процессов. Если бы тот кодер учился тому, что нужно, с самого начала, он бы в лёгкую вошёл в тему, но ему будет проблемой именно освоение нового средства, даже если оно в разы проще и удобнее.

А собственно уровень устройства технологии — он обычно может быть очень легко инкапсулирован в глубинах реализации.

Так я таки понял, что ты имеешь в виду, или (как обычно) будем ещё сотню сообщений уточнять термины?

Здравствуйте, mrTwister, Вы писали:

T>

Отладка кода вдвое сложнее, чем его написание.

Я уверен, что это заявление не является истинным на всех входных данных. Рассмотрим пример:

Обозначения:
С — сложность написания хорошего с точки зрения архитектуры кода;
с — сложность написания посредственного с точки зрения архитектуры кода;
O — сложность отладки хорошего с точки зрения архитектуры кода;
o — сложность отладки посредственного с точки зрения архитектуры кода;

Из исходного утверждения следует, что O/C = o/c = 2.

При этом, думаю, мало кто будет спорить, что:
1. С > c
2. O <= o (Иначе код С не так уж хорошо архитектурно продуман)
Откуда следует:
3. O/C < o/c

Что противоречит следствию из исходного утверждения

VD>То есть, дело в тупом руководстве?
В мировоззрении. (И чаще всего это "дороже денег" (не знаю насчёт зарубежа, но в России да))
"Нам не нужны умные, нам нужны верные"
"Главное — добросовестность"
В более тяжёлых случаях — "В настоящей жизни всё настоящее даётся только через напряжение, а этот не хочет делать так как трудно, всё придумывает как бы посачковать и позаниматься чем ему интересно, вместо того чтобы пахать как раб на галере. Вон все студенты пашут принятой в компании технологии и не жалуются что у них плуг между досок застревает"

Здравствуйте, VladD2, Вы писали:

VD>В последнее время все чаще слышу мнения в которых есть одно общее зерно — хороших программистов трудно найти, они хотят много денег, легко уходят... по этому мы берем на работу плохих программистов за меньшие деньги, но в больших количествах и наш софт должен писаться так, чтобы эти плохие программисты могли понять код. А раз так, то мы не можем использовать сложные решения поднимающие эффективность программиста.

VD>Я, честно говоря, с этим мнением в корне не согласен, так как усложнение задачи делает проект просто не подъемным для "простых программистов". Но вопрос не в этом. Меня интересует, какая часть посетителей данного форума придерживается тех же взглядов?

VD>Сформулируем вопрос так. Считаете ли вы, что лучше брать на работу посредственных программистов и решать проблемы их массой и применением примитивных технологий дабы не перегружать их мозг.

Отладка кода вдвое сложнее, чем его написание. Так что если вы пишете код настолько умно, насколько можете, то вы по определению недостаточно сообразительны, чтобы его отлаживать.
— Brian W. Kernighan.

Здравствуйте, VladD2, Вы писали:

VD>Сформулируем вопрос так. Считаете ли вы, что лучше брать на работу посредственных программистов и решать проблемы их массой и применением примитивных технологий дабы не перегружать их мозг.

1) Я считаю, что из двухсот кошек одного льва не сделаешь.
2) Чтобы рулить выдающимся программистом, нужно быть выдающимся менеджером.
Ну а дальше вы поняли.

Здравствуйте, VladD2, Вы писали:

VD>Я, честно говоря, с этим мнением в корне не согласен, так как усложнение задачи делает проект просто не подъемным для "простых программистов".

усложнение задачи или усложнение решения?. чаще "непростые погроммисты" усложняют решение.. зачастую даже не особо оправданно..

VD>Но вопрос не в этом. Меня интересует, какая часть посетителей данного форума придерживается тех же взглядов?
VD>Сформулируем вопрос так. Считаете ли вы, что лучше брать на работу посредственных программистов и решать проблемы их массой и применением примитивных технологий дабы не перегружать их мозг.

если с вопросом определился, то создай голосование..

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Архитектор это не менеджер, даже если он с большой буквы.
A>>Он нужен менеджменту.
НС>А программист не нужен?

Ценность программиста и арзитектора для менеджмента разная. Архитектор предсказывает характеристики процесса разработки и квалифицирован менять технологическую сторону процесса для достижения нужных характеристик. Программист этого не может.

Здравствуйте, VladD2, Вы писали:

VD>В последнее время все чаще слышу мнения в которых есть одно общее зерно — хороших программистов трудно найти, они хотят много денег, легко уходят... по этому мы берем на работу плохих программистов за меньшие деньги, но в больших количествах и наш софт должен писаться так, чтобы эти плохие программисты могли понять код. А раз так, то мы не можем использовать сложные решения поднимающие эффективность программиста.

VD>Я, честно говоря, с этим мнением в корне не согласен, так как усложнение задачи делает проект просто не подъемным для "простых программистов". Но вопрос не в этом. Меня интересует, какая часть посетителей данного форума придерживается тех же взглядов?

VD>Сформулируем вопрос так. Считаете ли вы, что лучше брать на работу посредственных программистов и решать проблемы их массой и применением примитивных технологий дабы не перегружать их мозг.
Если вы не можете объяснить пятилетнему ребенку, чем вы занимаетесь, значит вы занимаетесь не тем. (С) Р.Фейнман.

Здравствуйте, VladD2, Вы писали:

VD>Я, честно говоря, с этим мнением в корне не согласен, так как усложнение задачи делает проект просто не подъемным для "простых программистов".

Не согласен. Усложнение задачи всего-лишь повышает нагрузку на архитекторов проекта, которые должны более эффективно декомпозировать сложные задачи в группу простых, легко выполнимых обычным программистом среднего уровня или даже ниже.

Здравствуйте, x-code, Вы писали:

VD>>Сформулируем вопрос так. Считаете ли вы, что лучше брать на работу посредственных программистов и решать проблемы их массой и применением примитивных технологий дабы не перегружать их мозг.

XC>Лучше брать на работу программистов, которым интересно программирование. Которые занимаются программированием с удовольствием, которые обсуждают вопросы программинга вне контекста работы, которые пишут программы в свободное от работы время.

И он будет основное время просаживать на блоги, где в очередной раз обсуждается, что монады — это неимоверно круто.

Здравствуйте, neFormal, Вы писали:

F>Здравствуйте, gandjustas, Вы писали:

G>>Большинство программистов занимается таким унылым говном, что лучше застрелиться чем делать это. Документообороты, учетные системы, сайты, бухгалтерии, очередные датчики и scada-подобные системы, интеграция существующих решений... Далеко не всем везет работать в наукоемкой области.
G>>От этого возникает проблема: удержать первоклассного спеца на унылом проекте очень сложно. Мотивация деньгами работает до определенного предела, давать ему вольности "переписать все" — контрпродуктивно.

F>тогда совсем непонятно, почему "первоклассные спецы"™ не упрощают/ускоряют свою унылую работу, не автоматизируют?.
F>может не такие уж они и "первоклассные"™, если не могут это сделать?.

Не все можно автоматизировать. Если тебе надо написать 100 разных выборок из БД, то тебе в любом случае придется писать эти выборки.
В основном автоматизация бизнеса сводится к множеству маленьких задач. Как ни автоматизируй — их все равно надо решать.

VD>Почему-то всех прет отвечать на другие вопросы (не заданные мной) или сразу говорить что постановка вопроса некорректна.
А это неспроста. В школах со времён СССР всех учат тому что если нихрена не знаешь — нужно сказать хоть что-нибудь, потому что честное "не знаю" — это 2 балла сразу.

VD>А я правильно понял, что ты и есть этот самый оценщик?
Долгое время оценка и написание прототипов, в сложных случаях, были основным делом.

Здравствуйте, adontz, Вы писали:

L>>Ошибки реализации и ошибки выбора абстракций так же неприятны, как и ошибки архитектурные. Если за красивым архитектурным фасадом скрывается нечто из говна и палок, то поддержка этой конструкции ничем не отличается от подержки любой другой конструкции из говна и палок.
L>>Если, конечно, работа архитектора не состоит в том, чтобы разрабатывать интерфейсы всех классов еще до их реализации.

A>Да, но накопления технического долга нет. Когда припрёт можно достаточно безболезненно переделать.

Вот именно из таких вот предположений и вырастает технический долг.

Здравствуйте, adontz, Вы писали:

A>Если всё вышеперечисленное верно, а оно как правило верно, то лучше нанять среднячков, лучше использовать только мейнстрим. Всё равно менеджмент построен исходя из предположения о возможном увольнении и внезапно обнаружившейся недостаточной квалификации. Если эти риски уже учтены в структуре управления, и если их надо учитывать даже с гениями, то зачем нанимать гениев?

Мое мнение, возможно глубоко ошибочное — с таким подходом сколько не делай мерседес все лада-калина получается. Ибо надежно, знакомо, обкатано.....

Здравствуйте, adontz, Вы писали:

A>Тут речь шла о том что большая часть работы рутина.
Рутина она по тому что вместо шагающего экскаватара используют палки копалки.

Здравствуйте, Don Reba, Вы писали:

DR>Здравствуйте, alpha21264, Вы писали:

T>>>>

Отладка кода вдвое сложнее, чем его написание. Так что если вы пишете код настолько умно, насколько можете, то вы по определению недостаточно сообразительны, чтобы его отлаживать.
DR>— Brian W. Kernighan.

DR>>>Интересно, в чём измеряется сложность отладки, в чём написание, и какое это имеет отношение к сообразительности?

A>>Например числом переменных, которые вы одномоментно должны держать в памяти.

DR>То есть, во время отладки, в памяти необходимо держать вдвое больше переменных? Понятно, человек хотел сказать: "писать трудноотлаживаемый код — плохо." Но манеру выражения он выбрал пафосную и бессмысленную.

Ну типа да. Потому что обычно отладка это поиск какого-то сайд-эффекта. Что-то происходит за пределами твоего куска.
И тебе нужно зарезервировать часть мозгов, которая будет держать в поле зрения дополнительные сущности сайд эффекта.

А Керниган как раз очень хорошо умел выражался. Понятно и однозначно.

VD>Сформулируем вопрос так. Считаете ли вы, что лучше брать на работу посредственных программистов и решать проблемы их массой и применением примитивных технологий дабы не перегружать их мозг.

Изначально неверный вопрос, получившийся из неверной предпосылки. Других программистов просто *нет*. Это — реальность, данная нам в ощущениях. На работу приходится брать не то, чтобы хорооших, а хотя бы посредственных, потому что других просто нет.

У нас на собеседовании задают следующую задачку: есть таблица 3х3. Есть комбобокс, есть ссылка. При клике на ссылку в комбобокс с сервера загружаются значения «красный», «синий», «белый». При выборе какого-либо значения в комбобоксе центральная ячейка в таблице должна смениться на соответсвующий цвет.

Все.

Из двух десятков человек при наличии времени почти в полтора часа, с возможностью пользоваться инетом, задачу решили на сто процентов... 1 человек. Еще один решил ее на 90%. Остальные не решили ее даже близко.

Такова суровая реальность.

Здравствуйте, vitasR, Вы писали:

R>наверное так: для архитектурных и стратегических решений, а так же ключевые вещи должны делать профи, пусть за дорого. на остальном — можно сэкономить.
Бывает ведь и так когда наоборот — на низу сидят нормальные гуру, а на ключевых решениях — мамочки ж.

R>причем, ведь есть такая порода "гуру", люди которые сверху вниз на всех остальных смотрят и учат всех жить. Они умудряются делать даже простые вещи сложно (а то ж какой он иначе гуру?), при этом они вполне могут быть реально умными и продвинутыми. вот от таких надо держаться подальше, себе дороже будет. т.е. должен быть профи, а не гуру. как-то вот так.
В каждом программисте живёт свой эгоист. Только дружеское общение между двумя эгоистами может разрушить преграду пренебрежения.
А то о чём пишешь ты — это или умение выживать в этом мире — или это не гуру.

M>Из двух десятков человек при наличии времени почти в полтора часа, с возможностью пользоваться инетом, задачу решили на сто процентов... 1 человек. Еще один решил ее на 90%. Остальные не решили ее даже близко.

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

Здравствуйте, vitasR, Вы писали:

R>причем, ведь есть такая порода "гуру", люди которые сверху вниз на всех остальных смотрят и учат всех жить. Они умудряются делать даже простые вещи сложно (а то ж какой он иначе гуру?), при этом они вполне могут быть реально умными и продвинутыми. вот от таких надо держаться подальше, себе дороже будет. т.е. должен быть профи, а не гуру. как-то вот так.

Это самая худшая из всех возможных катастроф. Банда из 1000 индусов — ничто по сравнению с одним таким "гуру"

Здравствуйте, Mamut, Вы писали:

M>Здравствуйте, hi_octane, Вы писали:

M>>>Из двух десятков человек при наличии времени почти в полтора часа, с возможностью пользоваться инетом, задачу решили на сто процентов... 1 человек. Еще один решил ее на 90%. Остальные не решили ее даже близко.

_>>Это не говорит о том что все программисты тупые, это говорит лишь о том что ваши вакансии интересны именно таким людям, и процедуры отсеивания резюме и телефонного интервью поставлены крайне плохо. Тут надо не программистов ругать, а эйчар или кто там у вас делает их работу.

M>У нас нет телефонного интервью, потому что для этого просто нет времеи, увы. Резюме мы и так отсеиваем.

проще приглашать человека в офис, чем поговорить с ним по телефону?

Здравствуйте, adontz, Вы писали:

A>Менеджмент нужен в любом случае, вне зависимости от уровня программистов. Это накладные расходы, которые надо понести вне зависимости от того гении у тебя работают или идиоты. Если даже в проекте сплошь гении, нужны PM и Архитектор, и т.д.

Арихитектор это не менеджер, даже если он с большой буквы.

Здравствуйте, gandjustas, Вы писали:

G>Большинство программистов занимается таким унылым говном, что лучше застрелиться чем делать это. Документообороты, учетные системы, сайты, бухгалтерии, очередные датчики и scada-подобные системы, интеграция существующих решений... Далеко не всем везет работать в наукоемкой области.
G>От этого возникает проблема: удержать первоклассного спеца на унылом проекте очень сложно. Мотивация деньгами работает до определенного предела, давать ему вольности "переписать все" — контрпродуктивно.

тогда совсем непонятно, почему "первоклассные спецы"™ не упрощают/ускоряют свою унылую работу, не автоматизируют?.
может не такие уж они и "первоклассные"™, если не могут это сделать?.

Здравствуйте, neFormal, Вы писали:

F>тогда совсем непонятно, почему "первоклассные спецы"™ не упрощают/ускоряют свою унылую работу, не автоматизируют?.

Они это делают, но в других компаниях, которые пишут библиотеки, фреймворки, платформы.

Здравствуйте, landerhigh, Вы писали:

L>>>Monkey-driven development (когда управляют приматы), равно как и development done by monkeys (когда они программируют), неизбежно приводит к одному и тому же результату: к созданию и накоплению технического долга.

A>>Только при архитектурных ошибках.

L>Ошибки реализации и ошибки выбора абстракций так же неприятны, как и ошибки архитектурные. Если за красивым архитектурным фасадом скрывается нечто из говна и палок, то поддержка этой конструкции ничем не отличается от подержки любой другой конструкции из говна и палок.
L>Если, конечно, работа архитектора не состоит в том, чтобы разрабатывать интерфейсы всех классов еще до их реализации.

Да, но накопления технического долга нет. Когда припрёт можно достаточно безболезненно переделать.

Здравствуйте, gandjustas, Вы писали:

G>Большинство программистов занимается таким унылым говном, что лучше застрелиться чем делать это. Документообороты, учетные системы, сайты, бухгалтерии, очередные датчики и scada-подобные системы, интеграция существующих решений... Далеко не всем везет работать в наукоемкой области.

Даже больше — наукоемнкие проекты многие также считают болотом

G>Получается такой замкнутый круг: хреновые специалисты создают неинтересные проекты, неинтересные проекты не позволяют нанять и удержать хороших специалистов.

"Неинтересные" это от человека зависит.

Здравствуйте, Ikemefula, Вы писали:

A>>Да, но накопления технического долга нет. Когда припрёт можно достаточно безболезненно переделать.
I>Переделать за нулевое время конечно же ?

Конечно нет. Но есть такое понятие, как time-to-market и его, как правило, надо минимизировать. Поэтому и поулчаются "долги". В этом смысле технологические долги аналогичны банковским кредитам. На оба начисляются проценты, оба беруться чтобы быстрее добиться захвата рынка.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, mik1, Вы писали:

M>>Сегодня вот обнаружил String.equals(""+char). Только вот в очень вложенном цикле... Само по себе фигня вроде...
G>1)Какой процент времени занимает это сложение?
G>2)Если меньше 1% то нафига ты туда лазил? У тебя более важных дел не нашлось?

1) Ты понимаешь, что там под капотом происходит?
2) Ускорение всего модуля в 4 раза за счет переделывания вот такой строчки. Я же сказал — она в очень вложенном цикле...

Здравствуйте, alpha21264, Вы писали:

A>А Керниган как раз очень хорошо умел выражался. Понятно и однозначно.

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

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, alpha21264, Вы писали:

A>>А Керниган как раз очень хорошо умел выражался. Понятно и однозначно.

N>Почему "умел"? Он живой и не собирается пока сдаваться

Это я с прямым углом перепутал.

N>Но этот вывод мне не нравится. Мол, пишите тупо, тогда хватит мозгов на отладку.

Пишите просто — будет работать надежно. Это не значит тупо.
Автомат Калашникова простой. Но не тупой.

Здравствуйте, mik1, Вы писали:

M>Да, и одной такой строчкой я свою зп за день с лихвой окупил. Мы молотилками данных занимаемся.

Такие строчки легко вылавливаются профайлером за очень скромное время. Для этого не нужна мегаквалификация.

Здравствуйте, _d_m_, Вы писали:

___>Очередной мля непризанный гений. Я таких нах увольняю. Нафиг мне человек супер-пупер прогер, если на него нельзя положится — он ломает все планы. Толку от его гениальности — если он завалит проект по срокам, т.е. в итоге результат 0.

Так это не он завалил. Это ты завалил. Тебя и увольнять надо.

Здравствуйте, gandjustas, Вы писали:

G>Я понимаю проблемы могут быть когда работа удаленная, но когда человек сидит рядом, в том же офисе, то всегда можно поговорить и выяснить причины.

А если удаленная, то "поговорить и выяснить причины" уже нельзя?

Здравствуйте, VladD2, Вы писали:

VD>Сформулируем вопрос так. Считаете ли вы, что лучше брать на работу посредственных программистов и решать проблемы их массой и применением примитивных технологий дабы не перегружать их мозг.

Кстати, неплохая альтернативная расшифровка для MDD (model-driven development).

PS. 'driven' читается как 'дривн'.

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

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

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

VD>Считаете ли вы, что лучше брать на работу посредственных программистов
Возможно было бы информативнее вопрос расширить.
а) считаете ли вы
б) считает ли ваше руководство
(моё бывшее да)

Здравствуйте, VladD2, Вы писали:

VD>Сформулируем вопрос так. Считаете ли вы, что лучше брать на работу посредственных программистов и решать проблемы их массой и применением примитивных технологий дабы не перегружать их мозг.

реалии таковы, что где-то это работает а где-то нет. пример: контора А, не абстрактная т.е. она была и есть в Москве занимается прямо скажем говнокодированием, код туп, прост даже для посредственных студентов и контора не боится ухода "звезды" коих не так много. Где-то мелькало, то ли у Спольски то ли еще у кого, что MS тоже не берет звезд в плане массового набора и код пишется без выворотов аля boost или нутро ротора. Мне кажется, что дело не в тупом примении принципа "навалимся массой", а в грамотном архитекторе и вообще руководителях проектов, иначе ни звезды, ни масса не в состоянии работать как часы и вообще хоть что-то делать совместно

Здравствуйте, VladD2, Вы писали:

VD> Сформулируем вопрос так. Считаете ли вы, что лучше брать на работу посредственных программистов и решать проблемы их массой и применением примитивных технологий дабы не перегружать их мозг.

Считаю, что нужно брать на работу программистов, способных выдавать приемлемый результат за приемлемые ресурсы (время/деньги) и в работе использовать технологии, которые были проверены практикой и временем.

P.S. И лучше переформулировать вопрос, убрав из него ненужную экспрессию — все всё понимают.

Здравствуйте, Osaka, Вы писали:

VD>>Считаете ли вы, что лучше брать на работу посредственных программистов
O>Возможно было бы информативнее вопрос расширить.
O>а) считаете ли вы
O>б) считает ли ваше руководство
O>(моё бывшее да)

То есть, дело в тупом руководстве?

Здравствуйте, VladD2, Вы писали:

VD>То есть, дело в тупом руководстве?
Не обязательно тупом.
Ответ на твой вопрос зависит от целой массы параметров: состояния рынка труда, специфики решаемой задачи, бюджетов, сроков и т.п.
Единого оптимального ответа на все случаи жизни просто не существует.

Здравствуйте, VladD2, Вы писали:

VD>Сформулируем вопрос так. Считаете ли вы, что лучше брать на работу посредственных программистов и решать проблемы их массой и применением примитивных технологий дабы не перегружать их мозг.

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

Здравствуйте, Arsen.Shnurkov, Вы писали:

A>> из двухсот кошек одного льва не сделаешь

AS>Только из 200 кошек и можно гарантированно сделать одного льва.
AS>Но для этого должна быть система обучения, которая стоит денег.
AS>Если же зааутсорсить эту функцию во внешний мир и набирать готовых специалистов,
AS>то можно достигнуть двух целей:
AS>1) обеспечить независимость бизнеса от ухода разработчиков
AS>2) избежать издержек на систему обучения

Ты наверное не знаешь, что такое лев.
Льва нельзя получить с помощью "системы обучения".
Ну и это... насчет "готовых специалистов" (в Москве) ты тоже сильно обольщаешься.

Здравствуйте, VladD2, Вы писали:

VD>Я, честно говоря, с этим мнением в корне не согласен, так как усложнение задачи делает проект просто не подъемным для "простых программистов". Но вопрос не в этом. Меня интересует, какая часть посетителей данного форума придерживается тех же взглядов?
Задачи бывают разными. В задачах переложить одни данные из одного места, обработать и положить в другое — есть тоже своя большая сложность. Если отсутствует общая организация/процесс и документация — то бесполезно — борьба с мельницей. Лично у меня — мельница масштабов страны — иногда доходит до смешного. А практически все учётные задачи такие. От банков до... х.з. чего даже. Для решения этих задач — супер языков не нужно — а вот хоть мало мальски грамотный программист — нужен и очень сильно.
Скажем, ребята, которые вбивали в серверный код константы, которые меняются ежедневно и должны браться из справочников рядом стоящего комплекса — таких удалось понаблюдать — вообще за такое можно ещё на штрафные санкции налететь — но это, я считаю, крайний случай, тем не менее — с такими раскладами — я бы лично не рискнул брать настолько бестолковых.
Так что с тобой не согласится, мне кажется невозможным.
То о чём говоришь ты — мне кажется выше того, что я описал — тем не менее — программист должен быть программистом. Нужно иметь пытливый ум, а остальное приложится за месяц. Не знаешь? Научим. Не хочешь — досвидания.

VD>Сформулируем вопрос так. Считаете ли вы, что лучше брать на работу посредственных программистов и решать проблемы их массой и применением примитивных технологий дабы не перегружать их мозг.
Считаю, что нужно брать вменяемых. Дочитать всё до конца!
Считаю, что не стоит использовать "непроверенные" технологии. Из проверенных языков под дотнет — это C#, F#.
Если на пальцах, — ради примера. Меня на работе никто и ничто не заставит использовать Nemerle, если не будет веских оснований. Потому, что последователи ниосилят и это в том числе. А последователи будут... Но, и сам ниосилил, пока что.
На днях очень серьёзно смотрел на ваш PEG, и подмывало очень. Но проблема решилась или временно или на совсем, — пока не знаю, но нашел готовый и, что важно, вменяемый — EcmaScript5 парсер. Посему заморачиваться с каким-либо другим решением смысла не было. Но, если бы не нашел — взял бы без вопросов Nemerle — ведь важен конечный результат, а не тулзы.
Если я сейчас, условно, Nemerle отнёс к непроверенным — то WiX который я использую вовсю вот уже более 4-х лет — такая же непроверенная тулза. Лично для меня их отличает: WiX я в живую пускал, со второй только вскользь игрался. При этом, я почему-то уверен, что Nemerle генерирует нормальный код, а то, что билды WiX 3 beta в своё время были полностью неработоспособными — знаю на практике.

Здравствуйте, RonWilson, Вы писали:

RW>реалии таковы, что где-то это работает а где-то нет. пример: контора А, не абстрактная т.е. она была и есть в Москве занимается прямо скажем говнокодированием, код туп, прост даже для посредственных студентов и контора не боится ухода "звезды" коих не так много. Где-то мелькало, то ли у Спольски то ли еще у кого, что MS тоже не берет звезд в плане массового набора и код пишется без выворотов аля boost или нутро ротора. Мне кажется, что дело не в тупом примении принципа "навалимся массой", а в грамотном архитекторе и вообще руководителях проектов, иначе ни звезды, ни масса не в состоянии работать как часы и вообще хоть что-то делать совместно

На счет МС, мне достоверно известно, что там работает не один очень достойный программист.

Что до архитекторов... а они что не программисты? Думаешь можно заниматься архитектурой не садясь за компьютер?

Здравствуйте, mrTwister, Вы писали:

T>

Отладка кода вдвое сложнее, чем его написание. Так что если вы пишете код настолько умно, насколько можете, то вы по определению недостаточно сообразительны, чтобы его отлаживать.
T>— Brian W. Kernighan.

Я ему всегда не доверял.

Здравствуйте, Mamut, Вы писали:

M>Изначально неверный вопрос, получившийся из неверной предпосылки. Других программистов просто *нет*. Это — реальность, данная нам в ощущениях. На работу приходится брать не то, чтобы хорооших, а хотя бы посредственных, потому что других просто нет.

А себя ты каким считаешь?

Здравствуйте, hi_octane, Вы писали:

_>Ну и соответственно я, после того как на метриках прочухал это, занимаюсь проектами со спецами — там интереснее и процент идущий в карман с завершённых проектов выше.

Интересно... что это один из немногих ответов хоть как-то по делу. Почему-то всех прет отвечать на другие вопросы (не заданные мной) или сразу говорить что постановка вопроса некорректна.

А я правильно понял, что ты и есть этот самый оценщик?

Здравствуйте, vitasR, Вы писали:

R>а вот интересно, как сам г-н Фейнман обьяснял 5 летнему ребенку интегралы по траекториям, которыми занимался?

Судя по его научно-популярным книгам, запросто мог. Но это очень редкий талант.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Mamut, Вы писали:

M>>Изначально неверный вопрос, получившийся из неверной предпосылки. Других программистов просто *нет*. Это — реальность, данная нам в ощущениях. На работу приходится брать не то, чтобы хорооших, а хотя бы посредственных, потому что других просто нет.

IT>А себя ты каким считаешь?

Весьма посредственным.

Здравствуйте, hi_octane, Вы писали:

M>>Из двух десятков человек при наличии времени почти в полтора часа, с возможностью пользоваться инетом, задачу решили на сто процентов... 1 человек. Еще один решил ее на 90%. Остальные не решили ее даже близко.

_>Это не говорит о том что все программисты тупые, это говорит лишь о том что ваши вакансии интересны именно таким людям, и процедуры отсеивания резюме и телефонного интервью поставлены крайне плохо. Тут надо не программистов ругать, а эйчар или кто там у вас делает их работу.

У нас нет телефонного интервью, потому что для этого просто нет времеи, увы. Резюме мы и так отсеиваем.

Здравствуйте, mrTwister, Вы писали:

T>

Отладка кода вдвое сложнее, чем его написание. Так что если вы пишете код настолько умно, насколько можете, то вы по определению недостаточно сообразительны, чтобы его отлаживать.
T>— Brian W. Kernighan.

Забавная максима, но сильно несправедливая. Она обычно имеет смысл в обстановке, где тяжело с отладкой и диагностировать приходится по косвенным признакам — например, такое бывает с крэшами ядра. Далее, непонятно, что значит "настолько умно, насколько можете" — имеется в виду только собственный ум или можно использовать также вложенное другими в используемые средства? Например, если я применяю valgrind для проверки корректности работы с динамической памятью и вообще с указателями, я поступаю на пределе собственного ума или я всё-таки сумел подключить коллективную мудрость коллег?

Здравствуйте, ArtDenis, Вы писали:

AD>Не согласен. Усложнение задачи всего-лишь повышает нагрузку на архитекторов проекта, которые должны более эффективно декомпозировать сложные задачи в группу простых, легко выполнимых обычным программистом среднего уровня или даже ниже.

Что в пределе ведет к команде состоящей сплошь из "архитекторов" (высококвалифицированных программистов)

Здравствуйте, VladD2, Вы писали:

_>>Ну и соответственно я, после того как на метриках прочухал это, занимаюсь проектами со спецами — там интереснее и процент идущий в карман с завершённых проектов выше.
VD>Интересно... что это один из немногих ответов хоть как-то по делу. Почему-то всех прет отвечать на другие вопросы (не заданные мной) или сразу говорить что постановка вопроса некорректна.

это потому, что:
Вопрос из разряда, хотите ли вы быть богатым и здоровым или бедным и больным. © Lloyd

ясен пень, никто не хочет работать с плохими сотрудниками или писать очередной helloworld..
но что делать?. сложных интересных задач на всех не хватает, а бессмысленно повышать сложность только ради ласкания своего чсв глупо..
поэтому на работе работаем с кем придётся (кто способен решить задачу), а для наколенных прожектов уже можно искать спецов.. или скорее участвовать в проектах спецов..

Здравствуйте, adontz, Вы писали:

A>Я не случайно упомянул узлы компьютера, а не что-то одушевлённое. Никаких персоналий в правильном менеджменте нет. То что крутую задачу нельзя решить средствами обезьянок это правда. Но разве для того чтобы написать ПО нужно чтобы каждая обезьянка хорошо понимала всё решение? А что тогда делает архитектор? Нет, обезьянки не придумают решение, но зато реализуют, а большего и не надо.

Всё таки до обезьянки надо донести как цель её локальной задачи, так и более глобальную цель. Зачем? А чтоб была обратная связь архитектора/etc с тем кто его писанину использует. Те кому пофиг сделают как сказали, а кому не пофиг может чего полезного выдадут.

Здравствуйте, dr.Chaos, Вы писали:

DC>Всё таки до обезьянки надо донести как цель её локальной задачи, так и более глобальную цель. Зачем? А чтоб была обратная связь архитектора/etc с тем кто его писанину использует. Те кому пофиг сделают как сказали, а кому не пофиг может чего полезного выдадут.

Если выдадут что-то полезное, значит уже не обезьянки

Здравствуйте, adontz, Вы писали:

A>Если выдадут что-то полезное, значит уже не обезьянки

Ну блин, у каждого не написано на лбу: "Йа, абезьяко!" и даже сертификата такого нет. Я употребил это насвание из твоего поста, можно заменить на "винтик" и т.п.

Здравствуйте, VladD2, Вы писали:

VD>Сформулируем вопрос так. Считаете ли вы, что лучше брать на работу посредственных программистов и решать проблемы их массой и применением примитивных технологий дабы не перегружать их мозг.

Хуже то, что вся цепочка менеджмента вплоть до самого верха тоже рассчитывает на использование програмиздов скажем так, средней квалификации. А некоторые менеджеры даже и не в курсе того, что существуют какие-то другие.

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

Здравствуйте, Pzz, Вы писали:

Pzz>Хуже то, что вся цепочка менеджмента вплоть до самого верха тоже рассчитывает на использование програмиздов скажем так, средней квалификации. А некоторые менеджеры даже и не в курсе того, что существуют какие-то другие.

Дык средней это не так уж и плохо. Тут то народ все время говорит об каких-то чуть ли не обезьянах. Они типа даже с yeild српавиться не могут.

Здравствуйте, VladD2, Вы писали:

Pzz>>Хуже то, что вся цепочка менеджмента вплоть до самого верха тоже рассчитывает на использование програмиздов скажем так, средней квалификации. А некоторые менеджеры даже и не в курсе того, что существуют какие-то другие.

VD>Дык средней это не так уж и плохо. Тут то народ все время говорит об каких-то чуть ли не обезьянах. Они типа даже с yeild српавиться не могут.

Слово "средний" я от врожденной политкорректности сказал

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Архитектор это не менеджер, даже если он с большой буквы.

Он нужен менеджменту.

Здравствуйте, adontz, Вы писали:

НС>>Архитектор это не менеджер, даже если он с большой буквы.

A>Он нужен менеджменту.

А программист не нужен?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, netch80, Вы писали:

N>>Изначально в вопросе непонятен один момент — что имеется в виду под "примитивными технологиями"?

НС>Расшифрую — не использование Nemerle

Спасибо, идея понятна

Здравствуйте, dr.Chaos, Вы писали:

DC>Здравствуйте, adontz, Вы писали:

A>>Если выдадут что-то полезное, значит уже не обезьянки

DC>Ну блин, у каждого не написано на лбу: "Йа, абезьяко!" и даже сертификата такого нет.

Есть

Здравствуйте, landerhigh, Вы писали:

VD>>Сформулируем вопрос так. Считаете ли вы, что лучше брать на работу посредственных программистов и решать проблемы их массой и применением примитивных технологий дабы не перегружать их мозг.
L>Monkey-driven development (когда управляют приматы), равно как и development done by monkeys (когда они программируют), неизбежно приводит к одному и тому же результату: к созданию и накоплению технического долга.

Только при архитектурных ошибках.

Здравствуйте, LaptevVV, Вы писали:

LVV>Они не думают о ДЕЛЕ, они не умеют (и не хотят) "выращивать" дело...

Несколько, старомодно, конечно Но истово плюсую ваше мнение.

Здравствуйте, Visor2004, Вы писали:

V>Здравствуйте, LaptevVV, Вы писали:

LVV>>Они не думают о ДЕЛЕ, они не умеют (и не хотят) "выращивать" дело...

V>Несколько, старомодно, конечно Но истово плюсую ваше мнение.
Кстати, одна из книжек о бизнесе (собственном деле), которую я читал, так и называлась "Я выращиваю свой бизнес". Мужик там писал (англичанин), что поставить бизнес на ноги — это дело долгое. "На ноги" — это когда бизнес работает уже практически без твоего участия... И личность "постановщика" играет решающую роль!

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, landerhigh, Вы писали:

VD>>>Сформулируем вопрос так. Считаете ли вы, что лучше брать на работу посредственных программистов и решать проблемы их массой и применением примитивных технологий дабы не перегружать их мозг.
L>>Monkey-driven development (когда управляют приматы), равно как и development done by monkeys (когда они программируют), неизбежно приводит к одному и тому же результату: к созданию и накоплению технического долга.

A>Только при архитектурных ошибках.

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

Здравствуйте, adontz, Вы писали:

F>>тогда совсем непонятно, почему "первоклассные спецы"™ не упрощают/ускоряют свою унылую работу, не автоматизируют?.
A>Они это делают, но в других компаниях, которые пишут библиотеки, фреймворки, платформы.

а в текущей компании написание хотя бы библиотеки под запретом?.

Здравствуйте, gandjustas, Вы писали:

F>>тогда совсем непонятно, почему "первоклассные спецы"™ не упрощают/ускоряют свою унылую работу, не автоматизируют?.
F>>может не такие уж они и "первоклассные"™, если не могут это сделать?.
G>Не все можно автоматизировать. Если тебе надо написать 100 разных выборок из БД, то тебе в любом случае придется писать эти выборки.
G>В основном автоматизация бизнеса сводится к множеству маленьких задач. Как ни автоматизируй — их все равно надо решать.

конечно, только в какой области деятельности нет рутины?.

Здравствуйте, neFormal, Вы писали:

F>а в текущей компании написание хотя бы библиотеки под запретом?.

Менеджмент предпочтёт купить готовую. У меня был прикольный случай, когда библиотеку уже написали, а потом, вместо её дальнейшей поддержки, купили готовую, хотя технологических причин не было.

Здравствуйте, neFormal, Вы писали:

F>конечно, только в какой области деятельности нет рутины?.

Тут речь шла о том что большая часть работы рутина.

M>>>>Из двух десятков человек при наличии времени почти в полтора часа, с возможностью пользоваться инетом, задачу решили на сто процентов... 1 человек. Еще один решил ее на 90%. Остальные не решили ее даже близко.

_>>>Это не говорит о том что все программисты тупые, это говорит лишь о том что ваши вакансии интересны именно таким людям, и процедуры отсеивания резюме и телефонного интервью поставлены крайне плохо. Тут надо не программистов ругать, а эйчар или кто там у вас делает их работу.

M>>У нас нет телефонного интервью, потому что для этого просто нет времеи, увы. Резюме мы и так отсеиваем.

B>проще приглашать человека в офис, чем поговорить с ним по телефону?

В нашем случае — да.

Здравствуйте, neFormal, Вы писали:

F>Здравствуйте, gandjustas, Вы писали:

F>>>тогда совсем непонятно, почему "первоклассные спецы"™ не упрощают/ускоряют свою унылую работу, не автоматизируют?.
F>>>может не такие уж они и "первоклассные"™, если не могут это сделать?.
G>>Не все можно автоматизировать. Если тебе надо написать 100 разных выборок из БД, то тебе в любом случае придется писать эти выборки.
G>>В основном автоматизация бизнеса сводится к множеству маленьких задач. Как ни автоматизируй — их все равно надо решать.

F>конечно, только в какой области деятельности нет рутины?.

Рутина есть везде, вопрос только в относительном объеме рутины. В автоматизации бизнеса процент близок к 100, в какой-нить разработке компилятора — на порядок меньше.

Здравствуйте, Mamut, Вы писали:

M>>>>>Из двух десятков человек при наличии времени почти в полтора часа, с возможностью пользоваться инетом, задачу решили на сто процентов... 1 человек. Еще один решил ее на 90%. Остальные не решили ее даже близко.

_>>>>Это не говорит о том что все программисты тупые, это говорит лишь о том что ваши вакансии интересны именно таким людям, и процедуры отсеивания резюме и телефонного интервью поставлены крайне плохо. Тут надо не программистов ругать, а эйчар или кто там у вас делает их работу.

M>>>У нас нет телефонного интервью, потому что для этого просто нет времеи, увы. Резюме мы и так отсеиваем.

B>>проще приглашать человека в офис, чем поговорить с ним по телефону?

M>В нашем случае — да.

А можно поподробнее?
Чем приглашение проще получасового скринера по телефону, после которого можно уже и в офис пригласить?

Здравствуйте, FR, Вы писали:

R>>а вот интересно, как сам г-н Фейнман обьяснял 5 летнему ребенку интегралы по траекториям, которыми занимался?

FR>Судя по его научно-популярным книгам, запросто мог. Но это очень редкий талант.

Объяснить то он мог бы, но вряд ли ребенок понял Ребенок в этом возрасте не умеет воспринимать факты существующие независимо от него, не умеет оперировать ими и много чего еще не умеет. Вот где то с 7 лет уже можно чего то объяснить.

Здравствуйте, vitasR, Вы писали:

R>Здравствуйте, denisko, Вы писали:

D>>Если вы не можете объяснить пятилетнему ребенку, чем вы занимаетесь, значит вы занимаетесь не тем. (С) Р.Фейнман.

R>а вот интересно, как сам г-н Фейнман обьяснял 5 летнему ребенку интегралы по траекториям, которыми занимался?
Во-первых, это не "чем" занимался, это "как" занимался. Во-вторых, данный формализм и был развит тов. Фейнманом, чтобы КТП могла заниматься относительная школота, поскольку образование устроено так, что школота после университета худо-бедно интегрировать умеет, а считать ряды практически нет.

Здравствуйте, adontz, Вы писали:

L>>Если, конечно, работа архитектора не состоит в том, чтобы разрабатывать интерфейсы всех классов еще до их реализации.

A>Да, но накопления технического долга нет. Когда припрёт можно достаточно безболезненно переделать.

Переделать за нулевое время конечно же ?

Здравствуйте, mrTwister, Вы писали:

T>

Отладка кода вдвое сложнее, чем его написание. Так что если вы пишете код настолько умно, насколько можете, то вы по определению недостаточно сообразительны, чтобы его отлаживать.
T>— Brian W. Kernighan.

И это он еще слабо сказал !

M>>>>У нас нет телефонного интервью, потому что для этого просто нет времеи, увы. Резюме мы и так отсеиваем.

B>>>проще приглашать человека в офис, чем поговорить с ним по телефону?

M>>В нашем случае — да.

B>А можно поподробнее?
B>Чем приглашение проще получасового скринера по телефону, после которого можно уже и в офис пригласить?

Тогда мы вообще никого на работу брать не будем А так, хоть видно, можно ли человека хотя бы обучить

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, RonWilson, Вы писали:

RW>>реалии таковы, что где-то это работает а где-то нет. пример: контора А, не абстрактная т.е. она была и есть в Москве занимается прямо скажем говнокодированием, код туп, прост даже для посредственных студентов и контора не боится ухода "звезды" коих не так много. Где-то мелькало, то ли у Спольски то ли еще у кого, что MS тоже не берет звезд в плане массового набора и код пишется без выворотов аля boost или нутро ротора. Мне кажется, что дело не в тупом примении принципа "навалимся массой", а в грамотном архитекторе и вообще руководителях проектов, иначе ни звезды, ни масса не в состоянии работать как часы и вообще хоть что-то делать совместно

VD>На счет МС, мне достоверно известно, что там работает не один очень достойный программист.

VD>Что до архитекторов... а они что не программисты? Думаешь можно заниматься архитектурой не садясь за компьютер?

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

Здравствуйте, Mamut, Вы писали:

M>>>>>У нас нет телефонного интервью, потому что для этого просто нет времеи, увы. Резюме мы и так отсеиваем.

B>>>>проще приглашать человека в офис, чем поговорить с ним по телефону?

M>>>В нашем случае — да.

B>>А можно поподробнее?
B>>Чем приглашение проще получасового скринера по телефону, после которого можно уже и в офис пригласить?

M>Тогда мы вообще никого на работу брать не будем А так, хоть видно, можно ли человека хотя бы обучить

непонятно, зачем приглашать всех в офис, если совсем неадекваты отсеиваются на этапе скриннинга.

Здравствуйте, VladD2, Вы писали:

VD>Сформулируем вопрос так. Считаете ли вы, что лучше брать на работу посредственных программистов и решать проблемы их массой и применением примитивных технологий дабы не перегружать их мозг.

Очевидно, что все зависит от задачи и окружающего мира.

Не все задачи требуют гениев, надо разделять изобретение колеса и использование колеса. Для очень большого количества проектов (особенно тех которые не предполагается поддерживать и развивать) сверхквалифицированная рабочая сила просто не нужна.

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

Вот простой пример. Открыла в твоем городе офис фирма, которая может позволить себе переманивать людей на гораздо большие зарплаты и переманила у тебя 50% всех разработчиков. Проект встал. Может это проблема, а может и нет — но учитывать подобные риски в бизнес-проектах необходимо.

Еще такой момент. В любом проекте есть огромное количество рутины, которой кто-то должен заниматься. А совмещать в одном проекте разработчиков очень сильных и очень посредственных, с разным уровнем знаний и (это тоже важно) зарплат это порождать почву для недовольства, а значит и для конфликтов.

Резюмируя. Выбор уровня разработчиков на проекте, так же сложен и так же важен, как и выбор технологии.

Здравствуйте, mrTwister, Вы писали:

T>

Отладка кода вдвое сложнее, чем его написание. Так что если вы пишете код настолько умно, насколько можете, то вы по определению недостаточно сообразительны, чтобы его отлаживать.
— Brian W. Kernighan.

Интересно, в чём измеряется сложность отладки, в чём написание, и какое это имеет отношение к сообразительности?

Здравствуйте, Ikemefula, Вы писали:

G>>Получается такой замкнутый круг: хреновые специалисты создают неинтересные проекты, неинтересные проекты не позволяют нанять и удержать хороших специалистов.

I>"Неинтересные" это от человека зависит.

Конечно, некоторые и рутину автоматизации бизнеса считают интересной. Это самые ценные кадры

M>>>>>>У нас нет телефонного интервью, потому что для этого просто нет времеи, увы. Резюме мы и так отсеиваем.

B>>>>>проще приглашать человека в офис, чем поговорить с ним по телефону?

M>>>>В нашем случае — да.

B>>>А можно поподробнее?
B>>>Чем приглашение проще получасового скринера по телефону, после которого можно уже и в офис пригласить?

M>>Тогда мы вообще никого на работу брать не будем А так, хоть видно, можно ли человека хотя бы обучить

B>непонятно, зачем приглашать всех в офис, если совсем неадекваты отсеиваются на этапе скриннинга.

Совсем неадекватные отсеиваются на этапе просмотра резюме. Из десятка резюме хорошо, если два-три вызывают интерес. Их и приглашаем.

Здравствуйте, iyura, Вы писали:

A>>Если всё вышеперечисленное верно, а оно как правило верно, то лучше нанять среднячков, лучше использовать только мейнстрим. Всё равно менеджмент построен исходя из предположения о возможном увольнении и внезапно обнаружившейся недостаточной квалификации. Если эти риски уже учтены в структуре управления, и если их надо учитывать даже с гениями, то зачем нанимать гениев?
I>Мое мнение, возможно глубоко ошибочное — с таким подходом сколько не делай мерседес все лада-калина получается. Ибо надежно, знакомо, обкатано.....

И, что важнее, продаётся. Вобщем-то не всё так печально, но вы правы. А что, есть большой продукт, который внутри прекрасен?

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, iyura, Вы писали:

A>>>Если всё вышеперечисленное верно, а оно как правило верно, то лучше нанять среднячков, лучше использовать только мейнстрим. Всё равно менеджмент построен исходя из предположения о возможном увольнении и внезапно обнаружившейся недостаточной квалификации. Если эти риски уже учтены в структуре управления, и если их надо учитывать даже с гениями, то зачем нанимать гениев?
I>>Мое мнение, возможно глубоко ошибочное — с таким подходом сколько не делай мерседес все лада-калина получается. Ибо надежно, знакомо, обкатано.....

A>И, что важнее, продаётся. Вобщем-то не всё так печально, но вы правы. А что, есть большой продукт, который внутри прекрасен?

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

ИМХО, речь идет о том, что программирования из высокотехнологического инженерного процесса пытаются превратить в ремесло, в котором знать о формальных грамматиках, исчислении Черча и "прочей лабуде" знать не обязательно — тебе ведь покажут, как кодировать "отсюда и до забора".

Вот мы и получаем снижающийся профессионализма в нашем деле.

Здравствуйте, adontz, Вы писали:

A>Дублирование снижает риски. Лучше нанять не одного гения, а двух средних программистов, но точно знать с увольнением/болезнью любого их них проект не загнётся.

A>Идеальное качество недостижимо, приемлемое для продажи и конкурентной борьбы — вполне.

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

А потом время от времени я нахожу в чужом коде одно-строчные косяки, результатом которых может быть прыжок с обработки 10К сообщений в секунду до 40-100К...
Вплоть до чуда из чудес — удаления из ArrayList в цикле первого элемента. Длина списка — пара миллионов записей. Но при разработке было много меньше. Средние программисты... рассматривают только средние случаи...

Здравствуйте, iyura, Вы писали:

I>ИМХО, речь идет о том, что программирования из высокотехнологического инженерного процесса пытаются превратить в ремесло, в котором знать о формальных грамматиках, исчислении Черча и "прочей лабуде" знать не обязательно — тебе ведь покажут, как кодировать "отсюда и до забора".

Это требует цель — зарабатывать деньги.

I>Вот мы и получаем снижающийся профессионализма в нашем деле.

Это везде наблюдается.

Здравствуйте, mik1, Вы писали:

M>А потом время от времени я нахожу в чужом коде одно-строчные косяки, результатом которых может быть прыжок с обработки 10К сообщений в секунду до 40-100К...
M>Вплоть до чуда из чудес — удаления из ArrayList в цикле первого элемента. Длина списка — пара миллионов записей. Но при разработке было много меньше. Средние программисты... рассматривают только средние случаи...

Стабильность важнее скорости, мегагерцы дешевле человекочасов. Это реальный мир.

I>Здравствуйте, adontz, Вы писали:
не обязательно — тебе ведь покажут, как кодировать "отсюда и до забора".

Извините, наделал кучу ошибок ибо спешил Грамматики и Чёрч упомянуты исключительно для примера. С тем же успехом можно говорить о Чебышеве и кривых Безье...

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, iyura, Вы писали:

I>>ИМХО, речь идет о том, что программирования из высокотехнологического инженерного процесса пытаются превратить в ремесло, в котором знать о формальных грамматиках, исчислении Черча и "прочей лабуде" знать не обязательно — тебе ведь покажут, как кодировать "отсюда и до забора".

A>Это требует цель — зарабатывать деньги.

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

I>>Вот мы и получаем снижающийся профессионализма в нашем деле.

A>Это везде наблюдается.

К сожалению. И с этим нужно что-то делать

Здравствуйте, iyura, Вы писали:

A>>Это требует цель — зарабатывать деньги.
I>Если цель состоит исключительно в зарабатывании денег

Ещё в захвате сфер влияния. Внедрил один софт, легче пропихнуть другой. Значит надо быстро их выпускать.

I>>>Вот мы и получаем снижающийся профессионализма в нашем деле.
A>>Это везде наблюдается.
I>К сожалению. И с этим нужно что-то делать

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

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, mik1, Вы писали:

M>>А потом время от времени я нахожу в чужом коде одно-строчные косяки, результатом которых может быть прыжок с обработки 10К сообщений в секунду до 40-100К...
M>>Вплоть до чуда из чудес — удаления из ArrayList в цикле первого элемента. Длина списка — пара миллионов записей. Но при разработке было много меньше. Средние программисты... рассматривают только средние случаи...

A>Стабильность важнее скорости, мегагерцы дешевле человекочасов. Это реальный мир.

Во-первых, эта разница может стать решающей. Могут быть временные ограничения на готовность результатов. Многопоточность, к слову, к добродетелям средних программистов тоже слабенько относится. А на одном ядре уже давно каш нормально не сваришь.
Во-вторых, я же сказал — однострочные косяки. Они к стабильности отношения не имеют. Сегодня вот обнаружил String.equals(""+char). Только вот в очень вложенном цикле... Само по себе фигня вроде...
И в-третьих, это уже скорее к оригинальному письму Влада, не усложнять надо, а упрощать. По этому поводу высказывание знаменитое же есть... И это как раз да — библиотеки писать, за изобретение велосипедов по рукам стучать, и т.д. Тогда сложность начнет укладываться в заданные рамки.

Здравствуйте, mik1, Вы писали:

M>Во-первых, эта разница может стать решающей. Могут быть временные ограничения на готовность результатов.

Это очень специфичное требование.

M>И в-третьих, это уже скорее к оригинальному письму Влада, не усложнять надо, а упрощать. По этому поводу высказывание знаменитое же есть... И это как раз да — библиотеки писать, за изобретение велосипедов по рукам стучать, и т.д. Тогда сложность начнет укладываться в заданные рамки.

+1. Библиотеки — сила.

Здравствуйте, adontz, Вы писали:

I>>>>Вот мы и получаем снижающийся профессионализма в нашем деле.
A>>>Это везде наблюдается.
I>>К сожалению. И с этим нужно что-то делать

A>Можно рассказывать свои внукам, что раньше трава была зеленее, а вода мокрее Я не знаю что с этим делать, людей больше, рабочая сила дешевле, результат предсказуем.

И поэтому (для большей убедительности) не нужно учить все эти цитологии и анатомии.....?

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

> Мэйнстрим == манки-драйвен-девелопмент?

вот сижу и ломаю голову: то ли дривн, то ли drunken имелось в виду

Здравствуйте, iyura, Вы писали:

I>И поэтому (для большей убедительности) не нужно учить все эти цитологии и анатомии.....?

Ну вот если честно, то мне цитология как-то не пригодилась . Алгебра да, развивает абстрактное мышление, а зачем учить принудительно цитологию я не знаю.

I>Снижение уровня профессиональных знаний в той или иной области не может быть оправдано никаким образом. Что если самолеты начнут строить по принципу "быстрее захватить рынок и сделать это с помощью дешовой, пусть и не всегда квалифицированой рабочей силы"?. Вы в таком самолете будете чувствовать себя комфортно?

А по вашему сейчас не так?

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, iyura, Вы писали:

I>>И поэтому (для большей убедительности) не нужно учить все эти цитологии и анатомии.....?

A>Ну вот если честно, то мне цитология как-то не пригодилась . Алгебра да, развивает абстрактное мышление, а зачем учить принудительно цитологию я не знаю.

Ну, я о врачах, вообще-то....

I>>Снижение уровня профессиональных знаний в той или иной области не может быть оправдано никаким образом. Что если самолеты начнут строить по принципу "быстрее захватить рынок и сделать это с помощью дешовой, пусть и не всегда квалифицированой рабочей силы"?. Вы в таком самолете будете чувствовать себя комфортно?

A>А по вашему сейчас не так?

Надеюсь, что нет

Здравствуйте, adontz, Вы писали:

F>>а в текущей компании написание хотя бы библиотеки под запретом?.
A>Менеджмент предпочтёт купить готовую.

У меня менеджмент предпочитает быстренько захачить на тяп-ляп.

Здравствуйте, adontz, Вы писали:

A>Конечно нет. Но есть такое понятие, как time-to-market и его, как правило, надо минимизировать. Поэтому и поулчаются "долги". В этом смысле технологические долги аналогичны банковским кредитам. На оба начисляются проценты, оба беруться чтобы быстрее добиться захвата рынка.
Это понятие (time to market) в последнее время было жестко изнасиловано "эффективными менеджерами". Кстати, одним из положительных эффектов от внедрения scrum является то, что ЭМ больше не могут заметать созданный ими же технический долг под ковер.

Технический долг всегда вылезет. Когда-то у Нокии была чуть ли не половина рынка.

Здравствуйте, mik1, Вы писали:

M>Сегодня вот обнаружил String.equals(""+char). Только вот в очень вложенном цикле... Само по себе фигня вроде...
1)Какой процент времени занимает это сложение?
2)Если меньше 1% то нафига ты туда лазил? У тебя более важных дел не нашлось?

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, mik1, Вы писали:

M>>Сегодня вот обнаружил String.equals(""+char). Только вот в очень вложенном цикле... Само по себе фигня вроде...
G>1)Какой процент времени занимает это сложение?
G>2)Если меньше 1% то нафига ты туда лазил? У тебя более важных дел не нашлось?

Да, и одной такой строчкой я свою зп за день с лихвой окупил. Мы молотилками данных занимаемся.

Здравствуйте, adontz, Вы писали:

A>Задача менеджемента — добиться цели. Один из основных методов — минимизация рисков. Следовательно, менеджмент даже с гениями обращаеться как с идиотами. Не потому что они идиоты, а потому что это минимизирует риски. Никто не станет основывать успешность разработки на знаниях идиота, поэтому на знаниях гения её тоже не стоит основывать.

A>Дублирование снижает риски. Лучше нанять не одного гения, а двух средних программистов, но точно знать с увольнением/болезнью любого их них проект не загнётся.

Есть и другое мнение:

Microsoft (back in the day), Google, and Facebook have all been obsessed with hiring the best programmers. Yahoo wasn't. They preferred good programmers to bad ones, but they didn't have the kind of single-minded, almost obnoxiously elitist focus on hiring the smartest people that the big winners have had. And when you consider how much competition there was for programmers when they were hiring, during the Bubble, it's not surprising that the quality of their programmers was uneven.

In technology, once you have bad programmers, you're doomed. I can't think of an instance where a company has sunk into technical mediocrity and recovered. Good programmers want to work with other good programmers. So once the quality of programmers at your company starts to drop, you enter a death spiral from which there is no recovery.

— Paul Graham (What happened to Yahoo)

Здравствуйте, iyura, Вы писали:

I>>Здравствуйте, adontz, Вы писали:
I>не обязательно — тебе ведь покажут, как кодировать "отсюда и до забора".

I>Извините, наделал кучу ошибок ибо спешил Грамматики и Чёрч упомянуты исключительно для примера. С тем же успехом можно говорить о Чебышеве и кривых Безье...
можно говорить о чем угодно. Но если вакансия звучит как "участие в разработке сервера телефонии" (к примеру), то с какими-нибудь замечательными кривыми Безье кандитат не столкнется в течение очень долгого времени отсюда вопрос, точнее два.
1) Насколько полно и точно будет в памяти вся эта теория, когда она все же пригодится (если пригодится)?
2) (основываясь на вопросе 1)Есть ли смысл учить ее в универе, так "шоб на всю жись", если когда ты все же с ней столкнешься — у тебя будет возможность с нуля ее освоить?

Здравствуйте, landerhigh, Вы писали:

L>Monkey-driven development (когда управляют приматы), равно как и development done by monkeys (когда они программируют), неизбежно приводит к одному и тому же результату: к созданию и накоплению технического долга. Со временем это приводит к наложению проблем друг на друга до тех пор, пока поддержка и развитие имеющегося кода не становится попросту невозможной.

L>Это годится для одноразовых проектов. Фьючерсы на односолодовый виски там для трейдеров на коленке посчитать. Или игру написать. Для проектов, жизненный цикл которых превышает одну итерацию это смертельно.
загляни в код Mozilla Thunderbird 2. А ведь сколько лет живет.......

Здравствуйте, Don Reba, Вы писали:

DR>Здравствуйте, mrTwister, Вы писали:

T>>

Отладка кода вдвое сложнее, чем его написание. Так что если вы пишете код настолько умно, насколько можете, то вы по определению недостаточно сообразительны, чтобы его отлаживать.
DR>— Brian W. Kernighan.

DR>Интересно, в чём измеряется сложность отладки, в чём написание, и какое это имеет отношение к сообразительности?

Например числом переменных, которые вы одномоментно должны держать в памяти.

Здравствуйте, March_rabbit, Вы писали:

M_>1) Насколько полно и точно будет в памяти вся эта теория, когда она все же пригодится (если пригодится)?
Не важно.

M_>2) (основываясь на вопросе 1)Есть ли смысл учить ее в универе, так "шоб на всю жись", если когда ты все же с ней столкнешься — у тебя будет возможность с нуля ее освоить?
Есть. Хотябы за тем чтобы когда понадобится вспомнить что они вообще есть, а не начать изобретать колесо.

Здравствуйте, alpha21264, Вы писали:

T>>>

Отладка кода вдвое сложнее, чем его написание. Так что если вы пишете код настолько умно, насколько можете, то вы по определению недостаточно сообразительны, чтобы его отлаживать.
— Brian W. Kernighan.

DR>>Интересно, в чём измеряется сложность отладки, в чём написание, и какое это имеет отношение к сообразительности?

A>Например числом переменных, которые вы одномоментно должны держать в памяти.

То есть, во время отладки, в памяти необходимо держать вдвое больше переменных? Понятно, человек хотел сказать: "писать трудноотлаживаемый код — плохо." Но манеру выражения он выбрал пафосную и бессмысленную.

Здравствуйте, gandjustas, Вы писали:

M>>Сегодня вот обнаружил String.equals(""+char). Только вот в очень вложенном цикле... Само по себе фигня вроде...
G>1)Какой процент времени занимает это сложение?
G>2)Если меньше 1% то нафига ты туда лазил? У тебя более важных дел не нашлось?

Иногда приходится оптимизировать и Equals и GetHashCode оптимизировать, когда числодробилки пишешь и больше оптимизировать уже негде

Здравствуйте, Osaka, Вы писали:

VD>>То есть, дело в тупом руководстве?
O>В мировоззрении. (И чаще всего это "дороже денег" (не знаю насчёт зарубежа, но в России да))
O>"Нам не нужны умные, нам нужны верные"
O>"Главное — добросовестность"
O>В более тяжёлых случаях — "В настоящей жизни всё настоящее даётся только через напряжение, а этот не хочет делать так как трудно, всё придумывает как бы посачковать и позаниматься чем ему интересно, вместо того чтобы пахать как раб на галере. Вон все студенты пашут принятой в компании технологии и не жалуются что у них плуг между досок застревает"

Очередной мля непризанный гений. Я таких нах увольняю. Нафиг мне человек супер-пупер прогер, если на него нельзя положится — он ломает все планы. Толку от его гениальности — если он завалит проект по срокам, т.е. в итоге результат 0.

___>Очередной мля непризанный гений. Я таких нах увольняю.
butthurt detected

>Нафиг мне человек супер-пупер прогер, если на него нельзя положитЬся — он ломает все планы.
Нафиг мне ножик, если на него нельзя положиться — он всё режет.
Для чего нужны "супер-пупер прогеры" и как обходить их ограничения, уже много писалось, у того же Джоэла например.

>Толку от его гениальности — если он завалит проект по срокам, т.е. в итоге результат 0.
А заранее согласовать сроки с запасом — вера не позволяет? Хотя, кто у нас способен планировать на долгосрочную перспективу...

Здравствуйте, Osaka, Вы писали:

___>>Очередной мля непризанный гений. Я таких нах увольняю.
O>butthurt detected

Не следует выдавать желаемое за действительное.

>>Нафиг мне человек супер-пупер прогер, если на него нельзя положитЬся — он ломает все планы.
O>Нафиг мне ножик, если на него нельзя положиться — он всё режет.

Аналогия ваще не в кассу. Чушь короче. Вобщем охарактеризовал ты себя отсутствием логики.

Здравствуйте, iyura, Вы писали:

I>ИМХО, речь идет о том, что программирования из высокотехнологического инженерного процесса пытаются превратить в ремесло

Ты чего то путаешь. Это как раз ремесло отличает сильная зависимость результата от таланта мастера.

Здравствуйте, gandjustas, Вы писали:

G>Рутина есть везде, вопрос только в относительном объеме рутины. В автоматизации бизнеса процент близок к 100, в какой-нить разработке компилятора — на порядок меньше.

Я бы не был в этом так уверен.

Здравствуйте, Osaka, Вы писали:

O>Так вот почему многие настаивают что пошаговый отладчик не нужен!

В те времена никакой пошаговости не было. А отладка была.

Здравствуйте, Madruel, Вы писали:

M>2. O <= o (Иначе код С не так уж хорошо архитектурно продуман)

Далеко не всегда, чем больше лишнего кода/абстракций, тем больше тестов и отладки.

M>Откуда следует:
M>3. O/C < o/c

M>Что противоречит следствию из исходного утверждения

Исходное допущение как бы среднее по палате, а ты лишь показал девиацию. Перечитай, исходное утверждение содержало лишь следующее:
O+C > o+c

Здравствуйте, Don Reba, Вы писали:

DR>Интересно, в чём измеряется сложность отладки, в чём написание, и какое это имеет отношение к сообразительности?

Человеко-часах, помноженных на требуемую квалификацию. Больше ничем.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, March_rabbit, Вы писали:

M_>>1) Насколько полно и точно будет в памяти вся эта теория, когда она все же пригодится (если пригодится)?
WH>Не важно.

M_>>2) (основываясь на вопросе 1)Есть ли смысл учить ее в универе, так "шоб на всю жись", если когда ты все же с ней столкнешься — у тебя будет возможность с нуля ее освоить?
WH>Есть. Хотябы за тем чтобы когда понадобится вспомнить что они вообще есть, а не начать изобретать колесо.
Можешь с ходу сказать, сколько колец безопасности было в защищенном режиме процессора i486? И сколько их в i7 к примеру? И где задается кольцо текущего процесса? Или ты никогда не слышал о защищенном режиме работы процессора?

или все-таки ответ на первый вопрос другой?

Здравствуйте, irium, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

G>>Я понимаю проблемы могут быть когда работа удаленная, но когда человек сидит рядом, в том же офисе, то всегда можно поговорить и выяснить причины.

I>А если удаленная, то "поговорить и выяснить причины" уже нельзя?

Можно, но сложнее.