Кстати, действительно "про меня" — только не с той стороны. Ты сам-то читал что там написано и где именно я противоречу этому, если вообще противоречу?
Здравствуйте, FR, Вы писали:
TL>>Не вопрос. Что именно в современном решении задач ИТ используется "несерийного"?
FR>Я не про решение задач IT я про производство софта, это в чистом виде ОКР, который если и требует "рабочих" то FR>высококвалифицированных.
Я ж не против. И вообще не надо программистов обижать: они ре "рабочие" и не "ремесленники" и даже не "инженера" — они "художники"!
Здравствуйте, The Lex, Вы писали:
TL>Здравствуйте, samius, Вы писали:
S>>Конечно, они решали разные задачи, но связка 3 в одном оказывалась более плодовита чем команда людей с разными специализациями. Случаев явно маловато для того чтобы говорить о каких-то правилах, но они имеют место.
TL> Ровным счетом ни о чем не говорит — бардак с тем же успехом организовывается и в собственной голове "3 в 1". С тем же успехом на всех без исключения научных производствах (не знаю как назвать: производящих науку в общем — научными исследованиями занимающихся) можно выгонять лаборантов и техников и пускай "умы" занимаются рутиной всякой в т.ч. — ведь им легче "самим с собой договориться"?
Я ведь ничего не предлагал, только привел факты. Более того, могу сказать что там, где я работал, таких 3в1 лишь единицы на несколько сотен узких спецов.
Кстати, для некоторых задач требуется не 3 типа специалистов, а 4! Есть так называемые расчетчики — люди, которые знают как задачу запустить, куда положить начальные данные, где взять результаты промежуточных вычислений, куда и как их подсунуть, и в конце концов откуда забрать результаты. Для некоторых задач существуют целые отделы расчетчиков (со своими начальниками, замами и т.п.), которые в несколько смен много лет "считают" задачу. И я не предлагаю оставить их без работы. Мне немного не нравится, куда идут налоги, но это не самый вопиющий случай
Здравствуйте, Niemand, Вы писали:
N>Еще интересный момент который заметил (много общаюсь со знакомыми на эту тему). Собеседования типа "встретились, попили пива, поговорили о жизни" практикуются как правило в стартапах.
Из стартапов выстреливает один из десяти
>А потом все скатывается в i++++i и зачем нужен виртуальный деструктор (кстати на этом вопросе закончилось мое самое короткое 3х-минутное собеседование в CDD).
А потом надо и деньги зарабатывать.
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, Ларик, Вы писали:
Л>MSXML чтение запись, выбор, перебор, поиск, больше ничего не делал и т.д. Л>Разумеется по поводу узких технологий. Л>Эта тактика изначально провальная? Л>Или она честная и мы не будем тратить время друг друга понапрасну?
Знания и умения это не самая большая часть того, что человек может принести в команду.
Знания устаревают, а умения решать уже решенные задачи не требуются. Нужны умения решать новые задачи, усваивать новые знания.
Поэтоу тактика абсолютно честная в случае честного подхода и изначально провальная.
Материал из Википедии — свободной энциклопедии, -_*
> Т.е. если человек тупой, то он ремесленник, если человек умный, то он инженер, а если особо умный, то ученый. Исключительно глубокая мысль.
если человек имеет низкое абстрактное мышление — то он рабочий,
если более высокое — то инженер,
если имеет очень развитое абстрактное мышление — то он ученый.
навык декомпозиции — это часть абстрактного мышления.
U>Управленец занимается обеспечением разработки продукта ресурсами: кадрами, материалами, финансами
этим занимается снабжение, а не управленец(менеджер). т.е. устранением противоречий между возможностями поставщиков и требованиями организации — занимается снабжение.
U>, а также оцениваем нужность и качество продукта с точки зрения заказчика.
этим занимается маркетинг, а не управленец. т.е. устранением противоречий между желаниями заказчика и возможностями организации — занимается маркетинг.
> Собственно разработкой управленец не занимается, для этого у него нет достаточной квалификации, разработкой занимаются инженеры.
у меня складывается впечатление, что ты всю непроизводственную составляющую стрижешь под одну гребенку.
на самом деле деле там проблемы и задачи разные, и решаются разными людьми, разными способами.
и еще раз повторю, что основная задачу управленца — это устранить противоречия между людьми
DG>>ты кстати сколько можешь назвать требований к хорошо сделанной форме?
U>В смысле? Это к чему вопрос?
я утверждаю, что требований к форме слишком много, они очень противоречивы. готовой инструкции по разрешению этих противоречий нет,
поэтому для создания хорошей формы требуется человек со значительно развитым навыком абстрактного мышления — а это и есть инженер(программист), а не рабочий(кодировщик).
U>Вот тот человек, который декомпозицию задачи умеет делать только в голове, это ремесленник. А тот кто способен сделать декомпозицию задачи понятной другим людям это инженер.
уметь объяснить другим, то что уже есть в голове — это довольно простой навык, которому легко обучить (за год точно можно справиться)
U>Т.е. Монро был не просто умный, а очень умный, значит, он даже не инженер, а цельный ученый. Глубина мысли поражает.
вот быть умным (уметь развитый навык абстрактного мышления и соответственно уметь решать сложные задачи) — учить намного сложнее.
обучение абстрактному мышлению на текущий момент занимает 15 лет. и школа, и институт — наивным образом пытаются развить именно этот навык.
кстати, абстрактное мышление — это один из немногих навыков — который отличает человека от животного.
и получается, что важнее уметь выделять умных (а потом их учить формулировать свои знания для других), чем делить людей на "ремесленников" и "конструкторов", и фактически руководствоваться тем, что способности людей даны от рождения, менять их нельзя, и поэтому нефига людей вообще ничему обучать.
U>Такой недоконструктор может в лучшем случае выступать в роли эксперта, но никак не руководить разработкой.
более верное утверждение, что такая пара будет менее эффективна, чем один человек, за счет затрат на коммуникацию между ними.
и руководить разработкой сможет, просто чуть менее эффективно.
про тебя похоже.
TL> Гапертон — тренер.
не, он занимался какими-то биржевыми роботами, там типо того что чудеса — его гуру летал и у него один раз получилось
но сейчас эту муть об'ли два норвежца http://profi-forex.org/news/entry1008056551.html и кажется это может любой д..
Здравствуйте, DarkGray, Вы писали:
DG>если человек имеет низкое абстрактное мышление — то он рабочий, DG>если более высокое — то инженер, DG>если имеет очень развитое абстрактное мышление — то он ученый.
И какие практические выводы следуют из этого гениального наблюдения? Что-то типа, если у вас работа над проектом идет плохо, увольте программистов и наберите более умных? Очень глубокий и полезный вывод.
Вот из индустриальной организации труда в программировании следуют следующие практические выводы:
1) В проекте необходимо выделить конструктора, т.е. человека, который будет освобожден от рутинной работы и за счет этого все свои усилия сможет тратить на понимание задачи как единого целого. Такая работа требует следующих навыков: а) способность понять задачу как единое целое б) способность разбить задачу на слабо связанные между собой подзадачи в) способность доступным языком донести имеющееся в голове разбиение общей задачи на подзадачи до других программистов
2) В проекте необходимо выделить технолога, т.е. человека, который будет освобожден от рутинной работы и за счет этого все свои усилия сможет тратить на выделение типовых задач в проекте и разработки типовых решений для таких задач. Также задачей технолога является помощь программистам-рабочим в сложных местах решаемых задач.
3) В проекте должны быть программисты-рабочие различной квалификации, от невысокой — для выполнения рутинной работы, до очень высокой — для написания, к примеру, сложных алгоритмов.
DG>и получается, что важнее уметь выделять умных (а потом их учить формулировать свои знания для других), чем делить людей на "ремесленников" и "конструкторов", и фактически руководствоваться тем, что способности людей даны от рождения, менять их нельзя, и поэтому нефига людей вообще ничему обучать.
Не понял откуда следует, что для рабочего должен быть закрыт путь в конструкторы или технологи? Вон у Форда вообще все нанимаемые инженеры должны были в начале пару лет отработать рабочими. Это оттого, что Форд ничего не понимал в индустриальном методе производства или оттого, что рабочий не может стать инженером?
U>И какие практические выводы следуют из этого гениального наблюдения? Что-то типа, если у вас работа над проектом идет плохо, увольте программистов и наберите более умных? Очень глубокий и полезный вывод.
теперь можно целенаправленно подбирать людей на проект.
т.е. можно еще до начала проекта на основе оценки сложности проекта — оценить люди с какой квалификацией нужны для его выполнения.
также можно прикинуть что нужно делать если людей нужной квалификации не хватает.
можно каждую работу измерить сколько единиц каждого навыка необходимо для ее исполнения, смотреть какие есть кандидаты и принимать решения кого куда поставить, чему научить и т.д.
U>Вот из индустриальной организации труда в программировании следуют следующие практические выводы:
U>1) В проекте необходимо выделить конструктора .. U>2) В проекте необходимо выделить технолога .. U>3) В проекте должны быть программисты-рабочие различной квалификации, от невысокой — для выполнения рутинной работы, до очень высокой — для написания, к примеру, сложных алгоритмов.
вот только опыт показывает, что хорошие изобретения были сделаны когда и конструкторское мышление, и технологическое мышление, и изготовление были сконцентрированы в одном человеке.
автомат калашникова, ил-2, форд-т и т.д. были сделаны людьми, которые совмещали в себя и конструктора, и технолога, и исполнителя.
форд еще это смешивал с менеджерскими навыками.
в тоже время форд совсем упускал из виду и игнорировал маркетинговую составляющую (и на этом его сделал крайслер)
специализация имеет серьезные минусы, возрастают затраты на коммуникацию.
в идеальном мире (где люди могут развиваться бесконечно) — хотелось бы, чтобы каждый человек имел и конструкторское мышление, и технологическое, и менеджерское, и маркетинговое, и экономическое и т.д.
невозможно сконструировать хорошее изделие, если конструктор
не думает о том насколько хорошо это изделие будет решать проблемы заказчика (это маркетинговые навыки),
не думает о том — как это изделие будет проще сделать (это технологические навыки),
не думает о том как конструктор сможет окупить свои затраты (это экономические навыки)
и т.д.
проблема специализации видна на примере текущей науки:
смежные области развиваются очень медленно: например, гениальный программ в биологии, химии и т.д. не видно, просто потому что талантливый биолог(химик и т.д.) не знает программирование и не может объяснить программисту свои проблемы,
а программист не понимает химии, биологии и не может донести свои знания и умения до биологов и химиков.
в реальном мире хочется, чтобы конструктор обладал хотя бы общим маркетинговым, технологическим и т.д. видением,
технолог — конструкторским, маркетинговым, менеджерским и т.д.
маркетолог — конструкторским, технологическим, менеджерским и т.д.
DG>>и получается, что важнее уметь выделять умных (а потом их учить формулировать свои знания для других), чем делить людей на "ремесленников" и "конструкторов", и фактически руководствоваться тем, что способности людей даны от рождения, менять их нельзя, и поэтому нефига людей вообще ничему обучать.
U>Не понял откуда следует, что для рабочего должен быть закрыт путь в конструкторы или технологи? Вон у Форда вообще все нанимаемые инженеры должны были в начале пару лет отработать рабочими. Это оттого, что Форд ничего не понимал в индустриальном методе производства или оттого, что рабочий не может стать инженером?
логика непонятная в абзаце.
оттого что от инженера требуется сначала работать рабочим, совсем не следует, что рабочий может стать инженером
это даже с точки зрения типизации не проходит
(new инженер() as рабочий) as инженер — отработает, а вот new рабочий() as инженер — упадет.
форд посылал инженеров на производство, чтобы они понимали технологическую составляющую.
и этим он из конструкторов — делал конструкторов с навыками технологов. опять же интуитивно понимая, что специализация в чистом виде — это зло.
Здравствуйте, DarkGray, Вы писали:
DG>вот только опыт показывает, что хорошие изобретения были сделаны когда и конструкторское мышление, и технологическое мышление, и изготовление были сконцентрированы в одном человеке. DG>автомат калашникова, ил-2, форд-т и т.д. были сделаны людьми, которые совмещали в себя и конструктора, и технолога, и исполнителя.
Естественно лучше всего когда в человеке все эти навыки совмещены. Только вот проблема, что таких людей очень немного. Соответственно если на должность программиста-конструктора найти такого человека еще можно, то заполнить должности рядовых программистов такими людьми никогда не получится.
DG>специализация имеет серьезные минусы, возрастают затраты на коммуникацию.
У специализации есть свои плюсы, есть свои минусы. Кто с этим спорит-то? Но когда задачи превышают определенный порог сложности специализация это единственный способ их решить, соответственно хочешь — не хочешь, а применять специализаю надо, но естественно при этом надо помнить о том какие проблемы специализация несет.
DG>в идеальном мире (где люди могут развиваться бесконечно) — хотелось бы, чтобы каждый человек имел и конструкторское мышление, и технологическое, и менеджерское, и маркетинговое, и экономическое и т.д.
Естественно лучше быть здоровым и богатым, чем бедным и больным. Вот только мы живем не в идеальном, а в реальном мире, в которым этих самых бесконечно развитых людей как-то не наблюдается, поэтому приходится работать с тем, что есть. Соответственно в реальном мире нужна такая форма организации, которая позволит приносить пользу и программистам с не столь широкой и высокой квалификацией.
DG>проблема специализации видна на примере текущей науки:
Во многом проблема со специализацией возникла как раз потому, что инженерами стали называть всех кого ни попадя. Соответственно потерялся главный смысл профессии инженера — способность широкого взгляда на проблему, т.к. на это способны очень не многие, а инженером стали называть чуть ли не каждого второго, по факту прочтения человеком десятка умных книжек и наличия диплома. Как результат профессия выродилась.
DG>т.е. можно еще до начала проекта на основе оценки сложности проекта — оценить люди с какой квалификацией нужны для его выполнения. DG>также можно прикинуть что нужно делать если людей нужной квалификации не хватает.
Ценнейшее наблюдение. Капитан-очевидность отдыхает.
DG>форд посылал инженеров на производство, чтобы они понимали технологическую составляющую. DG>и этим он из конструкторов — делал конструкторов с навыками технологов. опять же интуитивно понимая, что специализация в чистом виде — это зло.
Сейчас и так всех начинающих программистов принимают на работу как рабочих. Или ты студентам разработку архитектуры доверяешь? И что это сильно мешает тем вчерашним студентам, которые имеют способности развивать навыки конструкторов и технологов? Я же нигде не говорил, что обучать инженеров-программистов и рабочих-программистов надо по разному. На работу всех принимаем на общих основаниях, далее те кто имеют способности продвигаются в конструкторы, технологи или высококвалифицированные рабочие, а те кто такими способностям не обладают остаются кодерами, благо рутинные задачи тоже кому-то надо решать. Где здесь можно увидеть то, что программист-рабочий не может стать программистом-инженером и уж тем более то, что "способности людей даны от рождения"?
U> На работу всех принимаем на общих основаниях, далее те кто имеют способности продвигаются в конструкторы, технологи или высококвалифицированные рабочие, а те кто такими способностям не обладают остаются кодерами, благо рутинные задачи тоже кому-то надо решать.
у этого варианта есть ряд минусов:
1. если инженера ставить на рутинную работу — то он начинает тупеть, а не развиваться (т.к. бытие влияет на сознание)
2. есть наблюдение, что активность снижается с возрастом (пик где-то в районе 25-30), поэтому если человека прогонять через все карьерные ступеньки, то наверх он уже приходит в том возврасте, когда ему ничего не хочется
т.е. в идеале: ученого стоит ставить сразу на место ученого, инженера на место инженера, а рабочего на место рабочего.
зы
в идеале, с точки зрения развития, человека стоит ставить на задачи — которые на 5-15% сложнее, чем тот уровень задач, которые он умеет решать.
если ставить на более простые: то идет снижение умственной активности и демотивация по линии самореализации,
если ставить на более сложные: то идет сильная демотивация по линии достижений.
и исходя из этого — будущего инженера неэффективно ставить токарем, его необходимо ставить как минимум помощником инженера.
U>Естественно лучше всего когда в человеке все эти навыки совмещены. Только вот проблема, что таких людей очень немного. Соответственно если на должность программиста-конструктора найти такого человека еще можно, то заполнить должности рядовых программистов такими людьми никогда не получится.
до этого ты утверждал, что если в человеке все навыки совмещены и ему никто не нужен, то он в лучшем случае ремесленник.
а если люди глупые, сами решить задачу не могут и для этого нанимают других, которым ставят задачи — то они сразу становятся конструкторами.
зы
я до сих пор утверждаю, что квалификация человека определяется сложностью решаемых лично им задач: и не важно делается это в одиночку или есть при этом коммуникация с другими людьми.
Здравствуйте, DarkGray, Вы писали:
DG>а если люди глупые, сами решить задачу не могут и для этого нанимают других, которым ставят задачи — то они сразу становятся конструкторами.
Цитату, пожалуйста, в которой я утверждал, что конструктор это человек, который сам не может решить задачу.
Ты читать точно умеешь? Первый пункт навыков конструктора гласит: способность понимать задачу как единое целое (включая детали). Как можно понимать задачу и при этом быть не способным ее решить? Конструктор выделяется вовсе не потому, что он не может решать задачи за рабочих, а потому что тратить его время на решение тех задач, с которыми вполне могут справиться рабочие, это забивание гвоздя микроскопом.
Здравствуйте, DarkGray, Вы писали:
DG>1. если инженера ставить на рутинную работу — то он начинает тупеть, а не развиваться (т.к. бытие влияет на сознание)
Так при современной организации труда в программировании и приходится инженера ставить в том числе на рутинную работу. Т.к. рутинной работы много, а отработанной организации труда, которая позволила бы эту работу передавать менее квалифицированным работникам, для которых такая работа как раз достаточно сложная и способствующая их развитию, нет. Ты с чем споришь-то вообще?
DG>и исходя из этого — будущего инженера неэффективно ставить токарем, его необходимо ставить как минимум помощником инженера.
Кто такой токарь и кто такой помощник инженера в программировании?
Здравствуйте, Undying, Вы писали:
DG>>1. если инженера ставить на рутинную работу — то он начинает тупеть, а не развиваться (т.к. бытие влияет на сознание)
U>Так при современной организации труда в программировании и приходится инженера ставить в том числе на рутинную работу. Т.к. рутинной работы много, а отработанной организации труда, которая позволила бы эту работу передавать менее квалифицированным работникам, для которых такая работа как раз достаточно сложная и способствующая их развитию, нет. Ты с чем споришь-то вообще?
У меня как-то наоборот получалось. Интересные, но несложные таски я отдавал джуниорам, интересные и сложные медам, а сам педалил тупые и рутинные. Потому что это давало возможность подумать и "охватить все в целом" как тут в ветке говорят, да еще и выполнение остальных задач контроллировать удавалось.
Здравствуйте, SE, Вы писали:
SE>У меня как-то наоборот получалось. Интересные, но несложные таски я отдавал джуниорам, интересные и сложные медам, а сам педалил тупые и рутинные. Потому что это давало возможность подумать и "охватить все в целом" как тут в ветке говорят, да еще и выполнение остальных задач контроллировать удавалось.
SE>Только я хитрил — где мог автоматизировал.
Т.е. ты выполнял работу технолога, сам решая рутинные задачи для того, чтобы понять как их можно автоматизировать.
Здравствуйте, Ларик, Вы писали:
Л>Здравствуйте, Кодёнок, Вы писали:
Кё>>Откуда постоянно лезет употребление слова “завалить” применительно к собеседованиям?
Л>Ну ладно не завалить, сбить с ритма.
На собеседовании нет понятия "завалить". Тут нет критерия как на экзамене , что нужно ответить на все вопросы.
Может даже оказаться что вы не ответили ни на один вопрос, при этом успешно прошли собеседование. Например в случае если задаются заведомо сложные вопросы и важна просто реакция человека на них. Как правило на собеседовании задают 2 типа вопросов простые на которые вы обязаны ответить, и заковыристые или на смекалку просто посмотреть как вы подойдете к проблеме.
Я программист, я Иван Помидоров, хватить трепатся — наш козырь error.
что производственный подход мало пригоден в разработке софта.
U>Т.е. я утверждаю, что разработка программы принципиально не отличается от разработки автомобиля и изготовления его опытного образца.
Отличается, и принципиально. Стоит лишь чуть-чуть углубиться в конкретику.
1) Изготовление опытного образца автомобиля — дорогой и длительный процесс. Сборка итерации программы — минуты. В худшем случае — часы. Это — огромная и очень существенная разница. Когда процесс изготовления протитопа медленный — имеет смысл заряжать несколько вариантов "детали" в параллель. В софте — не имеет смысла, пробовать по очереди так же быстро.
2) Изготовление опытного образца автомобиля — детали собираются и подгоняются вручную. При этом — технологический процесс опытного и серийного образцов не одинаков — они разные (и будут разные конструктивные ошибки). К примеру, для прототипов пластиковых деталей применяется другая технология отвердения с временными прессформами, а для металлических — может применяться фрезеровка вместо какой-нить "экструзии". Эти "мелочи" оказывают огромное влияние на процесс разработки. Сборка же итерации программы — полностью автоматическая, и разницы в технологии между опытным и серийным образцом нет.
3) При проектировании автомобиля надо сразу учитывать себестоимость деталей и технологичность. Ничего подобного в софте нет.
Продолжать? На самом деле, если вникать в детали — то надо будет как следует постараться, чтобы хоть что-нибудь общее найти. Кроме простого факта, что в обоих случаях результатом разработки является спецификация изделия, предназначенная для серийного производства.
U>Соответственно подходы применяемые в разработке автомобилей и изготовлении опытных образцов автомобилей вполне могут работать и в программировании.
Если в детали "механического проектирования" не вдаваться, и не обращать внимания на то, насколько по разному выглядят упомянутые спецификации, ограничиваясь упоминанием одних названий — то оно все "может работать".
Но все — это ничего.
U>Как, к примеру, программистские шаблоны проектирования появились на основе изучения архитектурных шаблонов проектирования.
И это тоже не так. Архитектура была притянута за уши в качестве аналогии, людьми, которые в ней не разбираются.
Я вообще не понимаю, откуда у программистов такая тяга — привлекать для объяснений аналогии из областей, в которых они разбираются заведомо хуже, чем в программировании. Вот зачем? Потому, что неизвестные области имеют ореол мистики?
U> А вот между изготовлением серийного образца программы и серийного автомобиля нет ничего общего, т.к. серийная программа изготавливается по нажатию F5, а для изготовления серийного автомобиля надо еще пахать и пахать.
Ровно столько же общего, сколько и в процессе разработки. Не больше, и не меньше. А F5 там или не F5 — это не принципиально.
U> Соответственно подходы пригодные для изготовления серийных изделий, совершенно не пригодны для изготовления программ.
Программный продукт точно также также является серийным изделием. С той разницей, что его тиражирование обходится почти бесплатно и не привносит ошибок. Все дефекты — конструктивные по определению.
Здравствуйте, artem_korneev, Вы писали:
_>Здравствуйте, Niemand, Вы писали:
N>> А потом все скатывается в i++++i и зачем нужен виртуальный деструктор (кстати на этом вопросе закончилось мое самое короткое 3х-минутное собеседование в CDD).
_>Не ответил?
А какой правильный ответ кстати?
UNIX way — это когда тебе вместо туалетной бумаги дают топор, рубанок и карту близлежащего леса
Ты сам-то читал что там написано и где именно я противоречу этому, если вообще противоречу? 
И вообще не надо программистов обижать: они ре "рабочие" и не "ремесленники" и даже не "инженера" — они "художники"! 
и изначально провальная.
