Здравствуйте, mik1, Вы писали:
M>Во-первых, эта разница может стать решающей. Могут быть временные ограничения на готовность результатов.
Это очень специфичное требование.
M>И в-третьих, это уже скорее к оригинальному письму Влада, не усложнять надо, а упрощать. По этому поводу высказывание знаменитое же есть... И это как раз да — библиотеки писать, за изобретение велосипедов по рукам стучать, и т.д. Тогда сложность начнет укладываться в заданные рамки.
Здравствуйте, adontz, Вы писали:
I>>>>Вот мы и получаем снижающийся профессионализма в нашем деле. A>>>Это везде наблюдается. I>>К сожалению. И с этим нужно что-то делать
A>Можно рассказывать свои внукам, что раньше трава была зеленее, а вода мокрее Я не знаю что с этим делать, людей больше, рабочая сила дешевле, результат предсказуем.
И поэтому (для большей убедительности) не нужно учить все эти цитологии и анатомии.....?
Снижение уровня профессиональных знаний в той или иной области не может быть оправдано никаким образом. Что если самолеты начнут строить по принципу "быстрее захватить рынок и сделать это с помощью дешовой, пусть и не всегда квалифицированой рабочей силы"?. Вы в таком самолете будете чувствовать себя комфортно?
Здравствуйте, iyura, Вы писали:
I>И поэтому (для большей убедительности) не нужно учить все эти цитологии и анатомии.....?
Ну вот если честно, то мне цитология как-то не пригодилась . Алгебра да, развивает абстрактное мышление, а зачем учить принудительно цитологию я не знаю.
I>Снижение уровня профессиональных знаний в той или иной области не может быть оправдано никаким образом. Что если самолеты начнут строить по принципу "быстрее захватить рынок и сделать это с помощью дешовой, пусть и не всегда квалифицированой рабочей силы"?. Вы в таком самолете будете чувствовать себя комфортно?
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, iyura, Вы писали:
I>>И поэтому (для большей убедительности) не нужно учить все эти цитологии и анатомии.....?
A>Ну вот если честно, то мне цитология как-то не пригодилась . Алгебра да, развивает абстрактное мышление, а зачем учить принудительно цитологию я не знаю.
Ну, я о врачах, вообще-то....
I>>Снижение уровня профессиональных знаний в той или иной области не может быть оправдано никаким образом. Что если самолеты начнут строить по принципу "быстрее захватить рынок и сделать это с помощью дешовой, пусть и не всегда квалифицированой рабочей силы"?. Вы в таком самолете будете чувствовать себя комфортно?
A>А по вашему сейчас не так?
Здравствуйте, VladD2, Вы писали:
VD>Сформулируем вопрос так. Считаете ли вы, что лучше брать на работу посредственных программистов и решать проблемы их массой и применением примитивных технологий дабы не перегружать их мозг.
На всех контрактах, где мне довелось поработать тут, видел одну и ту же картину — пара-тройка сильных контракторов ваяют каркас приложения, ключевые компоненты и библиотеки, армия быдлокодеров...ммм...быдлокодит всё остальное. Вскоре после запуска проекта в продакшен контракторы успешно сваливают, а вместо них нанимают ещё кучку пермщиков-быдлокодеров (ибо никакой более-менее вменяемый спец не пойдёт на саппорт продукта, да и бабки там обычно дают не большие). Вся эта куча народу настраивает много слоёв подпорок, костылей и "хаков", каждое последующее изменение обходится дороже предыдущего, и в итоге в один прекрасный момент менеджеру приходит мысль, что "переписать всё нах" будет дешевле. С этим "открытием" манагер идёт к экзекутивам — разумеется, изрядно приправив его красивыми графиками, идущими в небеса, обещаниями всеобщего счастья — те утверждают бюджет, всю эту армию разгоняют, нанимают контракторов и новых быдлокодеров и...goto в начало поста.
Вот такие дела...
Здравствуйте, VladD2, Вы писали:
VD> хороших программистов трудно найти, они хотят много денег, легко уходят... по этому мы берем на работу плохих программистов...
Во-первых, любая контора берёт ЛУЧШИХ, но чтобы они писали в пределах корпоративной культуры и архитектуры. Во-вторых, нет таких коллективов, где нет хороших прогеров. Они составляют "мозг проекта", а вокруг них можно нанимать хоть негров — они одинаково эффективно решат _разложенные_по_полочкам_ задачи. Не надо думать, что проекты — это сплошь шахматы и ребусы, подавляющая их часть — РУТИНА, оформленная в красивые модули и стрелочки.
VD> наш софт должен писаться так, чтобы эти плохие программисты могли понять код.
Ясный код понимаем любым. Плохой не понимаем даже специалистами. Так что нет "специального кода для обезьян" — есть "обезьяний код".
VD> А раз так, то мы не можем использовать сложные решения поднимающие эффективность программиста.
Можем, но только решения, проверенные практикой. Опять же, повторюсь: НЕТ столько головоломок, сколько немерлисты хотят решить своими макросами — и без немерли, и даже без жабы/сишарпа писались многомиллионные проекты НА ПРОСТОМ СИ — _тем_ танцорам язык не мешал. Почему? Потому что "эффективность — она в головах", а не синтаксисе.
VD>Я, честно говоря, с этим мнением в корне не согласен, так как усложнение задачи делает проект просто не подъемным для "простых программистов".
Для этого есть "мозг проекта", но и тут выплывает ещё один плюс "средних решений" — они _понимаемы_всеми_ членами команды, т.е. имеем бенефит коллективного разума. Более того — "средние решения" легче модернизировать в силу их "незаумности".
VD> Но вопрос не в этом. Меня интересует, какая часть посетителей данного форума придерживается тех же взглядов?
Среди профи и бизнесменов — 100%. Это _требования_рынка_, а не похоть ленивых прогеров. "Для себя" можно хоть брэйнфакать, но для бизнеса нужны надёжные средства.
Здравствуйте, 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% то нафига ты туда лазил? У тебя более важных дел не нашлось?
1) Ты понимаешь, что там под капотом происходит?
2) Ускорение всего модуля в 4 раза за счет переделывания вот такой строчки. Я же сказал — она в очень вложенном цикле...
Здравствуйте, 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.
Здравствуйте, 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)Есть ли смысл учить ее в универе, так "шоб на всю жись", если когда ты все же с ней столкнешься — у тебя будет возможность с нуля ее освоить?
Есть. Хотябы за тем чтобы когда понадобится вспомнить что они вообще есть, а не начать изобретать колесо.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, adontz, Вы писали:
A>Тут речь шла о том что большая часть работы рутина.
Рутина она по тому что вместо шагающего экскаватара используют палки копалки.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Отладка кода вдвое сложнее, чем его написание. Так что если вы пишете код настолько умно, насколько можете, то вы по определению недостаточно сообразительны, чтобы его отлаживать.
— Brian W. Kernighan.
DR>>Интересно, в чём измеряется сложность отладки, в чём написание, и какое это имеет отношение к сообразительности?
A>Например числом переменных, которые вы одномоментно должны держать в памяти.
То есть, во время отладки, в памяти необходимо держать вдвое больше переменных? Понятно, человек хотел сказать: "писать трудноотлаживаемый код — плохо." Но манеру выражения он выбрал пафосную и бессмысленную.
Здравствуйте, WolfHound, Вы писали:
A>>Тут речь шла о том что большая часть работы рутина. WH>Рутина она по тому что вместо шагающего экскаватара используют палки копалки.
Если тебе надо выкопить двести семьдесят одно мелких отверстий разной формы, то экскаватор тебе не поможет. Ирония в том, что автоматизация бизнес-процессов штука неавтоматизируемая, потому что процессы, как правило, исторически через жопу.
Я не знаю что с этим делать, людей больше, рабочая сила дешевле, результат предсказуем.
отсюда вопрос, точнее два. 
