Что за зверь кодер? - Философия программирования

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

AC>Здравствуйте, Павел Кузнецов, Вы писали:

>>> Кодеру знать нужно ровно то, что от него требует работодатель. Хороший же программист <...>
ПК>>Вот никак не могу понять, что такое "кодер"

Junior Software Engineer/Developer/Programmer — понимаю.

AC>Можно попробывать с другой стороны. Вот у вас конвеер. Например, ваша конора на VB клепает формочки по шаблону сделанному действительно хорошим программером, ну или на MFC/MSVC, на чём, собственно говоря, не важно . Важно то, что есть детерминированная рутинная последовательность действий, теребующая соблюдения от человека техпроцесса, но не полёта мысли и самостоятельного решения проблемы. Вот эти работники конвеера и есть кодеры. А уж что они там пользуют и какой у них скил, это уже детали. Важно, что такой человек это винтик. Для него приоритетно не умение решить поставленную задачу или самому её ставить на основе требований, а соблюсти техпроцесс и не выёживаться.

Эх! Люблю фантазии!

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

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

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

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

Возмём библу X и и сварганим Y. Вы не согласны, что это 'кульная' идеология? Дык от неё куча народа на форуме тащится. Ремесло в чистом виде. Знание того, как присоедениь A к B чтобы выполнить задание. ИМХО, вот что требуется индустрии. И это и есть кодер. Всё, что от него требуется знать как соеденить A и B c помощью либы X.

Подставьте вместо X: MFC, ATL, STL, BOOST. Ведь в принципе, на уровне соеденить A и B, ну никакой разницы.

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

ГВ>Здравствуйте, Alexey Chen, Вы писали:

AC>>Здравствуйте, Павел Кузнецов, Вы писали:

>>>> Кодеру знать нужно ровно то, что от него требует работодатель. Хороший же программист <...>
ПК>>>Вот никак не могу понять, что такое "кодер"

Junior Software Engineer/Developer/Programmer — понимаю.

AC>>Можно попробывать с другой стороны. Вот у вас конвеер. Например, ваша конора на VB клепает формочки по шаблону сделанному действительно хорошим программером, ну или на MFC/MSVC, на чём, собственно говоря, не важно . Важно то, что есть детерминированная рутинная последовательность действий, теребующая соблюдения от человека техпроцесса, но не полёта мысли и самостоятельного решения проблемы. Вот эти работники конвеера и есть кодеры. А уж что они там пользуют и какой у них скил, это уже детали. Важно, что такой человек это винтик. Для него приоритетно не умение решить поставленную задачу или самому её ставить на основе требований, а соблюсти техпроцесс и не выёживаться.

ГВ>Эх! Люблю фантазии!

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

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

Я вот тоже не хочу работать винтиком. И не работаю.
Но даже беглый взгляд по форумам C/C++ показывает, что большинство вопросов -- из серии, "как присобачить вот эту ...ню вот к этой ...не".
Т.е. спрос на винтиков и желание и готовность ими быть наличиствуют. Фактически, творческий программмист -- это исключение, а не правило.

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

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

AC>Хм, вы против конвеера?
В программировании — да. Ещё уточню: под "конвейером" я понимаю такое разделение труда, которое подразумевает обязательное наличие низкоквалифицированных программистов (кодеров).

AC>Это выгодно,
Нет. Это не выгодно. Это — предсказуемо. Больше ничего. И то, как правило, предсказуемо в том смысле, что мы всегда сможем сказать, что нечто есть долго и дорого, и нечто иногда — очень долго и очень дорого.

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

AC>и пока это выгодно попытки изничтожить будут приравнены к фанатизму.
Не исключаю, что таких приравнивателей даже будет большинство. Когда-то, если не ошибаюсь, Нильс Бор отказался выставить свои положения на голосование, мотивировав отказ формулировкой: "Дураков всегда больше". Надеюсь, аналогия достаточно понятна?

Аутотренинг on
AC>Мне творить тоже нравиться, но _это_ — индустрия. Индустрия сборки софта из кубиков и подгонки готовых шаблонов под кастомера. Эта работа не требует полёта фантазии, но чувствительна к выполнению поручений менеджера.

Аутотренинг off (Здесь нужно добавить ещё гласных и разбавить глаголами. Эффект будет сильнее.)

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

AC>Возмём библу X и и сварганим Y. Вы не согласны, что это 'кульная' идеология?
Она никак не связана с понятием конвеера. Разумеется, под любую деятельность можно подвести понятие "конвеер". В конце концов, всегда нужны:

— постановка задачи (неважно, в каком конкретно виде)
— понимание путей её решения (это есть анализ);
— реализация решения (это есть девелопмент);
— проверка адекватности решения (читай: QA).

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

AC>Дык от неё куча народа на форуме тащится. Ремесло в чистом виде. Знание того, как присоедениь A к B чтобы выполнить задание.

Стоп. Снова думаем. А сами задания-то каковы? Они что, совершенно одинаковы? Если да, то почему эта работа до сих пор не автоматизирована в прямом смысле слова? Почему нет библиотеки готовых решений, которые можно использовать одним пальцем ноги? Это же было бы выгодно! А если задания разные, то где гарантия, что с 99% из них кодер просто не управится?

AC>ИМХО, вот что требуется индустрии. И это и есть кодер. Всё, что от него требуется знать как соеденить A и B c помощью либы X.
AC>Подставьте вместо X: MFC, ATL, STL, BOOST. Ведь в принципе, на уровне соеденить A и B, ну никакой разницы.

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

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

Реальные причины можно найти, если учесть такие факторы.

1. Хороших программистов всегда мало.
2. Рынок информационных продуктов (особенно, неординарных) всегда ёмкий, ergo, они програмисты из п.1 всегда нужны.
3. Быстро находить адекватные решения сложных проблем мы ещё не научились (не доросли ещё...).

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

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

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

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

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

Так что, ни в коем случае не стоит считать эту, в сущности, патологию развития конечной целью. Мы, в конце концов, на кормёжку балбесов ориентируемся или на выпуск продуктов? Кстати, и индустрии требуются на самом деле не кодеры, а те, кто сможет написать продукт.

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

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

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

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

Ш>Я вот тоже не хочу работать винтиком. И не работаю.
Ш>Но даже беглый взгляд по форумам C/C++ показывает, что большинство вопросов -- из серии, "как присобачить вот эту ...ню вот к этой ...не".
Ш>Т.е. спрос на винтиков и желание и готовность ими быть наличиствуют. Фактически, творческий программмист -- это исключение, а не правило.

Не спорю. Только что в этом хорошего?

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

Здравствуйте, Геннадий Васильев

Очень интересное письмо, но я вынужден с ним не согласиться.

AC>>Хм, вы против конвеера?
ГВ>В программировании — да. Ещё уточню: под "конвейером" я понимаю такое разделение труда, которое подразумевает обязательное наличие низкоквалифицированных программистов (кодеров).

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

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

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

Так же и в программировании. Есть архитекторы, есть главные программисты, есть программисты (кодеры), есть менеджеры. Можно ли сравнивать степень важности каждого из них? На ком-то действительно лежит большая ответственность. Но все они должны быть проффессиональными.

Но проффессионализм архитектора и кодера разный. Уровень знаний и умений у них разный. Должен ли программист разбираться в тонкостях технологии или обладать таким же объемом знаний о всей системе, как архитектор? Вряд ли. Зато кодер должен сделать свою работу точно, качественно и в срок. При этом он, естественно, должен хорошо владеть технологией (будь то STL, Boost, MFC, ATL, Swing, Corba, JSP, EJB, ...), но главные его качества, имхо, в другом. Он, в отличии, от архитектора (т.к. творчество вряд ли можно вместить в жесткие рамки), должен быть надежен, взаимозаменяем и предсказуем. И, есть у меня такое подозрение, эти качества не так уж часто встречаются. Например, имхо, большинство участников форума "Философия программирования" просто не смогут быть кодерами, т.е. не смогут качествено и надежно выполнять монотонную однообразную работу в течении длительного времени (не важно, что именно это будет -- рисование формочек, вклепывание чего-то в БД, тестирование и др.).

И здесь можно затронуть вопросу о том, почему кто-то является кодером, а кто-то нет. Имхо, причин здесь может быть много. Например, как в моем случае, амбиции и вера в то, что я могу что-то придумать и самостоятельно довести придуманное до реализации (и в моем случае есть две проблемы: во-первых, я могу ошибаться о своих способностях, во-вторых, не правильно в наше время что-то делать самостоятельно). У кого-то еще могут быть свои причины.

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

Более того, по словам Суворова (поководца), самый важный человек в армии -- это солдат. Так и в программировании, чем больше проект, тем важнее в нем роль кодера. Если взять мой проект объектного хранилища ObjESSty, то моих способностях в нем на долго не хватит. Если он будет развиваться, то неизбежно настанет момент, когда потребуются дополнительные рабочие руки. Причем не амбициозные архитекторы со своими идеями, которые захотят повернуть ObjESSty в свою сторону, а именно добросовесные исполнители, которые точно и качествено воплотят мои идеи, которые я не в состоянии сделать сам. Что в этом плохого? Только то, что амбициозные товарищи, вроде меня, вряд ли захотят быть винтиками в таком проекте. Но именно винтики (в самом хорошем смысле) и нужны будут для получения результирующего продукта.

... << RSDN@Home 1.1.4 beta 7 rev. 447>>

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

Интересный текст. Местами захватывающе интересный. Вам книжки писать надо. Это не подколка, но совершенно серьёзно.

Теперь же о наших баранах.

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

Это моё понимание конвеера. Поток заказов, разделение обязанностей, взаимозаменяемость. Про квалификацию ни слова. Почему? Дык разная она для разных 'профессий'. Кодер, девелопер (программист), архитектор (сис. аналитик) — это разные профессии, а не профессиональный рост. Это конечно моё ИМХО, но именно так я и считаю. И требования к людям для этих профессий зело разные.

Почему же вы хотите избавится от разделения труда? Думаете что это выгодно, посадаить человека, с аналитическим складом ума и опытом разработки распрелённых систем, дизайнить диалоги для мелкой аппликухи? Хм, для этого есть другие люди которые с этой задачей справятся _лучше_. Получается что их квалификация выше?

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

Вот интересный кусочек, который я бы хотел обсудить.
ГВ>Кстати, а не приходило Вам в голову, что конвейер часто становится почвой для заведомо неэффективных решений с мотивацией: "...ну и работу для себя тоже нужно сохранить".
Да я встречался с такой постановкой вопроса. Но чаще я встречался с вариантом: сделаем сейчас так, а потом когда это будет нужно, будем углублять и усугублять. Результат как бы один, но эффект разный.

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

Из крайности в крайность.

E>Можно провести еще одну аналогию -- больница. Врач назначает лечение. Но без медсестер и санитарок выздоровление вряд ли возможно. При этом и от врача и от медсестры требуются разные навыки и знания, а так же умения. Но что нужно обязательно -- это проффессионализм. Но, если есть хороший врач и хорошая медсестра, то можно ли врачу снисходительно отзываться о младшем медперсонале? Да, врачу потребовалось больше усилий и для получения диплома, и для получения места. И ответственность на нем лежит большая, чем на медсетре. За это врач и получает больше. Но реально ли он более важен? Имхо, здесь вообще степень важность сравнивать вряд ли возможно, т.к. занимаются они разными вещами но в одной области -- медицине.

E>Так же и в программировании. Есть архитекторы, есть главные программисты, есть программисты (кодеры), есть менеджеры. Можно ли сравнивать степень важности каждого из них? На ком-то действительно лежит большая ответственность. Но все они должны быть проффессиональными.
В этой аналогии, ты здесь забыл одну вещь. Каждый врач проверяется более старшим врачом (зав отделением).

И тут получается одна неприятность. Врача могут поправить более старший товарищ. Зав. отделением никто не поправит. Может стоит бороться не с врачом а именно с зав отделениями? В нашей аналогии получается главный программист must die.

Именно его ошибку никто не исправит, потому что никто кроме него никто ее не видит.

E>Но проффессионализм архитектора и кодера разный. Уровень знаний и умений у них разный. Должен ли программист разбираться в тонкостях технологии или обладать таким же объемом знаний о всей системе, как архитектор? Вряд ли. Зато кодер должен сделать свою работу точно, качественно и в срок.
Разделяй. Старший программист, junior и архитектор. Несколько разные вещи. А бить будут менеджера (и кстати правильно бить).

E>Он, в отличии, от архитектора (т.к. творчество вряд ли можно вместить в жесткие рамки), должен быть надежен, взаимозаменяем и предсказуем.
Это не должно быть свойство простого кодера. Это должно быть свойство самого процесса разработки. Есть два пути: первый путь вложиться в хороших программистов, и распространить информацию чтобы можно было в достаточной степени говорить о взаимозаменяемости. Второй путь, нанять мальчиков, и одного(несколько) хороших программистов. Которые уже отвечают за процесс и качество работы. К сожалению в жизни неоднократно встречался вариант — дешевый программист должен работать так, чтобы что-то и как-то заработало. Потом перепишем.

Что касается архитектора, то и он в особенности должен быть надежен, взаимозаменяем и предсказуем.

E>И, есть у меня такое подозрение, эти качества не так уж часто встречаются. Например, имхо, большинство участников форума "Философия программирования" просто не смогут быть кодерами, т.е. не смогут качествено и надежно выполнять монотонную однообразную работу в течении длительного времени (не важно, что именно это будет -- рисование формочек, вклепывание чего-то в БД, тестирование и др.).
Тут есть два интересных момента.
1. В большинстве своем коммерческое программирование именно из этого и состоит. Скучноватое занятие, поэтому лучше либо уходить в архитекторы, либо уходить в то малое где работа становится интересной.
2. Как бы ни старались выстроить процесс создание продукта из рисования формочек, всегда нет да и находится что-то интересное. И тут уже, человеку который хочет себя проявить — может всегда это сделать.

E>Но есть много программистов, для которых программирование -- это всего лишь работа. За счет своих способностей и старания они смогли стать программистами, а не, скажем, токарями. Но суть не меняется. Они садятся за компьютер не как художник за мольберт, а как токарь становится к станку. Можно ли их в чем-то обвинять или относиться к ним снисходительно? Обзывать их кодерами, говорить о низкой квалификации? Лично я бы не смог.
Сначало кодеры — это не обзывалово. Теперь кодер — оскорбление. Тебя и не поймешь.

E>Более того, по словам Суворова (поководца), самый важный человек в армии -- это солдат. Так и в программировании, чем больше проект, тем важнее в нем роль кодера.
Чем больше проект, тем больше роль менегера.

И вот это, и есть поле жизни хренового кодера.
E>Если взять мой проект объектного хранилища ObjESSty, то моих способностях в нем на долго не хватит. Если он будет развиваться, то неизбежно настанет момент, когда потребуются дополнительные рабочие руки. Причем не амбициозные архитекторы со своими идеями, которые захотят повернуть ObjESSty в свою сторону, а именно добросовесные исполнители, которые точно и качествено воплотят мои идеи, которые я не в состоянии сделать сам. Что в этом плохого?
Инициатива наказуема?
В этом очень много плохого. Я был свидетелем команд с одним очень амбициозным лидером. И тут опасность не только в том, что он может уйти, и все придется начинать сначала. После какого-то момента продукт начинал загнивать. Загнивает архитектор, который сидит в своих великих идеях и уже не может отойти от них ни влево не вправо. Он уже начинает в силу своей самодостаточности переставать стараться что-то кардинально изменить в лучшую сторону. И продукт вместо быстрого и кардинального развития функционала начинает обрастать рюшечками и винтиками. В результате в конкурентной борьбе он проигрывает новым продуктам созданных с нуля.

Мое IMHO не то, что все члены команды должны хорошо писать код. Процесс разработки достаточно хорошего кода легко выстраивается. Даже от хорошего профессионала легко получить хреновый код (правда он может сказать что он хреновый

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

С уважением, Gleb.

... << RSDN@Home 1.1.4 beta 4 rev. 358>>

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

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

GZ>Из крайности в крайность.

А то

Сначала, я хотел бы остановиться всего на нескольких моментах.

E>>Так же и в программировании. Есть архитекторы, есть главные программисты, есть программисты (кодеры), есть менеджеры. Можно ли сравнивать степень важности каждого из них? На ком-то действительно лежит большая ответственность. Но все они должны быть проффессиональными.
GZ>В этой аналогии, ты здесь забыл одну вещь. Каждый врач проверяется более старшим врачом (зав отделением).

И тут получается одна неприятность. Врача могут поправить более старший товарищ. Зав. отделением никто не поправит.

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

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

E>>Он, в отличии, от архитектора (т.к. творчество вряд ли можно вместить в жесткие рамки), должен быть надежен, взаимозаменяем и предсказуем.
GZ>Это не должно быть свойство простого кодера. Это должно быть свойство самого процесса разработки. Есть два пути: первый путь вложиться в хороших программистов, и распространить информацию чтобы можно было в достаточной степени говорить о взаимозаменяемости. Второй путь, нанять мальчиков, и одного(несколько) хороших программистов. Которые уже отвечают за процесс и качество работы. К сожалению в жизни неоднократно встречался вариант — дешевый программист должен работать так, чтобы что-то и как-то заработало. Потом перепишем.

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

GZ>Что касается архитектора, то и он в особенности должен быть надежен, взаимозаменяем и предсказуем.

Слабо себе представляю взаимозаменяемых Рострелли или Эйфеля.

E>>И, есть у меня такое подозрение, эти качества не так уж часто встречаются. Например, имхо, большинство участников форума "Философия программирования" просто не смогут быть кодерами, т.е. не смогут качествено и надежно выполнять монотонную однообразную работу в течении длительного времени (не важно, что именно это будет -- рисование формочек, вклепывание чего-то в БД, тестирование и др.).
GZ>Тут есть два интересных момента.
GZ>1. В большинстве своем коммерческое программирование именно из этого и состоит. Скучноватое занятие, поэтому лучше либо уходить в архитекторы, либо уходить в то малое где работа становится интересной.
GZ>2. Как бы ни старались выстроить процесс создание продукта из рисования формочек, всегда нет да и находится что-то интересное. И тут уже, человеку который хочет себя проявить — может всегда это сделать.

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

GZ>Инициатива наказуема?

А то:

Хуже дурака только дурак с инициативой

((С) из какого-то совецкого фильма)

GZ>Мое IMHO не то, что все члены команды должны хорошо писать код. Процесс разработки достаточно хорошего кода легко выстраивается. Даже от хорошего профессионала легко получить хреновый код (правда он может сказать что он хреновый

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

Именно так. Но при этом нет гонений на тех, кто не проявляет инициативу, а просто делает то, что ему говорят. И так как говорят. И тогда, когда говорят. Вот лично я крайне редко на такое способен

Вообще, мой пост был написан, чтобы отразить три тезиса:

1. Имхо, программирование не имеет смысла сравнивать с конвейером. Лучше со строительством. Или медициной. Потому как на конвейере можно себе представить "прикручивателя ручек к левой передней двери на автосборочном конвейере". А вот "маляра правой от входа стены" в строительстве представить сложно. Равно как и медсестру, чья специализация -- "уколы в левую ягодицу". Так и в программировании -- даже выполняющий рутинные операции программист должен обладать широким набором знаний, навыков и умений.

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

3. Хороших кодеров так же мало, как и хороших архитекторов, и хороших менеджеров. Поэтому их нужно ценить, а не относиться к ним с пренебрежительной иронией.

... << RSDN@Home 1.1.4 beta 7 rev. 447>>

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

ГВ>Здравствуйте, Шахтер, Вы писали:

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

Ш>>Я вот тоже не хочу работать винтиком. И не работаю.
Ш>>Но даже беглый взгляд по форумам C/C++ показывает, что большинство вопросов -- из серии, "как присобачить вот эту ...ню вот к этой ...не".
Ш>>Т.е. спрос на винтиков и желание и готовность ими быть наличиствуют. Фактически, творческий программмист -- это исключение, а не правило.

ГВ>Не спорю. Только что в этом хорошего?

Точно так же можно спросить, а что в этом плохого.
Это просто жизненная реальность. Которую вряд ли можно изменить.
Именно эта жизненная реальность привела к появлению таких языков "для индусов", как Java и С#.
Компании вынуждены использовать тех людей, которые есть в наличии.
И использовать те методы организации производства и технологии, которые способны дать результат.

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

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

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

E>Вот как раз такой посыл мне и не нравится. Какое-то деление на программистов первого и второго сорта. Дешевизна программиста может проитекать либо от недостаточного опыта/объема знаний (ну студент, например, некогда еще было опыт приобрести), либо от кривизны рук. Если речь идет о недостатке опыта, то можно строить из себя суперкрутых программистов и подчеркивать, что он, мягко говоря, кодер. А можно построить в команде нормальное обучение новых людей. Чтобы постепенно поднять их проффессиональный уровень на достаточную высоту.
E>А если речь идет о кривых руках, то гнать нужно в шею. И все.

А тут речь не только о кривых руках и мягких мозгах. Суперкрутые программисты тоже люди. И очень любят гнать пургу в коде. Только вид при этом сохраняют очень умный

E>Слабо себе представляю взаимозаменяемых Рострелли или Эйфеля.

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

GZ>>Инициатива наказуема?
E>А то:
E>

E>Хуже дурака только дурак с инициативой

E>((С) из какого-то совецкого фильма)
Именно совецкого. Советского строя уже нет, а любовь к тому чтобы все строем ходили осталась.

Категорически не согласен.
IMHO Для меня дурак с инициативой значительно более ценен чем умный но безинициативный. С ним сложнее работать, но иногда он и меня выставляет дураком.

GZ>>Мое IMHO не то, что все члены команды должны хорошо писать код. Процесс разработки достаточно хорошего кода легко выстраивается. Даже от хорошего профессионала легко получить хреновый код (правда он может сказать что он хреновый

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

E>

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

E>Вообще, мой пост был написан, чтобы отразить три тезиса:
[три июньского тезиса скипнуты, возражать не собираюсь]

Мой пост написан в двух тезисах:
1. Можно не зарекаться на профессионализм кодера (который во первых надо взращивать, во вторых каждый умный может выглядеть дураком). Нужно строить процесс так, чтобы не было зависимости от профессионализма конкретного кодера.
2. Инициатива более важна для процесса разработки. Качеством разработки еще можно контролировать и управлять. Генерацией новых идей уже труднее. А один инициативный на 10 тихонь — очень плохо. Продукт силен командой а не одним человеком.

С уважением, Gleb.

... << RSDN@Home 1.1.4 beta 4 rev. 358>>

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

E>>Слабо себе представляю взаимозаменяемых Рострелли или Эйфеля.

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

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

GZ>>>Инициатива наказуема?
E>>А то:
E>>

E>>Хуже дурака только дурак с инициативой

E>>((С) из какого-то совецкого фильма)
GZ>Именно совецкого. Советского строя уже нет, а любовь к тому чтобы все строем ходили осталась.

Категорически не согласен.
GZ>IMHO Для меня дурак с инициативой значительно более ценен чем умный но безинициативный. С ним сложнее работать, но иногда он и меня выставляет дураком.

Ну здесь я придерживаюсь другого мнения.

E>>Именно так. Но при этом нет гонений на тех, кто не проявляет инициативу, а просто делает то, что ему говорят. И так как говорят. И тогда, когда говорят.
GZ>А гонений таких людей не бывает. Таких очень менеджеры любят. Только и зарплату меньше платят.

Так а если человека такое положение вещей устраивает, то почему бы и нет.

GZ>Мой пост написан в двух тезисах:
GZ>1. Можно не зарекаться на профессионализм кодера (который во первых надо взращивать, во вторых каждый умный может выглядеть дураком). Нужно строить процесс так, чтобы не было зависимости от профессионализма конкретного кодера.
GZ>2. Инициатива более важна для процесса разработки. Качеством разработки еще можно контролировать и управлять. Генерацией новых идей уже труднее. А один инициативный на 10 тихонь — очень плохо. Продукт силен командой а не одним человеком.

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

А вообще, нужно привести одну байку для прояснения моей позиции:

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

Так вот в моем представлении кодер, это тот, кто после выполнения очередного задания приходит и спрашивает: "Что мне делать дальше?".

... << RSDN@Home 1.1.4 beta 7 rev. 447>>

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

E>Собственно, Эйфель как раз был выдающимся инженером, чей технический (а не организационный) талант позволил построить одноименную башню в Париже, да и не только ее. Например, сам Эйфель разработал правила техники безопасности при строительстве так, что не было ни одного серьезного инцидента, не говоря уже о смертельных случаях.
Много воды уже утекло с тех пор. Хотя и при строительстве Останкино (не помню архитектора) идея обеспечения устойчивасти изнутри принадлежит именно архитектору, существовало очень много людей которые расчитывали фундамент крепление и материалы(по моему этим занимался целый институт).

E>Так а если человека такое положение вещей устраивает, то почему бы и нет.
Низкая зарплата человека устраивает?

E>А вообще, нужно привести одну байку для прояснения моей позиции:
E>

E>Говорят, что когда в лабораторию к Резерфорду приходил новый сотрудник и спрашивал: "Что мне делать?", Резерфорд давал ему задание. Если после выполнения задания этот сотрудник приходил еще раз и спрашивал: "Что мне делать дальше?", то Резерфорд увольнял его.

Гениально! Не даром его учеником был некто Нильс Бор, а не безымянный кодер.
E>Так вот в моем представлении кодер, это тот, кто после выполнения очередного задания приходит и спрашивает: "Что мне делать дальше?".
Нет. Если он не пришел и не спросил "Что делать дальше?", то это анархист и саботажник.

Хороший человек отличается от бяки тем, что не спрашивает: "Как делать?". Тут у него поле для инициативы и творчества. И в том числе и ошибок.

С уважением, Gleb.

... << RSDN@Home 1.1.4 beta 4 rev. 358>>

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

E>>Так а если человека такое положение вещей устраивает, то почему бы и нет.
GZ>Низкая зарплата человека устраивает?

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

E>>А вообще, нужно привести одну байку для прояснения моей позиции:
E>>

E>>Говорят, что когда в лабораторию к Резерфорду приходил новый сотрудник и спрашивал: "Что мне делать?", Резерфорд давал ему задание. Если после выполнения задания этот сотрудник приходил еще раз и спрашивал: "Что мне делать дальше?", то Резерфорд увольнял его.

GZ>Гениально! Не даром его учеником был некто Нильс Бор, а не безымянный кодер.

Именно так, но ведь Резерфорд не занимался производством.

E>>Так вот в моем представлении кодер, это тот, кто после выполнения очередного задания приходит и спрашивает: "Что мне делать дальше?".
GZ>Нет. Если он не пришел и не спросил "Что делать дальше?", то это анархист и саботажник.

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

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

Такое мое имхо.

... << RSDN@Home 1.1.4 beta 7 rev. 447>>

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

ГВ>>Не спорю. Только что в этом хорошего?

Ш>Точно так же можно спросить, а что в этом плохого.
Ш>Это просто жизненная реальность. Которую вряд ли можно изменить.
Ш>Именно эта жизненная реальность привела к появлению таких языков "для индусов", как Java и С#.

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

Ключевое слово: вынуждены. Попробую провести аналогию. Некто вынужден покупать полупротухшую колбасу, потому что другой в его краях нет. И она (полутухлая колбаса) — продаётся. Если привязаться к тому, что "она продаётся", то вскоре получаем естественное следствие в виде вопроса: "Насколько тухлой должна быть колбаса, чтобы её можно было продать?" Если же не забывать о главном — о желании потребителя приобрести максимально свежую и вкусную колбасу, то получим другое следствие в виде вопроса "Какой козёл прислал сюда тухлятину?" Ранее же прозвучавший вопрос (Насколько тухлой должна быть колбаса?) выглядит вообще абсурдом.

Ш>И использовать те методы организации производства и технологии, которые способны дать результат.

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

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

	От:	Павел Кузнецов
	Дата:	07.06.05 23:01
	Оценка:	1 (1) +7 -2

	От:	Alexey Chen
	Дата:	08.06.05 06:50
	Оценка:	1 (1) +2

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	13.06.05 18:08
Оценка:	-3

	От:	Alexey Chen
	Дата:	13.06.05 18:36
	Оценка:	1 (1) +3

	От:	Шахтер
	Дата:	14.06.05 02:04
	Оценка:	12 (1) +1

От:	eao197	http://eao197.blogspot.com
Дата:	14.06.05 07:58
Оценка:	192 (19) +3

	От:	GlebZ
	Дата:	15.06.05 10:57
	Оценка:	+1

	От:	AndrewJD
	Дата:	15.06.05 18:26
	Оценка: