ИМХО, каждое десятилетие в ИТ отрасли происходит какая-нибудь революция или пассионарный прорыв новых знаний.
Также постоянно появляются новые отцы-основатели, звезды, находчивые дельцы и просто хорошие инженеры.
Так происходит и в наши дни. Так будет и в будущем.
А новое время бросает новые вызовы, и задачи не становятся проще.
Донского понять можно. Он прожил жизнь в программировании. И вот так все это переосмыслить, поставить себя в ряд с молодыми программистами он просто не может. Не может оставить свои задачи, к которым прирос и которым посвятил свою жизнь. Фактически его жизнь — это его задачи. А раз новое поколение этим задачам не уделяет должного внимания, то, как он считает, это слабое поколение. Это все понятно. Не понятно одно — человек с годами становится мудрее. А статья этой мудростью не отличается. Честное слово.
Ну что толку плакать о шахматных задачах и изобретении массивов, когда наше время ставит нам не менее интересные задачи — теже игры, распределенные системы, мобильные системы, web-сервисы, телекоммуникации, работа с громадными массивами данных и так далее.
ГВ>Давай так. Формальный процесс прежде всего вносит ясность: кто, чем и почему занят, и что сделано.
У-у-у-у какая наивность.
Нет уж. Фигвам. Формальный процесс может в лучшем случае создать видимость такой ясности.
Кстати, на тему ясности тут вообще есть пара забавных историй из жизни. Жила-была одна контора средних размеров (>100 сотрудников). Без особых формальных процессов. Контора писала софт, частично аутсорсинг, частично на себя (интеграция). Поначалу все шло хорошо: программистов было много, начальников и разного рода посредников — мало. Контора работала эффективно и имела устойчивый рост по финансам и по сотрудникам. В какой-то момент гендиректор перестал полностью контролировать набор персонала (т.е. даже не было личной беседы с новыми сотрудниками) и в контору начали проникать настоящие "корпоративные работники", натуральные крысы. Кто как: кто по дружбе, кто по родственным связям, кто за еще какие услуги. Эффективность стала резко падать: людей все больше и больше, а объем решаемых задач не растёт.
Решили проанализировать, узнать, куда же уходят деньги. Ввели — весьма последовательно! — кучу формализаций, от репортов по времени до еженедельных митингов и прочих петингов. Эффективность еще упала, т.к. теперь еще и процесс стал занимать значительное время.
Руководитель тогда принял сложное (но, по-видимому, правильное) решение — разогнать к чертям собачьим половину шарашки. Тех самых манагеров. Которые умели прекрасно изобразить процесс, выставив себя в этом процессе исключительно важными и незаменимыми людьми.
Сейчас эта контора продолжает работать — но не растёт, в среднем, количество персонала в ней стабильно и где-то не превышает 120 человек. Работают люди достаточно эффективно. И с минимумом процесса.
Мораль всего этого такова: процесс — это особенный, специфический навык. Никакого отношения к созданию продукта процесс не имеет. Специалисты по процессу — особые люди. Своего рода прилипалы.
DM>Про достижения 60-х: DM>здорово, конечно, рассказывать, как делал свою ОС. Только когда вся память в машине — 4 кб, это по-любому не очень большой и сложный проект. Не намного сложнее современных 4k intro, которые до сих пор пишутся пачками.
Димон, ты не прав. Тебе никогда не понять что это такое, видимо никогда не приходилось работать с такими ограничениями. Мне приходилось приближаться — реализовывать Heap на 2kb памяти — это была более чем реальная ситуация. Они делали это не в текстовом редактре и не в среде IDE, в которых работаю нынешние "микрокернелисты". Они делали это с печатающего телетайпа, перфокарт используя весьма дерьмовый ассемблер.
DM>В целом, неплохой рассказ, да и то, что автор до сих пор занимается реальными проектами и работает с современными технологиями (пусть и с ворчанием) — вызывает только уважение.
Да тут я смотрю много сейчас чуваков которые имея современные средства разработки бъют себя кулаком в грудь...
Довольно интересное чтиво. Особенно, если не обращать внимания на выводы и прогнозы, которые делаются на изначально неверной аналогии про автомобили и шофёров.
... << RSDN@Home 1.2.0 alpha rev. 771>>
Если нам не помогут, то мы тоже никого не пощадим.
AVK>Дело не столько в нестыковках, сколько в том, что текст, вызывающий истерический смех и демонстрирующий полный дилетантизм в вопросах девелопмента, перемежается вполне вменяемыми кусками, написанными явно "летающим" профессионалом. Поэтому и получается — либо это шизофрения, либо текст писали два разных человека. Мне во второе верится больше.
Без обид, но это напоминает басню "слон и моська". Человека, который учавствовал в создании Каиссы — победителя первого чемпионата мира по шахматам оценивают Василии Пупкины, люди которые не известны практически ничем. Как много мосек тявкает, а слону пофиг — он их не замечает.
Здравствуйте, sourcerer, Вы писали:
S>Здравствуйте все,
Я так понимаю в статье Донского общественность задела та идея, что "программисты мельчают" и профессия программиста уже не является передовой и интеллектуальной — для ее освоения достаточно минимальных знаний и навыков. И общественность, похоже, думает что это не так. Ну тогда ответьте на такой вопрос: насколько хорошо вы знаете математику, а насколько хорошо ее знают другие программисты? Да, конечно, сегодня уже не то программирование, что раньше. Все сильнее звучат голоса тех, кто утверждает, что математика в программировании не нужна. Что уже давно сместился акцент на SOA или что там еще выдумают маркетологи завтра. В общем, программирование становится все более гуманитарной специальностью. И эту тенденцию отражает факт появления таких специальностей как "программист PHP". Но разве гуманитаризация и появление таких языков как PHP не снижает барьеры входа в отрасль? Не делает ее более массовой? А разве эта массовость не приводит к общему снижению уровня программистов? Как еще можно объяснить тот факт, что люди утверждающие что хорошо знают алгоритмы начинают испуганно молчать при вопросе о сложности алгоритма быстрой сортировки? И даже не могут объяснить идею пузырьковой.
Если хотите, вы можете еще долго издеваться над уважаемым человеком и обсуждать как правильно писать голландские фамилии, но правоту идеи этой статьи о "мельчании" программистов наверняка отлично осознает каждый.
Здравствуйте, sourcerer, Вы писали:
S>Здравствуйте все,
S>Интереснейшая статья Михаила Донского о профессии, о том что "программер счас не тот" , о том "как все начиналось", о перспективах отрасли.
Достали аналогии для программостроения... То про "залетевшего дятла, который бы разрушил цивилизацию", расскажут. То, вот, теперь программиста с водителем или пилотом сравнят.
Если кого и сравнивать с шоферами, то пользователей ЭВМ. Тогда бы аналогия была корректна.
Когда я начинал программировать (на той самой ЕС ЭВМ, которую привезли нам в 1979 году с ВДНХ), далеко не все программисты были пользователями ЭВМ. Общался я с пользователями ЭВМ через специальный шкаф, в который сегодня клал свои перфокарты и/или перфоленты, а завтра, если повезет, получал листинг с результатами. Сейчас же «любая кухарка может управлять» ЭВМ. Не прощло и 60 лет!
ИМХО, мне представляется, что до выхода из «детского» периода программированию еще очень далеко. Пока, на мой взгляд, сложность и масштаб программистских задач растет быстрее, чем взрослеет программное производство.
Здравствуйте, denisko, Вы писали:
S>>>Интереснейшая статья Михаила Донского о профессии, о том что "программер счас не тот" , о том "как все начиналось", о перспективах отрасли.
ГВ>>На самом деле читателю навязывается две простенькие мысли:
ГВ>>- математика современному программисту не нужна; D>Это, на мой взгляд, что-то из глубин подсознания, а не из статьи. Даже намека не увидел на это.
Конечно, прямым текстом он об этом не говорит. Но фактически, подводит читателей к мысли, что специализация оказалась настолько глубока, что математика вытеснилась из собственно программирования (прям как в анекдоте — прое$алась). Хотя притом сам себе противоречит, говоря:
Если до середины 80-х еще реальны были программы, созданные если не одним человеком, то хотя бы в рамках одного коллектива, то в дальнейшем в производство шли программы, построенные по принципу «Лего», а именно, собранные из различных полуфабрикатов (библиотек и компонент), разработанных в разных уголках мира.
Как ни странно, это сделало ценность программистов с хорошим математическим (не скажу образованием, а подходом) гораздо выше.
И правильно, поскольку хоть кто-то должен думать в этом бедламе.
Противоречий у него на самом деле намного больше, взять хотя бы вот эти два тезиса:
Одним из важнейших принципов программирования для меня является необходимость создания собственного инструментария для любого проекта, начиная с проектов средней величины.
и
А понять внутреннюю организацию сложных систем можно только одним способом – самому сделать что-то подобное, пусть и гораздо более простое. Но я не слышал, чтобы студентам задавали в качестве курсовой работы создание простой операционной системы или системы управления базами данных.
В итоге профессия программиста меняет свой характер. Если раньше программисты знали свою программу досконально, то теперь в лучшем случае они умеют эффективно использовать то или иное инструментальное средство.
То есть, собственные инструментальные средства, являющиеся по его словам залогом рентабельности IT-бизнеса (здесь ему как раз можно верить, поскольку он точно знает, о чём говорит — сам же бизнесмен), уже магически оказались не нужны. По-видимому, совесть не позволяет откровенно соврать, сказав что-нибудь вроде того, что залог эффективности IT-бизнеса — доскональное знание продуктов Microsoft (дело не в названии фирмы, разумеется).
Значит, по словам Донского, IT-бизнес должен автоматически стать нерентабельным, сиречь, для сохранения рентабельности — наполненным дешёвыми обезьянками с единичными вкраплениями "математиков" (см. пассаж про аналитиков). Тогда как на самом деле одна из главных черт IT-бизнеса в том, что он по своей сущности тяготеет к сокращению количества исполнителей, благодаря повышению их квалификации. Но нет, ни фига. Донской уверен, что всё пришло к тому, к чему пришло и измениться уже не сможет.
Что характерно, процитированный фрагмент заканчивается не критикой системы образования, которая не учит детей писать свои СУБД и ОС, а совершенно неожиданным припевом: "профессия программиста становится рутинной". Я хренею, my dear editor. Так если современные средства нельзя понять, не написав аналога, то... Хотя, чему удивляться? Если бы прозвучал тезис о том, что детей надо учить писать свои СУБД, это сразу бы потащило за собой кучу дополнительных выводов, в частности о том, что образование должно включать в себя не "реальные условия", а фундаментальную подготовку, развитие абстрактного мышления и т.п.
А так получилось депрессивно, глупо, зато, как это ни странно , очень в унисон с нынешней политикой в области образования. Почему я в итоге не удивлён, что подобные излияния попали на polit.ru?
D>Единственное, что было сказано о подготовке программистов, -- это то, что готовят их неправильно. Была высказана очень простая и остроумная мысля -- чтобы подготовить реального программиста надо заставлять его работать в реальных условиях. Например, надо приучить к мысли, что требования в процессе D>разработки могут с большой вероятностью поменяться. Приучить, создав модельную ситуацию.
Угу. Мелкая косметическая деталь — бесспорно наихудший изъян образования. Кто бы спорил. Здесь как раз вылезает совершенно дурной подход. Вместо того, чтобы порекомендовать учить детей проектировать, предусматривая лёгкость модификации, он лепечет что-то про "реальные условия". Стыдоба.
ГВ>>- программирование становится рутинной профессией (основной тезис статьи). D>Становится, что поделать.
Оно ею не может стать по своей сути. Это уже действительно, возможно только "в подсознании" или при массовом сне. Хотя, я не против: сон — тоже деятельность сознания по мнению йогов. Какое-никакое, а дело.
D>Кстати, слышал, что ему принадлежит утверждение, что все средства производства проходят 3 стадии развития "Как делать?" --> "Что делать?" --> "Зачем делать?". Скорее всего, "автор хотел сказать" именно эту мыслю, единственно, что выразился не очень понятно. D>З.ы. Этап "как", имхо, уже агонизирует довольно давно.
А... Да, можно проследить и такую "сюжетную линию". Только, по-моему, это уже совсем вдалеке от основной мысли.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
AVK>>Есть такое ощущение, что статью писали два человека — сам Донской и кто то из его архитектов.
ГВ>Разнобой в мыслях есть, это точно.
Не просто разнобой, скорее некоторая шизофрения. Я не понимаю как в соседних кусках текста могу соседствовать размышления о maintainability кода и рассказы про необходимость написания собственных языков под любой проект.
ГВ> Но подпись-то под статьёй одна.
Кто бы сомневался. Советской закалки человек, знает как в СССР докторские и статьи в научные журналы писались.
... << RSDN@Home 1.2.0 alpha 4 rev. 1106 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Valery A. Boronin, Вы писали:
VAB>Подсказка: разработчик с 3мя годами боевого подтвержденного опыта — уже что-то.
Мой опыт говорит о том, что подобные критерии не являются чем-то. Я знал дятлов с 20-летним опытом, которым страшно было что-либо доверять, и вчерашних студентов, которые впрягались в работу и тянули проекты.
VAB>но все равно — попробуйте сослаться на всех своих знакомых при следующем разговоре о повышении ЗП
Мне не приходилось, но я знаю случаи, когда моим знакомым повышали зарплаты после того, как они озвучивали своему начальству суммы зарплат в предложениях от конкурентов.
E>>А этот абзац вообще о чем? VAB>Евгений, я и так уже достаточно этим вечером написал — даже не знаю чем тут помочь... прочитайте снова? или забейте.
Ладно, забъем. Хотя мне показалось, что вы озвучивали какой-то свой негативный опыт.
VAB>И ключевой тут момент, в моей теории — перейти от общих слов к конкретным критериям. Это бывает сложно, но всегда можно (при желании). А там и становится понятно, что нужно сделать для решения проблемы — и все сразу становится не так страшно, как об этом часто пишут\расказывают. И все.
VAB>Обращаю особое внимание — я даже ни разу не усомнился в том что нехватка ресурсов есть
Тогда давайте так. Я лично делю людей по такому критерию: способен ли человек решить задачу самостоятельно или нет. Ну, например, даю тестовое задание двум студентам -- написать парсер некого текстового формата. Каждому из них дается одно и то же описание, я отвечаю на все их вопросы. Причем стараюсь обсуждать основные моменты с ними одновременно, чтобы не повторять одно и то же несколько раз. Помогаю, если нужно. А спустя отведенное время проверяю полученные результаты. И тут возможно три исхода:
1. Человек не смог сам ничего сделать. Т.е. он постоянно доставал меня вопросами и делал лишь то, что я ему сказал.
2. Человек сам сделал реализацию, но реализация оказалась такова, что ее проще выбросить, чем переделать. При этом меня не столько волнует непосредственно качество кода и хорошее знание конкретного языка (будь то C++ или Ruby), сколько взятые за основу проектные решения. Т.е. если человек после нескольких лет в ВУЗе не может самостоятельно сделать декомпозицию небольшой библиотеки на классы/функции/методы, то тратить на него свое время мне уже жалко.
3. Человек сам сделал реализацию, которая не смотря на огрехи может быть доведена до ума и пущена в эксплуатацию. А уж если в ней и огрехов серьезных нет -- значит этот человек уже программирует лучше меня
Так вот задача в том, чтобы искать людей как раз показывающих третий тип результата (в соседней ветке Vzhyk, имхо, именно об этом говорил озвучивая 10 за $1000 или 3 за $2500). Именно таких я называю толковыми.
VAB>Женя, лучше бы написали с чем конкретно согласны или несогласны? Пока даже это мне не очень понятно. Если несогласны — где Ваша позиция, где объективные аргументы в пользу неправильности моей, на Ваш взгляд? Мне же тоже интересно, где я могу заблуждаться. И что предложили бы Вы для решения проблемы поиска днем с огнем своим знакомым? Вот это было бы дело. А так...
Валера, здесь уже много чего было сказано и я, если чесно, уже начинаю путаться в том, с кем о чем спорю. Поэтому я просто озвучу свою позицию.
Итак, я вижу, что в последнее время выпускники ВУЗов, как ни банально, "уже не те". Ну, чтобы не быть голословным: я в конце первого курса в качестве задания "работа с текстовыми файлами в языке Паскаль" написал текстовый редактор (ну по типу, что каждый настоящий программист должен написать свой текстовый редактор, компилятор и ОС ). Это был 1991. Где-то в 1996 я разговаривал со студентом своего же факультета, который написал свой текстовый редактор. В 1990-х годах на нашем факультете несколько преподов делали силами студентов себе кандидатские и докторские диссертации. И я знал людей, которыми были написаны система имитационного моделирования и другие штуки для наших преподов (и все это были не мальникие проекты). Лет семь-восемь назад на собеседованиях я разговаривал со студентами и выпускниками и они рассказывали, какие задачи они делали по учебе и для себя. По учебе уже не было ничего серьезного (какие уж тут текстовые редакторы). Но люди хотя бы делали что-то для себя. В последние несколько лет я провожу собеседования с такими же студентами и выпускниками -- учебные задания становятся какими-то совсем смешными, а для себя люди вообще почти ничего не делают. И это при том, что в начале 90-х если у кого-то и были свои компьютеры, то класса Байт-а, Спектрума или Синклера. Не то, что нонче.
Посему у меня напрашивается вывод о том, что если раньше на специальность "программирование" шли более-менее увлеченные люди, то сейчас это уже не так. Корифеи и монстры среди нынешних студентов, к счастью, встречаются. Они настолько сильно выделяются среди остальных, что действительно выглядят как брилианты в навозе (пардон за мой французкий).
Отсюда и самый верный способ (на мой взгляд) поиска людей -- среди студентов. Если привлекать ребят 4-х, 5-х курсов к реальной работе, то это дает им необходимые знания и опыт (который они в принципе не могут получить в ВУЗе), а нам это дает возможность производить отсев нужных нам кандидатов. Ну и кроме того, если человек во время учебы начинает участвовать в проектах и видит, как размер его зарплаты растет по мере его проффессионального роста, то может у него и не будет желания по окончанию ВУЗа линять за бугор.
Только процесс этот очень не быстрый и весьма трудоемкий.
Вот как-то так
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Flying Dutchman, Вы писали:
FD>Если быть совершенно точным, то голландская фамилия Dijkstra произносится как нечто среднее между "Дийкстра" и "Дяйкстра" (с ударением на первом слоге). Так что Донской в чем-то прав. Хотя, конечно, закрепившееся написание в русскоязычной литературе "Дейкстра".
Мало ли что как произносится. Некоторых звуков вообще в русском языке нет (те же английские th). Зато существуют общепринятые правила транскрипции имен собственных, согласно которым голландская фамилия Dijkstra должна писаться и произноситься по-русски как "Дейкстра".
Здравствуйте, eao197, Вы писали:
E>Да я вроде не пил сегодня E>Но вот пример из того же Форда...Сборка радиатора превратилась из сложной, тебующей умения, терпения, ловкости и сноровки, операции превратилась в совершенно тупую рутину.
Здесь аналогия неправильная. Программист — творческая профессия, аналогией было бы сравнивать не сборщика радиатора и программиста, а сборщика радиатора и [C++,Java,Delphi,подставить нужное]кодера. А программиста сравнивать с конструктором или дизайнером в автомобильной промышленности.
E>Аналогичные события происходят и сегодня. Раньше требовалась изрядная подготовка для того, чтобы написать отказоустойчивое класстерное приложение, да и сама задача эта была редкой, своего рода вызовом. Теперь Java-программисты не самой выской квалификации делают это путем сборки нескольких стандартных компонентов. Т.е. рабочая должность "программист" вроде как остается, но вот количество знаний/умений для нее сейчас сокращается.
Java-программисты не пишут отказоустойчивых кластерных приложений! Они фактически производят сборку и настройку готового приложения. Готового в виде отдельных блоков.
Это вообще проблема, что между разработкой каких-либо вещей и их сборкой из готовых компонентов ставится, фактически, знак равенства.
E>>>a) невыполним. Мало кто из преподавателей в ВУЗах бывшего СССР хоть что-то понимает в разработке СУБД и ОС. И горит желанием хоть чему-то в этом научиться. И, возможно, такая ситуация не только на постсоветском пространстве, но и в Европе, Азии и, может, быть в США.
Такая ситуация, насколько я в курсе, везде и это очень плохо.
E>Пределы-пределами, но есть такая простая штука, как репутация. Очень быстро станет известно, что на каком-то курсе обучение сложное и требования повышенные. Посему большая часть абитурьентов, которым вообще пофигу, чем заниматься и чему учится, уйдут туда, где репутация получше.
Последовательное применение этого принципа: учить лишь бы у дебилов и пофигистов мозг не расплавился способно ликвидировать нашу цивилизацию вообще. Человечество просто утратит свои достижения, что несмотря на внешние успехи, потихоньку и происходит. И не только "у нас", но и "у них"
E>Где ты видишь разницу? Сейчас везде говорят, что квалифицированных программистов нужно днем с огнем искать. В Москве, судя по обсуждениям в данном форуме, сейчас зарплаты начинающих программистов стартуют от 50-60т, а матерым платят по 120т. И все равно есть жалобы, что людей не хватает. Но при этом софт нужно писать постоянно, и с каждым днем все быстрее и быстрее, да чтобы лучше и дешевле.
У меня сугубо субъективное впечатление, что такое положение (софт нужно писать постоянно, и с каждым днем все быстрее и быстрее, да чтобы лучше и дешевле) — результат серьезных системных ошибок и перекосов во всей техноиндустрии. Я не готов здесь представить серьезных анализ этого утверждения. Один из перекосов — это ситуация, при которой софт пишется в основном сторонними софтверными фирмами по заказу, как мне представляется более правильно, с точки зрения качества, — это наличие собственного штата программистов (а не кодеров или тем более конфигуристов 1С) при предприятии, ориентированного на свои нужды и специфику. Это противоречит нынешней экономической модели (плата за простой, недостаточные силы для полноценного продукта и т.п.), но мне в этой связи нравится OpenSource модель, именно для таких программистов она просто, фактически, не заменима.
E> Все как в случае с Фордом. Поэтому-то большие оффшорные компании и внедряют у себя разные модели разработки, при которых рядовой программист становится винтиком -- много от него не нужно, да и заменить просто, а все, что он делает строго регламентированно.
В этих моделях разработки рядового программиста стоит перестать называть программистом. Это кодер, выполняющий работу чуть более интеллектуальную, чем машинистка.
Дядька умный, читал с удовольствием.
В комментах, как водится, яростно отметились обиженные дети
Кстати многим программистам свойственно сохранять незамутненное подростковое мировозрение и в 30 лет
sourcerer пишет: > > Интереснейшая статья Михаила Донского > том что "программер счас не тот" , о том "как все начиналось", о > перспективах отрасли.
Имхо, вот ее суть: "статью к своему 60-му дню рождения, возраст
пенсионный, и, похоже, кончается не только мой жизненный цикл"
Здравствуйте, Mystic, Вы писали:
ГВ>>Вот ради удаления этих самых рутинных задач и имеет смысл уходить на следующий виток развития.
M>Мне кажется, ситуация строго обратная.
Ситуация всегда будет казаться "обратной", поскольку всегда хочется сказать, что "всё хорошо, не надо краше", что дальше уже некуда, что всё уже придумано. Это нормально и естественно. Лень искать источник, но в каком там году сказали, что всё уже придумано и развиваться дальше некуда? В 1890-м, нет? А тоже ведь, по идее, эра придумывания должна была закончиться.
M>Наоборот, уже много лет ведется планомерная работа, чтобы сделать работу программиста как можно более рутинной. Тогда ее будет в состоянии выполнить любой индус. Творчество, конечно, хорошо, его нельзя поставить на конвейер. Нынешний идеал: составить такой набор инструций, чтобы по ним можно было разработать программный продукт.
Нынешний??? Разработки генераторов программ по требованиям велись ещё в 80-х, если мне не изменяет память. А начала положены, скорее всего, где-то в 70-х или раньше. Так что, насчёт "нынешнего" ты определённо погорячился.
Кроме того (бляха-муха, как я не люблю вспоминать про то, "что было, было, было", но приходится), я хорошо помню балабольство вокруг 4GL в первой половине 90-х, что, мол, скоро программисты окажутся не нужны, что визуальные средства сделают ненужным программирование, что достаточно будет собирать программы из "кубиков" на конвейере... Ага, и про рутину вспоминали, и про то, что сейчас всех домохозяек за SmallTalk усадим — пылесосы программировать. Ещё был такой продукт — Framework, который напрочь должен был уничтожить офисных конкурентов.
Короче говоря, идеал "конвейера" в качестве постоянно присутсвующего бродячего призрака никуда не денется, поскольку на всю нашу производственную культуру сильно повлиял конвейер как таковой. Этого не надо бояться и принимать слишком близко к сердцу.
M>Обычно считается, что любую рутину можно запрограммировать. Но это не совсем так. Запрограммировать можно то, что формализуемо.
Так а чем, по-твоему, занимаются программисты? Формализацией и доопределением того, что на первый взгляд неформализуемо и неопределённо.
M>Ну а так можно написать Большую Инструкцию для архитекторов для составления иерархии классов. Начиная с того, что нужно проанализировать ТЗ, выписать все прецеденты, описать их в последовательности выполнения действий выбрать глаголы и т. д. и т. п. Если инструкция будет достаточно детальной, то мы получим как раз рутинный процесс. Но запрограммировать его пока что нельзя.
Вопрос в том, какие формы определяются инструкциями. Если в инструкции сказано "выписать все use cases и поместить их в документ Use Case List", то здесь огромное и глубокое море для дополнительной формализации того, что такое use case, как его выделять и т.п. То, что пишется в книгах по этому поводу, по сути — рекомендации.
И между прочим, здесь есть куда ткнуть свои продукты. Правда, это уже матлингвистика... Далековато от "паттернов ООП" и решения мегапроблемы принадлежности объекта, правда?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, Handie, Вы писали:
DM>>> Только когда вся память в машине — 4 кб, это по-любому не очень большой и сложный проект.
H>> Тебе никогда не понять что это такое
DM>Вот спасибо за оценку моих способностей!
DM>Да, средства производства и сам процесс тогда были более трудоемкими. Но просто из теории информации и колмогоровской сложности, если угодно, получается, что в 4 кб — это не сильно сложная система. Даже если все это — код, это всего порядка 2к строк ассемблера довольно простого компьютера (сейчас процессоры сложнее).
Ты опять не понял. Чтобы машина с 4 кб памяти реализовывала нормальную задачу,
нужно, чтобы бОльшая часть интелекта находилась вне компьютера.
А ты оцениваешь только ту сложность, которая внутри, подразумевая, что то, что вне, будут делать другие люди.
Но даже сложность "внутри" ты оцениваешь неправильно.
Прикинь сколько переменных должен держать в голове программист при "отладке на листке бумаги".
Вот это и есть сложность для программиста.
Здравствуйте, eao197, Вы писали:
ГВ>>Да-да. И вывод он делает просто потрясающий: программирование становится рутинным. То есть это не вал дураков, с которым никто не хочет управляться, не деградация образования, а просто меняется характер профессии. Знаешь, сожаление здесь можно усмотреть только после третьего стакана.
E>Да я вроде не пил сегодня
Сегодня ещё не кончилось.
E>Но вот пример из того же Форда. Первоначально сборкой радиаторов для автомобилей занимались кузнецы очень высокой квалификации, которые выполняли сложную работу. Затем схему сборки радиаторов изменили и надобность в квалифицированных кузнецах отпала. Т.е. рабочая должность "сборщик радиаторов" сохранилась, то теперь для нее не требуется кузнец. Сборка радиатора превратилась из сложной, тебующей умения, терпения, ловкости и сноровки, операции превратилась в совершенно тупую рутину.
Ну опять двадцать пять. Повторяющиеся операции можно и должно вообще всячески вытеснять из сферы человеческой деятельности. Этим должны заниматься роботы. Нельзя тут проводить прямую аналогию с программированием.
E>Аналогичные события происходят и сегодня. Раньше требовалась изрядная подготовка для того, чтобы написать отказоустойчивое класстерное приложение, да и сама задача эта была редкой, своего рода вызовом. Теперь Java-программисты не самой выской квалификации делают это путем сборки нескольких стандартных компонентов. Т.е. рабочая должность "программист" вроде как остается, но вот количество знаний/умений для нее сейчас сокращается.
Только при одном условии — что тот самый отказоустойчивый/кластеризуемый фреймворк останется один forever. Чего в нашем бизнесе не бывает по определению.
ГВ>>Вода камень точит. Будут долбить — всё изменится. А так, конечно... E>А вот ты сам веришь, что кто-нибудь будет долбить?
Я уверен, что уже кто-то долбит. Только боюсь, что не в наших пенатах.
ГВ>>Про военную кафедру школьник ещё понимает, а про остальное... E>Пределы-пределами, но есть такая простая штука, как репутация. Очень быстро станет известно, что на каком-то курсе обучение сложное и требования повышенные. Посему большая часть абитурьентов, которым вообще пофигу, чем заниматься и чему учится, уйдут туда, где репутация получше.
Хм. Так репутация учебного заведения складывается не из сложности обучения, а из того, куда попали и кем стали выпускники. Я почему-то уверен, что люди быстро разберутся, где готовят серьёзных специалистов, а где — одипломливают биомассу. А потом, прямая обязанность учебного заведения — объяснить сложные вещи доступным языком, сиречь — научить. Научили же нас писать программы. Так что, ИМХО, опасность репутации "сложного обучения" ты преувеличиваешь.
ГВ>>Только Форд-то здесь причём? У него в принципе не было возможности набрать массу квалифицированных инженеров и рабочих, и построить, например, автоматизированное производство. Ощути разницу направлений: выкручиваться в условиях отсутствия квалифицированного персонала и сознательно снижать квалификацию персонала, подгоняя его под "модель производства". Не находишь, что это две большие разницы?
E>Где ты видишь разницу?
Вот смотри, берём две ситуации.
Первая. Те же радиаторы.
Сначала у нас небольшое производство, которое вполне обслуживается, скажем пятью квалифицированными кузнецами. Чуть позже производство расширяется, пятерых кузнецов не хватает, зато — навалом малоквалифицированных, скажем, разорившихся фермеров. Что мы сделаем? Мы постараемся сделать так, чтобы объём продукции минимально зависел от количества кузнецов, переложив на них, например, исправление огрехов литья. Остальные операции повторяются с точностью до автоматизма, и их сможет освоить после минимального обучения любой фермер, который может отличить соху от телеги. На какой-то момент производство стало дороже, поскольку платить меньше некоего минимума людям невозможно, но это компенсировалось увеличением объёма продаж. То есть мы выкрутились в условиях недостатка квалифицированного персонала.
Вторая ситуация. Тот же самые радиаторы. Но! Вместо того, чтобы заменить сотню вчерашних фермеров, например, станком с ЧПУ и парой операторов, мы разводим вакханалию лозунгов о том, что вообще достаточно ограничиться знанием отличий сохи от телеги. Соха и телега внесены в учебные программы, готовим полуфермеров массово. Вроде как вершина прогресса достигнута, дальше космос кончился.
Ты всё ещё не видишь различий?
E>Сейчас везде говорят, что квалифицированных программистов нужно днем с огнем искать. В Москве, судя по обсуждениям в данном форуме, сейчас зарплаты начинающих программистов стартуют от 50-60т, а матерым платят по 120т. И все равно есть жалобы, что людей не хватает. Но при этом софт нужно писать постоянно, и с каждым днем все быстрее и быстрее, да чтобы лучше и дешевле. Все как в случае с Фордом.
Всё как в случае с Фордом в нашей профессии не может быть по определению. Аналогии с механическим производством развенчивались даже на RSDN не один десяток раз. Форд должен был наращивать количество выпускаемой идентичной продукции. У нас стоимость именно экземпляра — копейка в базарный день (CD + электроэнергия на запись). Не одну и ту же программу ведь приходится писать по многу раз, верно? Наша проблема состоит в необходимости аккумулировать знания о предметной, воплощая их в API, фреймворки, ОС, СУБД и т.п. Да, сейчас проблема базовых инструментов (те же ОС, СУБД, языки высокого уровня, фреймворки) более или менее разрешима. Но неужели ты считаешь, что нынешние, скажем, СУБД — вершина развития IT? По-моему, это только зачаточное состояние. У них даже метафоры использования недалеко ушли от книжной полки.
E>Поэтому-то большие оффшорные компании и внедряют у себя разные модели разработки, при которых рядовой программист становится винтиком -- много от него не нужно, да и заменить просто, а все, что он делает строго регламентированно.
Встречный вопрос: ты сам-то веришь в то, что можно в нашей работе что-то "строго регламентировать" кроме элементарных процедурных моментов? Ну, типа, обязательно зачекинить код в конце рабочего дня? Я вот не вижу такой возможности.
И кроме того, наличие формального процесса само по себе вовсе не означает, что можно снизить квалификацию сотрудников, хотя это заблуждение очень распространено даже среди менеджмента. Всё строго наоборот: формальный процесс как раз предъявляет очень высокие требования к абстрактному мышлению, а то придётся следить за каждым словом, написанным "обезьянкой". По сути дела, формализация процессов нужна для помощи разработчикам, а не для превращения их в винтики, только в таких условиях эта самая формализация и работает толком, а иначе получим пустую бюрократию.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Курилка, Вы писали:
К>Хотя, возможно, какие-то советские переводчики как "дийкстра" переводили (кто-то вроде тут говорил про украинские учебники с таким написанием), тот же Клини, к примеру, по вине переводчиков так читается, на самом деле он Клейни. К>Хотя всё это так, несущественные мелочи, конечно
Это фигня, у меня где-то есть книжка, в которой упоминается известный специалист Д. Нут
Ой, предыдущий пост написал не читая статьи, а только по постам.
Поглядел статью, короче автору респект и уважуха. Дай бох каждому как говорится.
Наверняка сейчас есть и такие как он, просто мест для приложения своих сил тоже много. Вот их и незаметно.
Здравствуйте, eao197, Вы писали:
ГВ>>То есть, собственные инструментальные средства, являющиеся по его словам залогом рентабельности IT-бизнеса (здесь ему как раз можно верить, поскольку он точно знает, о чём говорит — сам же бизнесмен), уже магически оказались не нужны. По-видимому, совесть не позволяет откровенно соврать, сказав что-нибудь вроде того, что залог эффективности IT-бизнеса — доскональное знание продуктов Microsoft (дело не в названии фирмы, разумеется).
E>Гена, похоже, что в этом тексте каждый видит то, что хочет видеть.
Всё проще. На RSDN сбросили ссылку, я по этой ссылке прошёлся. Отчего-то возникло желание, извините, взблевнуть или застрелиться. Начал выяснять — почему. Выяснилась масса интересного. Вуаля.
E>Я например, вижу сожаления Донского о том, что:
E>a) не смотря на то, что собственные инструментальные средства лучше для разработки своих продуктов (по мнению Донского), сейчас мало кто создает эти самые собственные средства.
E>b) но даже когда используются готовые чужие инструментальные средства далеко не все разработчики способны понять их устройство и, как следствие, эффективно использовать.
Да-да. И вывод он делает просто потрясающий: программирование становится рутинным. То есть это не вал дураков, с которым никто не хочет управляться, не деградация образования, а просто меняется характер профессии. Знаешь, сожаление здесь можно усмотреть только после третьего стакана.
ГВ>>Что характерно, процитированный фрагмент заканчивается не критикой системы образования, которая не учит детей писать свои СУБД и ОС, а совершенно неожиданным припевом: "профессия программиста становится рутинной". Я хренею, my dear editor. Так если современные средства нельзя понять, не написав аналога, то... Хотя, чему удивляться? Если бы прозвучал тезис о том, что детей надо учить писать свои СУБД, это сразу бы потащило за собой кучу дополнительных выводов, в частности о том, что образование должно включать в себя не "реальные условия", а фундаментальную подготовку, развитие абстрактного мышления и т.п.
E>А вот такой призыв, имхо, в современных условиях:
E>a) невыполним. Мало кто из преподавателей в ВУЗах бывшего СССР хоть что-то понимает в разработке СУБД и ОС. И горит желанием хоть чему-то в этом научиться. И, возможно, такая ситуация не только на постсоветском пространстве, но и в Европе, Азии и, может, быть в США.
Вода камень точит. Будут долбить — всё изменится. А так, конечно...
E>б) бесполезен. Пока обычному программисту не нужна фундаментальная подготовка и развитие абстрактное мышление, а простое знание XML и HTML обеспечивают получение непыльной работенки с достаточно приличным окладом, восстребованность подобной системы образования будет минимальной со стороны самих учащихся. Насколько я помню, даже в СССР, во времена, когда студентов ВУЗ-ов без военных кафдр забирали в армию после первого курса, в подобные ВУЗы был относительно малый поток ребят-абитурьентов. Аналогичная ситуация произойдет, если какой-нибудь ВУЗ в Мухосранске захочет создать курс с углубленным изучением предмета. Отучатся на нем несколько фанатов-ботаников, а остальные разбегутся в самом начале.
Вот ещё, учащихся спрашивать?! Уж в своём ли ты уме ли? Демократия-демократией, но свои пределы-то должны быть. Ты не путай востребованность военной кафедры в условиях призыва и востребованность самого образования. Это всё таки разные категории. Про военную кафедру школьник ещё понимает, а про остальное... Ну, к примеру, я до курса дискретной математики не знал даже, что такая существует. Но почему-то вовсе не считаю, что над моими мозгами злобно надругались, заставив этот курс пройти. То же самое с другими теоретическими дисциплинами. А между прочим, ОО-программирование постиг вполне самостоятельно, хотя сейчас уже уверен, что его значимость, откровенно говоря, переоценена. Пустышка это, оттого и столько визга вокруг него. В прочем, не суть.
E>в) банален. Да, это очень банально покивать на систему образования и сказать, что вот если бы... А можно реалистично взглянуть на мир вокруг и вспомнить, чего добился Генри Форд на своих заводах: большинство рабочих проффессий благодоря усовершенствованию технологического процесса не требовали никаких выдающихся умственных/физических качеств, рабочий мог приступить к работе с полной отдачей после нескольких часов/дней инструктажа. Производство ПО сейчас напоминает перевод Генри Фордом производства автомобилей от кустарного к полуавтоматизированному производству.
Йопт. И ты туда же. Спасибо за повторение тезиса о рутинности программирования. Наслышан. Все как попугаи повторяют друг другу одно и то же — программирование становится рутинным, рутинным, рутинным. Хорошо, спасибо.
Только Форд-то здесь причём? У него в принципе не было возможности набрать массу квалифицированных инженеров и рабочих, и построить, например, автоматизированное производство. Ощути разницу направлений: выкручиваться в условиях отсутствия квалифицированного персонала и сознательно снижать квалификацию персонала, подгоняя его под "модель производства". Не находишь, что это две большие разницы?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, The Lex, Вы писали:
TL>Я понял. Ты таки стремишься к созданию Универсальной Программы Всего и Вся, которая бы исключила всю эту "рутину, формально называемую программированием".
Ложная посылка. Для того чтобы избавится от рутины, совершенно необязательно создавать "Универсальную Программу Всего и Вся".
... << RSDN@Home 1.2.0 alpha 4 rev. 1106 on Windows Vista 6.0.6001.65536>>
Здравствуйте, eao197, Вы писали:
E>Угу. Но это будет работать до тех пор, пока проект не обрастет множеством мелких задачек по настройке/адаптации/сопровождению.
А вот тут как раз таки и нужен вменяемый архитект, чтобы "множество мелких задачек по настройке/адаптации/сопровождению" решались системно, а не по принципу "лишь бы работало".
... << RSDN@Home 1.2.0 alpha 4 rev. 1106 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Поэтому, я думаю, должно быть так:
- неосознанно выполняются повторяющиеся (ставшие обычными) действия;
— по мнению субъекта не существует возможности отказаться от существующего положения вещей (субъект намеренно игнорирует возможности, или не хочет сменить/заменить/изменить выполняемые действия, предпочитая следовать устоявшемуся обычаю).
Мне нравится. Пора бежать в магазин!
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Геннадий Васильев, Вы писали:
E>>>> Но вряд ли они сами считали свою работу рутиной. AVK>>>Ха. Ну таким аргументом можно что угодно доказать. E>>А у тебя есть какие-то объективные критерии оценки того, является ли какая-то работа рутиной или нет?
ГВ>А у тебя такие критерии есть? Я вот по-соседству вывел
РУТИНА ж. франц. безотчетное следованье преданью, обычаю.
то рутиной, на мой взгляд, является работа, в которой:
— выполняются повторяющиеся (ставшие обычными) действия;
— не существует возможности отказаться от существующего положения вещей (нет желания или возможности сменить/заменить/изменить выполняемые действия).
Разработка среды программирования и кластерного решения к ней я не могу по таким критериям причислить к рутине, поскольку создание среды программирования не является повторяющимся действием.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
DM>Все равно не более одной команды на ячейку, а скорее всего меньше. Т.е. те же 2к команд где-то.
Плотность команд очень разная. некоторые ассемблерные инструкции заменяют десяток строк на "С".
Для старых мейнфреймов характерны сложные системы команд — там ассемблер является языком почти высокого уровня.
Именно поэтому все ассемблерные наработки было так жалко потерять. У меня иногда уходило до недели времени чтобы написать функцию на ассемблере — сложность там была запредельная
Здравствуйте, eao197, Вы писали:
E>Я не могу судить о том, что происходит _реально_ в Москве и Новосибирске, но вот у нас в Гомеле толковых C++ников днем с огнем поискать. И не только C++ников: на наш небольшой город приходится несколько больших программистских контор (в том числе филиалы EPAm и BelIBA) + какое-то количество мелких + несколько крупных государственных контор. И еще масса народа (очень толкового) поуезжала в Москву и другие заграницы. В результате все мои знакомые жалуются на то, что поиск новых людей -- это постоянная головная боль. А я сам по крайней мере раз в год получаю предложения сменить работу.
опустим не относящееся к делу и опять видим ровно то, о чем было написано мной выше.
Если разбирать картину выше объективно, можно снова отметить, как костеря нехватку толковых людей Вы не указали ни что есть "очень толковый" в Гомельском понимании (ну это ладно), ни уровень с которого бегут (правда, вижу что дали какие-то цифры позже), ни других объективных критериев. Но пожаловались, сославшись на столь авторитетный источник как "все знакомые".
Тем не менее, можно легко прийти к выводу что чтобы удержать толковый народ на месте, с учетом всех местных плюсов\минусов — указанных ниже по ветке цифр уже недостаточно. Что же делать? Вероятно, нужно раскошелиться. Хорошо раскошелитесь\создадите условия — из Москвы потянутся уже к вам. Что тут необычного или заслуживающего набивших оскомину стенаний?
Нормальный экономический процесс.
Итак, нет денег на улучшение условий ведущим людям\давит жабец? Хорошо, тогда снижайте требования к проектам — по качеству и\или срокам. Конечно не хочется... ибо чревато всеми возможными бедами в перспективе. Все понимаю. Ну так зато дешево и сердито — по Сеньке шапка. А как вы хотели?
Да, тяжело выкручиваться в условиях нехватки требуемых ресурсов. Но что сделали указанные компании, чтобы решить вопрос — тем более что их там у вас, видимо, много и все они в одной лодке (как и в любом городе)? Вероятно, их просто устраивает указанная ситуация по ряду причин — поэтому разговоры про то, что "денег нет, город небольшой и т.п." снова получаются в пользу бедных. Продают-то изделия\сервис, чай, не в небольшом городке Гомеле, а зачастую на мировом рынке + накладные расходы поменьше, чем в столицах. Так в чем же дело — почему об этом не плачем?
Тем более что речь идет не о том чтобы поднять условия всем вокруг в штате и за штатом — а лишь тем, кто нужен на ключевых позициях, обладает необходимым знанием\опытом для проекта\команды\компании, кто реально делает дело и в конечном счете поможет остальным вырости, вместо сбегания в столицы (не думаю что все у вас бегут лишь по причине условий), заодно повысив капитализацию компании. Это не так редко даже дешевле стоимости поиска адекватной замены, не говоря уже о том чтобы впрячь замену в процесс — кому же лучше от такого "держания рынка" любой ценой? Загнали себя в угол и оттуда стонем.
Так что, если у кого проблемы с огнем днем — думать надо было, начиная дело и хватая проекты, непросчитанные \ необеспеченные ресурсами и\или с рисками, с которыми не умеем работать имеющимися кадрами. Ну и заодно быть готовым к головной боли, а як же шь.
PS Конечно, сочувствовать испытывающим кадровый голод легко, где-то даже поможет добрать вистов, однако я предпочитаю решать проблемы вместо их бесполезного обмусоливания. Посему вот такое мое суровое ИМХО выше.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, eao197, Вы писали:
E>Где ты видишь разницу? Сейчас везде говорят, что квалифицированных программистов нужно днем с огнем искать. В Москве, судя по обсуждениям в данном форуме, сейчас зарплаты начинающих программистов стартуют от 50-60т, а матерым платят по 120т. И все равно есть жалобы, что людей не хватает.
ну опять как у по совместительству модерирующего "тот самый форум" не первый год — у меня складывается мнение что поднимать шум по типу процитированного просто модно — также как ругать Билли и высокие цены на бензин\правительство. к примеру, меня, как и многих других — можно найти
А реальность такова, что серьезным профессионалам наоборот не так-то просто найти работу, и дело тут не всегда в одних только зарплатах. Кстати, цитата выше про 50-60 и 120 напоминает анекдот про Петьку, ВИ и приборы Кому хочется менять шило на мыло? Из многочисленных матерых знакомых редко кто нашел приличную работу менее чем за неск. мес — полгода (и иногда более) весьма интенсивных поисков. Тоже своего рода критерий профессионализма. Предложения-то как раз пусть иногда и требуют на словах матерых — но по факту на отнюдь не матерые позиции или в отнюдь не матерые проекты или с совсем не матерыми условиями.
Обычно плач идет о том, что нет матерых людей на нематерые условия — если разбирать каждый конкретный случай объективно.
Шумят же (те что поумнее) — как в другом анекдоте "чтобы денег не платить", большинство же как на стадио — глорят за компанию. Жалобы на дорогой бензин из той же оперы, это же не означает, что бензина нет. Просто демпинговые цены не каждый год стоят, а текущая цена складывается из вполне себе объективных факторов, она не виновата в том что высока или низка.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
eao197 пишет: > > > "Очень толковый" в нашем понимании -- это практически то же, что "очень > толковый" в Москве, только без понтов.
Это уже, скажем так "провинциализм". Что "лаптем щи хлебам"?
> > В маленьком городе это более достоверный источник, чем изучение списков > вакансий
Не такой он уж и маленький. В Беларуси таких всего 5 и еще столица.
> > Потом мне пишут > из Питера -- мол давай к нам, проекты интересные, деньги нормальные, а > людей нет. О как думаю, совпаденьеце. Потом то же самое начинают писать > из Москвы. Потом из США. Тенденция, однако. Потом смотрю в местные > форумы объявлений о работе и вижу объявления с множеством ответов из > одного слова "up", причем фирмы так же не Гомельские и даже не Минские.
1. 99% процентов объяв — мусор.
2. Многие хотят энштейнов по копейке за сотню.
3. Почитай форум о работе или бо управлении, 90% сообщений об
бестолковости менеджмента.
Имхо, достаточно, чтобы понять откуда такой кадровый голод — в первую
отсутствие управления на 90% контор и только во-вторую — отсутвие кадров
(но тут тоже все просто — не может быть все население программистами,
тем более толковыми).
На вашей конторе, поднимайте эффективность управления и будет вам шасце.
Очень много проектов можно сделать в несколько раз меньшим количеством
людей, чем делается это сейчас, причем качество будет на порядок выше.
Как пример классика: что выгоднее 10 програмеров по 1000 или 3 по 2500?
Здравствуйте, eao197, Вы писали:
E>Ну да. Но все сведется к тому, чтобы изучить второй фреймворк. А, по мнению Донского (и я с ним согласен), это уже рутина по сравнению с написанием такого фреймворка.
Да нет, вот как раз реализация одних и тех же алгоритмов кластеризации и хождение по граблям, по которым уже прошла куча народу — это и есть рутина. А концентрация на реальных требованиях, а не борьба с кластерными заморочками как раз таки не рутина, а именно то, за что программисту платят.
... << RSDN@Home 1.2.0 alpha 4 rev. 1106 on Windows Vista 6.0.6001.65536>>
Здравствуйте, sourcerer, Вы писали:
S>Интереснейшая статья Михаила Донского о профессии, о том что "программер счас не тот" , о том "как все начиналось", о перспективах отрасли.
На самом деле читателю навязывается две простенькие мысли:
— математика современному программисту не нужна;
— программирование становится рутинной профессией (основной тезис статьи).
Короче говоря, автор благословляет программистов на деградацию. Лихо, ничего не скажешь.
Но на фоне таких тезисов равнять себя с Шенноном и Экзюпери несколько некорректно, не находите?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, sourcerer, Вы писали:
S> вы за деревьями леса не увидели...
Там не лес, а болото.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
По поводу обучения:
на нашем факультете второкурсники в качестве семинарского задания (не курсовой) пишут свой шелл и небольшой sql сервер.
Про достижения 60-х:
здорово, конечно, рассказывать, как делал свою ОС. Только когда вся память в машине — 4 кб, это по-любому не очень большой и сложный проект. Не намного сложнее современных 4k intro, которые до сих пор пишутся пачками.
В целом, неплохой рассказ, да и то, что автор до сих пор занимается реальными проектами и работает с современными технологиями (пусть и с ворчанием) — вызывает только уважение.
Здравствуйте, Handie, Вы писали:
DM>> Только когда вся память в машине — 4 кб, это по-любому не очень большой и сложный проект.
H> Тебе никогда не понять что это такое
Вот спасибо за оценку моих способностей!
Да, средства производства и сам процесс тогда были более трудоемкими. Но просто из теории информации и колмогоровской сложности, если угодно, получается, что в 4 кб — это не сильно сложная система. Даже если все это — код, это всего порядка 2к строк ассемблера довольно простого компьютера (сейчас процессоры сложнее).
DM>>В целом, неплохой рассказ, да и то, что автор до сих пор занимается реальными проектами и работает с современными технологиями (пусть и с ворчанием) — вызывает только уважение.
H>Да тут я смотрю много сейчас чуваков которые имея современные средства разработки бъют себя кулаком в грудь...
Эти чуваки тут не при чем. Просто нередко люди останавливаются на каком-то этапе и новую информацию перестают воспринимать. Здесь же автор в маразм не впал, за это ему респект.
Здравствуйте, Геннадий Васильев, Вы писали:
E>>Я например, вижу сожаления Донского о том, что:
E>>a) не смотря на то, что собственные инструментальные средства лучше для разработки своих продуктов (по мнению Донского), сейчас мало кто создает эти самые собственные средства.
E>>b) но даже когда используются готовые чужие инструментальные средства далеко не все разработчики способны понять их устройство и, как следствие, эффективно использовать.
ГВ>Да-да. И вывод он делает просто потрясающий: программирование становится рутинным. То есть это не вал дураков, с которым никто не хочет управляться, не деградация образования, а просто меняется характер профессии. Знаешь, сожаление здесь можно усмотреть только после третьего стакана.
Да я вроде не пил сегодня
Но вот пример из того же Форда. Первоначально сборкой радиаторов для автомобилей занимались кузнецы очень высокой квалификации, которые выполняли сложную работу. Затем схему сборки радиаторов изменили и надобность в квалифицированных кузнецах отпала. Т.е. рабочая должность "сборщик радиаторов" сохранилась, то теперь для нее не требуется кузнец. Сборка радиатора превратилась из сложной, тебующей умения, терпения, ловкости и сноровки, операции превратилась в совершенно тупую рутину.
Аналогичные события происходят и сегодня. Раньше требовалась изрядная подготовка для того, чтобы написать отказоустойчивое класстерное приложение, да и сама задача эта была редкой, своего рода вызовом. Теперь Java-программисты не самой выской квалификации делают это путем сборки нескольких стандартных компонентов. Т.е. рабочая должность "программист" вроде как остается, но вот количество знаний/умений для нее сейчас сокращается.
E>>a) невыполним. Мало кто из преподавателей в ВУЗах бывшего СССР хоть что-то понимает в разработке СУБД и ОС. И горит желанием хоть чему-то в этом научиться. И, возможно, такая ситуация не только на постсоветском пространстве, но и в Европе, Азии и, может, быть в США.
ГВ>Вода камень точит. Будут долбить — всё изменится. А так, конечно...
А вот ты сам веришь, что кто-нибудь будет долбить?
E>>б) бесполезен. Пока обычному программисту не нужна фундаментальная подготовка и развитие абстрактное мышление, а простое знание XML и HTML обеспечивают получение непыльной работенки с достаточно приличным окладом, восстребованность подобной системы образования будет минимальной со стороны самих учащихся. Насколько я помню, даже в СССР, во времена, когда студентов ВУЗ-ов без военных кафдр забирали в армию после первого курса, в подобные ВУЗы был относительно малый поток ребят-абитурьентов. Аналогичная ситуация произойдет, если какой-нибудь ВУЗ в Мухосранске захочет создать курс с углубленным изучением предмета. Отучатся на нем несколько фанатов-ботаников, а остальные разбегутся в самом начале.
ГВ>Вот ещё, учащихся спрашивать?! Уж в своём ли ты уме ли?
Надеюсь, но не всегда уверен в этом
ГВ>Демократия-демократией, но свои пределы-то должны быть. Ты не путай востребованность военной кафедры в условиях призыва и востребованность самого образования. Это всё таки разные категории. Про военную кафедру школьник ещё понимает, а про остальное... Ну, к примеру, я до курса дискретной математики не знал даже, что такая существует. Но почему-то вовсе не считаю, что над моими мозгами злобно надругались, заставив этот курс пройти. То же самое с другими теоретическими дисциплинами. А между прочим, ОО-программирование постиг вполне самостоятельно, хотя сейчас уже уверен, что его значимость, откровенно говоря, переоценена. Пустышка это, оттого и столько визга вокруг него. В прочем, не суть.
Пределы-пределами, но есть такая простая штука, как репутация. Очень быстро станет известно, что на каком-то курсе обучение сложное и требования повышенные. Посему большая часть абитурьентов, которым вообще пофигу, чем заниматься и чему учится, уйдут туда, где репутация получше.
ГВ>Только Форд-то здесь причём? У него в принципе не было возможности набрать массу квалифицированных инженеров и рабочих, и построить, например, автоматизированное производство. Ощути разницу направлений: выкручиваться в условиях отсутствия квалифицированного персонала и сознательно снижать квалификацию персонала, подгоняя его под "модель производства". Не находишь, что это две большие разницы?
Где ты видишь разницу? Сейчас везде говорят, что квалифицированных программистов нужно днем с огнем искать. В Москве, судя по обсуждениям в данном форуме, сейчас зарплаты начинающих программистов стартуют от 50-60т, а матерым платят по 120т. И все равно есть жалобы, что людей не хватает. Но при этом софт нужно писать постоянно, и с каждым днем все быстрее и быстрее, да чтобы лучше и дешевле. Все как в случае с Фордом. Поэтому-то большие оффшорные компании и внедряют у себя разные модели разработки, при которых рядовой программист становится винтиком -- много от него не нужно, да и заменить просто, а все, что он делает строго регламентированно.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Да это ещё туда-сюда... Там навалом нестыковок покруче.
Дело не столько в нестыковках, сколько в том, что текст, вызывающий истерический смех и демонстрирующий полный дилетантизм в вопросах девелопмента, перемежается вполне вменяемыми кусками, написанными явно "летающим" профессионалом. Поэтому и получается — либо это шизофрения, либо текст писали два разных человека. Мне во второе верится больше.
... << RSDN@Home 1.2.0 alpha 4 rev. 1106 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>И кроме того, наличие формального процесса само по себе вовсе не означает, что можно снизить квалификацию сотрудников, хотя это заблуждение очень распространено даже среди менеджмента. Всё строго наоборот: формальный процесс как раз предъявляет очень высокие требования к абстрактному мышлению, а то придётся следить за каждым словом, написанным "обезьянкой". По сути дела, формализация процессов нужна для помощи разработчикам, а не для превращения их в винтики, только в таких условиях эта самая формализация и работает толком, а иначе получим пустую бюрократию.
именно! +1
Считаю, жесткое регламентирование процессов налагает очень высокие требования как раз к тим- и другим лидам, которые ответственны за то, чтобы эти процессы работали на благо команды, а не против. Очень красивый фрэймворк из процессов на бумаге может посыпаться в овраги, как только квалификация ключевых людей уменьшится или перестанет дотягивать до уровня, необходимого для дальнейшего развития компании\бизнеса. Простой пример: один лид проводит митинги по всем правилам этого исскусства, другой тупо ежедневно выдергивает всю бригаду из контекста на полчасика для отчета о проделанной работе "потому что процесс так велит" или через раз настраивая ср-ва связи по 15 мин, заставляя всех зевать и дивиться его неуклюжести. Формально процесс один, а результат совершенно разный. И таких "мелочей" — миллион, даже не касаясь разницы в технических аспектах. Как будем офрэймворчивать
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, Valery A. Boronin, Вы писали:
VAB>Шумят же (те что поумнее) — как в другом анекдоте "чтобы денег не платить", большинство же как на стадио — глорят за компанию. Жалобы на дорогой бензин из той же оперы, это же не означает, что бензина нет. Просто демпинговые цены не каждый год стоят, а текущая цена складывается из вполне себе объективных факторов, она не виновата в том что высока или низка.
Проблема в том, что если цена на программиста слишком высока — то многие компании просто физически не смогут его взять на работу. Ну не хватит денег просто.
Если бы был избыток кадров, то такой проблемы бы не было.
C>Проблема в том, что если цена на программиста слишком высока — то многие компании просто физически не смогут его взять на работу. Ну не хватит денег просто.
В настоящее время у подавляющего большинства компаний проблемы найти дополнительные $15k в год нет. Мешает жадность и... желание "манагеров" получать больше своих подчиненных. Иначе какой он тогда манагер, ага.
Здравствуйте, Handie, Вы писали:
H>Без обид, но это напоминает басню "слон и моська".
В этом особенность публичных выступлений. Это во-первых. А во-вторых, погугли по ключевым словам: "некорректная аргументация" и "апелляция к личности".
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, SkyDance, Вы писали:
TL>>Вот именно: формализация нужна разработчикам, чтобы "не приходилось следить за каждым словом, написанным обезьянкой".
SD>Нет уж, господа. Формализация процесса нужна не разработчикам. Она нужна менеджменту. Чтобы видеть, что разработчик не в носу ковыряется, а чем-то занят. Неважно чем: он может быть занят чисто процессом. Даже не программировнаием. А именно процессом. В глазах менеджмента это значит, что разработчик работает. В то же время другой разработчик может "педалить код" (С) мегабайтами. Но не соблюдать процесс. В глазах менеджмента он — бездельник.
Давай так. Формальный процесс прежде всего вносит ясность: кто, чем и почему занят, и что сделано. Его можно использовать по-разному, это уже отдельный вопрос. Но по-любому помощь самим разработчикам он оказывает вполне приличную. Хотя бы обеспечением возможности что-то почитать, а не тормошить коллег расспросами.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
E>>Но вот пример из того же Форда. Первоначально сборкой радиаторов для автомобилей занимались кузнецы очень высокой квалификации, которые выполняли сложную работу. Затем схему сборки радиаторов изменили и надобность в квалифицированных кузнецах отпала. Т.е. рабочая должность "сборщик радиаторов" сохранилась, то теперь для нее не требуется кузнец. Сборка радиатора превратилась из сложной, тебующей умения, терпения, ловкости и сноровки, операции превратилась в совершенно тупую рутину.
ГВ>Ну опять двадцать пять. Повторяющиеся операции можно и должно вообще всячески вытеснять из сферы человеческой деятельности. Этим должны заниматься роботы. Нельзя тут проводить прямую аналогию с программированием.
Думаю, что когда в программировании придумают инструменты, которые способны заменить человека для исправления ошибок вида "поехало форматирование в форме NNN под Opera 9.5 на SuSe Linux" или решения задач вида "добавить общее количество страниц в нижний колонтитул каждой печатоемой страницы отчетов RRR/ZZZ/XXX", то это обязательно сделают.
А пока на данные операции берут людей с небольшим опытом или бесперспективных в плане роста. А к ним еще и нанимают кучу тестеров в отдел QA, чтобы проверять, что подобные баги и задачки решаются.
E>>Аналогичные события происходят и сегодня. Раньше требовалась изрядная подготовка для того, чтобы написать отказоустойчивое класстерное приложение, да и сама задача эта была редкой, своего рода вызовом. Теперь Java-программисты не самой выской квалификации делают это путем сборки нескольких стандартных компонентов. Т.е. рабочая должность "программист" вроде как остается, но вот количество знаний/умений для нее сейчас сокращается.
ГВ>Только при одном условии — что тот самый отказоустойчивый/кластеризуемый фреймворк останется один forever. Чего в нашем бизнесе не бывает по определению.
Я говорил не про фреймворк, а про создание кластерного приложения для решения какой-нибудь прикладной задачи.
ГВ>>>Вода камень точит. Будут долбить — всё изменится. А так, конечно... E>>А вот ты сам веришь, что кто-нибудь будет долбить?
ГВ>Я уверен, что уже кто-то долбит. Только боюсь, что не в наших пенатах.
Ну так о том и речь. Что у нас вряд ли что-нибудь изменится, поскольку передовые разработки в околосистемных областях ведутся на Западе и у нас просто недостаточно людей, которые знают о чем идет речь. А уж скольких из них можно будет привлечь к системе образования -- это вообще смешно.
ГВ>>>Про военную кафедру школьник ещё понимает, а про остальное... E>>Пределы-пределами, но есть такая простая штука, как репутация. Очень быстро станет известно, что на каком-то курсе обучение сложное и требования повышенные. Посему большая часть абитурьентов, которым вообще пофигу, чем заниматься и чему учится, уйдут туда, где репутация получше.
ГВ>Хм. Так репутация учебного заведения складывается не из сложности обучения, а из того, куда попали и кем стали выпускники. Я почему-то уверен, что люди быстро разберутся, где готовят серьёзных специалистов, а где — одипломливают биомассу.
Да ладно, Гена. Это всегда было известно -- пара-тройка ВУЗ-ов в Москве + по одному-два ВУЗа в крупных городах (т.к. Питер, Минск, Киев, Новосибирск и т.д.). Те ВУЗы, которые неподалеку (в родном городе или в паре-тройке часов от родного города) они, как правило, одипломнивают биомассу. Но изрядная доля работающих сейчас программистов как раз и является продуктом как раз таких ВУЗов.
ГВ>А потом, прямая обязанность учебного заведения — объяснить сложные вещи доступным языком, сиречь — научить. Научили же нас писать программы.
Имхо, те, кто этому научился, научились этому самостоятельно.
ГВ>>>Только Форд-то здесь причём? У него в принципе не было возможности набрать массу квалифицированных инженеров и рабочих, и построить, например, автоматизированное производство. Ощути разницу направлений: выкручиваться в условиях отсутствия квалифицированного персонала и сознательно снижать квалификацию персонала, подгоняя его под "модель производства". Не находишь, что это две большие разницы?
E>>Где ты видишь разницу?
ГВ>Вот смотри, берём две ситуации.
ГВ>Первая. Те же радиаторы.
ГВ>Сначала у нас небольшое производство, которое вполне обслуживается, скажем пятью квалифицированными кузнецами. Чуть позже производство расширяется, пятерых кузнецов не хватает, зато — навалом малоквалифицированных, скажем, разорившихся фермеров. Что мы сделаем? Мы постараемся сделать так, чтобы объём продукции минимально зависел от количества кузнецов, переложив на них, например, исправление огрехов литья. Остальные операции повторяются с точностью до автоматизма, и их сможет освоить после минимального обучения любой фермер, который может отличить соху от телеги. На какой-то момент производство стало дороже, поскольку платить меньше некоего минимума людям невозможно, но это компенсировалось увеличением объёма продаж. То есть мы выкрутились в условиях недостатка квалифицированного персонала.
ГВ>Вторая ситуация. Тот же самые радиаторы. Но! Вместо того, чтобы заменить сотню вчерашних фермеров, например, станком с ЧПУ и парой операторов, мы разводим вакханалию лозунгов о том, что вообще достаточно ограничиться знанием отличий сохи от телеги. Соха и телега внесены в учебные программы, готовим полуфермеров массово. Вроде как вершина прогресса достигнута, дальше космос кончился.
ГВ>Ты всё ещё не видишь различий?
Не-а. Очень похоже на то, что сейчас я вижу вокруг себя. Людей в ВУЗах (провинциальных, как в столичных я не знаю) учат отличать соху от телеги, не более того. После чего они идут в филиалы оффшорных компаний, начинают клепать JSP-странички или еще что-то трудоемкое, но не сильно заумное. Кто-то из них, естественно, растет и со временем становится классным специалистом. Но таких не много. Имхо, процент классных программистов всегда был одинаков. Но вот в абсолютном выражении количество тех программистов, которым для нормальной жизни не приходится заниматься серьезными задачами растет.
E>>Сейчас везде говорят, что квалифицированных программистов нужно днем с огнем искать. В Москве, судя по обсуждениям в данном форуме, сейчас зарплаты начинающих программистов стартуют от 50-60т, а матерым платят по 120т. И все равно есть жалобы, что людей не хватает. Но при этом софт нужно писать постоянно, и с каждым днем все быстрее и быстрее, да чтобы лучше и дешевле. Все как в случае с Фордом.
ГВ>Всё как в случае с Фордом в нашей профессии не может быть по определению. Аналогии с механическим производством развенчивались даже на RSDN не один десяток раз. Форд должен был наращивать количество выпускаемой идентичной продукции.
Я понимаю, что прямая аналогия не возможна, что все-таки ситуация похожа: приходится наращивать выпуск почти идентичной продукции. По крайней мере временами складывается впечатление, что вокруг успешной разработки постоянно оказывается масса мелких и, вроде бы, простеньких задачек, которые все время плодятся и размножаются и никак не хотят заканчиваться: вот тут сигнальчик в такой-то ситуации должен заиграть, вот этот отчетик должен построится в 03:30 и отослаться по почте, вот этот столбец в БД было бы хорошо добавить, при обработке вот такой транзакции нужно учесть вот такой вот ньюанс, при такой-то ситуации нужно выдать вот такую диагностику вместо существующей, и т.д. и т.п. Это не конвейер, как у Форда, но очень уж похоже на рутину.
ГВ>Встречный вопрос: ты сам-то веришь в то, что можно в нашей работе что-то "строго регламентировать" кроме элементарных процедурных моментов? Ну, типа, обязательно зачекинить код в конце рабочего дня? Я вот не вижу такой возможности.
Нет, не верю.
ГВ>По сути дела, формализация процессов нужна для помощи разработчикам, а не для превращения их в винтики, только в таких условиях эта самая формализация и работает толком, а иначе получим пустую бюрократию.
По тому что я видел в EPAm-е и слышал после того, крупные оффшоры как раз к этому и приходят -- к пустой бюрократии.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>А вот такой призыв, имхо, в современных условиях:
E>a) невыполним. Мало кто из преподавателей в ВУЗах бывшего СССР хоть что-то понимает в разработке СУБД и ОС. И горит желанием хоть чему-то в этом научиться. И, возможно, такая ситуация не только на постсоветском пространстве, но и в Европе, Азии и, может, быть в США.
Ну почему же... Кое кто — понимает...
Тут хотелось бы узнать, как Таненбаум со своими студентами делал Миникс — этот опыт и использовать...
E>б) бесполезен. Пока обычному программисту не нужна фундаментальная подготовка и развитие абстрактное мышление, а простое знание XML и HTML обеспечивают получение непыльной работенки с достаточно приличным окладом, восстребованность подобной системы образования будет минимальной со стороны самих учащихся. Насколько я помню, даже в СССР, во времена, когда студентов ВУЗ-ов без военных кафдр забирали в армию после первого курса, в подобные ВУЗы был относительно малый поток ребят-абитурьентов. Аналогичная ситуация произойдет, если какой-нибудь ВУЗ в Мухосранске захочет создать курс с углубленным изучением предмета. Отучатся на нем несколько фанатов-ботаников, а остальные разбегутся в самом начале. E>в) банален. [...]
Тут разделение образования на 2 ступени — как раз на руку. Первая бакалаврская ступень массово готовит "рутинных" программистов. А вот вторая — магистерская — ее бы как раз хорошо заточить под глубину. Учитывая, что после 2 лет магистра еще 3-4 года аспирантуры — вот как раз и можно готовить глубоких спецов. И таких, естественно, не в массовом порядке, как бакалавров, а в единичных экземплярах...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, SkyDance, Вы писали:
SD>Мораль всего этого такова: процесс — это особенный, специфический навык. Никакого отношения к созданию продукта процесс не имеет. Специалисты по процессу — особые люди. Своего рода прилипалы.
Не стоит из одного случая делать столь далеко идущие выводы.
E>Ничего не обычного. Просто вот что происходит: смотрю на происходящее у нас и вижу, что не хватает людей, даже при том, что зарплаты все время растут. Ладно, думаю, все умные от нас уехали, нам дуракам никак не справится со своими тупыми мозгами и пустыми кошельками. Потом мне пишут из Питера -- мол давай к нам, проекты интересные, деньги нормальные, а людей нет. О как думаю, совпаденьеце. Потом то же самое начинают писать из Москвы. Потом из США. Тенденция, однако. Потом смотрю в местные форумы объявлений о работе и вижу объявления с множеством ответов из одного слова "up", причем фирмы так же не Гомельские и даже не Минские.
Жадность — штука интернациональная. Границ не признает. Она есть везде.
Здравствуйте, Геннадий Васильев, Вы писали:
E>>Думаю, что когда в программировании придумают инструменты, которые способны заменить человека для исправления ошибок вида "поехало форматирование в форме NNN под Opera 9.5 на SuSe Linux" или решения задач вида "добавить общее количество страниц в нижний колонтитул каждой печатоемой страницы отчетов RRR/ZZZ/XXX", то это обязательно сделают.
ГВ>Так здесь как раз поле для удаления "рутины".
А как ее удалить?
E>>Я говорил не про фреймворк, а про создание кластерного приложения для решения какой-нибудь прикладной задачи.
ГВ>Ну ты сам говоришь, что такое приложение легко пишется сборкой стандартных компонентов. А я, в свою очередь, предполагаю, что на одном фреймворке (наборе компонентов) свет клином не сошёлся. Был один, появится и второй.
Ну да. Но все сведется к тому, чтобы изучить второй фреймворк. А, по мнению Донского (и я с ним согласен), это уже рутина по сравнению с написанием такого фреймворка.
ГВ>Ну и ещё большая проблема в том, что СУБД и ОС — это лишь частности от более абстрактных штучек. Собственно, вот это — тоже беда, потому что даже натаскав на разработку СУБД всё равно получим мастера-разработчика СУБД, а не программиста-генератора абстракций.
Вот в этом я сомневаюсь. Человек, который сможет написать СУБД вряд ли будет рядовым мастером-разработчиком СУБД (взять в качестве примера Константина Книжника).
ГВ>а во-вторых — вокруг много плохих программистов, мне это отлично известно. Что с того? Это не означает, что подобное status quo есть хорошо. Это очень, очень плохо. И это ни в коем случае не означает, что под них нужно равнять стандарты профессии.
А ты не боишься, что стандарты профессии, со временем, именно они и будут устанавливать?
Не может ли произойти так, что программисты со временем разделяться на две категории -- программисты-архитекторы и программисты-сборщики?
ГВ>>>А потом, прямая обязанность учебного заведения — объяснить сложные вещи доступным языком, сиречь — научить. Научили же нас писать программы. E>>Имхо, те, кто этому научился, научились этому самостоятельно.
ГВ>Хм. Что, совсем? Ты не видишь разницу, что в первом случае основополагающим было желание развить производство, а во втором — впитать людскую массу, ограничив её развитие?
Гена, а откуда такая уверенность, что софтверные компании поголовно заинтересованны во впитывании людской массы и ограничении ее развития? Подобное я наблюдаю в больших, бюрократизированных огранизациях. Но вот в маленьких компаниях, в которых все на виду, и нет жесткого деления специализации (архитектор/программист/тестер/технический писатель), на мой взгляд происходит обратное -- чем больше растут люди, тем лучше самой компании.
Да и ДаМарко с Листером пишут уже столько лет о том, что человеческий фактор -- залог успеха. Неужели к ним так никто и не прислушивается? Тот же Google, к примеру?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197 пишет: > >> > V>Как пример классика: что выгоднее 10 програмеров по 1000 или 3 по 2500? >> > >> > It depends. > V>А вот тут интересно, расскажи про свою арифметику. > > Если задача конторы состоит в поиске и правке багов "поехало > форматирование в форме NNN под Opera 9.5 на SuSe Linux" или настройке 1C > в сотне-другой мелких торговых организаций, то выгода от 3 по 2500 не > так уж и очевидна.
Вот именно, теперь вопрос а нафига для такой конторы спецы, когда вполне
хватит обезьянок?
Дальше, спрос на спецов определяется конторой, точнее заказами, которые
эта контора выполняет. И тут всплывает ньюанс, что на выполнении простых
заказов и небольших прибыль моет оказаться выше, чем на крутых и сложных
заказах (рисков в них больше).
Т.е. спрос начинает увеличиваться на обезьянок и уменьшаться на спецов.
Но спецы то сами не возникают из ничего, чтобы стать спецом, человек
должен сначала поучиться у других спецов.
Итог всего выше: спецы локализуются в тех местах, где на них есть спрос
и где можно стать спецом.
Здравствуйте, AndrewVK, Вы писали:
ГВ>> Но подпись-то под статьёй одна. AVK>Кто бы сомневался. Советской закалки человек, знает как в СССР докторские и статьи в научные журналы писались.
Ну, не надо, мужики...
Разные докторские и разные статьи писались...
Например, кандидатская диссертация Баяковского Юрия Матвеевича — это графическая система, которая работала во всех вычислительных центрах Советского Союза... Нынешним кандидатам такое и не снилось.
И СУБД ИНЕС Михаила Донского тоже работала во всех ВЦ СССР.
В общем, серьезные раньше люди были, серьезные...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Mystic, Вы писали:
M> Наоборот, уже много лет ведется планомерная работа, чтобы сделать работу программиста как можно более рутинной.
Не знаю от чего такой вывод, но, скажем, технологии для разработки от Microsoft в последнее время значительно усложнились. Сравни WinForms и WPF, Вебсервисы и WCF, С# 1.0 и 3.0.
... << RSDN@Home 1.2.0 alpha 4 rev. 1106 on Windows Vista 6.0.6001.65536>>
Здравствуйте, eao197, Вы писали:
E>Выгода от размещения вне Москвы -- сокращение расходов на ЗП и аренде.
Расходы по ЗП не так очевидны — в Москве можно найти программиста с производительностью равной 10 средним программистам, а платить ему всего в 2 раза больше.
... << RSDN@Home 1.2.0 alpha 4 rev. 1106 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Mystic, Вы писали:
M>Ну так чем проще программировать, тем меньше квалификация нужна.
Совсем нет. Потому что задачи программирования, а, как следствие, и критерии квалификации, состоят отнюдь не в борьбе со сложностями средств разработки. Т.е. программист высокой квалификации, это не тот, кто умеет пользоваться очередным мегаультрасложным средством разработки, а тот кто способен решать мегультрасложные задачи. Средство разработки — инструмент, а не цель.
... << RSDN@Home 1.2.0 alpha 4 rev. 1106 on Windows Vista 6.0.6001.65536>>
Здравствуйте, ononim, Вы писали:
O>А читали например "Книгу о счестье и несчастьях" Н. Амосова (такого кардиохирурга). Там вообще описания операций на сердце перемежаются мемуарами о детстве и рассуждениями о смысле жизни. По моему вполне нормальное явление для человека который не зациклен на одном.
Переключение темы — нормальное явление. Высказывание противоположных точек зрения и демонстрирование разной философии что ли в одном и том же виде деятельности в соседних абзацах — ненормальное.
O> Программисты вообще никогда не отличались литературной стройностью изложения мысли.
Не обобщай.
O>Давно заметил что когда программисты начинают рассуждать о чемто кроме программирования, зачастую они становяться похожими на бухгалтерш, рассуждающих о программировании.
Статья, вообще то, исключительбно о программировании.
... << RSDN@Home 1.2.0 alpha 4 rev. 1106 on Windows Vista 6.0.6001.65536>>
FR пишет: > > > Интроверты обычно ленивы и малоамбициозны, при этом умные и хорошие > программисты, и среди > программистов их большинство.
Ну и ладно, каждый начальник набирает людей под себя (как пример,
госаппарат Беларуси).
P.S. А вот по интровертам, ты не прав, они обычно не ленивы и
амбициозны. Впрочем как и экстраверты.
P.P.S. Осталось спросить а какой палец у тебя длинее средний или безымянный?
E>РУТИНА ж. франц. безотчетное следованье преданью, обычаю.
E>то рутиной, на мой взгляд, является работа, в которой: E>- выполняются повторяющиеся (ставшие обычными) действия; E>- не существует возможности отказаться от существующего положения вещей (нет желания или возможности сменить/заменить/изменить выполняемые действия).
Пятёрка за пример и двойка по формальной логике. Исходное определение совершенно точно включает "безотчётность", то есть это — характеристика субъекта, а не условий.
Отсюда вывод, что твоё доопределение рутины нужно перефразировать так:
- неосознанно выполняются повторяющиеся (ставшие обычными) действия;
— по мнению субъекта не существует возможности отказаться от существующего положения вещей (нет желания или он сознательно игнорирует возможности сменить/заменить/изменить выполняемые действия).
E>Разработка среды программирования и кластерного решения к ней я не могу по таким критериям причислить к рутине, поскольку создание среды программирования не является повторяющимся действием.
Были бы рутинёры, а уж превратить в рутину они сумеют всё, что угодно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Michael7, Вы писали:
M>Java-программисты не пишут отказоустойчивых кластерных приложений! Они фактически производят сборку и настройку готового приложения. Готового в виде отдельных блоков.
Это фантастика... В Java, действительно, больше инструментов для разработки кластерных приложений, но они сам по нажатию кнопки "Next" в визарде не делаются.
Здравствуйте, Michael7, Вы писали:
M>В этих моделях разработки рядового программиста стоит перестать называть программистом. Это кодер, выполняющий работу чуть более интеллектуальную, чем машинистка.
Да ты что... а почему рынок не наводнят ими никак? Раз такая простая работа. то можно брать с улицы и за пару месяцев выучить на "машинистку" и вперед. Затраты сразу снизить, а то вон в Мск на 50 К безработные не идут, понимаешь.
Здравствуйте, AndrewVK, Вы писали:
ГВ>>Разнобой в мыслях есть, это точно.
AVK>Не просто разнобой, скорее некоторая шизофрения. Я не понимаю как в соседних кусках текста могу соседствовать размышления о maintainability кода и рассказы про необходимость написания собственных языков под любой проект.
Существует мнение, что люди шизоидного типа могут достигать больших успехов в программировании. Не исключено, что в случае с Донским это именно так. Отсюда и проявления шизофрении в его статье -- за разные фрагменты отвечали "разные" части его личности (звучит излишне страшновато, однако).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Vzhyk, Вы писали:
V>sourcerer пишет: >> >> Интереснейшая статья Михаила Донского >> том что "программер счас не тот" , о том "как все начиналось", о >> перспективах отрасли. V>Имхо, вот ее суть: "статью к своему 60-му дню рождения, возраст V>пенсионный, и, похоже, кончается не только мой жизненный цикл"
Здравствуйте, Vzhyk, Вы писали:
V>sourcerer пишет: >> >> >> вы за деревьями леса не увидели... V>Это точно, ну не вижу я там леса, пару чахлых березок и осинок.
Согласен, человек имя Дейкстры не знает как пишется, Мозаика у него 13 лет назад появилась, про практически "прогибание" под микрософт уже молчу
Здравствуйте, sourcerer, Вы писали:
S>Интереснейшая статья Михаила Донского о профессии, о том что "программер счас не тот" , о том "как все начиналось", о перспективах отрасли.
[a]
Приходящая же в профессию молодежь, не имеет такого запаса. И не столько потому, что глупее, а потому, что их не так учат. В моей молодости обучение программированию в институтах было вообще смешным – изучались только синтаксисы разных языков на простейших программах.
[/q]
Смешно
Сейчас дело обстоит чуть получше, но я не слышал, чтобы во время сдачи курсовой или дипломной работы студенту на ходу меняли техническое задание. А мне в жизни приходилось, сдавая большую систему с удивлением узнавать об изменении формата входных данных. Я считаю такую ситуацию нормальной, а молодые программисты – издевательством.
Они не понимают, что если заказчик меняет требования к уже почти готовой системе, это означает, что система ему нравится. Если система ему не нравится, он вздохнет, заплатит за нее и про нее забудет.
Все молодые ребята, приходящие ко мне обладают одним и тем же недостатком. Они устремлены к тому, чтобы их часть программы заработала как можно быстрее, думая, что это – успешный конец работы. Никто до меня их не научил, что работающая программа – это только начало. Дальше, в ходе ее использования будут возникать все новые требования, и программу придется непрерывно менять. Поэтому изначально в нее должна быть заложена эластичность, без которой вносить изменения в программу будет крайне сложно.
Ну это вообще клевета на наше текущее программистов и менеджеров, которые изучают и внедряют техники управления процессом производства, позволяющие такие ситуации предотвращать или хотя бы разруливать, если они уж всё-таки случились.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Vzhyk, Вы писали:
V>>sourcerer пишет: >>> >>> >>> вы за деревьями леса не увидели... V>>Это точно, ну не вижу я там леса, пару чахлых березок и осинок.
К>Согласен, человек имя Дейкстры не знает как пишется, Мозаика у него 13 лет назад появилась, про практически "прогибание" под микрософт уже молчу
если уж на то пошлО, то что сделано с фамилией автора С++ — просто ужжжжасно а про Майкрософт — холивары непродуктивны...с майкрософтом — это его мнение ... и пром. стандарт де-факто.
Здравствуйте, Курилка, Вы писали:
К>Согласен, человек имя Дейкстры не знает как пишется
По-английски, он пишется "Dijkstra", так что про тут понятно откуда такое написание фамилии.
К>Мозаика у него 13 лет назад появилась, про практически "прогибание" под микрософт уже молчу
Ну да, про MS он конечно погорячился.
Здравствуйте, sourcerer, Вы писали:
S>Интереснейшая статья Михаила Донского о профессии, о том что "программер счас не тот" , о том "как все начиналось", о перспективах отрасли.
хвастовство сплошное, с явным уклоном на "у меня длиннее всех, а молодежь тупаааая"
да и противоречит он там сам себе местами...
(имхо) как "программер, которые сейчас не те" (закончил интститут в четыре года назад), скажу — насчет того, чему сейчас учат и чему не учат — гон, наглый причем.
а говорить (да еще и с отрицательно оценкой) о том, чего не знаешь/не видел — недостойно серьезного дяденьки
Здравствуйте, sourcerer, Вы писали:
S>Здравствуйте все,
S>Интереснейшая
Ну фиг его знает...
Курсовая на тему ОС или СУБД это конечно перебор, т.к. объем минимальных
современных технологий и требований выходит далеко за рамки курсовой, имхо.
Про юниксоида и зал игровых автоматов — откровенная чушь, т.к. чтобы оценить
прав юниксоид или нет надо как минимум почитать ТЗ заказчика и посмотреть то,
что сделал этот юниксоид. Не зная этого, я бы сказал, что юниксоид прав.
Вообще, такое ощущение, что товарищ страшно отстал от жизни и почему-то
ставит это в упрек этой жизни... К старости обычно люди становятся мудрее,
но в его случае, видимо, КАИСС и осознание того, что он может реализовать
ЛЮБОЙ алгоритм, мудрее стать не дают.
Еще одна странность, для меня. Про Донского первый раз слышу, а Дейкстру,
Кнута, Страуструпа прочитал вдоль и поперек несколько раз в обоих
направлениях. К чему бы это?
Если уж товарисчь так "болеет" за свое дело, то надо не пиарить свою
контору на "желтых" сайтах а заниматься продвижением своих технологий
(если таковые вообще имеются) в массы.
Для того чтобы я мог работать и зарабатывать деньги тот же Торвальдс
сделал во сто крат больше чем сабжевый Донской.
Есть одно в чем он 100% прав. PHP и html программисты — это не програм-
мисты
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Курилка, Вы писали:
К>>Согласен, человек имя Дейкстры не знает как пишется C>По-английски, он пишется "Dijkstra", так что про тут понятно откуда такое написание фамилии.
По-моему если человек столько лет IT занимается, то можно было узнать.
Пишется оно по-голландски, и про ij в вики можно посмотреть, если на то пошло.
Хотя, возможно, какие-то советские переводчики как "дийкстра" переводили (кто-то вроде тут говорил про украинские учебники с таким написанием), тот же Клини, к примеру, по вине переводчиков так читается, на самом деле он Клейни.
Хотя всё это так, несущественные мелочи, конечно
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Cyberax, Вы писали:
C>>Здравствуйте, Курилка, Вы писали:
К>>>Согласен, человек имя Дейкстры не знает как пишется C>>По-английски, он пишется "Dijkstra", так что про тут понятно откуда такое написание фамилии.
К>По-моему если человек столько лет IT занимается, то можно было узнать. К>Пишется оно по-голландски, и про ij в вики можно посмотреть, если на то пошло. К>Хотя, возможно, какие-то советские переводчики как "дийкстра" переводили (кто-то вроде тут говорил про украинские учебники с таким написанием), тот же Клини, к примеру, по вине переводчиков так читается, на самом деле он Клейни. К>Хотя всё это так, несущественные мелочи, конечно
Если быть совершенно точным, то голландская фамилия Dijkstra произносится как нечто среднее между "Дийкстра" и "Дяйкстра" (с ударением на первом слоге). Так что Донской в чем-то прав. Хотя, конечно, закрепившееся написание в русскоязычной литературе "Дейкстра".
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, sourcerer, Вы писали:
S>>Интереснейшая статья Михаила Донского о профессии, о том что "программер счас не тот" , о том "как все начиналось", о перспективах отрасли.
ГВ>На самом деле читателю навязывается две простенькие мысли:
ГВ>- математика современному программисту не нужна;
Это, на мой взгляд, что-то из глубин подсознания, а не из статьи. Даже намека не увидел на это.
Единственное, что было сказано о подготовке программистов, -- это то, что готовят их неправильно. Была высказана очень простая и остроумная мысля -- чтобы подготовить реального программиста надо заставлять его работать в реальных условиях. Например, надо приучить к мысли, что требования в процессе
разработки могут с большой вероятностью поменяться. Приучить, создав модельную ситуацию. ГВ>- программирование становится рутинной профессией (основной тезис статьи).
Становится, что поделать. Кстати, слышал, что ему принадлежит утверждение, что все средства производства проходят 3 стадии развития "Как делать?" --> "Что делать?" --> "Зачем делать?". Скорее всего, "автор хотел сказать" именно эту мыслю, единственно, что выразился не очень понятно.
З.ы. Этап "как", имхо, уже агонизирует довольно давно.
Cебарит какой-то
Лично я вообще себе запретил вспоминать что либо более чем 5 летней давности. А то как старик Михаил Донской буду. Мне неприятно таким быть.
Молодой ли старый, все фигня.
Дали мяч — %уячь!
Здравствуйте, Vzhyk, Вы писали:
V>sourcerer пишет: >> >> Интереснейшая статья Михаила Донского >> том что "программер счас не тот" , о том "как все начиналось", о >> перспективах отрасли. V>Имхо, вот ее суть: "статью к своему 60-му дню рождения, возраст V>пенсионный, и, похоже, кончается не только мой жизненный цикл"
DM>Вот спасибо за оценку моих способностей!
Я тоже не смогу понять. Я учавствовал в демонтаже Минск-22, люди которые работали на таком железе — однозначно заслуживают уважения. Это счас любой посредственый пилот может пересечь океан, а братья Райт летели на такой технике, что шансы на выживание были очень неоднозначные.
DM>Да, средства производства и сам процесс тогда были более трудоемкими. Но просто из теории информации и колмогоровской сложности, если угодно, получается, что в 4 кб — это не сильно сложная система. Даже если все это — код, это всего порядка 2к строк ассемблера довольно простого компьютера (сейчас процессоры сложнее).
4x48, что есть 24 килобайта. Учитывая возможность оверлеев — когда приходится перетирать данные и код другими данными и кодом, отсутсвием полноценной ОС (Дима, есть опыт создания приложений без ОС?) — это гораздо больше.
Сейчас процесоры проще с точки зрения программера. Человек который видел ассемблер IBM360 — должен оценить его сложность. Там было 360 инструкций. В 8086 инструкций намного меньше и они проще. Сегментная адресация — это просто верх простоты по сравнению с адресацией в мейнфреймах. Дизайн языков высокого уровня привел к тому, что набор команд стали затачивать под компиляторы, а не программера, это привело к резкому упрощению системы команд. Система комманд ARM — весьма современная разработка — чрезвычайна проста и вмещается на один лист.
Здравствуйте, alpha21264, Вы писали:
A>Ты опять не понял. Чтобы машина с 4 кб памяти реализовывала нормальную задачу, A>нужно, чтобы бОльшая часть интелекта находилась вне компьютера. A>А ты оцениваешь только ту сложность, которая внутри, подразумевая, что то, что вне, будут делать другие люди.
Ну, тогда 4кб система работала с железом, сейчас 4к демка работает с DirectX и через него с железом (со всевозможными шейдерами, звуками и пр.). Т.е. в обоих случаях есть нетривиальное окружение. Но пишут же.
A>Прикинь сколько переменных должен держать в голове программист при "отладке на листке бумаги". A>Вот это и есть сложность для программиста.
Но все равно все устройство компьютера и операционки было вполне умопостижимо одним человеком. И еще в голове место оставалось для задачи.
Уверен, что какой-нибудь Торвальдс с не меньшим числом переменных в голове ходит. Только у него это не переменные, а более высокоуровневые конструкции.
Я не хочу сказать, что тогда все было легко и просто. Но и слишком преувеличивать сложность тоже не стоит.
Здравствуйте, Handie, Вы писали:
H> люди которые работали на таком железе — однозначно заслуживают уважения.
Заслуживают, однозначно. Нисколько не спорю.
DM>> 4 кб — это не сильно сложная система. Даже если все это — код, это всего порядка 2к строк ассемблера довольно простого компьютера.
H>4x48, что есть 24 килобайта.
Все равно не более одной команды на ячейку, а скорее всего меньше. Т.е. те же 2к команд где-то.
Кстати, на Вояджере, который уже покинул солнечную систему, но продолжает держать связь, было как раз 4к памяти и возможность перепрошивки с Земли.
H> Дима, есть опыт создания приложений без ОС?
Почти — на Спектруме, где почти все управление и ввод-вывод сводились к записи либо в нужный порт, либо в нужную часть памяти.
Здравствуйте, sourcerer, Вы писали:
S>Интереснейшая статья Михаила Донского о профессии, о том что "программер счас не тот" , о том "как все начиналось", о перспективах отрасли.
1. Респект мужику за вклад в развитие отечественной программерской культуры.
2. С большинством выводов в статье не согласен — задачи сейчас не менее сложные и интересные, чем было 20-30 лет назад. Они просто другие, это вызвано нехилыми техническими достижениями за указанное время, и сравнивать их некорректно.
3. Про цикл развития отрасли и изменение статуса программистов — согласен отчасти. Имхо, как и в любой профессии, всегда будет присутствовать какая-то наиболее квалифицированаая часть специалистов. Сейчас им даже лучше — они избавлены от задач, не требующих специальных знаний — типа указанной в статье необходимости составления отчётов специальным шрифтом. От того, что слово "программист" потеряло свой романтический ореол, сущности ни людей ни задач не поменялись. Если хотите, можно придумать какое-то другое слово для обозначения "небыдлокодера", вот, например, придуманный/сгенерённый Дмитрием Кирсановым мыслюх.
4. Это больше походило не на статью, а на пиар своей компании, типа, смотрите, мы уже тридцать лет решаем сложнейшие задачи. И не ведитесь на демпинговые цены конкурентов, они специально вас заманивают, чтоб потом вытрясти всё до копейки — да и к тому же у них работают вчерашние студенты, они ничего не смыслят в настоящем программировании. Вот за это не респект.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, sourcerer, Вы писали:
S>Здравствуйте все,
S>Интереснейшая статья Михаила Донского о профессии, о том что "программер счас не тот" , о том "как все начиналось", о перспективах отрасли.
Статья очень понравилась.
Выводы правда там ни к чему — лучше бы просто о себе написал.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Противоречий у него на самом деле намного больше, взять хотя бы вот эти два тезиса:
ГВ>
Одним из важнейших принципов программирования для меня является необходимость создания собственного инструментария для любого проекта, начиная с проектов средней величины.
ГВ>и ГВ>
А понять внутреннюю организацию сложных систем можно только одним способом – самому сделать что-то подобное, пусть и гораздо более простое. Но я не слышал, чтобы студентам задавали в качестве курсовой работы создание простой операционной системы или системы управления базами данных.
ГВ>В итоге профессия программиста меняет свой характер. Если раньше программисты знали свою программу досконально, то теперь в лучшем случае они умеют эффективно использовать то или иное инструментальное средство.
ГВ>То есть, собственные инструментальные средства, являющиеся по его словам залогом рентабельности IT-бизнеса (здесь ему как раз можно верить, поскольку он точно знает, о чём говорит — сам же бизнесмен), уже магически оказались не нужны. По-видимому, совесть не позволяет откровенно соврать, сказав что-нибудь вроде того, что залог эффективности IT-бизнеса — доскональное знание продуктов Microsoft (дело не в названии фирмы, разумеется).
Гена, похоже, что в этом тексте каждый видит то, что хочет видеть. Я например, вижу сожаления Донского о том, что:
a) не смотря на то, что собственные инструментальные средства лучше для разработки своих продуктов (по мнению Донского), сейчас мало кто создает эти самые собственные средства.
b) но даже когда используются готовые чужие инструментальные средства далеко не все разработчики способны понять их устройство и, как следствие, эффективно использовать.
ГВ>Что характерно, процитированный фрагмент заканчивается не критикой системы образования, которая не учит детей писать свои СУБД и ОС, а совершенно неожиданным припевом: "профессия программиста становится рутинной". Я хренею, my dear editor. Так если современные средства нельзя понять, не написав аналога, то... Хотя, чему удивляться? Если бы прозвучал тезис о том, что детей надо учить писать свои СУБД, это сразу бы потащило за собой кучу дополнительных выводов, в частности о том, что образование должно включать в себя не "реальные условия", а фундаментальную подготовку, развитие абстрактного мышления и т.п.
А вот такой призыв, имхо, в современных условиях:
a) невыполним. Мало кто из преподавателей в ВУЗах бывшего СССР хоть что-то понимает в разработке СУБД и ОС. И горит желанием хоть чему-то в этом научиться. И, возможно, такая ситуация не только на постсоветском пространстве, но и в Европе, Азии и, может, быть в США.
б) бесполезен. Пока обычному программисту не нужна фундаментальная подготовка и развитие абстрактное мышление, а простое знание XML и HTML обеспечивают получение непыльной работенки с достаточно приличным окладом, восстребованность подобной системы образования будет минимальной со стороны самих учащихся. Насколько я помню, даже в СССР, во времена, когда студентов ВУЗ-ов без военных кафдр забирали в армию после первого курса, в подобные ВУЗы был относительно малый поток ребят-абитурьентов. Аналогичная ситуация произойдет, если какой-нибудь ВУЗ в Мухосранске захочет создать курс с углубленным изучением предмета. Отучатся на нем несколько фанатов-ботаников, а остальные разбегутся в самом начале.
в) банален. Да, это очень банально покивать на систему образования и сказать, что вот если бы... А можно реалистично взглянуть на мир вокруг и вспомнить, чего добился Генри Форд на своих заводах: большинство рабочих проффессий благодоря усовершенствованию технологического процесса не требовали никаких выдающихся умственных/физических качеств, рабочий мог приступить к работе с полной отдачей после нескольких часов/дней инструктажа. Производство ПО сейчас напоминает перевод Генри Фордом производства автомобилей от кустарного к полуавтоматизированному производству.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
ГВ>Йопт. И ты туда же. Спасибо за повторение тезиса о рутинности программирования. Наслышан. Все как попугаи повторяют друг другу одно и то же — программирование становится рутинным, рутинным, рутинным. Хорошо, спасибо.
А как по мне так совсем наоборот , просто больше рутинной работы начали называть "програмированием". Можно даже увидеть "програмист HTML or EXEL"
Здравствуйте, Sash_xp, Вы писали:
S_>Здравствуйте, sourcerer, Вы писали:
S>>Здравствуйте все,
S_>Я так понимаю в статье Донского общественность задела та идея, что "программисты мельчают" и профессия программиста уже не является передовой и интеллектуальной — для ее освоения достаточно минимальных знаний и навыков. И общественность, похоже, думает что это не так. Ну тогда ответьте на такой вопрос: насколько хорошо вы знаете математику, а насколько хорошо ее знают другие программисты? Да, конечно, сегодня уже не то программирование, что раньше. Все сильнее звучат голоса тех, кто утверждает, что математика в программировании не нужна. Что уже давно сместился акцент на SOA или что там еще выдумают маркетологи завтра. В общем, программирование становится все более гуманитарной специальностью. И эту тенденцию отражает факт появления таких специальностей как "программист PHP". Но разве гуманитаризация и появление таких языков как PHP не снижает барьеры входа в отрасль? Не делает ее более массовой? А разве эта массовость не приводит к общему снижению уровня программистов? Как еще можно объяснить тот факт, что люди утверждающие что хорошо знают алгоритмы начинают испуганно молчать при вопросе о сложности алгоритма быстрой сортировки? И даже не могут объяснить идею пузырьковой.
Кто не может, конкретно имена, фамилии, пароли явки))))))))
Проценнт идиотов какждой профессии примерно одинаков, я думаю даже грузчики есть не очень хорошие S_>Если хотите, вы можете еще долго издеваться над уважаемым человеком и обсуждать как правильно писать голландские фамилии, но правоту идеи этой статьи о "мельчании" программистов наверняка отлично осознает каждый.
Объясните мне, что не так с PHP?Ась?
Здравствуйте, minorlogic, Вы писали:
ГВ>>Йопт. И ты туда же. Спасибо за повторение тезиса о рутинности программирования. Наслышан. Все как попугаи повторяют друг другу одно и то же — программирование становится рутинным, рутинным, рутинным. Хорошо, спасибо.
M>А как по мне так совсем наоборот , просто больше рутинной работы начали называть "програмированием". Можно даже увидеть "програмист HTML or EXEL"
ИМХО, появилось много работы, связанной с обслуживанием конечного пользователя. Ну там, всякие подкрутки, перестановки кнопочек, мелкие базы данных и т.п. С одной стороны — это достаточно простые задачи, для решения которых много знаний не нужно. А с другой — это можно считать частной недоработкой, например, адаптивных интерфейсов пользователя.
Конечно, формально всё это можно называть программированием. Но это ж не означает, что программирование "в целом" становится рутинным, правда? Это просто нерешённые частности такие на сегодняшний день. Точно такой же перекос, как тот, что был во времена записи программ в машинных кодах.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
S_>Если хотите, вы можете еще долго издеваться над уважаемым человеком и обсуждать как правильно писать голландские фамилии, но правоту идеи этой статьи о "мельчании" программистов наверняка отлично осознает каждый.
Вот!!! Спасибо что Вы так ясно изложили суть статьи. А цепляться к частностям — для этого надо быть очень энергичным и молодым
PS: мысли вслух: Не является ли Ваш вывод побудительным мотивом для того чтобы "лишний раз" полистать "Конкретную математику" и третий том Кнута ?
Здравствуйте, AndrewVK, Вы писали:
AVK>Есть такое ощущение, что статью писали два человека — сам Донской и кто то из его архитектов.
Разнобой в мыслях есть, это точно. Но подпись-то под статьёй одна.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Как еще можно объяснить тот факт, что люди утверждающие что хорошо знают алгоритмы начинают испуганно молчать при вопросе о сложности алгоритма быстрой сортировки? И даже не могут объяснить идею пузырьковой.
Кто не может, конкретно имена, фамилии, пароли явки))))))))
Ну я, например.
Правда, особенно хорошим программистом я себя не считаю, но законченных коммерческих проектов много. И опыт более десяти лет. И вообще все хорошо .
Конечно, что такое пузырьковая сортировка я еще помню. Но это остаточные знания — уже много-много лет мне не приходилось выбирать тип сортировки . И не потому что я такой дурак, а потому что даже если что-то где-то тормозило, то злобные профайлеры показывали узкие места совсем не в сортировке — а в ошибках алгоритмики или API вызовах . Что такое сложность алгоритма я уже почти не помню. И совершенно точно не назову его для qsort или hash lookup.
Наверное, это все из-за усложнения профессии и ее фрагментации на отдельные дисциплины. Математика отдельно, машинный код отдельно, языки высокого уровня отдельно, архитектура отдельно.
Каждая область стала настолько сложной, что знать на высоком уровне несколько — для обычного человека очень тяжело. Десять лет назад я очень хорошо знал ассемблер, мог легко написать 4к демо в защищенном режиме и собственный 3д движок. Сейчас я хорошо знаю С, С++, архитектуру программ, API нужных операционок. А ассемблер уже вообще не помню .
А рядом сидит коллега, который великолепно знает устройство процессора и ассемблер. Может на пальцах оптимизировать код по конвейерам и творить прочие чудеса. Но С++ и API знает очень плохо.
Здравствуйте, AndrewVK, Вы писали:
AVK>Не просто разнобой, скорее некоторая шизофрения. Я не понимаю как в соседних кусках текста могу соседствовать размышления о maintainability кода и рассказы про необходимость написания собственных языков под любой проект.
Да это ещё туда-сюда... Там навалом нестыковок покруче.
ГВ>> Но подпись-то под статьёй одна. AVK>Кто бы сомневался. Советской закалки человек, знает как в СССР докторские и статьи в научные журналы писались.
Ну тогда драма плавно переходит в комедию.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Handie, Вы писали:
DM>>Про достижения 60-х: DM>>здорово, конечно, рассказывать, как делал свою ОС. Только когда вся память в машине — 4 кб, это по-любому не очень большой и сложный проект. Не намного сложнее современных 4k intro, которые до сих пор пишутся пачками.
H>Димон, ты не прав. Тебе никогда не понять что это такое, видимо никогда не приходилось работать с такими ограничениями. Мне приходилось приближаться — реализовывать Heap на 2kb памяти — это была более чем реальная ситуация. Они делали это не в текстовом редактре и не в среде IDE, в которых работаю нынешние "микрокернелисты". Они делали это с печатающего телетайпа, перфокарт используя весьма дерьмовый ассемблер.
Я разбирался в машинных кодах 8080, набивая на программаторе опубликованную в бумажном варианте CP/M — и что? А еще раньше — ну и позже тоже — разбрасывал по 105 ячейкам ПМК увесистый алгоритм численного расчета? Это заслуга? Повод гордиться? имхо, "повод померяться длиной" — ничего боле.
DM>>В целом, неплохой рассказ, да и то, что автор до сих пор занимается реальными проектами и работает с современными технологиями (пусть и с ворчанием) — вызывает только уважение.
H>Да тут я смотрю много сейчас чуваков которые имея современные средства разработки бъют себя кулаком в грудь...
Это ж какие? Ну да — программных эмуляторов тогда не было — но и те самые "2 кб памяти в хипе" зело попроще были "с ног до головы" и в целом где-то ну уровне как раз современного вон из соседнего потока "кастомного менеджера хипа на пару-другую миллион объектов удаляемых одним махом вместе с памятью без вызова деструкторов" — на 2 кб памяти особо не развернешься и никакой современной динамики там не было в принципе — приукрашать тоже не надо.
Здравствуйте, Kubyshev Andrey, Вы писали:
KA>Поглядел статью, короче автору респект и уважуха. Дай бох каждому как говорится. KA>Наверняка сейчас есть и такие как он, просто мест для приложения своих сил тоже много. Вот их и незаметно.
Ну дык! Алгоритмы-то никто не отменял — несмотря на кажущийся безграничный рост производительности современного железа...
Здравствуйте, Handie, Вы писали:
H>4x48, что есть 24 килобайта. Учитывая возможность оверлеев — когда приходится перетирать данные и код другими данными и кодом,
В условиях ограниченной памяти это мягко-мягко так говоря дело настолько обычное, что я даже не представляю с чем бы его в современных условиях сравнить... Ну, может с вытеснением страницы виртуальной памяти?
H>... отсутсвием полноценной ОС (Дима, есть опыт создания приложений без ОС?) — это гораздо больше.
Я не Дима, но эта "пузомерка" смешная: приложение без ОС само по себе работает запросто — "просто работает" — а зачем вообще "просто приложению" ОС? Вон даже в современной винде-юнихе — тебе ОС требуется только при обращении "наружу приложения" — периферия всякая и пр. — а какая периферия у той машины? Никакой значимой ОС — тем более уровня API — там не надо в принципе.
H>Сейчас процесоры проще с точки зрения программера. Человек который видел ассемблер IBM360 — должен оценить его сложность. Там было 360 инструкций. В 8086 инструкций намного меньше и они проще. Сегментная адресация — это просто верх простоты по сравнению с адресацией в мейнфреймах.
Ну, такое есть — мейнфреймы отличаются такими вот "особенностями процессора" — да и сама ОС там "не лыком шита" — имхо, это не показатель ничего.
H>Дизайн языков высокого уровня привел к тому, что набор команд стали затачивать под компиляторы, а не программера, это привело к резкому упрощению системы команд.
Это ты вообще о чем?
H>Система комманд ARM — весьма современная разработка — чрезвычайна проста и вмещается на один лист.
Хм. Ну дык там и "заархитектурить по железу" особо не разгонишься — только это показатель чего?
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Только Форд-то здесь причём? У него в принципе не было возможности набрать массу квалифицированных инженеров и рабочих, и построить, например, автоматизированное производство. Ощути разницу направлений: выкручиваться в условиях отсутствия квалифицированного персонала и сознательно снижать квалификацию персонала, подгоняя его под "модель производства". Не находишь, что это две большие разницы?
Хм. Странный вывод. Исходя из старого-доброго "количество интеллекта — постоянная" — следует как раз обратное: необходимость подгонки "модели производства" под априори невозможмость получения достаточного количества персонала высокой квалификации.
С Фордом, кстати, разница не совсем та — Форд реализовал разделения труда, примененное одновременно к одному и тому же объекту сборки в течение очень ограниченного периода времени — а именно, конвейер. В принципе это изобретение применимо и к "сборищу высококвалифицированных" — только обратно нужно разделение труда и организация. Вопрос всего-то в том, что задачи просто масштабнее стали — математикам-изобретателям-творцам действительно места _не_ меньше, зато обычным "кодерам — сборщикам на конвейере" работы валом. В результате же последних _значительно_ больше и создается эффект, якобы первым "работы нет и вообще не у дел". имхо, это и так, и не так: с одной стороны, индустрия вышла на уровень индустрии — уже многое изобретено и реализавано и многим и даже большинством можно пользоваться "из библиотеки", не изобретая свое собственное, а просто комбинируя нужным образом для решения конкретной прикладной задачи; с другой — места для изобретений все так же имхо достаточно — просто они стали гораздо менее заметны "основной массе". Где-то так.
Здравствуйте, minorlogic, Вы писали:
ГВ>>Йопт. И ты туда же. Спасибо за повторение тезиса о рутинности программирования. Наслышан. Все как попугаи повторяют друг другу одно и то же — программирование становится рутинным, рутинным, рутинным. Хорошо, спасибо.
M>А как по мне так совсем наоборот , просто больше рутинной работы начали называть "програмированием". Можно даже увидеть "програмист HTML or EXEL"
Хех. А почему "программа на 4-х килобайтах" была "программирование", а загонка нужного алгоритма-рачета в таблицу — уже нет?
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Ну опять двадцать пять. Повторяющиеся операции можно и должно вообще всячески вытеснять из сферы человеческой деятельности. Этим должны заниматься роботы. Нельзя тут проводить прямую аналогию с программированием.
Можно. Или с высока не считать "эту низкую рутину" — программированием.
ГВ>Первая. Те же радиаторы.
ГВ>Сначала у нас небольшое производство, которое вполне обслуживается, скажем пятью квалифицированными кузнецами. Чуть позже производство расширяется, пятерых кузнецов не хватает, зато — навалом малоквалифицированных, скажем, разорившихся фермеров. Что мы сделаем? Мы постараемся сделать так, чтобы объём продукции минимально зависел от количества кузнецов, переложив на них, например, исправление огрехов литья. Остальные операции повторяются с точностью до автоматизма, и их сможет освоить после минимального обучения любой фермер, который может отличить соху от телеги. На какой-то момент производство стало дороже, поскольку платить меньше некоего минимума людям невозможно, но это компенсировалось увеличением объёма продаж. То есть мы выкрутились в условиях недостатка квалифицированного персонала.
Что делать, если необходимая квалификация кузнеца такова, что процент фермеров, таки достигших ее обучением, презренно мал?
ГВ>Вторая ситуация. Тот же самые радиаторы. Но! Вместо того, чтобы заменить сотню вчерашних фермеров, например, станком с ЧПУ и парой операторов, мы разводим вакханалию лозунгов о том, что вообще достаточно ограничиться знанием отличий сохи от телеги. Соха и телега внесены в учебные программы, готовим полуфермеров массово. Вроде как вершина прогресса достигнута, дальше космос кончился.
Насчет "станков с ЧПУ" — лично я не понял.
ГВ>Ты всё ещё не видишь различий?
Объясни как-нибудь иначе вторую аналогию — уж больно запутанно...
ГВ>Всё как в случае с Фордом в нашей профессии не может быть по определению. Аналогии с механическим производством развенчивались даже на RSDN не один десяток раз. Форд должен был наращивать количество выпускаемой идентичной продукции. У нас стоимость именно экземпляра — копейка в базарный день (CD + электроэнергия на запись). Не одну и ту же программу ведь приходится писать по многу раз, верно?
Да ну? Сайты. Формы. Очередное формирование очередного отчета. Не все звездолеты куют — вот ведь в чем вопрос — рутины "просто собирающей очередную готовую реализацию из готовых заготовок-фреймфоков-библиотек" — не просто валом — это чуть ли не есть основная задача программиста на сегодня. Чем ты ее заменить собираешься? Универсальным Решением Всего?
ГВ>... Наша проблема состоит в необходимости аккумулировать знания о предметной, воплощая их в API, фреймворки, ОС, СУБД и т.п. Да, сейчас проблема базовых инструментов (те же ОС, СУБД, языки высокого уровня, фреймворки) более или менее разрешима. Но неужели ты считаешь, что нынешние, скажем, СУБД — вершина развития IT? По-моему, это только зачаточное состояние. У них даже метафоры использования недалеко ушли от книжной полки.
Ну дык Кесарю — Кесарево. (к) Кому — новые метафоры СУБД выдумывать, а кому — их реализовывать и поддерживать, а еще кому — уже реализацию в своих конкретным задачах использовать — и последним имя — легион.
ГВ>И кроме того, наличие формального процесса само по себе вовсе не означает, что можно снизить квалификацию сотрудников, хотя это заблуждение очень распространено даже среди менеджмента.
Снизить — нельзя — и нет такой цели. Ты и сам дальше пишешь:
ГВ>... Всё строго наоборот: формальный процесс как раз предъявляет очень высокие требования к абстрактному мышлению, а то придётся следить за каждым словом, написанным "обезьянкой".
А... нет.
ГВ>... По сути дела, формализация процессов нужна для помощи разработчикам
Вот именно: формализация нужна разработчикам, чтобы "не приходилось следить за каждым словом, написанным обезьянкой". Как современный компилятор современного языка сам следит за типами данных — при правильном подходе и примении инструмента конечно же — так и формальный процесс позволяет "реализовать один раз процесс и дальше не задумываться о том, тот ли код зачекинен и какую именно сборку мы сейчас вообще собираем" — и многое другое тоже. Формальный процесс — это та самая механизация и автоматизация многих рутинных операций очень объемного процесса создания очередного экземпляра программы. имхо. И да, действительно: программисту не обязательно быть семи пядей во лбу и помнить все 4К команд его проекта — особенно учитывая что команд гораздо больше — программист теперь может работать над более мелкими конкретными задачами, которые все вместе совмещаются формальным процессом в одну большую — в целом действительно очень напоминает конвейер ну и по сути таковым является — я так думаю.
ГВ>..., а не для превращения их в винтики, только в таких условиях эта самая формализация и работает толком, а иначе получим пустую бюрократию.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Конечно, формально всё это можно называть программированием. Но это ж не означает, что программирование "в целом" становится рутинным, правда? Это просто нерешённые частности такие на сегодняшний день. Точно такой же перекос, как тот, что был во времена записи программ в машинных кодах.
Я понял. Ты таки стремишься к созданию Универсальной Программы Всего и Вся, которая бы исключила всю эту "рутину, формально называемую программированием". Ну и как? Виден свет в конце тоннеля — или хотя бы сам тоннель обрел свои очертания из беграничного черного пространства возможных решений?
Здравствуйте, eao197, Вы писали:
E>Где ты видишь разницу? Сейчас везде говорят, что квалифицированных программистов нужно днем с огнем искать. В Москве, судя по обсуждениям в данном форуме, сейчас зарплаты начинающих программистов стартуют от 50-60т, а матерым платят по 120т. И все равно есть жалобы, что людей не хватает. Но при этом софт нужно писать постоянно, и с каждым днем все быстрее и быстрее, да чтобы лучше и дешевле. Все как в случае с Фордом. Поэтому-то большие оффшорные компании и внедряют у себя разные модели разработки, при которых рядовой программист становится винтиком -- много от него не нужно, да и заменить просто, а все, что он делает строго регламентированно.
хочу пару соображений добавить к правильным словам Геннадия
рядом: пока я собирался ответить он уже успел отметиться — и избавил меня от части соображений, спс
так вот, отцитированное Евгением возможно, если жить также как Форд все время чем-то одним — автомобилями. Про софт часто, даже про разные major релизы, нельзя сказать, что это один и тот же класс авто (если вообще авто). Если же полировать что-то одно — то таки да, можно заточить процесс производства под это одно — более того это так всегда и происходит. Причем и в продуктовых и в оффшорных компаниях, специализирующихся на чем-то конкретном или имеющих много заказов в одной области.
Сейчас покажу как: сначала наработки нарабатываются, потом их рефакторят в библиотеки для применения в похожих проектах\новых фичах и избавления от велосипедов, потом идет офрэймворчивание и стабилизация условного движка, потом уже новички не в курсе "как оно все это работает" (в недрах) просто потому что это им уже не нужно\не могут (старички уже давно в др местах, а сюда нанимают людей попроще и почаще, доучивают и ростят их дальше на месте), они пишут условно говоря плагины под фрэймворк, заодно и его в меру сил расширяют-допиливают-марафетят. Иногда это даже отражают в названиях команд — sustained teams в MSFT и прочие maintanance команды (не назову это легким трудом — встроить, не поломав тоже надо уметь). Имеем тот же конвейер. Абсолютно. Знаменитая RUP картинка под эту эволюцию нормально ложится.
Просто в нашем стремительном IT-мире конструкция относительно быстро устаревает (иногда морально, иногда технически — неважно. продажи закончились, конкуренты поджали и привет), а под новые технологии "как есть" переехать не выходит — и тогда начинается все по-новой: технология, наработки, фрэймворк, жесткая эксплуатация. Эволюция развивается по спирали — "все это я видел уже не раз" и т.п. Будьте любезны (с)
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
TL>Вот именно: формализация нужна разработчикам, чтобы "не приходилось следить за каждым словом, написанным обезьянкой".
Нет уж, господа. Формализация процесса нужна не разработчикам. Она нужна менеджменту. Чтобы видеть, что разработчик не в носу ковыряется, а чем-то занят. Неважно чем: он может быть занят чисто процессом. Даже не программировнаием. А именно процессом. В глазах менеджмента это значит, что разработчик работает. В то же время другой разработчик может "педалить код" (С) мегабайтами. Но не соблюдать процесс. В глазах менеджмента он — бездельник.
Здравствуйте, Valery A. Boronin, Вы писали:
VAB>Шумят же (те что поумнее) — как в другом анекдоте "чтобы денег не платить", большинство же как на стадио — глорят за компанию. Жалобы на дорогой бензин из той же оперы, это же не означает, что бензина нет. Просто демпинговые цены не каждый год стоят, а текущая цена складывается из вполне себе объективных факторов, она не виновата в том что высока или низка.
Я не могу судить о том, что происходит _реально_ в Москве и Новосибирске, но вот у нас в Гомеле толковых C++ников днем с огнем поискать. И не только C++ников: на наш небольшой город приходится несколько больших программистских контор (в том числе филиалы EPAm и BelIBA) + какое-то количество мелких + несколько крупных государственных контор. И еще масса народа (очень толкового) поуезжала в Москву и другие заграницы. В результате все мои знакомые жалуются на то, что поиск новых людей -- это постоянная головная боль. А я сам по крайней мере раз в год получаю предложения сменить работу.
Что же касается вашего призыва о сотрудничестве -- то я не говорил, что легко найти работу по душе. Это совсем другая история и я лично вас прекрасно понимаю.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Handie, Вы писали:
H>Без обид, но это напоминает басню "слон и моська". Человека, который учавствовал в создании Каиссы — победителя первого чемпионата мира по шахматам
Будь он хоть трижды победителем — это совсем не означает, что все, что он изрекает это абсолютная истина. Он был хорошим специалистом тогда, сейчас все изменилось.
... << RSDN@Home 1.2.0 alpha 4 rev. 1106 on Windows Vista 6.0.6001.65536>>
Здравствуйте, The Lex, Вы писали:
ГВ>>Сначала у нас небольшое производство, которое вполне обслуживается, скажем пятью квалифицированными кузнецами. [...] TL>Что делать, если необходимая квалификация кузнеца такова, что процент фермеров, таки достигших ее обучением, презренно мал?
Если ты не заметил, я не критикую подобный подход. Наоборот — естественный и разумный выход из положения.
ГВ>>Вторая ситуация. Тот же самые радиаторы. Но! Вместо того, чтобы заменить сотню вчерашних фермеров, например, станком с ЧПУ и парой операторов, мы разводим вакханалию [...] TL>Насчет "станков с ЧПУ" — лично я не понял.
В первом случае в производство вынужденно вовлекли низкоквалифицированный персонал. Во втором — сознательно ориентировались на низкую квалификацию, проигнорировав возможности её повышения. Выигрыш тут, в принципе, только условно-социальный: масса народу чем-то занята. ИМХО, Донской агитирует как раз за второй подход.
ГВ>>Всё как в случае с Фордом в нашей профессии не может быть по определению. Аналогии с механическим производством развенчивались даже на RSDN не один десяток раз. Форд должен был наращивать количество выпускаемой идентичной продукции. У нас стоимость именно экземпляра — копейка в базарный день (CD + электроэнергия на запись). Не одну и ту же программу ведь приходится писать по многу раз, верно?
TL>Да ну? Сайты. Формы. Очередное формирование очередного отчета. Не все звездолеты куют — вот ведь в чем вопрос — рутины "просто собирающей очередную готовую реализацию из готовых заготовок-фреймфоков-библиотек" — не просто валом — это чуть ли не есть основная задача программиста на сегодня. Чем ты ее заменить собираешься? Универсальным Решением Всего?
Если посмотреть в ретроспективе, то какой-то "рутины" в программировании всегда навалом. Например, та же разработка специальных БД для проектных команд, которая сейчас заменена средствами ведения проектов. В принципе, я тут имею в виду то, что повторяющаяся работа должна заменяться продуктами, которые устранят однообразие. Группы таких продуктов должны сменяться новыми продуктами, те — новым поколением опять по циклу и т.п. ИМХО, это и есть развитие.
Если хочешь, это моё Универсальное Решение Всего — постоянный процесс развития.
ГВ>>... Наша проблема состоит в необходимости аккумулировать знания о предметной, воплощая их в API, фреймворки, ОС, СУБД и т.п. Да, сейчас проблема базовых инструментов (те же ОС, СУБД, языки высокого уровня, фреймворки) более или менее разрешима. Но неужели ты считаешь, что нынешние, скажем, СУБД — вершина развития IT? По-моему, это только зачаточное состояние. У них даже метафоры использования недалеко ушли от книжной полки. TL>Ну дык Кесарю — Кесарево. (к) Кому — новые метафоры СУБД выдумывать, а кому — их реализовывать и поддерживать, а еще кому — уже реализацию в своих конкретным задачах использовать — и последним имя — легион.
Как тебе сказать... Я согласен с тем, что не все должны выдумывать СУБД (ОС, языки, ЭС...). Но если выдумщиков будет больше, больше будет и вариантов выбора. ИМХО, это — хорошо.
ГВ>>И кроме того, наличие формального процесса само по себе вовсе не означает, что можно снизить квалификацию сотрудников, хотя это заблуждение очень распространено даже среди менеджмента. TL>Снизить — нельзя — и нет такой цели. Ты и сам дальше пишешь: ГВ>>... Всё строго наоборот: формальный процесс как раз предъявляет очень высокие требования к абстрактному мышлению, а то придётся следить за каждым словом, написанным "обезьянкой". TL>А... нет. ГВ>>... По сути дела, формализация процессов нужна для помощи разработчикам TL>Вот именно: формализация нужна разработчикам, чтобы "не приходилось следить за каждым словом, написанным обезьянкой".
Я имел в виду квалифицированных разработчиков, которым и помогают формализованные процессы. От обезьяньих глупостей формальный процесс не спасёт никаким боком.
TL>Как современный компилятор современного языка сам следит за типами данных — при правильном подходе и примении инструмента конечно же — так и формальный процесс позволяет "реализовать один раз процесс и дальше не задумываться о том, тот ли код зачекинен и какую именно сборку мы сейчас вообще собираем" — и многое другое тоже. Формальный процесс — это та самая механизация и автоматизация многих рутинных операций очень объемного процесса создания очередного экземпляра программы. имхо.
Нет. Формальный процесс сам по себе ничего не автоматизирует, он только делит обязанности и приблизительно определяет структуру коммуникаций внутри команды. В этом разница между процессом и компилятором.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, SkyDance, Вы писали:
C>>Проблема в том, что если цена на программиста слишком высока — то многие компании просто физически не смогут его взять на работу. Ну не хватит денег просто. SD>В настоящее время у подавляющего большинства компаний проблемы найти дополнительные $15k в год нет.
Хороший программист будет стоит порядка $40k в год, а их ещё и несколько штук нужно. Так что небольшой отдел из трёх программистов запросто может потребовать все $150k в год. А это уже немало даже для средних компаний.
SD>Мешает жадность и... желание "манагеров" получать больше своих подчиненных. Иначе какой он тогда манагер, ага.
Не надо на компании и менеджеров гнать, большинство из них вполне адекватны.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, SkyDance, Вы писали:
C>>>Проблема в том, что если цена на программиста слишком высока — то многие компании просто физически не смогут его взять на работу. Ну не хватит денег просто. SD>>В настоящее время у подавляющего большинства компаний проблемы найти дополнительные $15k в год нет. C>Хороший программист будет стоит порядка $40k в год, а их ещё и несколько штук нужно. Так что небольшой отдел из трёх программистов запросто может потребовать все $150k в год. А это уже немало даже для средних компаний.
SD>>Мешает жадность и... желание "манагеров" получать больше своих подчиненных. Иначе какой он тогда манагер, ага. C>Не надо на компании и менеджеров гнать, большинство из них вполне адекватны.
Sash_xp пишет: > > Если хотите, вы можете еще долго издеваться над уважаемым человеком и > обсуждать как правильно писать голландские фамилии, но правоту идеи этой > статьи о "мельчании" программистов наверняка отлично осознает каждый.
Смешно. Статейка исключительно в стиле, эх когда я был молодой девки так
и падали, а сейчас я старенький.
eao197 пишет: > > Я не могу судить о том, что происходит _реально_ в Москве и > Новосибирске, но вот у нас в Гомеле толковых C++ников днем с огнем > поискать. И не только C++ников: на наш небольшой город приходится > несколько больших программистских контор (в том числе филиалы EPAm и > BelIBA) + какое-то количество мелких + несколько крупных государственных > контор.
Откуда он вдруг возьмется в вашем городе?
И если возьмется, что в вашем г. Гомеле делать толковому С++-нику?
Ну еще в дополнение, как с экологией-то?
> И еще масса народа (очень толкового) поуезжала в Москву и другие > заграницы. В результате все мои знакомые жалуются на то, что поиск новых > людей -- это постоянная головная боль. А я сам по крайней мере раз в год > получаю предложения сменить работу.
И правильно сделали.
P.S. Ты бы озвучил, сколько вы платите С++-снику в вашем городе
AVK>Будь он хоть трижды победителем — это совсем не означает, что все, что он изрекает это абсолютная истина. Он был хорошим специалистом тогда, сейчас все изменилось.
Бывших хороших специалистов не бывает, как не бывает быших Олимпийских чемпионов.
Ничего не изменилось, тогда нужны были люди с мозгами и сейчас нужны.
Здравствуйте, AndrewVK, Вы писали:
TL>>Я понял. Ты таки стремишься к созданию Универсальной Программы Всего и Вся, которая бы исключила всю эту "рутину, формально называемую программированием".
AVK>Ложная посылка. Для того чтобы избавится от рутины, совершенно необязательно создавать "Универсальную Программу Всего и Вся".
Здравствуйте, The Lex, Вы писали:
TL>Предлагай другой метод.
Универсального метода всего и вся тоже не существует. В каждом конкретном случае нужны свои решения. И средства разработки таки постоянно эволюционируют в этом направлении.
... << RSDN@Home 1.2.0 alpha 4 rev. 1106 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>В первом случае в производство вынужденно вовлекли низкоквалифицированный персонал. Во втором — сознательно ориентировались на низкую квалификацию, проигнорировав возможности её повышения. Выигрыш тут, в принципе, только условно-социальный: масса народу чем-то занята. ИМХО, Донской агитирует как раз за второй подход.
Еще раз: "принцев мало и на всех их не хватает" — априори не хватает — чисто практически никак не получается воспитать нужное количество высококвалифицированных — стремиться к недостижимой цели (попутно раскручивая колесо роста зарплат в отрасли) или решать задачи доступными средствами?
TL>>Да ну? Сайты. Формы. Очередное формирование очередного отчета. Не все звездолеты куют — вот ведь в чем вопрос — рутины "просто собирающей очередную готовую реализацию из готовых заготовок-фреймфоков-библиотек" — не просто валом — это чуть ли не есть основная задача программиста на сегодня. Чем ты ее заменить собираешься? Универсальным Решением Всего?
ГВ>Если посмотреть в ретроспективе, то какой-то "рутины" в программировании всегда навалом. Например, та же разработка специальных БД для проектных команд, которая сейчас заменена средствами ведения проектов. В принципе, я тут имею в виду то, что повторяющаяся работа должна заменяться продуктами, которые устранят однообразие. Группы таких продуктов должны сменяться новыми продуктами, те — новым поколением опять по циклу и т.п. ИМХО, это и есть развитие.
имхо, нет смысла менять работающее старое на что-то новое, руководствуясь только лишь новизной последнего.
ГВ>Если хочешь, это моё Универсальное Решение Всего — постоянный процесс развития.
Именно! Но развитие ради развития, тем ни менее, все еще не дает решения всей той массы рутинных насущных задач, которыми сегодня занимаются программисты. Я думаю здесь дело больше в "профессиональной обиде" тех, кто занимается прогрессом и развитием, что и их, и "рутинных клепальщиков" одинаково называют "программистами": бухгалтер тоже работает с цифрами, но математиком его не считают — программисты же и там, и там — наверное математикам-программистам некошерно стоять как бы рядом с программистами-бухгалтерами.
ГВ>Как тебе сказать... Я согласен с тем, что не все должны выдумывать СУБД (ОС, языки, ЭС...). Но если выдумщиков будет больше, больше будет и вариантов выбора. ИМХО, это — хорошо.
Да? Ну... Не знаю насколько "хорошо", но точно знаю, что работа "непосредственным внедряльщикам уже выдуманных СУБД" всегда есть и ее всегда много.
ГВ>>>... По сути дела, формализация процессов нужна для помощи разработчикам TL>>Вот именно: формализация нужна разработчикам, чтобы "не приходилось следить за каждым словом, написанным обезьянкой".
ГВ>Я имел в виду квалифицированных разработчиков, которым и помогают формализованные процессы. От обезьяньих глупостей формальный процесс не спасёт никаким боком.
"Обезьянни глупости" может допускать и "квалифицированный" — вся эта формализация позволяет сильно продвинуть процесс "спасания от", так же как современные редакторы кода сильно эффективнее старинного набивания перфокарт. имхо.
ГВ>Нет. Формальный процесс сам по себе ничего не автоматизирует, он только делит обязанности и приблизительно определяет структуру коммуникаций внутри команды. В этом разница между процессом и компилятором.
Это смотря как относится к формальному процессу. Я отношусь к нему, как к компилятору: идеи и процесс их реализации тут же проходят проверку на формальную допустимость и вместе с тем дают инструмент для управления и выявления ошибок и "дополнительных путей" — все вместе дает внятную и формально понятную картину "что где и как происходит и что мы в данный момент вообще делаем" — а также позволяет избегать накопления мелких ошибок, так или иначе связанных с вероятной неупорядоченностью отдельных этапов процесса. Я, конечно, хорошо понимаю что гений может естественным путем поддерживать свой собственный жесткий порядок или же творческий беспорядок и все равно эффективно "двигать процесс" — но я не гений и опираться на то, что работать придется исключельно с гениями тоже не получается.
Здравствуйте, Vzhyk, Вы писали:
>> Я не могу судить о том, что происходит _реально_ в Москве и >> Новосибирске, но вот у нас в Гомеле толковых C++ников днем с огнем >> поискать. И не только C++ников: на наш небольшой город приходится >> несколько больших программистских контор (в том числе филиалы EPAm и >> BelIBA) + какое-то количество мелких + несколько крупных государственных >> контор. V>Откуда он вдруг возьмется в вашем городе?
Вырастет.
<реклама on>
В Гомель из Новосибирска в конце 70-х было переведено КБ Системного Программирования. Куда впоследствии распределялись выпускники ВУЗ-ов из Москвы, Питера и Минска. В последствии на математическом факультете местного университета была открыта специализация "прикладная математика" и две кафедры, занимающимися подготовкой программистов специально для КБСП (изрядная доля преподавателей на этих кафедрах была выходцами из КБСП). При разработке советской ПРО половина софта для радиолокационных станций раннего оповещения и ведения перехвата была создана в КБСП.
На момент 1991-1992 (т.е. апогея работ по этой теме) в КБСП работало порядка 1200 программистов. После распада Союза большая их часть разбежалась, кто вернулся в Москву, кто в Новосибирск. Но некоторая часть осталась, организовав собственные фирмы и фирмочки. Плюс к тому каждый год ВУЗы выпускают по 50-75 программистов.
<реклама off>
V>И если возьмется, что в вашем г. Гомеле делать толковому С++-нику?
Работать. Работы море -- на 99.9% оффшор.
V>Ну еще в дополнение, как с экологией-то?
Вроде как Чернобыль не так уж и далеко, но вряд ли сильно хуже, чем в Москве.
V>И правильно сделали.
Все не могут уехать по определению. У многих моих знакомых с квартирным вопросом все нормально, поэтому и не спешат куда-либо переезжать.
V>P.S. Ты бы озвучил, сколько вы платите С++-снику в вашем городе
Года полтора-два назад ведущему программисту (Java) мы предлагали порядка $1200. С тех пор зарплаты ощутимо подрасли и продолжают расти (с 2002 по 2008 зарплата программистов в Гомеле вырасла где-то в 5 раз). Например, сейчас аренда 2-х комнатной квартиры -- это порядка $150-200, год назад были в два раза меньше.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndrewVK, Вы писали:
TL>>Предлагай другой метод.
AVK>Универсального метода всего и вся тоже не существует. В каждом конкретном случае нужны свои решения. И средства разработки таки постоянно эволюционируют в этом направлении.
Угму. Ну как только сможем "заменить обезьянок роботами" — тут же и я соберусь на пенсию и буду на берегу моря вино попивать... Пока же — "обезьянка — самый незаменимый человек индустрии".
Здравствуйте, The Lex, Вы писали:
TL>Здравствуйте, AndrewVK, Вы писали:
TL>>>Предлагай другой метод.
AVK>>Универсального метода всего и вся тоже не существует. В каждом конкретном случае нужны свои решения. И средства разработки таки постоянно эволюционируют в этом направлении.
TL>Угму. Ну как только сможем "заменить обезьянок роботами" — тут же и я соберусь на пенсию и буду на берегу моря вино попивать... Пока же — "обезьянка — самый незаменимый человек индустрии".
Ммм, если заменишь их не ты, то и вино на берегу моря тоже будет другой человек попивать
Здравствуйте, The Lex, Вы писали:
TL>Угму. Ну как только сможем "заменить обезьянок роботами" — тут же и я соберусь на пенсию и буду на берегу моря вино попивать...
А ты обезьянкой, что ли, работаешь?
TL> Пока же — "обезьянка — самый незаменимый человек индустрии".
Ага, ИНДУСтрии.
... << RSDN@Home 1.2.0 alpha 4 rev. 1106 on Windows Vista 6.0.6001.65536>>
Здравствуйте, LaptevVV, Вы писали:
LVV>Тут разделение образования на 2 ступени — как раз на руку. Первая бакалаврская ступень массово готовит "рутинных" программистов. А вот вторая — магистерская — ее бы как раз хорошо заточить под глубину. Учитывая, что после 2 лет магистра еще 3-4 года аспирантуры — вот как раз и можно готовить глубоких спецов. И таких, естественно, не в массовом порядке, как бакалавров, а в единичных экземплярах...
Тяжело разбить программу таким образом, чтобы это осуществить. Например, спецальная математическая подготовка не нужна бакалаврам, но если взять паузу в несколько лет, то магистрам ее осваивать будет намного сложнее.
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, LaptevVV, Вы писали:
LVV>>Тут разделение образования на 2 ступени — как раз на руку. Первая бакалаврская ступень массово готовит "рутинных" программистов. А вот вторая — магистерская — ее бы как раз хорошо заточить под глубину. Учитывая, что после 2 лет магистра еще 3-4 года аспирантуры — вот как раз и можно готовить глубоких спецов. И таких, естественно, не в массовом порядке, как бакалавров, а в единичных экземплярах...
M>Тяжело разбить программу таким образом, чтобы это осуществить. Например, спецальная математическая подготовка не нужна бакалаврам, но если взять паузу в несколько лет, то магистрам ее осваивать будет намного сложнее.
Да, я это давно отметил... Бакалаврская программа обучения усеченная, облегченная и обрезанная.... Как народ в магистрах глубокие вещи изучать будет без глубокой базовой подготовки — фиг знает...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
eao197 пишет: > > V>Откуда он вдруг возьмется в вашем городе? > > Вырастет. > <реклама on>
<skip> > <реклама off>
Эх, много чего было в 70-е и 80-е. Но вот сейчас, все изменилось сильно.
И старыми заслугами уже смешно хвастаться.
А образование, согласись уровень БГУ и MРТИ превосходит гомельских в
среднем.
> > Работать. Работы море -- на 99.9% оффшор.
Но в Минске же больше выбор и контор и заплатят больше, селяви, и работы
больше. А до Гомеля из Минска рукой подать, если маму с папой навестить
надо.
> > Вроде как Чернобыль не так уж и далеко, но вряд ли сильно хуже, чем в > Москве.
Да я не про Москву... А про него, про Чернобыль и грибочки за грибниками
бегающие .
> > V>И правильно сделали. > > Все не могут уехать по определению. У многих моих знакомых с квартирным > вопросом все нормально, поэтому и не спешат куда-либо переезжать.
Но молодежь все одно в столицы едет или еще дальше. Можешь поговорить с
ними, объяснят, причин много.
> > V>P.S. Ты бы озвучил, сколько вы платите С++-снику в вашем городе > > Года полтора-два назад ведущему программисту (Java) мы предлагали > порядка $1200.
Ладно, про Яву. Но почему тогда есть у меня знакомые и немало и из
Гомеля в т.ч., которые в Минске оседают, даже квартиру снимая?
Что ж им в Гомеле не нравиться?
Здравствуйте, Vzhyk, Вы писали:
>> V>Откуда он вдруг возьмется в вашем городе? >> >> Вырастет. >> <реклама on> V><skip> >> <реклама off> V>Эх, много чего было в 70-е и 80-е. Но вот сейчас, все изменилось сильно. V>И старыми заслугами уже смешно хвастаться.
Тем не менее, школа-то осталась.
V>А образование, согласись уровень БГУ и MРТИ превосходит гомельских в V>среднем.
А так всегда было и будет. Обычная разница между столицей и не столицей.
>> Работать. Работы море -- на 99.9% оффшор. V>Но в Минске же больше выбор и контор и заплатят больше, селяви, и работы V>больше. А до Гомеля из Минска рукой подать, если маму с папой навестить V>надо.
Что-то не так уж много народу из Гомеля в Минск съезжают. Даже из тех кто там учился. Тем более, что в совковой Беларуссии, имхо, без особой разницы, где жить -- в Гомеле или Минске.
V>Но почему тогда есть у меня знакомые и немало и из V>Гомеля в т.ч., которые в Минске оседают, даже квартиру снимая? V>Что ж им в Гомеле не нравиться?
Провинция со всеми вытекающими.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
LaptevVV пишет: > > Тут разделение образования на 2 ступени — как раз на руку. Первая > бакалаврская ступень массово готовит "рутинных" программистов. А вот > вторая — магистерская — ее бы как раз хорошо заточить под глубину. > Учитывая, что после 2 лет магистра еще 3-4 года аспирантуры — вот как > раз и можно готовить глубоких спецов. И таких, естественно, не в > массовом порядке, как бакалавров, а в единичных экземплярах...
Утопист ты
eao197 пишет: > > V>Эх, много чего было в 70-е и 80-е. Но вот сейчас, все изменилось сильно. > V>И старыми заслугами уже смешно хвастаться. > > Тем не менее, школа-то осталась.
Не могла она остаться. Дедушки по 70 лет — это не школа. (говорю, что
сам плотно с оным столкнулся и на своей собственной шкуре видел, как
неспеша загибалась научная беларуская школа по одному из научных
направлении, кстати одному из неплохо финансируемых у америкосов и
загнулась, фактически — осталось только хвастаться своими достижениями
30-20 летней давности)
> > V>А образование, согласись уровень БГУ и MРТИ превосходит гомельских в > V>среднем. > > А так всегда было и будет. Обычная разница между столицей и не столицей.
Причина, оттока умных ребят, так? А в беларуси всего-то 10 миллионов
населения.
> > Что-то не так уж много народу из Гомеля в Минск съезжают. Даже из тех > кто там учился. Тем более, что в совковой Беларуссии, имхо, без особой > разницы, где жить -- в Гомеле или Минске.
Разница есть. Говорю по знакомым не минчанам. Ну и ты сам говоришь, что
разработчиков нет, уезжают (отмотай посты назад).
> > Провинция со всеми вытекающими.
Вот видишь.
Здравствуйте, Vzhyk, Вы писали:
>> V>Эх, много чего было в 70-е и 80-е. Но вот сейчас, все изменилось сильно. >> V>И старыми заслугами уже смешно хвастаться. >> >> Тем не менее, школа-то осталась. V>Не могла она остаться. Дедушки по 70 лет — это не школа. (говорю, что V>сам плотно с оным столкнулся и на своей собственной шкуре видел, как V>неспеша загибалась научная беларуская школа по одному из научных V>направлении, кстати одному из неплохо финансируемых у америкосов и V>загнулась, фактически — осталось только хвастаться своими достижениями V>30-20 летней давности)
Мне довелось поработать с людьми, которым тогда было от 30 до 40, а сейчас им от 40 до 55.
>> V>А образование, согласись уровень БГУ и MРТИ превосходит гомельских в >> V>среднем. >> >> А так всегда было и будет. Обычная разница между столицей и не столицей. V>Причина, оттока умных ребят, так? А в беларуси всего-то 10 миллионов V>населения.
По твоему все умные стараются уехать?
Я вижу не такую картину. Не все уезжающие умные, не все остающиеся дураки.
>> Что-то не так уж много народу из Гомеля в Минск съезжают. Даже из тех >> кто там учился. Тем более, что в совковой Беларуссии, имхо, без особой >> разницы, где жить -- в Гомеле или Минске. V>Разница есть. Говорю по знакомым не минчанам. Ну и ты сам говоришь, что V>разработчиков нет, уезжают (отмотай посты назад).
Ну ладно у нас уезжают (далеко не все, самых толковых молодых специалистов расхватывают еще во время учебы). Но и из Москву уже уезжают. Причем в провинцию.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197 пишет: > >> > V>Эх, много чего было в 70-е и 80-е. Но вот сейчас, все изменилось > сильно. > V>30-20 летней давности) > > Мне довелось поработать с людьми, которым тогда было от 30 до 40, а > сейчас им от 40 до 55.
Это как с 70-х, 80-х прошло минимум 19 лет. Т.е. от 49 до 59 уже в
лучшем случае. А школа-то не на одном 10-летии строится, идеально, когда
внее есть люди профессионалы из каждого возрастного десятилетия и
желательно не по одному.
> > По твоему все умные стараются уехать? > Я вижу не такую картину. Не все уезжающие умные, не все остающиеся дураки.
Нет, это ты так пишешь. Уезжают активные и амбициозные в первую очередь,
а среди этих умных ребят больше обычно.
А почему уезжают ты уже сам в нескольких постах написал причины.
Здравствуйте, Cyberax, Вы писали:
VAB>>Жалобы на дорогой бензин из той же оперы, это же не означает, что бензина нет. Просто демпинговые цены не каждый год стоят, а текущая цена складывается из вполне себе объективных факторов, она не виновата в том что высока или низка. C>Проблема в том, что если цена на программиста слишком высока — то многие компании просто физически не смогут его взять на работу. Ну не хватит денег просто.
Потрясающей глубины вывод. 2+2=4. И?
А вообще нет и не было цели чтобы все компании могли физически взять на работу всех. Это еще зачем Вы придумали?
чтобы было понятнее, о чем было написано — Вы вот лучше попробуйте в след раз на АЗС заправить полный бак за полцены, мотивируя это дело схожим образом. Мол до дома иначе не доеду. Физически. Успехов в этом нелегком деле... потом можно будет пожаловаться про отсутствие бензина \за желаемую цену — напомню\ опять же.
C>Если бы был избыток кадров, то такой проблемы бы не было.
ну зачем уходить "в если бы да кабы"?
есть конкретная и вполне нормальная, обычная ситуация.
я бы сказал больше — стандартная жизненная. Субж.
Просто не понимаю зачем поднимать такой шум вокруг этого
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, Cyberax, Вы писали:
SD>>В настоящее время у подавляющего большинства компаний проблемы найти дополнительные $15k в год нет. C>Хороший программист будет стоит порядка $40k в год, а их ещё и несколько штук нужно. Так что небольшой отдел из трёх программистов запросто может потребовать все $150k в год.
опять 25. Это все совершенно разговоры ни о чем. Что, если подумать немного шире?
В одной предместной области рэйты от 5 уе потолок, в другой 300 на старте. Позиции, обязанности и ответственность разная... география... Риски разные... бизнес опять же в разных цифрах меряется. У кого 10 тыр в мес на кону, у кого потенциально миллиард уе в год. О чем тут судить\рядить, да еще в абсолютных цифрах?
Понятно что исходя из возможностей решают вопрос с кадрами — разве об этом была речь? SD написал о ситуации, когда возможности — есть, однако жабец поддавливает или еще какие соображения играют — отчего в конечном счете частенько проигрывают все.
C>А это уже немало даже для средних компаний.
ну так немало обычно и доход получается от толковых людей, надо полагать. Почему об этом не шумим?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, Vzhyk, Вы писали:
>>> > V>Эх, много чего было в 70-е и 80-е. Но вот сейчас, все изменилось >> сильно. >> V>30-20 летней давности) >> >> Мне довелось поработать с людьми, которым тогда было от 30 до 40, а >> сейчас им от 40 до 55. V>Это как с 70-х, 80-х прошло минимум 19 лет. Т.е. от 49 до 59 уже в V>лучшем случае. А школа-то не на одном 10-летии строится, идеально, когда V>внее есть люди профессионалы из каждого возрастного десятилетия и V>желательно не по одному.
Там были люди очень разного возраста. Я работал в отделе, где разброс возрастов был от 21 до 40-ка с хвостиком.
>> По твоему все умные стараются уехать? >> Я вижу не такую картину. Не все уезжающие умные, не все остающиеся дураки. V>Нет, это ты так пишешь. Уезжают активные и амбициозные в первую очередь,
Амбициозные в первую очередь.
V>а среди этих умных ребят больше обычно.
Снобизмом попахивает однако
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Valery A. Boronin, Вы писали:
VAB>Если разбирать картину выше объективно, можно снова отметить, как костеря нехватку толковых людей Вы не указали ни что есть "очень толковый" в Гомельском понимании (ну это ладно), ни уровень с которого бегут (правда, вижу что дали какие-то цифры позже), ни других объективных критериев.
"Очень толковый" в нашем понимании -- это практически то же, что "очень толковый" в Москве, только без понтов. На счет понтов я серьезно говорю, т.к. по работе приходится общаться с товарищами из Москвы -- там очень много распальцовки и перевода стрелок (причем не могу сказать, что к этому склонны исключительно москвичи, "понаехавшие" в этом преуспевают не меньше).
VAB>Но пожаловались, сославшись на столь авторитетный источник как "все знакомые".
В маленьком городе это более достоверный источник, чем изучение списков вакансий
VAB>Тем не менее, можно легко прийти к выводу что чтобы удержать толковый народ на месте, с учетом всех местных плюсов\минусов — указанных ниже по ветке цифр уже недостаточно. Что же делать? Вероятно, нужно раскошелиться. Хорошо раскошелитесь\создадите условия — из Москвы потянутся уже к вам. Что тут необычного или заслуживающего набивших оскомину стенаний?
Ничего не обычного. Просто вот что происходит: смотрю на происходящее у нас и вижу, что не хватает людей, даже при том, что зарплаты все время растут. Ладно, думаю, все умные от нас уехали, нам дуракам никак не справится со своими тупыми мозгами и пустыми кошельками. Потом мне пишут из Питера -- мол давай к нам, проекты интересные, деньги нормальные, а людей нет. О как думаю, совпаденьеце. Потом то же самое начинают писать из Москвы. Потом из США. Тенденция, однако. Потом смотрю в местные форумы объявлений о работе и вижу объявления с множеством ответов из одного слова "up", причем фирмы так же не Гомельские и даже не Минские.
VAB>Тем более что речь идет не о том чтобы поднять условия всем вокруг в штате и за штатом — а лишь тем, кто нужен на ключевых позициях, обладает необходимым знанием\опытом для проекта\команды\компании, кто реально делает дело и в конечном счете поможет остальным вырости, вместо сбегания в столицы (не думаю что все у вас бегут лишь по причине условий), заодно повысив капитализацию компании. Это не так редко даже дешевле стоимости поиска адекватной замены, не говоря уже о том чтобы впрячь замену в процесс — кому же лучше от такого "держания рынка" любой ценой? Загнали себя в угол и оттуда стонем.
А этот абзац вообще о чем?
VAB>PS Конечно, сочувствовать испытывающим кадровый голод легко, где-то даже поможет добрать вистов, однако я предпочитаю решать проблемы вместо их бесполезного обмусоливания. Посему вот такое мое суровое ИМХО выше.
Не обижайтесь, но для человека, который опубликовал свое резюме в поисках работы, ваше суровое ИМХО слишком суровое.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, minorlogic, Вы писали:
M>Жти жалобы мне напоминают картину , стоят рыбаки и жалуются "и почему рыба сама не прыгает в ведро ? приходится удочки таскать и т.п. "
M>РЫНОК это!
В каждом сегменте рынка свой масштаб цен. Если начать платить в Гомеле московские зарплаты, то это не приведет ни к притоку программистов, ни к сохранению выгод от размещения разработки вне Москвы.
А так в рамках существующего у нас масштаба цен ведется обычная рыночная возня. Где ни один крупный игрок пока не сделал серьезного "хода конем" и не подмял рынок под себя.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197 пишет: > > > Там были люди очень разного возраста. Я работал в отделе, где разброс > возрастов был от 21 до 40-ка с хвостиком.
Ну коль они там и остались, желаю успехов "порвать всех".
> > V>Нет, это ты так пишешь. Уезжают активные и амбициозные в первую очередь, > > Амбициозные в первую очередь. > > V>а среди этих умных ребят больше обычно. > > Снобизмом попахивает однако
Ой, да господь с тобой. Еще не хватало. Просто, если поувлекаешься
психологией, организацией процессов мышления (хотя бы тем, что о них
сейчас уже известно) сам увидишь.
eao197 пишет: > > > В каждом сегменте рынка свой масштаб цен. Если начать платить в Гомеле > московские зарплаты, то это не приведет ни к притоку программистов, ни к > сохранению выгод от размещения разработки вне Москвы.
А какие выгоды от размещения в Москве?
И как это не приведет? Если в Гомеле хотя бы от 2000 платить начнете,
думаю, из Минска многие к вам точно поедут (особенно молодые и
амбициозные — а на них то много держится).
Вот так и представляю беларуская силиконовая долина в Гомеле со своим
домом отдыха на Соже.
> > А так в рамках существующего у нас масштаба цен ведется обычная рыночная > возня. Где ни один крупный игрок пока не сделал серьезного "хода конем" > и не подмял рынок под себя.
Продолжайте играйться.
Здравствуйте, The Lex, Вы писали:
TL>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>В первом случае в производство вынужденно вовлекли низкоквалифицированный персонал. Во втором — сознательно ориентировались на низкую квалификацию, проигнорировав возможности её повышения. Выигрыш тут, в принципе, только условно-социальный: масса народу чем-то занята. ИМХО, Донской агитирует как раз за второй подход.
TL>Еще раз: "принцев мало и на всех их не хватает" — априори не хватает — чисто практически никак не получается воспитать нужное количество высококвалифицированных — стремиться к недостижимой цели (попутно раскручивая колесо роста зарплат в отрасли) или решать задачи доступными средствами?
Стремиться к недостижимой цели. Только так и не иначе. Общее направление должно быть именно таким, иначе сваримся в собственном соку и не заметим. В сущности, чем лоботомия не рецепт к счастью?
ГВ>>Если посмотреть в ретроспективе, то какой-то "рутины" в программировании всегда навалом. Например, та же разработка специальных БД для проектных команд, которая сейчас заменена средствами ведения проектов. В принципе, я тут имею в виду то, что повторяющаяся работа должна заменяться продуктами, которые устранят однообразие. Группы таких продуктов должны сменяться новыми продуктами, те — новым поколением опять по циклу и т.п. ИМХО, это и есть развитие.
TL>имхо, нет смысла менять работающее старое на что-то новое, руководствуясь только лишь новизной последнего.
Не надо подменять мой тезис. Угу? Я нигде о новизне ради новизны не говорил.
ГВ>>Если хочешь, это моё Универсальное Решение Всего — постоянный процесс развития. TL>Именно! Но развитие ради развития, тем ни менее, все еще не дает решения всей той массы рутинных насущных задач, которыми сегодня занимаются программисты.
Вот ради удаления этих самых рутинных задач и имеет смысл уходить на следующий виток развития.
TL>Я думаю здесь дело больше в "профессиональной обиде" тех, кто занимается прогрессом и развитием, что и их, и "рутинных клепальщиков" одинаково называют "программистами": бухгалтер тоже работает с цифрами, но математиком его не считают — программисты же и там, и там — наверное математикам-программистам некошерно стоять как бы рядом с программистами-бухгалтерами.
...а не пестовать профессиональные обиды.
ГВ>>Как тебе сказать... Я согласен с тем, что не все должны выдумывать СУБД (ОС, языки, ЭС...). Но если выдумщиков будет больше, больше будет и вариантов выбора. ИМХО, это — хорошо.
TL>Да? Ну... Не знаю насколько "хорошо", но точно знаю, что работа "непосредственным внедряльщикам уже выдуманных СУБД" всегда есть и ее всегда много.
Вот ещё раз. Давай не будем путать лошадь и телегу. Лошадь — продукты. Телега — внедренцы. Будут продукты, появятся и внедренцы.
TL>"Обезьянни глупости" может допускать и "квалифицированный" — вся эта формализация позволяет сильно продвинуть процесс "спасания от", так же как современные редакторы кода сильно эффективнее старинного набивания перфокарт. имхо.
Никакой связи и неправильная аналогия. Согласен только с тем, что глупости могут делать и квалифицированные специалисты.
ГВ>>Нет. Формальный процесс сам по себе ничего не автоматизирует, он только делит обязанности и приблизительно определяет структуру коммуникаций внутри команды. В этом разница между процессом и компилятором.
TL>Это смотря как относится к формальному процессу.
Я подразумеваю (а не отношусь!) под термином "формальный процесс" прежде всего набор обязанностей и набор разновидностей документов. Главное — обязанности.
TL>Я отношусь к нему, как к компилятору: идеи и процесс их реализации тут же проходят проверку на формальную допустимость и вместе с тем дают инструмент для управления и выявления ошибок и "дополнительных путей" — все вместе дает внятную и формально понятную картину "что где и как происходит и что мы в данный момент вообще делаем" — а также позволяет избегать накопления мелких ошибок, так или иначе связанных с вероятной неупорядоченностью отдельных этапов процесса.
Каша какая-то. "Формальная допустимость идей" — это что за анимал такой?
TL>Я, конечно, хорошо понимаю что гений может естественным путем поддерживать свой собственный жесткий порядок или же творческий беспорядок и все равно эффективно "двигать процесс" — но я не гений и опираться на то, что работать придется исключельно с гениями тоже не получается.
Ты не путай устойчивые обороты типа "двигать процесс" и собственно "формальный процесс", как таковой.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, eao197, Вы писали:
E>Думаю, что когда в программировании придумают инструменты, которые способны заменить человека для исправления ошибок вида "поехало форматирование в форме NNN под Opera 9.5 на SuSe Linux" или решения задач вида "добавить общее количество страниц в нижний колонтитул каждой печатоемой страницы отчетов RRR/ZZZ/XXX", то это обязательно сделают.
Так здесь как раз поле для удаления "рутины".
E>Я говорил не про фреймворк, а про создание кластерного приложения для решения какой-нибудь прикладной задачи.
Ну ты сам говоришь, что такое приложение легко пишется сборкой стандартных компонентов. А я, в свою очередь, предполагаю, что на одном фреймворке (наборе компонентов) свет клином не сошёлся. Был один, появится и второй.
ГВ>>Я уверен, что уже кто-то долбит. Только боюсь, что не в наших пенатах. E>Ну так о том и речь. Что у нас вряд ли что-нибудь изменится, поскольку передовые разработки в околосистемных областях ведутся на Западе и у нас просто недостаточно людей, которые знают о чем идет речь. А уж скольких из них можно будет привлечь к системе образования -- это вообще смешно.
Да не так это сложно. СУБД, ОС и прочее — не такие уж и сложные программы, во всяком случае, представленные в виде курсовых. Проблема в другом — нет явного "социального заказа" на таких специалистов. Зато полным-полно нытья, что программирование становится рутинным.
Ну и ещё большая проблема в том, что СУБД и ОС — это лишь частности от более абстрактных штучек. Собственно, вот это — тоже беда, потому что даже натаскав на разработку СУБД всё равно получим мастера-разработчика СУБД, а не программиста-генератора абстракций. Кстати, это ещё один изъян в рассуждениях М.Д., ну тут простительно — технарь, как-никак.
E>Да ладно, Гена. Это всегда было известно -- пара-тройка ВУЗ-ов в Москве + по одному-два ВУЗа в крупных городах (т.к. Питер, Минск, Киев, Новосибирск и т.д.). Те ВУЗы, которые неподалеку (в родном городе или в паре-тройке часов от родного города) они, как правило, одипломнивают биомассу. Но изрядная доля работающих сейчас программистов как раз и является продуктом как раз таких ВУЗов.
Во-первых, я говорил не о том, а во-вторых — вокруг много плохих программистов, мне это отлично известно. Что с того? Это не означает, что подобное status quo есть хорошо. Это очень, очень плохо. И это ни в коем случае не означает, что под них нужно равнять стандарты профессии.
ГВ>>А потом, прямая обязанность учебного заведения — объяснить сложные вещи доступным языком, сиречь — научить. Научили же нас писать программы. E>Имхо, те, кто этому научился, научились этому самостоятельно.
На самом деле это синтез системы образования и личных склонностей студентов. Как правило, когда мы говорим, что в вузе "учатся самостоятельно", то имеем в виду, что диапазон возможностей у студента шире, чем у школьника. И в силу преподавательской базы, и в силу возраста, да ещё масса факторов. Так что, не сильно-то спекулируй на самостоятельности. Она, конечно, играет роль, но вуз нельзя сбрасывать со счетов.
ГВ>>Ты всё ещё не видишь различий?
E>Не-а.
Хм. Что, совсем? Ты не видишь разницу, что в первом случае основополагающим было желание развить производство, а во втором — впитать людскую массу, ограничив её развитие?
E>Очень похоже на то, что сейчас я вижу вокруг себя. Людей в ВУЗах (провинциальных, как в столичных я не знаю) учат отличать соху от телеги, не более того. После чего они идут в филиалы оффшорных компаний, начинают клепать JSP-странички или еще что-то трудоемкое, но не сильно заумное. Кто-то из них, естественно, растет и со временем становится классным специалистом. Но таких не много. Имхо, процент классных программистов всегда был одинаков. Но вот в абсолютном выражении количество тех программистов, которым для нормальной жизни не приходится заниматься серьезными задачами растет.
Спасибо, что поделился наблюдениями. Да, как раз — второй подход. Но это плохо и противоречит самой сути программирования.
E>>>Сейчас везде говорят, что квалифицированных программистов нужно днем с огнем искать. В Москве, судя по обсуждениям в данном форуме, сейчас зарплаты начинающих программистов стартуют от 50-60т, а матерым платят по 120т. И все равно есть жалобы, что людей не хватает. Но при этом софт нужно писать постоянно, и с каждым днем все быстрее и быстрее, да чтобы лучше и дешевле. Все как в случае с Фордом.
ГВ>>Всё как в случае с Фордом в нашей профессии не может быть по определению. Аналогии с механическим производством развенчивались даже на RSDN не один десяток раз. Форд должен был наращивать количество выпускаемой идентичной продукции.
E>Я понимаю, что прямая аналогия не возможна, что все-таки ситуация похожа: приходится наращивать выпуск почти идентичной продукции. По крайней мере временами складывается впечатление, что вокруг успешной разработки постоянно оказывается масса мелких и, вроде бы, простеньких задачек, [...] Это не конвейер, как у Форда, но очень уж похоже на рутину.
Ну, на мой взгляд, не так уж и много рутины, и тем более — совсем не похоже на фордовский конвейер. Обычная, в чём-то неизбежная проблема с настройками и мелкими доработками. На таких подзадачках можно передохнуть, в общем-то. Но ведь к ним одним вся профессия-то не сводится, верно? Ты же сам пишешь, что такой работой обрастает успешная разработка. Но эту-то разработку кто-то должен первоначалаьно сделать, правда?
ГВ>>Встречный вопрос: ты сам-то веришь в то, что можно в нашей работе что-то "строго регламентировать" кроме элементарных процедурных моментов? Ну, типа, обязательно зачекинить код в конце рабочего дня? Я вот не вижу такой возможности.
E>Нет, не верю.
Вот и я не верю.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, eao197, Вы писали:
E>"Очень толковый" в нашем понимании -- это практически то же, что "очень толковый" в Москве, только без понтов. На счет понтов я серьезно говорю, т.к. по работе приходится общаться с товарищами из Москвы -- там очень много распальцовки и перевода стрелок (причем не могу сказать, что к этому склонны исключительно москвичи, "понаехавшие" в этом преуспевают не меньше).
Вы или специально уводите беседу подальше или снова не догоняете:
есть объективные сиречь проверяемые критерии, кроме разговоров про понтовитость москвичей?
Подсказка: разработчик с 3мя годами боевого подтвержденного опыта — уже что-то.
VAB>>Но пожаловались, сославшись на столь авторитетный источник как "все знакомые". E>В маленьком городе это более достоверный источник, чем изучение списков вакансий
думаете, в больших это по-другому?
но все равно — попробуйте сослаться на всех своих знакомых при следующем разговоре о повышении ЗП
E>Ничего не обычного. Просто вот что происходит: смотрю на происходящее у нас и вижу, что не хватает людей, даже при том, что зарплаты все время растут. Ладно, думаю, все умные от нас уехали, нам дуракам никак не справится со своими тупыми мозгами и пустыми кошельками. Потом мне пишут из Питера -- мол давай к нам, проекты интересные, деньги нормальные, а людей нет. О как думаю, совпаденьеце. Потом то же самое начинают писать из Москвы. Потом из США. Тенденция, однако. Потом смотрю в местные форумы объявлений о работе и вижу объявления с множеством ответов из одного слова "up", причем фирмы так же не Гомельские и даже не Минские.
ну и? какой вывод можно сделать-то? Я свои сделал выше, если что. Они прекрасно и сюда подходят.
E>А этот абзац вообще о чем?
Евгений, я и так уже достаточно этим вечером написал — даже не знаю чем тут помочь... прочитайте снова? или забейте.
Поймите, я ни в коем случае не пытался что-то там этакое Вам доказать про Гомель или там в Ваших словах опровергнуть. Лишь обосновал свое мнение о том, почему не придаю большого значения всему этому шуму вокруг нехватки ресурсов. Старался-растекался по древу аж в нескольких сообщениях, потому что мне интересно услышать что думают коллеги по этому поводу, хоть они пока и отмалчиваются.
И ключевой тут момент, в моей теории — перейти от общих слов к конкретным критериям. Это бывает сложно, но всегда можно (при желании). А там и становится понятно, что нужно сделать для решения проблемы — и все сразу становится не так страшно, как об этом часто пишут\расказывают. И все.
Обращаю особое внимание — я даже ни разу не усомнился в том что нехватка ресурсов есть
VAB>>PS Конечно, сочувствовать испытывающим кадровый голод легко, где-то даже поможет добрать вистов, однако я предпочитаю решать проблемы вместо их бесполезного обмусоливания. Посему вот такое мое суровое ИМХО выше.
E>Не обижайтесь, но для человека, который опубликовал свое резюме в поисках работы, ваше суровое ИМХО слишком суровое.
уж какое получилось этим суровым вечерком после очередной успешной демонстрации достижений народного хозяйства только причем тут тот факт, что мое резюме опубликовано? Мне теперь нельзя иметь ИМХО?! Право слово, Вы умеете удивить Тоже не сердитесь — ставлю смайлик
Женя, лучше бы написали с чем конкретно согласны или несогласны? Пока даже это мне не очень понятно. Если несогласны — где Ваша позиция, где объективные аргументы в пользу неправильности моей, на Ваш взгляд? Мне же тоже интересно, где я могу заблуждаться. И что предложили бы Вы для решения проблемы поиска днем с огнем своим знакомым? Вот это было бы дело. А так...
...а так я бы на этом обмен мнениями в ветке завершил Напишите свои соображения — прочту и скажу спасибо
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, SkyDance, Вы писали:
ГВ>>Давай так. Формальный процесс прежде всего вносит ясность: кто, чем и почему занят, и что сделано.
SD>У-у-у-у какая наивность. SD>Нет уж. Фигвам. Формальный процесс может в лучшем случае создать видимость такой ясности.
Хорошо, я оговорился: вносит некоторую ясность. Так лучше?
[...история...]
SD>Мораль всего этого такова: процесс — это особенный, специфический навык. Никакого отношения к созданию продукта процесс не имеет.
Неправильно. Мораль такова: если что-то пошло не так, нужно разбираться в фактических причинах, а не искать, где светлее. Насколько я понимаю, непосредственный источник проблем обнаружили:
...в контору начали проникать настоящие "корпоративные работники", натуральные крысы. Кто как: кто по дружбе, кто по родственным связям, кто за еще какие услуги.
Следовательно причина — в схеме набора новых людей.
SD>Специалисты по процессу — особые люди. Своего рода прилипалы.
Это кого ты называешь специалистами? Вот этих славных ребят:
Тех самых манагеров. Которые умели прекрасно изобразить процесс, выставив себя в этом процессе исключительно важными и незаменимыми людьми.
Какие ж это специалисты? Это — бубльгум в галстуках.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>Хорошо, я оговорился: вносит некоторую ясность. Так лучше?
Возможна — и весьма часта — ситуация, когда процесс создает видимость ясности, на самом деле затуманивая еще больше реальную ситуацию. Начальство подменяет реальную картину той, которую создает процесс.
ГВ>Неправильно. Мораль такова: если что-то пошло не так, нужно разбираться в фактических причинах, а не искать, где светлее.
Формулировка верная. Но для чего тут "процесс"?
ГВ>Какие ж это специалисты? Это — бубльгум в галстуках.
Тем не менее, как только в конторе появляется такой "бубльгум", в ней тут же появляются и "процесс". Обратное тоже верно: если вдруг начальник с бодуна решит учудить процесс — можно не сомневаться, очень скоро в конторе появится "бубльгум". Они всегда идут в комплекте друг с другом. Увы.
VAB>SD написал о ситуации, когда возможности — есть, однако жабец поддавливает или еще какие соображения играют — отчего в конечном счете частенько проигрывают все.
Совершенно верно. Именно про такую ситуацию и пишу. С оной ситуацией знаком, увы, не по наслышке
Здравствуйте, Vzhyk, Вы писали:
>> В каждом сегменте рынка свой масштаб цен. Если начать платить в Гомеле >> московские зарплаты, то это не приведет ни к притоку программистов, ни к >> сохранению выгод от размещения разработки вне Москвы. V>А какие выгоды от размещения в Москве?
Выгода от размещения в Москве -- сокращение расходов на взаимодействие между клиентом и исполнителем.
Выгода от размещения вне Москвы -- сокращение расходов на ЗП и аренде.
V>И как это не приведет? Если в Гомеле хотя бы от 2000 платить начнете, V>думаю, из Минска многие к вам точно поедут (особенно молодые и V>амбициозные — а на них то много держится).
Молодым по 2000 платить в ближайшее время вряд ли кто будет. А опытным, я думаю, если еще по столько не платят, то скоро начнут. И на этой цифре вряд ли остановятся.
V>Вот так и представляю беларуская силиконовая долина в Гомеле со своим V>домом отдыха на Соже.
Не, в Беларуси не будет второй силиконовой долины.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Vzhyk, Вы писали:
>> "Очень толковый" в нашем понимании -- это практически то же, что "очень >> толковый" в Москве, только без понтов. V>Это уже, скажем так "провинциализм".
Это, скажем так, впечатление о том, как работа ускоряется в _разы_ когда со стороны заказчика/партнера в Москве появляется вменяемый человек, способный самостоятельно делать свою работу не переводя стрелки на кого-нибудь другого. Причем, в трех случаях это были коренные москвичи, на которых держалась работа целых отделов и которые, насколько мне известно, не были самыми высокооплачиваемыми специалистами.
V>3. Почитай форум о работе или бо управлении, 90% сообщений об V>бестолковости менеджмента.
Когда разработчики начинают писать о бестолковости менеджмента, то я верю этому настолько же, насколько менеджеры пишут о бестолковости исполнителей. У каждого своя правда, свои цели и свое видение ситуации.
V>На вашей конторе, поднимайте эффективность управления и будет вам шасце.
А вы диагноз телепатически ставить умеете доктор! Однако
V>Как пример классика: что выгоднее 10 програмеров по 1000 или 3 по 2500?
It depends.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Вот ради удаления этих самых рутинных задач и имеет смысл уходить на следующий виток развития.
Мне кажется, ситуация строго обратная. Наоборот, уже много лет ведется планомерная работа, чтобы сделать работу программиста как можно более рутинной. Тогда ее будет в состоянии выполнить любой индус. Творчество, конечно, хорошо, его нельзя поставить на конвейер. Нынешний идеал: составить такой набор инструций, чтобы по ним можно было разработать программный продукт.
Обычно считается, что любую рутину можно запрограммировать. Но это не совсем так. Запрограммировать можно то, что формализуемо. Ну а так можно написать Большую Инструкцию для архитекторов для составления иерархии классов. Начиная с того, что нужно проанализировать ТЗ, выписать все прецеденты, описать их в последовательности выполнения действий выбрать глаголы и т. д. и т. п. Если инструкция будет достаточно детальной, то мы получим как раз рутинный процесс. Но запрограммировать его пока что нельзя.
Здравствуйте, eao197, Вы писали:
E>Не может ли произойти так, что программисты со временем разделяться на две категории -- программисты-архитекторы и программисты-сборщики?
Со временем?
По-моему такое положение существует давно, только яб ещё добавил что первым приходится присматривать за вторыми (на предмет)
E>Да и ДаМарко с Листером пишут уже столько лет о том, что человеческий фактор -- залог успеха. Неужели к ним так никто и не прислушивается? Тот же Google, к примеру?
Только вот имхо суть не в разделении на "архитектов и кодеров", а в развитии и тех и других, конечно, учитывая индивидуальные особенности.
eao197 пишет: > > V>А какие выгоды от размещения в Москве? > > Выгода от размещения в Москве -- сокращение расходов на взаимодействие > между клиентом и исполнителем.
Это, если клиент в Москве. А если в Нью-Йорке?
> Выгода от размещения вне Москвы -- сокращение расходов на ЗП и аренде.
Ну а наемного работнику от этого какая польза? В Минске снять
однокомнатную вполне за 250 можно (многие знакомые и того меньше
снимают), а зарплаты выше, чем в Гомеле.
> > Молодым по 2000 платить в ближайшее время вряд ли кто будет. А опытным, > я думаю, если еще по столько не платят, то скоро начнут. И на этой цифре > вряд ли остановятся.
Ну вот. Когда начнете платить, как в Минске. Никто от вас в Минск
уезжать не будет, разве что в Монреаль или Торонто. В Минске тоже кстати
по 2000 редко очень платят.
И еще молодой по возрасту и опытный — вещи, конечно, коррелированные, но
не 1 коэффициент корреляции.
> > V>Вот так и представляю беларуская силиконовая долина в Гомеле со своим > V>домом отдыха на Соже. > > Не, в Беларуси не будет второй силиконовой долины.
Ну почему же? Вон даже государство уже несколько лет об этом жужжит.
eao197 пишет: > > Это, скажем так, впечатление о том, как работа ускоряется в _разы_ когда > со стороны заказчика/партнера в Москве появляется вменяемый человек, > способный самостоятельно делать свою работу не переводя стрелки на > кого-нибудь другого. Причем, в трех случаях это были коренные москвичи, > на которых держалась работа целых отделов и которые, насколько мне > известно, не были самыми высокооплачиваемыми специалистами.
Имхо, обсуждение "москалей" — это уже другая тема и место ей в священных
войнах.
> > V>3. Почитай форум о работе или бо управлении, 90% сообщений об > V>бестолковости менеджмента. > > Когда разработчики начинают писать о бестолковости менеджмента, то я > верю этому настолько же, насколько менеджеры пишут о бестолковости > исполнителей. У каждого своя правда, свои цели и свое видение ситуации.
Как там говорится, каждый са себе злобный буратино. Но вот без
приличного каменщика кирпичный дом не построишь, а вот прораба можно и
сменить — это если дом за свои личные денежки строишь.
> > V>На вашей конторе, поднимайте эффективность управления и будет вам шасце. > А вы диагноз телепатически ставить умеете доктор! Однако
Ага . В подобных постах уже не сложно.
> > V>Как пример классика: что выгоднее 10 програмеров по 1000 или 3 по 2500? > > It depends.
А вот тут интересно, расскажи про свою арифметику.
Здравствуйте, Vzhyk, Вы писали:
>> Выгода от размещения в Москве -- сокращение расходов на взаимодействие >> между клиентом и исполнителем. V>Это, если клиент в Москве. А если в Нью-Йорке?
Все равно сокращение. Так как добираться из Москвы в Нью-Йорк проще, чем из Гомеля. Да и интернет и другие виды связи в Москве дешевле.
>> Выгода от размещения вне Москвы -- сокращение расходов на ЗП и аренде. V>Ну а наемного работнику от этого какая польза? В Минске снять V>однокомнатную вполне за 250 можно (многие знакомые и того меньше V>снимают), а зарплаты выше, чем в Гомеле.
У нас за 250 снимают хорошие двух, а то и трехкомнатные квартиры.
Наемному работнику польза в том, что он остается в своем родном городе.
V>Ну вот. Когда начнете платить, как в Минске. Никто от вас в Минск V>уезжать не будет, разве что в Монреаль или Торонто. В Минске тоже кстати V>по 2000 редко очень платят.
Что уже за 2k перевалило?
>> V>Вот так и представляю беларуская силиконовая долина в Гомеле со своим >> V>домом отдыха на Соже. >> >> Не, в Беларуси не будет второй силиконовой долины. V>Ну почему же? Вон даже государство уже несколько лет об этом жужжит.
Так я про эту и говорю. Пусть хотя бы в Минске ее сделают.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197 пишет: > > 3. Человек сам сделал реализацию, которая не смотря на огрехи может быть > доведена до ума и пущена в эксплуатацию. А уж если в ней и огрехов > серьезных нет -- значит этот человек уже программирует лучше меня > > Так вот задача в том, чтобы искать людей как раз показывающих третий тип > результата (в соседней ветке Vzhyk, имхо, именно об этом говорил > озвучивая 10 за $1000 или 3 за $2500). Именно таких я называю толковыми.
Ага и таких людей очень мало, причем в любой профессии — их беречь надо
(кстати мой знакомый владелец небольшой строительной конторы так и
поступает с рабочими своими, которые спецы, а вот в програминге я
подобное не видел, ни разу)
> > Посему у меня напрашивается вывод о том, что если раньше на > специальность "программирование" шли более-менее увлеченные люди, то > сейчас это уже не так.
Конечно не так, чем более промышленной становится профессия, тем меньше
процент звезд в ней. До 90-х наша профессия была более творческой, все
решали "глобальные задачи (на асме)", сейчас же больше решают конкретные
задачи бизнеса, а процент звездных задач сильно уменьшился (хотя в
абсолютной цифре, думаю их количество увеличилось)
Здравствуйте, Vzhyk, Вы писали:
V>eao197 пишет: >> >> Это, скажем так, впечатление о том, как работа ускоряется в _разы_ когда >> со стороны заказчика/партнера в Москве появляется вменяемый человек, >> способный самостоятельно делать свою работу не переводя стрелки на >> кого-нибудь другого. Причем, в трех случаях это были коренные москвичи, >> на которых держалась работа целых отделов и которые, насколько мне >> известно, не были самыми высокооплачиваемыми специалистами. V>Имхо, обсуждение "москалей" — это уже другая тема и место ей в священных V>войнах.
Я об этом сказал лишь потому, что в моем понимании критерий "толковость" не меняется по географическим показателям.
>> V>Как пример классика: что выгоднее 10 програмеров по 1000 или 3 по 2500? >> >> It depends. V>А вот тут интересно, расскажи про свою арифметику.
Если задача конторы состоит в поиске и правке багов "поехало форматирование в форме NNN под Opera 9.5 на SuSe Linux" или настройке 1C в сотне-другой мелких торговых организаций, то выгода от 3 по 2500 не так уж и очевидна.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Vzhyk, Вы писали:
>> 3. Человек сам сделал реализацию, которая не смотря на огрехи может быть >> доведена до ума и пущена в эксплуатацию. А уж если в ней и огрехов >> серьезных нет -- значит этот человек уже программирует лучше меня >> >> Так вот задача в том, чтобы искать людей как раз показывающих третий тип >> результата (в соседней ветке Vzhyk, имхо, именно об этом говорил >> озвучивая 10 за $1000 или 3 за $2500). Именно таких я называю толковыми. V>Ага и таких людей очень мало, причем в любой профессии — их беречь надо V>(кстати мой знакомый владелец небольшой строительной конторы так и V>поступает с рабочими своими, которые спецы, а вот в програминге я V>подобное не видел, ни разу)
А вот мы у себя пытаемся так делать. Мы же не Минск, куда все едут, нам людей ценить нужно
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Так вот задача в том, чтобы искать людей как раз показывающих третий тип результата (в соседней ветке Vzhyk, имхо, именно об этом говорил озвучивая 10 за $1000 или 3 за $2500). Именно таких я называю толковыми.
даже на толковых экономишь
Здравствуйте, Vzhyk, Вы писали:
>> Тут разделение образования на 2 ступени — как раз на руку. Первая >> бакалаврская ступень массово готовит "рутинных" программистов. А вот >> вторая — магистерская — ее бы как раз хорошо заточить под глубину. >> Учитывая, что после 2 лет магистра еще 3-4 года аспирантуры — вот как >> раз и можно готовить глубоких спецов. И таких, естественно, не в >> массовом порядке, как бакалавров, а в единичных экземплярах... V>Утопист ты
Ну, значит, наши начальники в полном составе — утописты... Потому как они явно думают так же...
Я, скорее, оптимист... Но стараюсь следовать собственным оптимистическим мыслям...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, D. Mon, Вы писали:
DM>По поводу обучения: DM>на нашем факультете второкурсники в качестве семинарского задания (не курсовой) пишут свой шелл и небольшой sql сервер.
В какой системе? DM>Про достижения 60-х: DM>здорово, конечно, рассказывать, как делал свою ОС. Только когда вся память в машине — 4 кб, это по-любому не очень большой и сложный проект. Не намного сложнее современных 4k intro, которые до сих пор пишутся пачками.
Не совсем так. На БЭСМ-6 в было 32 тысячи 48-битных ячеек. Для этой машины было написано советскими программистами не менее 3(трех) полноценных многозадачных (а потом и многопользовательских) операционных систем. ОС ДИСПАК стала стандартом де-факто. А в Дубне отдел системного программирования написал не только ОС Дубна, но и классную систему программирования под нее Фортран-дубна. Так что такая работа была все же не чета современным "4k intro, которые до сих пор пишутся пачками". DM>В целом, неплохой рассказ, да и то, что автор до сих пор занимается реальными проектами и работает с современными технологиями (пусть и с ворчанием) — вызывает только уважение.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
eao197 пишет: > > V>Это, если клиент в Москве. А если в Нью-Йорке? > > Все равно сокращение. Так как добираться из Москвы в Нью-Йорк проще, чем > из Гомеля. Да и интернет и другие виды связи в Москве дешевле.
Осталось услышать оглашение причин этого и перейти в политику.
> > У нас за 250 снимают хорошие двух, а то и трехкомнатные квартиры.
Это уже небольшая проблема. Чаще важнее иметь крышу над головой и потом
уже какую. > Наемному работнику польза в том, что он остается в своем родном городе.
Но он же, такая сволочь, все уехать норовит.
> > Что уже за 2k перевалило?
В среднем нет, и даже не подобралось. А так знаю людей, что и по 3-4К в
Минске получают.
>> > Не, в Беларуси не будет второй силиконовой долины. > V>Ну почему же? Вон даже государство уже несколько лет об этом жужжит. > > Так я про эту и говорю. Пусть хотя бы в Минске ее сделают.
А вам-то в Гомеле, что от этого? Еще больше спецов уезжать будет.
Лучше бы коммуникациями занимались (государство в смысле).
eao197 пишет: > > > А вот мы у себя пытаемся так делать. Мы же не Минск, куда все едут, нам > людей ценить нужно
Так не понимаю, почему вы жалуетесь на отсутствие кадров. Если у вас
оплата вполне себе сравнима с Минской, коллектив спецов есть, берите
умных студентов и выращиваете спецов.
Для многих задач один спец 5 обезьянок стоит.
Здравствуйте, Vzhyk, Вы писали:
>> А вот мы у себя пытаемся так делать. Мы же не Минск, куда все едут, нам >> людей ценить нужно V>Так не понимаю, почему вы жалуетесь на отсутствие кадров. Если у вас V>оплата вполне себе сравнима с Минской, коллектив спецов есть, берите V>умных студентов и выращиваете спецов.
Мы так и делаем. Только, как я уже говорил -- процесс этот длительный и трудоемкий. И не всегда результат гарантирован.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
LaptevVV пишет: > > >> > Тут разделение образования на 2 ступени — как раз на руку. Первая >> > бакалаврская ступень массово готовит "рутинных" программистов. А вот >> > вторая — магистерская — ее бы как раз хорошо заточить под глубину. >> > Учитывая, что после 2 лет магистра еще 3-4 года аспирантуры — вот как >> > раз и можно готовить глубоких спецов. И таких, естественно, не в >> > массовом порядке, как бакалавров, а в единичных экземплярах... > V>Утопист ты > Ну, значит, наши начальники в полном составе — утописты... Потому как > они явно думают так же...
Ага, 1880-х мы этим страдаем.
Расскажи тогда, как ты представляешь подобную программы обучения.
В Союзе был вариант техникум -> вуз, но оба они имели полностью
независимые программы обучения. Фактически курсы техникума проходились
еще раз в гораздо более углубленном варианте.
eao197 пишет: > > > Мы так и делаем. Только, как я уже говорил -- процесс этот длительный и > трудоемкий. И не всегда результат гарантирован.
Без труда не выловишь и рыбки из пруда.
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, AndrewVK, Вы писали:
LVV>Ну, не надо, мужики... LVV>Разные докторские и разные статьи писались... LVV>Например, кандидатская диссертация Баяковского Юрия Матвеевича — это графическая система, которая работала во всех вычислительных центрах Советского Союза... Нынешним кандидатам такое и не снилось.
Собственно и тогдашним тоже, так как из Вашего утверждения следует, что или ни в одном вычислительном центре Советского Союза не стояла графическая система ни одного другого автора, или в некоторых вычислительных центрах предпочитали другие графические системы, дополнительно или вместо системы Юрия Матвеевича, что несколько умаляет его достижение
Здравствуйте, eao197, Вы писали:
E>>>Думаю, что когда в программировании придумают инструменты, которые способны заменить человека для исправления ошибок вида "поехало форматирование в форме NNN под Opera 9.5 на SuSe Linux" или решения задач вида "добавить общее количество страниц в нижний колонтитул каждой печатоемой страницы отчетов RRR/ZZZ/XXX", то это обязательно сделают.
ГВ>>Так здесь как раз поле для удаления "рутины". E>А как ее удалить?
Вариантов много — от разработки своего дополнительного продукта до переделки всей конструкции. Я не знаю, какой именно вам подойдёт.
E>>>Я говорил не про фреймворк, а про создание кластерного приложения для решения какой-нибудь прикладной задачи.
ГВ>>Ну ты сам говоришь, что такое приложение легко пишется сборкой стандартных компонентов. А я, в свою очередь, предполагаю, что на одном фреймворке (наборе компонентов) свет клином не сошёлся. Был один, появится и второй.
E>Ну да. Но все сведется к тому, чтобы изучить второй фреймворк. А, по мнению Донского (и я с ним согласен), это уже рутина по сравнению с написанием такого фреймворка.
О! Для кого-то — сведётся к изучению фреймворка, для кого-то — к выковыриванию его недостатков и разработке очередного. По идее, хороший фреймворк должен легко изучаться, следовательно, объём рутины сокращается. Разумеется, если не считать, что программирование вдруг начнёт сводиться к "изучению фреймворка". Изучение неизбежно, вопрос в том, как его рассматривать — как цель, или как этап.
ГВ>>Ну и ещё большая проблема в том, что СУБД и ОС — это лишь частности от более абстрактных штучек. Собственно, вот это — тоже беда, потому что даже натаскав на разработку СУБД всё равно получим мастера-разработчика СУБД, а не программиста-генератора абстракций.
E>Вот в этом я сомневаюсь. Человек, который сможет написать СУБД вряд ли будет рядовым мастером-разработчиком СУБД (взять в качестве примера Константина Книжника).
Да безразлично, "рядовой" он или единственный. Я о специализациях разного порядка, грубо говоря. Программист работает с информацией, узкий специалист — с продуктами определённого рода.
ГВ>>а во-вторых — вокруг много плохих программистов, мне это отлично известно. Что с того? Это не означает, что подобное status quo есть хорошо. Это очень, очень плохо. И это ни в коем случае не означает, что под них нужно равнять стандарты профессии.
E>А ты не боишься, что стандарты профессии, со временем, именно они и будут устанавливать?
Не-а, не боюсь. Хотя меня это и напрягает. Пусть устанавливают, мне не жалко. Жалко только, что на сей сизифов труд будет ухлопана уйма времени и сил, которые могли бы пойти на что-то более дельное.
E>Не может ли произойти так, что программисты со временем разделяться на две категории -- программисты-архитекторы и программисты-сборщики?
Нет, не может. Это нежизнеспособная химера.
ГВ>>>>А потом, прямая обязанность учебного заведения — объяснить сложные вещи доступным языком, сиречь — научить. Научили же нас писать программы. E>>>Имхо, те, кто этому научился, научились этому самостоятельно.
ГВ>>Хм. Что, совсем? Ты не видишь разницу, что в первом случае основополагающим было желание развить производство, а во втором — впитать людскую массу, ограничив её развитие?
E>Гена, а откуда такая уверенность, что софтверные компании поголовно заинтересованны во впитывании людской массы и ограничении ее развития?
Да нету у меня такой уверенности. Я лишь пытаюсь донести до тебя мысль, которая появляется при чтении статьи Донского. Так что, все вопросы такого рода — к нему. Это он уверен, что программирование становится рутинным, следователно, оно будет требовать массу низкоквалифицированного персонала.
E>Подобное я наблюдаю в больших, бюрократизированных огранизациях. Но вот в маленьких компаниях, в которых все на виду, и нет жесткого деления специализации (архитектор/программист/тестер/технический писатель), на мой взгляд происходит обратное -- чем больше растут люди, тем лучше самой компании.
Ну наконец-то, уф-ф-ф... Женя, я в тебя верил!
Да, правильно. И причём тут тогда "рутинизация", если маленькая компания может успешно грызться на рынке с более крупными конкурентами? Следовательно, как минимум, некоторый контингент людей, заинтересованных в непрерывном повышении квалификации программистов — есть.
E>Да и ДаМарко с Листером пишут уже столько лет о том, что человеческий фактор -- залог успеха. Неужели к ним так никто и не прислушивается? Тот же Google, к примеру?
Правильно-правильно. Думается, если бы Брин был уверен, что всё придумано до него и за него, то никакого бы Google не появилось.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Mystic, Вы писали:
M>> Наоборот, уже много лет ведется планомерная работа, чтобы сделать работу программиста как можно более рутинной.
AVK>Не знаю от чего такой вывод, но, скажем, технологии для разработки от Microsoft в последнее время значительно усложнились. Сравни WinForms и WPF, Вебсервисы и WCF, С# 1.0 и 3.0.
Как по мне, творческая составляющая определяется не сложностью, а свободой выбора. Если при разработке чего-нить я имею несколько способов реализации, среди которых у меня выбор, то работа творческая. Если свободы выбора нет, и решение вопросов сводится в поиске в документации ответа на вопрос "как?", то работа менее творческая. С WPF и WCF не сталкивался, что касается C# 3.0, то не могу сказать, что на нем программировать так уж сложнее, а изменения в языке революционны.
Здравствуйте, Vzhyk, Вы писали:
V>Расскажи тогда, как ты представляешь подобную программы обучения. V>В Союзе был вариант техникум -> вуз, но оба они имели полностью V>независимые программы обучения. Фактически курсы техникума проходились V>еще раз в гораздо более углубленном варианте.
C 2000 года, когда были приняты последние стандарты специалитета, стандартизация в области бакалавриата велась довольно грамотно... Например, в нашем направлении "Информатика и вычислительная техника" стандарт бакалавров был составлен по образцу и подобию стандарта для специалистов. То есть набор обязательных федеральных дисциплин был одинаковым. Более того, в стандарте бакалавров были учтены некоторые небольшие недоработки стандарта специалистов. Например, у специалистов не было отдельной дисциплины "Методы оптимизации", а для бакалавров ее ввели. Нам для специалистов пришлось вводить эту дисциплину как региональный компонент.
Стандарт магистров на данном этапе (тоже стандарт 2000 года) по нашему направлению предполагает 15 или 16 специализаций. Например, там есть специализация "Искусственный интеллект". В стандарте магистров прописан минимум обязательных федеральных дисциплин: примерно 3-5 для каждой специализации. Причем самого общего характера типа: Концепции современных информационных технологий". Остальное вуз устанавливает сам. В стандарте дается нехилый объем часов на полтора года обучения, причем по сравнению со специалистом аудиторная нагрузка уменьшена в 2 раза. То есть основная работа — самостоятельная. И последние полгода — написание магистерской диссертации под руководством руководителя.
Но сейчас ждем новых стандартов... Все говорят, что они вот-вот должны быть приняты, но на данный момент их еще нет.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Nuseraro, Вы писали:
N>Здравствуйте, LaptevVV, Вы писали:
LVV>>Здравствуйте, AndrewVK, Вы писали:
LVV>>Ну, не надо, мужики... LVV>>Разные докторские и разные статьи писались... LVV>>Например, кандидатская диссертация Баяковского Юрия Матвеевича — это графическая система, которая работала во всех вычислительных центрах Советского Союза... Нынешним кандидатам такое и не снилось.
N>Собственно и тогдашним тоже, так как из Вашего утверждения следует, что или ни в одном вычислительном центре Советского Союза не стояла графическая система ни одного другого автора, или в некоторых вычислительных центрах предпочитали другие графические системы, дополнительно или вместо системы Юрия Матвеевича, что несколько умаляет его достижение
Честно говоря, я кроме Графора и не помню ничего... Потом уже, когда ЕС вовсю пошли (реально они в массы пошли только в конце 70-х, году в 78-79, как Донской об этом и пишет), то появились варианты , а до ЕС — нифига кроме Графора не было...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Ситуация всегда будет казаться "обратной", поскольку всегда хочется сказать, что "всё хорошо, не надо краше", что дальше уже некуда, что всё уже придумано. Это нормально и естественно. Лень искать источник, но в каком там году сказали, что всё уже придумано и развиваться дальше некуда? В 1890-м, нет? А тоже ведь, по идее, эра придумывания должна была закончиться.
Я согласен с тем, что эра придумываения будет продолжаться. Но придумывает новое (в данном контексте) не такой уж большой процент программистов. Большинство пользуется уже готовым.
ГВ>Нынешний??? Разработки генераторов программ по требованиям велись ещё в 80-х, если мне не изменяет память. А начала положены, скорее всего, где-то в 70-х или раньше. Так что, насчёт "нынешнего" ты определённо погорячился.
Вот, определенные прогресс уже есть, раз индусы с невысокой квалификацией могут разрабатывать ПО Как по мне процесс переметнулся из области полностью автоматизированного процесса построения программы на процесс построения программы людьми с невысокой квалификацией.
ГВ>Кроме того (бляха-муха, как я не люблю вспоминать про то, "что было, было, было", но приходится), я хорошо помню балабольство вокруг 4GL в первой половине 90-х, что, мол, скоро программисты окажутся не нужны
Я слышал такое об SQL, типа любой бухгалтер в состоянии на родном [английском] языке написать запрос к базе и он будет работать. Зачем тогда программисты?
M>>Обычно считается, что любую рутину можно запрограммировать. Но это не совсем так. Запрограммировать можно то, что формализуемо.
ГВ>Так а чем, по-твоему, занимаются программисты? Формализацией и доопределением того, что на первый взгляд неформализуемо и неопределённо.
Если заменить "на первый взляд неформализуемо" на "описано в неформальном виде", то получится рутина в самом чистом виде. А вот составление шахматной программы задача более творческая. Ибо неясно, даст та или иная фича прирост силы или нет.
С другой стороны понятие рутины сугубо индивидумально. Кому-то и раскладывать пасьянс в котором все зависит от последовательности карт, а не от способностей человека, не рутина. А кому-то если задача разрешима в принципе, то уже рутина. С опытом иногда то, что раньше не казалось рутиной, превращается в рутину.
ГВ>Вопрос в том, какие формы определяются инструкциями. Если в инструкции сказано "выписать все use cases и поместить их в документ Use Case List", то здесь огромное и глубокое море для дополнительной формализации того, что такое use case, как его выделять и т.п. То, что пишется в книгах по этому поводу, по сути — рекомендации.
Как по мне, это как раз хороший пример неформальной, но рутинной работы. Формализовать нельзя, но операции все отнотипные.
Здравствуйте, AndrewVK, Вы писали:
LVV>>Разные докторские и разные статьи писались... AVK>Я ж не спорю что разные. Но и то, на что я намекал — было и нередко.
Ну, этого дерьма и сейчас хватает — и в нашем вузе тоже. Только не все ж такие. LVV>>И СУБД ИНЕС Михаила Донского тоже работала во всех ВЦ СССР. AVK>Она не Михаила Донского — он же сам там написал, что он что то вроде инсталлятора к ней ваял.
СУБД «ИНЕС», в которой я занимался системными вопросами – генерацией и дистрибуцией системы, системой поддержки версий, для чего была написана Архивная Система — и АСУ МНТС, устанавливать которую мне пришлось по всем министерствам и республикам СССР, принесли мне много хороших знакомых по всей стране.
В то время сгенерировать конкретную версию — работка была еще та... Отдел системного программирования, если имел опыт, то генерил ось на ЕС (например, ЕС1055) за неделю. А если опыта не имел, то за месяц... :?) Сам был свидетелем, как на СМ 1420 народ месяц парился, пока все параметры не выстроил как нужно. Так сто системные вопросы, коими Донской занимался, занимали едва ли не половину всей работы...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LaptevVV пишет: > > C 2000 года, когда были приняты последние стандарты специалитета, > стандартизация в области бакалавриата велась довольно грамотно...
Все это, конечно хорошо, красиво. Но вот с практической точки зрения.
Есть курс ТВиМС, например, и для бакалавров и для магистров одно и тоже
читаться будет? Но таких курсов много и они фундаментальные, в 3 года
влазят только (по своей учебе в советское время).
Теперь вспоминаем о том, что нужно именно производству — в первую
очередь программирование. Когда его давать?
Здравствуйте, Valery A. Boronin, Вы писали:
C>>Проблема в том, что если цена на программиста слишком высока — то многие компании просто физически не смогут его взять на работу. Ну не хватит денег просто. VAB>Потрясающей глубины вывод. 2+2=4. И?
И ничего.
VAB>А вообще нет и не было цели чтобы все компании могли физически взять на работу всех. Это еще зачем Вы придумали?
Это просто лишь значит, что рынок труда не может удовлетворить реальные потребности заказчиков.
Конечно, коллектив хороших программистов обычно в итоге принесёт прибыль (от автоматизации бизнес-процессов и т.п.), но это происходит обычно не сразу.
C>>Если бы был избыток кадров, то такой проблемы бы не было. VAB>ну зачем уходить "в если бы да кабы"? VAB>есть конкретная и вполне нормальная, обычная ситуация.
Ну так я не спорю, ничего особого тут нет. Просто констатирую факт.
Здравствуйте, Курилка, Вы писали:
C>>Не надо на компании и менеджеров гнать, большинство из них вполне адекватны. К>На базе какой выборки делается такое заявление?
Ну возможно у меня точка зрения не очень отражает состояние всей индустрии IT в России, но в успешных компаниях обычно и успешные менеджеры.
Cyberax пишет: > > C>>Не надо на компании и менеджеров гнать, большинство из них вполне > адекватны. > К>На базе какой выборки делается такое заявление? > Ну возможно у меня точка зрения не очень отражает состояние всей > индустрии IT в России, но в успешных компаниях обычно и успешные менеджеры.
Что есть успешная компания?
Google успешная? А ABBYY? А Cognitive? А Luxoft? А RECIF?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Курилка, Вы писали:
C>>>Не надо на компании и менеджеров гнать, большинство из них вполне адекватны. К>>На базе какой выборки делается такое заявление? C>Ну возможно у меня точка зрения не очень отражает состояние всей индустрии IT в России, но в успешных компаниях обычно и успешные менеджеры.
Ну как-то было бы странно видеть успешную компанию с неуспешным менеджментом, или я чего-то недогоняю
Здравствуйте, Курилка, Вы писали: К>Ну как-то было бы странно видеть успешную компанию с неуспешным менеджментом, или я чего-то недогоняю
Легко... конторы, созданные под откаты, или те, у которых основная детельность жестко завязана на откат определенному лицу или группе лиц.
Группа лиц находится один раз и требует минимального ухода.
Здравствуйте, denisko, Вы писали:
D>Здравствуйте, Курилка, Вы писали: К>>Ну как-то было бы странно видеть успешную компанию с неуспешным менеджментом, или я чего-то недогоняю D>Легко... конторы, созданные под откаты, или те, у которых основная детельность жестко завязана на откат определенному лицу или группе лиц. D>Группа лиц находится один раз и требует минимального ухода.
Речь вроде шла об успешных в программном бизнесе конторах, а не в спецах по нарубке бабла?
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, denisko, Вы писали:
К>Речь вроде шла об успешных в программном бизнесе конторах, а не в спецах по нарубке бабла?
Как можно измерить "успешность" компании, кроме как количеством зарабатываемого бабла?
Более того, для програмной конторы в России это вполне разумный способ ведения бизнеса.
Здравствуйте, Mystic, Вы писали:
M>Как по мне, творческая составляющая определяется не сложностью, а свободой выбора.
Со свободой выбора все хорошо. В C# 1.0 я довольно жестко был ограничен императивным стилем, в 3.0 добавился функциональный стиль.
M>С WPF и WCF не сталкивался, что касается C# 3.0, то не могу сказать, что на нем программировать так уж сложнее
Нет конечно, ни в коем случае не сложнее, наоборот проще.
... << RSDN@Home 1.2.0 alpha 4 rev. 1106 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Mystic, Вы писали:
M>Как по мне, творческая составляющая определяется не сложностью, а свободой выбора.
Со свободой выбора все хорошо. В C# 1.0 я довольно жестко был ограничен императивным стилем, в 3.0 добавился функциональный стиль.
M>С WPF и WCF не сталкивался, что касается C# 3.0, то не могу сказать, что на нем программировать так уж сложнее
Нет конечно, ни в коем случае не сложнее, наоборот проще.
... << RSDN@Home 1.2.0 alpha 4 rev. 1106 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Mystic, Вы писали:
ГВ>>Ситуация всегда будет казаться "обратной", поскольку всегда хочется сказать, что "всё хорошо, не надо краше", что дальше уже некуда, что всё уже придумано. Это нормально и естественно. Лень искать источник, но в каком там году сказали, что всё уже придумано и развиваться дальше некуда? В 1890-м, нет? А тоже ведь, по идее, эра придумывания должна была закончиться.
M>Я согласен с тем, что эра придумываения будет продолжаться. Но придумывает новое (в данном контексте) не такой уж большой процент программистов. Большинство пользуется уже готовым.
Правильно. Но я о другом. О том, что нельзя сводить "сверхидею" программирования к использованию готового. Понимаешь? Изучение чего-то нового или переоформленного старого было у нас всегда и пребудет вовеки. Вопрос в том (повторяю в пятнадцатый раз), как трактовать это изучение: как ступеньку, необходимый этап, или как конечную цель.
ГВ>>Нынешний??? Разработки генераторов программ по требованиям велись ещё в 80-х, если мне не изменяет память. А начала положены, скорее всего, где-то в 70-х или раньше. Так что, насчёт "нынешнего" ты определённо погорячился.
M>Вот, определенные прогресс уже есть, раз индусы с невысокой квалификацией могут разрабатывать ПО Как по мне процесс переметнулся из области полностью автоматизированного процесса построения программы на процесс построения программы людьми с невысокой квалификацией.
Кхм. Сказал бы я, что я думаю про разработки, сделанные "индусами с невысокой квалификацией", но боюсь — забанят за столь длинные выражения. Оно на практике получается дороже, хуже, и ещё и переделывать приходится. Если это — прогресс, то я — марсианин.
ГВ>>...я хорошо помню балабольство вокруг 4GL в первой половине 90-х, что, мол, скоро программисты окажутся не нужны M>Я слышал такое об SQL, типа любой бухгалтер в состоянии на родном [английском] языке написать запрос к базе и он будет работать. Зачем тогда программисты?
А теперь мы слышим то же самое, но вместо домохозяек фигурируют "индусы". Найди десять отличий, кроме того, что пресловутые "индусы" имеют хоть мало-мальское специальное образование, то есть так или иначе, но неквалифицированный персонал пришлось заменить хоть чуть-чуть, но квалифицированным.
M>>>Обычно считается, что любую рутину можно запрограммировать. Но это не совсем так. Запрограммировать можно то, что формализуемо.
ГВ>>Так а чем, по-твоему, занимаются программисты? Формализацией и доопределением того, что на первый взгляд неформализуемо и неопределённо.
M>Если заменить "на первый взляд неформализуемо" на "описано в неформальном виде", то получится рутина в самом чистом виде.
ИМХО, "рутина" здесь часто видится от нежелания заниматься структурированием этой работы. Например, выводить закономерности в модификациях требований, привязывать их к определённым клиентам, да много ещё чего можно придумать.
M>А вот составление шахматной программы задача более творческая. Ибо неясно, даст та или иная фича прирост силы или нет.
Скажем так, здесь творчество немного другого вида, я бы даже сказал — оно проще, чем работа с пользователями и их завитушками.
M>С другой стороны понятие рутины сугубо индивидумально. Кому-то и раскладывать пасьянс в котором все зависит от последовательности карт, а не от способностей человека, не рутина. А кому-то если задача разрешима в принципе, то уже рутина. С опытом иногда то, что раньше не казалось рутиной, превращается в рутину.
Чтобы не путаться, давай постановим, что мы сейчас "рутиной" называем несложные операции использования готовых продуктов по схеме "найти — подставить". То есть в том смысле, как об этом пишет Донской.
ГВ>>Вопрос в том, какие формы определяются инструкциями. Если в инструкции сказано "выписать все use cases и поместить их в документ Use Case List", то здесь огромное и глубокое море для дополнительной формализации того, что такое use case, как его выделять и т.п. То, что пишется в книгах по этому поводу, по сути — рекомендации.
M>Как по мне, это как раз хороший пример неформальной, но рутинной работы. Формализовать нельзя, но операции все отнотипные.
Ну знаешь... Эдак тогда всё программирование — однотипная операция. Сиди себе, кнопки жмакай, да бумажки пиши. В крайности же не надо впадать.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>>Разнобой в мыслях есть, это точно. AVK>Не просто разнобой, скорее некоторая шизофрения. Я не понимаю как в соседних кусках текста могу соседствовать размышления о maintainability кода и рассказы про необходимость написания собственных языков под любой проект.
А читали например "Книгу о счестье и несчастьях" Н. Амосова (такого кардиохирурга). Там вообще описания операций на сердце перемежаются мемуарами о детстве и рассуждениями о смысле жизни. По моему вполне нормальное явление для человека который не зациклен на одном. Программисты вообще никогда не отличались литературной стройностью изложения мысли. И кстати вполне воможно что статья изначально была больше или их было несколько а потом автор вырезал лишнее.
Давно заметил что когда программисты начинают рассуждать о чемто кроме программирования, зачастую они становяться похожими на бухгалтерш, рассуждающих о программировании.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Vzhyk, Вы писали:
>> V>Нет, это ты так пишешь. Уезжают активные и амбициозные в первую очередь, >> >> Амбициозные в первую очередь. >> >> V>а среди этих умных ребят больше обычно. >> >> Снобизмом попахивает однако V>Ой, да господь с тобой. Еще не хватало. Просто, если поувлекаешься V>психологией, организацией процессов мышления (хотя бы тем, что о них V>сейчас уже известно) сам увидишь.
Интроверты обычно ленивы и малоамбициозны, при этом умные и хорошие программисты, и среди
программистов их большинство.
Здравствуйте, AndrewVK, Вы писали:
M>>С WPF и WCF не сталкивался, что касается C# 3.0, то не могу сказать, что на нем программировать так уж сложнее
AVK>Нет конечно, ни в коем случае не сложнее, наоборот проще.
Ну так чем проще программировать, тем меньше квалификация нужна. Чем меньше квалификация нужна, тем более рутинный процесс
Здравствуйте, Геннадий Васильев, Вы писали:
M>>Вот, определенные прогресс уже есть, раз индусы с невысокой квалификацией могут разрабатывать ПО Как по мне процесс переметнулся из области полностью автоматизированного процесса построения программы на процесс построения программы людьми с невысокой квалификацией.
ГВ>Кхм. Сказал бы я, что я думаю про разработки, сделанные "индусами с невысокой квалификацией", но боюсь — забанят за столь длинные выражения. Оно на практике получается дороже, хуже, и ещё и переделывать приходится. Если это — прогресс, то я — марсианин.
Работа в этом направлении ведется и будет вестись. И не думаю, что вот так в раз откажутся от услуг индусов. И этот процесс как раз ассоциируется у меня с увеличением рутины.
ГВ>ИМХО, "рутина" здесь часто видится от нежелания заниматься структурированием этой работы. Например, выводить закономерности в модификациях требований, привязывать их к определённым клиентам, да много ещё чего можно придумать.
Наши позиции во многом схожи, вопрос только в том, что там где процесс мне кажется рутинным, для тебя он творческий.
M>>А вот составление шахматной программы задача более творческая. Ибо неясно, даст та или иная фича прирост силы или нет.
ГВ>Скажем так, здесь творчество немного другого вида, я бы даже сказал — оно проще, чем работа с пользователями и их завитушками.
Имхо, проще, потому что более творческая, следовательно более интересная. Но не так уж и проще, потому что пока никто не написал го программы, играющей в силу про.
Здравствуйте, AndrewVK, Вы писали:
E>>Ну да. Но все сведется к тому, чтобы изучить второй фреймворк. А, по мнению Донского (и я с ним согласен), это уже рутина по сравнению с написанием такого фреймворка.
AVK>Да нет, вот как раз реализация одних и тех же алгоритмов кластеризации и хождение по граблям, по которым уже прошла куча народу — это и есть рутина. А концентрация на реальных требованиях, а не борьба с кластерными заморочками как раз таки не рутина, а именно то, за что программисту платят.
Удовлетворять реальные требования можно по разному. Можно попытаться взять готовые сторонние решения, а можно придумать какой-то собственный нестандартный подход и, в случае успеха, получить дополнительную прибыль.
Ну, например, есть в Магнитогорске контора КомпасПлюс, которая когда-то делала SCADA "Флора". Но со SCADA дела шли не очень, поэтому "Флору" переориентировали на банковские системы. И теперь они являются лидерами в своем регионе. По словам одного из разработчиков "Флоры" именно эта среда программирования стала одним из факторов из успеха. А началось все с того, что в тяжелые времена решились заказ на разработку софта для местного банка сделать на "Флоре".
Тот же Erlang в Ericsson. Решили в Ericsson-е изобрести свой язык и выиграли.
Так что, наверное, опасны две крайности:
— стремление к "чистому искусству" (изобретательству) без оглядки на реальные требования;
— стремление к удовлетворению требований только "стандартными", "проверенными" решениями.
В связи с этим интересен такой феномен, который мне доводилось несколько раз наблюдать: после перехода на Java разработчики вдруг становились сторонниками исключительно готовых, кем-то где-то разработанных библиотек и компонентов. Ни дай бог что-нибудь свое написать.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndrewVK, Вы писали:
E>>Выгода от размещения вне Москвы -- сокращение расходов на ЗП и аренде.
AVK>Расходы по ЗП не так очевидны — в Москве можно найти программиста с производительностью равной 10 средним программистам, а платить ему всего в 2 раза больше.
Угу. Но это будет работать до тех пор, пока проект не обрастет множеством мелких задачек по настройке/адаптации/сопровождению. Распылять силы этого программиста на такие мелкие задачки уже будет не выгодно.
А если численность персонала начнет переваливать за несколько десятков человек (программисты, тестеры, технические писатели, техподдержка), то разница в средних зарплатах по сравнению с Москвой будет более заметной.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Mystic, Вы писали:
M>>Ну так чем проще программировать, тем меньше квалификация нужна.
AVK>Совсем нет. Потому что задачи программирования, а, как следствие, и критерии квалификации, состоят отнюдь не в борьбе со сложностями средств разработки. Т.е. программист высокой квалификации, это не тот, кто умеет пользоваться очередным мегаультрасложным средством разработки, а тот кто способен решать мегультрасложные задачи. Средство разработки — инструмент, а не цель.
А примеры таких мегаультрасложных задач, которыми занят разработчик? В большиснтве случаев все принципиально реализуемо, еще одна сборка/разборка автомата калашникова.
Здравствуйте, Mystic, Вы писали:
M>Работа в этом направлении ведется и будет вестись. И не думаю, что вот так в раз откажутся от услуг индусов. И этот процесс как раз ассоциируется у меня с увеличением рутины.
Мне такая ассоциация кажется ошибочной. Ну ладно, не будем меряться тем, что нам кажется.
ГВ>>ИМХО, "рутина" здесь часто видится от нежелания заниматься структурированием этой работы. Например, выводить закономерности в модификациях требований, привязывать их к определённым клиентам, да много ещё чего можно придумать. M>Наши позиции во многом схожи, вопрос только в том, что там где процесс мне кажется рутинным, для тебя он творческий.
Я неточно выразился. См. ниже.
M>>>А вот составление шахматной программы задача более творческая. Ибо неясно, даст та или иная фича прирост силы или нет. ГВ>>Скажем так, здесь творчество немного другого вида, я бы даже сказал — оно проще, чем работа с пользователями и их завитушками. M>Имхо, проще, потому что более творческая, следовательно более интересная. Но не так уж и проще, потому что пока никто не написал го программы, играющей в силу про.
Честно говоря, насчёт "проще" я несколько загнул. Не проще, а, скорее, шахматная задача, в виду дико большого объёма вычислительной работы на полный перебор, требует каких-то творческих, оригинальных решений для ограничения пространства перебора. Тогда как то, что ты называешь "рутиной" таких решений явно не требует. Хотя место для творчества, то есть для внедрения какой-то своей структуры в эту работу — есть. Другое дело, что второй вариант выглядит менее предсказуемым в смысле бонусов от результата и не содержит явного вызова.
Таким образом, дихотомия задач на "творческие" и "рутинные", по сути зачастую проводится по критерию необходимости творчества для решения данной задачи. Понимаешь? Необходимости, а не возможности. То есть из оценки исключаются способности самого носителя творческих решений. Иными словами, выбрасывается сам человек! Получается прям-таки "ёжик — птица гордая, пока не пнёшь — не полетит"!
В итоге, если долго играться с таким подходом, то к зрелому возрасту придёшь к панковской максиме: "весь мир — дерь...", тьфу — "рутина", конечно. А хрен ли? Собственного опыта уже достаточно для решения почти любых текущих задач, никто особо не пинает, на фига дальше-то развиваться? Ну а дальше — welcome депрессия, психосоматика, тяжёлый взгляд очей, исполненных снобизма и далее со всеми остановками.
Э-э-э... Как там в обсуждаемом первоисточнике? "Заканчивается мой жизненный цикл и заканчивается жизненный цикл программирования", так, кажется? А ведь чуть выше по тексту он назвал 64-летнего Шеннона — "нестарым", а 60-летнего себя — чуть ли не старой негодной плесенью величает, мерзавец этакий!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, eao197, Вы писали:
E>Удовлетворять реальные требования можно по разному. Можно попытаться взять готовые сторонние решения, а можно придумать какой-то собственный нестандартный подход и, в случае успеха, получить дополнительную прибыль.
Можно. Только разделение труда обычно рулит. Ни и к рутинности/нерутинности программирования это никакого отношения не имеет, это имеет отношение к risk management.
E>Ну, например, есть в Магнитогорске контора КомпасПлюс, которая когда-то делала SCADA "Флора". Но со SCADA дела шли не очень, поэтому "Флору" переориентировали на банковские системы.
При чем тут рутинность?
E>В связи с этим интересен такой феномен, который мне доводилось несколько раз наблюдать: после перехода на Java разработчики вдруг становились сторонниками исключительно готовых, кем-то где-то разработанных библиотек и компонентов.
Ты скорее всего спутал сторонников готовых компонентов со сторонниками стандартизации решений. Это не одно и то же.
... << RSDN@Home 1.2.0 alpha 4 rev. 1106 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
E>>Ну, например, есть в Магнитогорске контора КомпасПлюс, которая когда-то делала SCADA "Флора". Но со SCADA дела шли не очень, поэтому "Флору" переориентировали на банковские системы.
AVK>При чем тут рутинность?
Вот к этим твоим словам:
Да нет, вот как раз реализация одних и тех же алгоритмов кластеризации и хождение по граблям, по которым уже прошла куча народу — это и есть рутина.
Разработчики "Флоры" наверняка прошлись по каким-то граблям, по которым уже ходили. Но вряд ли они сами считали свою работу рутиной. Да и результат этой рутины получился довольно успешный.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndrewVK, Вы писали:
M>> В большиснтве случаев все принципиально реализуемо AVK>И что? Все что принципиально реализуемо — рутина? Тогда все коммерческое программирование и 99% некоммерческого у тебя рутиной получается.
Да уж, если правда оно, ну хотя бы на треть...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
O>>Давно заметил что когда программисты начинают рассуждать о чемто кроме программирования, зачастую они становяться похожими на бухгалтерш, рассуждающих о программировании. AVK>Статья, вообще то, исключительбно о программировании.
Я вощето имел ввиду программистов, косящих под литературных критиков
Как много веселых ребят, и все делают велосипед...
Здравствуйте, eao197, Вы писали:
E>>> Но вряд ли они сами считали свою работу рутиной. AVK>>Ха. Ну таким аргументом можно что угодно доказать. E>А у тебя есть какие-то объективные критерии оценки того, является ли какая-то работа рутиной или нет?
А у тебя такие критерии есть? Я вот по-соседству вывел
, что "рутина", она вообще только в мозгах наблюдателя.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Отсюда вывод, что твоё доопределение рутины нужно перефразировать так:
ГВ>
ГВ>- неосознанно выполняются повторяющиеся (ставшие обычными) действия;
ГВ>- по мнению субъекта не существует возможности отказаться от существующего положения вещей (нет желания или он сознательно игнорирует возможности сменить/заменить/изменить выполняемые действия).
Такое определение выглядит лучше моего, но мне кажется, что "неосознано" в первом пункте конфликтует с "сознательно игнорирует" во втором.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
ГВ>>- неосознанно выполняются повторяющиеся (ставшие обычными) действия;
ГВ>>- по мнению субъекта не существует возможности отказаться от существующего положения вещей (нет желания или он сознательно игнорирует возможности сменить/заменить/изменить выполняемые действия).
E>Такое определение выглядит лучше моего, но мне кажется, что "неосознано" в первом пункте конфликтует с "сознательно игнорирует" во втором.
Хорошо, давай заменим:
- по мнению субъекта не существует возможности отказаться от существующего положения вещей (нет желания или он игнорирует возможности сменить/заменить/изменить выполняемые действия следуя устоявшемуся обычаю).
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Хорошо, давай заменим:
ГВ>
- по мнению субъекта не существует возможности отказаться от существующего положения вещей (нет желания или он игнорирует возможности сменить/заменить/изменить выполняемые действия следуя устоявшемуся обычаю).
А как быть с организациями, в которой подавляется инициатива по изменению каких-то устоявшихся процессов?
Кроме того, если он игнорирует возможности, значит у него нет на это желания. Так что фраза "нет желания или он игнорирует" мне не нравится.
Может тогда так:
- по мнению субъекта не существует возможности отказаться от существующего положения вещей (субъект не имеет возможности или желания сменить/заменить/изменить выполняемые действия следуя устоявшемуся обычаю).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>А как быть с организациями, в которой подавляется инициатива по изменению каких-то устоявшихся процессов?
Очень просто: те, от кого исходит такое подавление и являются рутинёрами, которые превращают работу в скучную рутину.
E>Кроме того, если он игнорирует возможности, значит у него нет на это желания. Так что фраза "нет желания или он игнорирует" мне не нравится.
E>Может тогда так: E>
- по мнению субъекта не существует возможности отказаться от существующего положения вещей (субъект не имеет возможности или желания сменить/заменить/изменить выполняемые действия следуя устоявшемуся обычаю).
Нет-нет. Здесь нельзя вовлекать характеристики контекста. Исходное ожеговское определение очень точное на самом деле — именно тупое следование обычаю и является самой точной характеристикой.
Поэтому, я думаю, должно быть так:
E>
- по мнению субъекта не существует возможности отказаться от существующего положения вещей (субъект намеренно игнорирует возможности, или не хочет сменить/заменить/изменить выполняемые действия, предпочитая следовать устоявшемуся обычаю).
Кстати, я бы не сказал, что корпоративные рутинёры действуют неосознанно. Как раз попытки что-то поменять они отбивают очень даже чутко.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Vzhyk, Вы писали:
V>eao197 пишет: >> >>> > V>Как пример классика: что выгоднее 10 програмеров по 1000 или 3 по 2500? >>> > >>> > It depends. >> V>А вот тут интересно, расскажи про свою арифметику. >> >> Если задача конторы состоит в поиске и правке багов "поехало >> форматирование в форме NNN под Opera 9.5 на SuSe Linux" или настройке 1C >> в сотне-другой мелких торговых организаций, то выгода от 3 по 2500 не >> так уж и очевидна. V>Вот именно, теперь вопрос а нафига для такой конторы спецы, когда вполне V>хватит обезьянок? V>Дальше, спрос на спецов определяется конторой, точнее заказами, которые V>эта контора выполняет. И тут всплывает ньюанс, что на выполнении простых V>заказов и небольших прибыль моет оказаться выше, чем на крутых и сложных V>заказах (рисков в них больше). V>Т.е. спрос начинает увеличиваться на обезьянок и уменьшаться на спецов. V>Но спецы то сами не возникают из ничего, чтобы стать спецом, человек V>должен сначала поучиться у других спецов. V>Итог всего выше: спецы локализуются в тех местах, где на них есть спрос V>и где можно стать спецом.
Как показывает практика в таких конторах обезьянок большинство и они своим трудом затрахали не только себя, но и остальных
Здравствуйте, LaptevVV, Вы писали:
LVV>Например, кандидатская диссертация Баяковского Юрия Матвеевича — это графическая система, которая работала во всех вычислительных центрах Советского Союза... Нынешним кандидатам такое и не снилось.
Не знал, что Графор — это диссертация. Было еще несколько подобных библиотек, но живыми я их не видел. А Графор нормально работал на PC еще в конце 90-х в MS DOS. В самом деле удобный инструмент.
LVV>В общем, серьезные раньше люди были, серьезные...
Они и сейчас есть. Только наработки уровня того же Графора сейчас превращаются не в диссертации, а в звонкую монету.
M>Java-программисты не пишут отказоустойчивых кластерных приложений! Они фактически производят сборку и настройку готового приложения. Готового в виде отдельных блоков.
Давайте не будем обобщать и говорить о том, чего, судя по всему, вы не знаете.
Java-программисты бывают очень разными.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Michael7, Вы писали:
M>>Java-программисты не пишут отказоустойчивых кластерных приложений! Они фактически производят сборку и настройку готового приложения. Готового в виде отдельных блоков. C>Это фантастика... В Java, действительно, больше инструментов для разработки кластерных приложений, но они сам по нажатию кнопки "Next" в визарде не делаются.
Кстати имхо как раз из-за чрезмерного увлечения визардами и всякими "квадратиками" (без понимания стоящих за ними механизмов) получаются всякие корпоративные "монстры", глючные, на жутко дорогом железе и т.п. (сам работал пару лет назад в одном интеграторе, наблюдал подобное)
Так что доля правды в этих словах всё-таки имеется, пусть и не большая.
Здравствуйте, Курилка, Вы писали:
К>Давайте не будем обобщать и говорить о том, чего, судя по всему, вы не знаете. К>Java-программисты бывают очень разными.
Извиняюсь, если кого задел. Я не обобщаю. Мои слова надо понимать в контексте ответа на пример с написанием кластерной системы. Причём, возможно, на той же Java создаётся что-то другое, очень сложное.
Здравствуйте, Michael7, Вы писали:
M>Извиняюсь, если кого задел. Я не обобщаю. Мои слова надо понимать в контексте ответа на пример с написанием кластерной системы. Причём, возможно, на той же Java создаётся что-то другое, очень сложное.
Ты видел Apache Hadoop? Это система, практически повторяющая гугловскую инфраструктуру (BigTable, MapReduce, GFS) для массивных вычислений. Yahoo использует её на кластерах в 3000 компьютеров.
Здравствуйте, Michael7, Вы писали: M>Java-программисты не пишут отказоустойчивых кластерных приложений! Они фактически производят сборку и настройку готового приложения. Готового в виде отдельных блоков.
Программисты на ассемблере не пишут приложений. Они фактически производят сборку и настройку готового приложения. Готового в виде микропрограмм процессора.
, о том "как все начиналось", о перспективах отрасли.
Если нам не помогут, то мы тоже никого не пощадим.
, очень в унисон с нынешней политикой в области образования. Почему я в итоге не удивлён, что подобные излияния попали на polit.ru? 
))))))))
. И не потому что я такой дурак, а потому что даже если что-то где-то тормозило, то злобные профайлеры показывали узкие места совсем не в сортировке — а в ошибках алгоритмики или API вызовах 
Тоже не сердитесь — ставлю смайлик 
