Здравствуйте, Ларик, Вы писали:
Л>Здравствуйте, Ларик, Вы писали:
Л>А допустим так, имеет ли моральное право следующий подход, записываюсь на собеседование и сразу влоб начинаю рассказывать по пунктам: Л>У вас здесь знание MySQL, я умею подключаться клиентом, читать и писать, больше ничего не делал. Л>MSXML чтение запись, выбор, перебор, поиск, больше ничего не делал и т.д. Л>Разумеется по поводу узких технологий. Л>Эта тактика изначально провальная? Л>Или она честная и мы не будем тратить время друг друга понапрасну?
если вы говорите, что вы это не умеете, то это это минус, но небольшой;
если вы говорите, что вы это умеете, но валитесь на первом же вопросе -- это два минуса, образующих крест;
если вы говорите, что вы это умеете, но вас через полчаса все равно валят -- это два минуса, оборазующих плюс (нащупали границы ваших познаний);
если вы говорите, что вы это умеете и завалить вас не удается -- вы вылетаете по исключению, обрабатываемому (или необрабатываемому) вышестоящим манажментом;
у меня было много собеседований (хороших и разных) и я обычно начинал с того, что сам спрашивал в чем будет заключаться моя работа, что от меня ожидают и в каком объеме и часто этого оказывалось достаточно, чтобы понять, что им нужен кто-то другой и стемиться на эту позицию было бесмыссленно.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, Ларик, Вы писали:
Л>Подумал поработать, что не вакансия так минимум похоже я буду один операционную систему писать, судя по количеству необходимых знаний, ну я например много технологий знаю, причем не по книжкам, а реально сталкивался, разбирался, писал. Например работал с MSXML, но задай мне вопрос с которым я не сталкивался, я ноль, хотя за пару минут найду и примеры и пойму алгоритм решения. Т.е. если перечислить то что я "знаю" большой список получится, но если начать меня по нему тестировать завалить меня нечего делать.
Будь ты хоть трижды знатный гугловод, а без серьезного опыта наступишь по пути на все специфичные для технологии или языка грабли, до которых дотянешься.
Ну, а поскольку опыт проверить трудно, то проверяют знания.
Л>Собственно вот и возникает вопрос, а просто кодеры сейчас не нужны что-ли? Который может и не гуру в 20 темах, но решать вопросы нехватки знаний умеет. Или студенты эту нишу забивают?
Здравствуйте, Ларик, Вы писали:
Л>Подумал поработать, что не вакансия так минимум похоже я буду один операционную систему писать, судя по количеству необходимых знаний, ну я например много технологий знаю, причем не по книжкам, а реально сталкивался, разбирался, писал. Например работал с MSXML, но задай мне вопрос с которым я не сталкивался, я ноль, хотя за пару минут найду и примеры и пойму алгоритм решения. Т.е. если перечислить то что я "знаю" большой список получится, но если начать меня по нему тестировать завалить меня нечего делать. Л>Собственно вот и возникает вопрос, а просто кодеры сейчас не нужны что-ли? Который может и не гуру в 20 темах, но решать вопросы нехватки знаний умеет. Или студенты эту нишу забивают?
На сабжевый вопрос захотелось ответить, что программеры в этом сами и виноваты, превратив понятие простого кодинга в нечто унизительное и оскорбительное, словно этим какие-то недочеловеки занимаются. Далеко ходить не надо. На этом форуме то и дело проскакивают соответствующие фразенки в стиле "я же не кодер" или "да эту херню может просто кодер написать". Вот и фирмах теперь также: "нам простой кодер не нужен". Ну, а раз не нужен, то на тебе списочег на 500 наименований. Думаете HR-ы определяют запросы вакансии? Да всё те же программеры и определяют, HR просто передает.
Здравствуйте, Aviator, Вы писали:
A>Здравствуйте, SE, Вы писали:
SE>>Имея на руках описание требований вакансии никто не мешает сделать "несколько минут гугла" в течении хотя пары дней до собеседования. Ради одной вакансии, конечно, не стоит, но пригодится если не для этой так для другой. A>И какой смысл в этом сокральном действии?
Что, все расжевывать надо? Чем больше у тебя знаний и умений, тем больше у тебя возможностей.
Хотя, возможно, ты из тех людей, который не обладают ни толикой любознательности. Тогда забудь, все что я сказал. Ты не увидишь в этом смысла.
Здравствуйте, Aviator, Вы писали:
MM>>Я скорее процесс описал, в которым ключевое, что не HR определяет требования к вакансиям. Почему выдвигают такие требования, для меня тоже секрет. A>В РФ крайне редко встречается компетентный HR, обычно там работаю девочки — вчерашние студентки, которые даже грамотно составить приглашение на собеседование не умеют .
Гы. Отвечу тебе глазами HR
В РФ крайне редко встречается компетентный программист, обычно там работаю мальчики — вчерашние студенты, которые даже грамотно составить резюме не умеют .
Здравствуйте, Aviator, Вы писали:
A>Здравствуйте, SE, Вы писали:
SE>>Будь ты хоть трижды знатный гугловод, а без серьезного опыта наступишь по пути на все специфичные для технологии или языка грабли, до которых дотянешься. SE>>Ну, а поскольку опыт проверить трудно, то проверяют знания. A>C опытом, когда уже поработал с кучей технологий в разных задачах, вспомнить конкретику становится достаточно сложно. Другое дело, что несколько минут гугла освежат воспоминания.
Имея на руках описание требований вакансии никто не мешает сделать "несколько минут гугла" в течении хотя пары дней до собеседования. Ради одной вакансии, конечно, не стоит, но пригодится если не для этой так для другой.
Пару месяцев назад коллега собеседовал человека на проект, было видно, что тот очень хочет работать, но знаний не хватало, и как раз он ссылала на вариант "задачи все однотипные, а если что я нагуглю".
И ведь прав он. На 99% прав. Но:
1. Иногда не однотипные и очень, очень срочные.
2. Интернета под рукой может и не оказаться в самый ответственный момент.
А хуже всего, когда 1 и 2 совпадают в пространстве и времени.
Здравствуйте, MxMsk, Вы писали:
MM> Если же чувак шарит много в чем, то скорее всего он не кодер.
Если какая-то технология нужна, а спецов по ней в коллективе нет, тогда да знания у нанимаемого работника по данной технологии могут быть полезны. А если спецы уже есть, то новичок может вообще ничего не знать, т.к. если он программер приличного уровня, то у имеющихся спецов он всему обучится влет.
Здравствуйте, kaa.python, Вы писали:
P>>Зачем же тогда заваливают? KP>Кого заваливают? Где заваливают? Почему меня никто и никогда не пытался завалить?
Не знаю, может ты выглядишь страшно, боятся.
Здравствуйте, FR, Вы писали:
FR>Вот тут кстати одна проблемка, часто это переформулирование занимает времени сопоставимо с тем которое требуется чтобы просто ее самому решить. FR>А в результате то, что первовариантный программист сделает скажем за N человеко-часов "технолог" и "рабочие" затратят 2N тех же человеко-часов. FR>При этом у первого качество наверняка будет лучше. FR>Схема архитектор — разработчики (это "технолог" + "рабочий" в одном флаконе) мне кажется более адекватной для FR>совтостроения чем "конструктор" + "технологи" + "рабочие".
Есть что добавить. Работал я раньше в одном НИИ. Там очень распространена схема "физик" + "математик" + вагон и тележка программистов = несколько лет работы.
В противовес этой схемы я знаю двух человек, которые занимались сами от и до своими задачами. Вот слова одного из них:
— Я посредственный физик, хреновый математик, и совсем никакой программист (тут он явно скромничал). Но трем человекам в моей голове очень легко договориться между собой.
Конечно, они решали разные задачи, но связка 3 в одном оказывалась более плодовита чем команда людей с разными специализациями. Случаев явно маловато для того чтобы говорить о каких-то правилах, но они имеют место.
U>Это по твоему определение рабочего в общем случае? Вот к тебе сантехник пришел. Он рабочий? Ты что для него инструкцию как работать пишешь?
рабочий, конечно. инструкции у него уже все написаны (и получил он их в колледже)
сантехник не устраняет никаких противоречий, и не проводит никакой оптимизации, он берет имеющуюся деталь, и прикручивает ее туда куда написано.
U> который будет способен охватить решаемую задачу целиком и за счет этого сможет координировать деятельность рабочих, т.е. возникает потребность в конструкторе.
вот только это уже управленец (менеджер), а не конструктор.
конструктор — устраняет противоречия и оптимизирует конструкцию изделия. рабочих еще может никаких не быть.
управленец — устраняет противоречия и оптимизирует деятельность группы людей (и не надо управленца мешать с конструктором в единое целое)
тот же берт монро — конструктор, хотя никаких рабочих у него не было.
торвальдс, брин/пейдж, цукерберг и т.д. — даже в начале своей карьеры точно были конструкторами, а не рабочими, хотя и работали в одиночку без всякого вертикального разделения труда.
U> И тогда же возникает потребность в человеке, который будет думать как какую-то операцию можно сделать в принципе и как ее можно упростить, чтобы ее мог выполнять рабочий с меньшей квалификацией и/или с меньшими трудозатратами, и который будет заниматься формализацией действий рабочих, чтобы сделать возможным передачу опыта другим рабочим, т.е. возникает потребность в технологе.
технолог — устраняет противоречия и оптммизирует удешевление производства изделия. рабочих опять же может не быть.
например Матти Хольцберг — технолог, но рабочих у него нет.
U>Соответственно само понятие инженера имеет смысл только при наличии вертикального разделения труда. Если же в коллективе программистов вертикального разделения труда нет, а есть только горизонтальное, то инженеров в таком коллективе нет, в нем есть только рабочие, хотя возможно и очень высокой квалификации. В материальном производстве такое тоже было всего лишь полтысячелетия назад, называлось это ремесленничество.
т.е. ты делишь людей на рабочих и инженеров чисто по формальному признаку: если человек ставит задачу другим, то он — инженер, если человек ставит задачу сам себе — то он рабочий?
зы
есть такой человек — как прораб, он ставит задачи другим, но при этом он инженером не является.
сержант тоже ставит задачи другим, и он тоже не является инженером.
что самое интересное, когда лейтенант ставит задачи сержанту — он не выписывает ему инструкций, а лишь ставит задачу в общих чертах "построить взвод", "здесь и здесь отрыть окопы" и т.д.. инструкции сержант получил (также как и сантехник) в учебке.
можно взять и обратный пример — медицину. там врачи почти все поголовно инженеры при минимальном вертикальном разделении труда.
Здравствуйте, Undying, Вы писали:
U>Я еще раз повторяю, что конвейер это отличный способ производства серийного изделия, в программировании серийных изделий нет в принципе, есть только опытные. Соответственно было бы странным, если бы у японцев что-то получилось.
Насчет японцев не скажу, но у немцев я могу заказать машину, накликав в конфигураторе нужный мне комплект опций из немаленького такого списка вариантов. Да и по опыту часть задач в программировании действительно решается как "опытное производство", но в общем объеме производства она в целом не настолько велика на сегодняшний день и даже более того: программирования как такового остается все меньше, а все больше — "интеграции". Пусть даже в это слово включается и "создание дополнительных программных модулей в ходе кастомизации общего решения под конкретное приложение" — общего положения вещей это не отменяет: большая часть задач при этом — обыкновенный конвейер и серийное производство давно разработанных деталей и узлов и схем их сложения в готовую машину.
ЗЫ: а что, сегодня все еще пишут люди "свои собственные опытные, а не серийные изделия типа контейнера и пр."?
Здравствуйте, Undying, Вы писали:
DG>>1. если инженера ставить на рутинную работу — то он начинает тупеть, а не развиваться (т.к. бытие влияет на сознание)
U>Так при современной организации труда в программировании и приходится инженера ставить в том числе на рутинную работу. Т.к. рутинной работы много, а отработанной организации труда, которая позволила бы эту работу передавать менее квалифицированным работникам, для которых такая работа как раз достаточно сложная и способствующая их развитию, нет. Ты с чем споришь-то вообще?
У меня как-то наоборот получалось. Интересные, но несложные таски я отдавал джуниорам, интересные и сложные медам, а сам педалил тупые и рутинные. Потому что это давало возможность подумать и "охватить все в целом" как тут в ветке говорят, да еще и выполнение остальных задач контроллировать удавалось.
Здравствуйте, Ларик, Вы писали:
Л>MSXML чтение запись, выбор, перебор, поиск, больше ничего не делал и т.д. Л>Разумеется по поводу узких технологий. Л>Эта тактика изначально провальная? Л>Или она честная и мы не будем тратить время друг друга понапрасну?
Знания и умения это не самая большая часть того, что человек может принести в команду.
Знания устаревают, а умения решать уже решенные задачи не требуются. Нужны умения решать новые задачи, усваивать новые знания.
Поэтоу тактика абсолютно честная в случае честного подхода и изначально провальная.
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, Undying, Вы писали:
U>Ты вроде только что утверждал, что они пытались внедрить в программирование аналог конвейера, а не просто ввести разделение на конструкторов, технологов и рабочих. Если не сложно опиши в общем в чем состояла идея японцев.
Они пытались внедрить самые передовые тогда методы промышленности в софтостроение, тошиба хитачи и другие монстры этим занимались,
цель была обогнать Америку
Ну и благих целей было немало, и улучшение качества и меньшая зависимость от разработчиков и предсказуемость и т. п. http://www5d.biglobe.ne.jp/~y-h-m/An%20Approach%20to%20Cell-Based%20Software%20Factory-v.01.pdf
В результате у них получалось надежное ПО с достаточно предсказуемыми сроками, но при этом сами эти сроки разработки были
в разы дольше чем у американцев и требовали в те же разы больше рабочих ресурсов. Говорят их опыт частично переняли
индусы, ну и один из их главных идеологов до сих проталкивает (уже сильно измененную) технологию http://www.xosoftware.co.uk/Articles/WhatIsASoftwareFactory/
Подумал поработать, что не вакансия так минимум похоже я буду один операционную систему писать, судя по количеству необходимых знаний, ну я например много технологий знаю, причем не по книжкам, а реально сталкивался, разбирался, писал. Например работал с MSXML, но задай мне вопрос с которым я не сталкивался, я ноль, хотя за пару минут найду и примеры и пойму алгоритм решения. Т.е. если перечислить то что я "знаю" большой список получится, но если начать меня по нему тестировать завалить меня нечего делать.
Собственно вот и возникает вопрос, а просто кодеры сейчас не нужны что-ли? Который может и не гуру в 20 темах, но решать вопросы нехватки знаний умеет. Или студенты эту нишу забивают?
Самая большая в мире ложь — "Я прочел и согласен с условиями пользовательского соглашения".
Здравствуйте, Ларик, Вы писали:
Л>что не вакансия так минимум похоже я буду один операционную систему писать, судя по количеству необходимых знаний,
Обычно просто пишут с чем может быть придется столкнуться — не обязательно полностью подходить
Л>но если начать меня по нему тестировать завалить меня нечего делать.
Как правило, достаточно рассказать что и как делал, а на адекватных собеседованиях цели завалить не ставится.
Л>Собственно вот и возникает вопрос, а просто кодеры сейчас не нужны что-ли? Который может и не гуру в 20 темах, но решать вопросы нехватки знаний умеет. Или студенты эту нишу забивают?
Нужны. Студенты все же немного другую нишу забивают
20.10.2010 15:29, Ларик пишет: > > А допустим так, имеет ли моральное право следующий подход, записываюсь > на собеседование и сразу влоб начинаю рассказывать по пунктам: > У вас здесь знание MySQL, я умею подключаться клиентом, читать и писать, > больше ничего не делал. > MSXML чтение запись, выбор, перебор, поиск, больше ничего не делал и т.д. > Разумеется по поводу узких технологий. > Эта тактика изначально провальная?
Нет. Наиболее правильная, но надо отдавать себе отчет в какой стране ты
находишься и в каком городе этой страны и что ты хочешь от конторы, где
будешь работать.
Эта тактика не позволит тебе устроится в большинство местных компаний с
очень большим плюсом — в них не надо ничего делать, кроме находится в
офисе 8 часов и писать отчеты. > Или она честная и мы не будем тратить время друг друга понапрасну?
Да.
Здравствуйте, SE, Вы писали:
SE>Здравствуйте, Ларик, Вы писали:
Л>>Подумал поработать, что не вакансия так минимум похоже я буду один операционную систему писать, судя по количеству необходимых знаний, ну я например много технологий знаю, причем не по книжкам, а реально сталкивался, разбирался, писал. Например работал с MSXML, но задай мне вопрос с которым я не сталкивался, я ноль, хотя за пару минут найду и примеры и пойму алгоритм решения. Т.е. если перечислить то что я "знаю" большой список получится, но если начать меня по нему тестировать завалить меня нечего делать.
Это нормально, вы же робот, время идёт, такие вещи как названия методов и даже классов забываются. Поэтому надо смотреть на общий кругозор, умение рассуждать, спрашивать не как называется поле такого-то класса, а общую схему работы. Но множество работодателей в РФ собеседует почему-то иначе, потом жалуются на форумах куда пропали специалисты .
SE>Будь ты хоть трижды знатный гугловод, а без серьезного опыта наступишь по пути на все специфичные для технологии или языка грабли, до которых дотянешься. SE>Ну, а поскольку опыт проверить трудно, то проверяют знания.
C опытом, когда уже поработал с кучей технологий в разных задачах, вспомнить конкретику становится достаточно сложно. Другое дело, что несколько минут гугла освежат воспоминания.
Л>>Собственно вот и возникает вопрос, а просто кодеры сейчас не нужны что-ли? Который может и не гуру в 20 темах, но решать вопросы нехватки знаний умеет. Или студенты эту нишу забивают? SE>Да.
Качество студентов за последнее время ощутимо снижается, так что наврятли они могут покрыть эту значительную нишу.
U>Насколько я понял идея заключается в следующем. Используйте наши мегакрутые и мегауниверсальные решения и для разработки программного обеспечения вам понадобится только главный конструктор (архитектор) и толпа рабочих (кодеров).
Это сейчас у них такая идея, наверно для индусов стараются
Раньше был прямой перенос индустриальных методов, вот тут http://www5d.biglobe.ne.jp/~y-h-m/EssenceOfToshibaSoftwareFactory.pdf более подробно
в историческом плане.
U>Это примерно тоже самое, что разрабатывать автомобиль не имея своего конструкторского бюро и используя только универсальные решения разработанными другими КБ. Честно говоря я сильно удивляюсь как такой подход хоть у кого-то работает.
Работает, и гораздо худшие работают, если не думать об эффективности.
U>Для того, чтобы кодеры были эффективны, необходимо наличие прослойки конструкторов и технологов, которые будут переводить исходную задачу на понятный кодерам уровень.
А вот тут по моему спорно. Программирование это практически конструкторское бюро и есть, и кодер это и есть аналог технолога для индустрии. Технологи же по сути и выполняют работу кодера переводят теоретически готовый продукт на реальное производство, кодер практически занимается этим же.
U>Здесь в чем фишка вообще не понял, осталось только впечатление как о чем-то крайне зарегулированном. В творческой работе зарегулированность обычно работает плохо, и если это не взлетело даже у японцев с их специфическим менталитетом, то у остальных не взлетит подавно.
Да, но до сих пор многие не понимают, Gaperton прав ментальность выработалась.
U>Выделенное нужно заменить на ремесленники, т.к. рабочие это тоже продукт вертикального разделения труда, и если нет такого разделения, то нет и рабочих.
вводя термин "ремесленники" ты неявно вводишь деление ремесленный подход/производственный(научный) подход.
ремесленный подход — характеризируется наивной формой накопления опыта. когда улучшения делаются случайно, передача опыта делается методом делай также.
паре сотен лет назад в пику этому появился производственный(научный) подход, когда накопление опыта (улучшения) — делаются целенаправленно: формируются критерии, выстраиваются модели, проводятся исследования и ставятся эксперименты.
здесь тоже никакой корреляции с вертикальным разделением труда нет, а есть смена парадигмы накопления опыта через переход от наивного способа к целенаправленному.
U>Ключевые навыки конструктора: 1) способность охватить задачу целиком (т.е. включая детали) 2) способность формализовать задачу и разбить ее на подзадачи таким образом, чтобы для понимания подзадачи не требовалось понимания задачи в целом.
разбиение целого на части (она же декомпозиция) — это есть общая часто используемая задача.
ее делает и конструктор (разбивая изделие на части), и технолог (разбивая процесс изготовления на части), и сантехник (формируя образ что за чем крутить), и прораб(и сержант) — разбивая задачи по подчиненным
уж точно декомпозию делают дизайнеры, художники, ландшафтные дизайнеры, землеры и т.д. и т.п.
и на основе даже этого перечисления видно — что задача декомпозиции может быть сложная (когда необходимо проводить оптимизацию и устранять противоречия), а может быть шаблонной (когда деление жестко заданное и делается по алгоритму)
в тоже время, даже при наличии простой шаблонной декомпозиции — задача все равно может оставаться сложной.
декомпозиция автомобиля на узлы не меняется последние лет 20(если не последние лет 80), но несмотря на это — конструкционно задача все равно остается очень сложной, т. к. требуется устранить и оптимизировать кучу критериев.
U>Чистый управленец не способен ни охватить задачу целиком, ни формализовать ее и разбить на подзадачи. Его работа заключается в том, чтобы подобрать людей, которые смогут это сделать. К примеру, толковый управленец товарищ Сталин для разработки пушки привлекает толкового конструктора товарища Грабина, т.к. сам товарищ Сталин при всех своих способностях управленца не может ни охватить задачу разработки пушки целиком, ни разбить ее на подзадачи.
вижу передергивание на передергивании
задачу можно видеть в целом, по задаче можно видеть детали.
из-за ограничености ресурсов: на задачу смотрится либо в целом, либо смотрится детально.
тогда в паре Сталин/Грабин — Сталин смотрит в целом, что нужно стране, но не лезет в детали как делать пушки,
Грабин не лезет в целое — что лучше для страны, но разбирается с деталями — как лучше делать пушки.
> Чистый управленец не способен ни охватить задачу целиком, ни формализовать ее и разбить на подзадачи. Его работа заключается в том, чтобы подобрать людей, которые смогут это сделать.
подбор людей автоматически подразумевает декомпозицию задачи (как минимум декомпозируются сферы ответственности, сферы полномочий, бюджет и т.д.): вот этот будет отвечать за пушки, этот за армию, этот за транспорт, а этот будет бумажки перебирать.
DG>>тот же берт монро — конструктор, хотя никаких рабочих у него не было.
U>Берт Монро это ремесленник. Все до последнего винтика он изготавливал понимая задачу целиком, т.е. он не занимался вопросами формализации и разбиения задачи на подзадачи.
значит ты плохо прочитал статью.
там русским по белому написано — что он в одиночку в течении нескольких десятилетий(т.е. это не случайное озарение) совершенствовал свой мотоцикл в темпе всей мировой отрасли.
это возможно лишь при целенаправленном производственном подходе, и это не возможно при ремесленном подходе.
если читать более полные статьи о нем: то там видно, что Монро даже ближе к ученому чем к инженеру — он активно проводил исследования, ставил эксперименты, целенаправленно искал как сделать так, чтобы мотоцикл двигался еще быстрее.
U>Про большинство программистов можно сказать тоже самое. Само по себе умение писать код человека инженером не делает.
ты кстати сколько можешь назвать требований к хорошо сделанной форме?
U>Если человек способен формализовать задачу и разбивать ее на подзадачи таким образом, что для их понимания не требуется понимания задачи в целом, то да у него есть задатки конструктора, даже если он работает в одиночку. Но убедиться в том, что человек действительно обладает способностями конструктора можно только тогда, когда решать задачу начинает несколько человек. Т.е. если человек в одиночку успешно решает сложные задачи, то из этого безусловно следует, что он ремесленник высокой квалификации, но вовсе не факт, что этот человек способен быть конструктором.
в этом абзаце ты сейчас как раз руководствуешься ремесленным подходом (наивное наблюдение без целенаправленного движения), ты не проводишь ни анализа, ни построения модели, ни поиска готовых решений.
1. человек либо умеет делать сложную декомпозицию/либо не умеет
2. человек делает это либо осознанно, либо не осознанно.
3. человек либо умеет отслеживать как он думает, либо не умеет
4. человек либо умеет формулировать для других свои образы, либо не умеет.
решение сложные задач требует декомпозиции задачи хотя бы в голове, хотя бы не осознанно.
> Т.е. если человек в одиночку успешно решает сложные задачи, то из этого безусловно следует, что он ремесленник высокой квалификации, но вовсе не факт, что этот человек способен быть конструктором.
твое высказывание, что человек умеет решать сложные задачи, но при этом не является по твоей терминологии конструктором (т.е. не может разбить задачу для других) можно записать как:
человек умеет делать сложную декомпозицию = верно
(человек делает это осознанно И человек умеет отслеживать как он думает И человек умеет формулировать для других своих образы) = не верно
но отсутствие 2, 3, 4 — легко компенсируется кучей техник.
самая банальная — это приставление наблюдателя-аналитика, с параллельным использованием техник вопрошания.
т.е. из одного человека получался только недоконструктор (по твоей терминологии), а тут глядишь из двух человек — получился уже целый конструктор.
вот это как раз пример задачи, которую решает управленец (как скомбинировать неидеальных людей в хорошую систему).
Здравствуйте, Ларик, Вы писали:
Л>Подумал поработать...
Здравая мысль
HR пишут в объявлениях названия всех технологий подряд, которые хоть каким боком могут пригодиться.
К слову, начинающие программисты точно по такому же принципу составляют свои резюме.
Большинство вакансий именно для кодеров, и для этой скучной, рутинной, не требующей большого ума работы ищут гениев
Здравствуйте, Ларик, Вы писали:
Л>Собственно вот и возникает вопрос, а просто кодеры сейчас не нужны что-ли? Который может и не гуру в 20 темах, но решать вопросы нехватки знаний умеет. Или студенты эту нишу забивают?
я помню свое собеседование в тогда еще Валидио в бытность студентом. Даже имея опыт самостоятельной разработки внутри большого предприятния, потом сопроводжения средней руки бизнеса, двух шаровар, фриланса и будучи сейчас (по крайней мере официально) на должности сеньера, я то собеседование не прошел бы. Ну вот не знаю я всего наизусть, не знаю.
Потому с 2006го года (окромя попытки в МС в 2007м) ни одного собеседования не посетил. Обычно заказчики приходили либо по знакомству (т.е. меня кто-порекомендовал), либо просто удовлетворялись послужным списком.
Еще интересный момент который заметил (много общаюсь со знакомыми на эту тему). Собеседования типа "встретились, попили пива, поговорили о жизни" практикуются как правило в стартапах. А потом все скатывается в i++++i и зачем нужен виртуальный деструктор (кстати на этом вопросе закончилось мое самое короткое 3х-минутное собеседование в CDD).
If the message above is in English — means I'm wasting my work time and work computer to post here. No hard feelings
Здравствуйте, SE, Вы писали:
aik>>Но с русскими это не прокатывает — национальная подозрительность а-ля "у всех 10летних иномарок всегда скручен пробег". SE>Я пока встречался с "все индусы врут в резюме"
Я лет 10 назад собеседовал чувака одного — нужен был человек, знакомый с ядром линукса. Пришел товарищ и наплел что он в ядре какой то драйвер пишет-поддерживает (ntfs или что то похожее). После я написал парням, которые в драйвере упомянуты — они говорят "ну да, приходил такой то полгода назад, предлагал помощь, дали работу — а он и пропал напрочь". Такие сказочники попадаются
Здравствуйте, aik, Вы писали:
aik>Я лет 10 назад собеседовал чувака одного — нужен был человек, знакомый с ядром линукса. Пришел товарищ и наплел что он в ядре какой то драйвер пишет-поддерживает (ntfs или что то похожее). После я написал парням, которые в драйвере упомянуты — они говорят "ну да, приходил такой то полгода назад, предлагал помощь, дали работу — а он и пропал напрочь". Такие сказочники попадаются
Ну так может это они думают, что пропал, а он на самом деле пишет-поддерживает. Только никому не показывает.
Здравствуйте, MxMsk, Вы писали:
U>>Вообще-то не кодер от кодера отличается вовсе не знанием конкретных технологий. MM>Скорее всего ты хочешь сказать об умении, или даже желании думать/не_думать, расти/не_расти. Ну, а как это отразить в вакансии? "Кодеры не нужны"? Я подозреваю, что логика здесь такая: раз кодер тупо исполняет приказы, значит он не растет и знает мало. Если же чувак шарит много в чем, то скорее всего он не кодер.
Не думаю, что будет просто найти человека, который попал бы под данное определение кодера и при этом не считал бы, что "шарит много в чем"
То есть то, как определить, "шарит" или нет — вопрос открытый и не решённый.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, SE, Вы писали:
SE>Имея на руках описание требований вакансии никто не мешает сделать "несколько минут гугла" в течении хотя пары дней до собеседования. Ради одной вакансии, конечно, не стоит, но пригодится если не для этой так для другой.
И какой смысл в этом сокральном действии?
SE>Пару месяцев назад коллега собеседовал человека на проект, было видно, что тот очень хочет работать, но знаний не хватало, и как раз он ссылала на вариант "задачи все однотипные, а если что я нагуглю". SE>И ведь прав он. На 99% прав. Но: SE>1. Иногда не однотипные и очень, очень срочные.
Это к чему? После приёма на работу человек за месяц другой набьёт руку на задачах требующихся компании. Помнить всё нереально, год не поработал с АПИ — и уже помнишь только схему работы. SE>2. Интернета под рукой может и не оказаться в самый ответственный момент.
Да, ради этого стоит искать работника со знанием всех технологий которые могут пригодится в программировании SE>А хуже всего, когда 1 и 2 совпадают в пространстве и времени.
Здравствуйте, SE, Вы писали:
SE>Здравствуйте, Aviator, Вы писали:
A>>Здравствуйте, SE, Вы писали:
SE>>>Имея на руках описание требований вакансии никто не мешает сделать "несколько минут гугла" в течении хотя пары дней до собеседования. Ради одной вакансии, конечно, не стоит, но пригодится если не для этой так для другой. A>>И какой смысл в этом сокральном действии? SE>Что, все расжевывать надо? Чем больше у тебя знаний и умений, тем больше у тебя возможностей. SE>Хотя, возможно, ты из тех людей, который не обладают ни толикой любознательности. Тогда забудь, все что я сказал. Ты не увидишь в этом смысла.
Ты студент?
Да, я не вижу какие знания для собеседования можно подцепить за два дня гугла. Если работодатель смотрит на общий опыт то ему на это пофик, если ему важно знание конкретных технологий, то твоя двухдневная глубина знаний будет моментально вскрыта. Или ты не видишь разницы между знанием и знакомством?
Здравствуйте, Undying, Вы писали:
MM>>Скорее всего ты хочешь сказать об умении, или даже желании думать/не_думать, расти/не_расти. U>Некодер от кодера отличается уровнем архитектурных навыков, т.е. способностью делать сложное простым, и уровнем программистских навыков, т.е. способностью работать со сложным.
С некодерами бывает и наоборот.
Здравствуйте, MxMsk, Вы писали:
MM>Откровенно говоря, я не люблю это деление и мне не нравится, когда слово "кодер" употребляют в уничижительном смысле.
По уму в слове кодер нет ничего уничижительного, как нет ничего уничижительного в слове рабочий. В основной массе производственных профессий есть разделение на конструкторов, которые решают что мы будем делать, технологов, которые решают как мы будем делать и рабочих, которые собственно воплощают в жизнь задуманное конструкторами, используя решения технологов. Соответственно, хотя обычно работа рабочих требует меньшей квалификации, чем работа конструкторов и технологов, их работа никак не менее важна, т.к. без работы рабочих работа конструкторов и технологов никому не нужна.
Однако в программировании столь четкого разделения не произошло, из-за того, что средства производства программиста-конструктора, программиста-технолога и программиста-рабочего ничем не отличаются друг от друга, соответственно один и тот же программист легко может выполнять работу и конструктора, и технолога, и рабочего. Поэтому в программировании у нас есть два пути: 1) использовать только высококвалифицированных программистов, заставляя их заниматься и работой конструктора, и работой технолога, и работой рабочего 2) пойти по пути других производственных профессий, разделяя программистов на конструкторов, технологов и рабочих(кодеров).
В чем недостатки первого подхода, который сейчас можно считать общепринятым в программистской отрасли?
1) Трудности с набором сотрудников. Понятно, что точно также как и в любой другой профессии количество высококвалифицированных работников много меньше, чем общее число работников. Соответственно высококвалифицированных работников на всех не хватет и хватать не может. Если же мы берем (по ошибке или потому что других нет) работника менее квалифицированного, то он оказывается малополезен, т.к. при такой организации труда нет явно выделенных конструкторов и технологов, задачей которых было бы переформулирование исходной задачи в понятную менее квалифицированному программисту форму.
2) Высокая стоимость рабочей силы. Если нам повезло и все нанятые работники действительно оказались высококвалифицированными, то им и платить надо соответствующе. Однако если программист-технолог написал решение для типовой задачи, то производительность использования этого решения, что более высококвалифицированным, что менее квалифицированным программистом обычно близка. Соответственно возникает вопрос зачем платить больше?
3) Проблема с мотивацией. В любой работе есть рутинные задачи, типовое решение для которых уже давно найдено. И если программисты-технологи занимаются делом, то круг задач с типовыми решениями постоянно увеличивается. Если у нас есть только высококвалифицированные программисты, то хочешь не хочешь этими рутинными задачами приходиться заниматься им. Естественно они от этого не в восторге, т.к. для них эти задачи слишком примитивны и соответственно неинтересны. Кодеров же мотивировать на таких задачах проще, т.к. и сложность этих задач более близка к способностям кодера, и людей в кодеры можно набирать с предрасположенностью к рутинной работе.
4) Проблема с амбициями. Если у нас есть только высококвалифицированные программисты, то каждый имеет свое мнение на тему что и как делать. Соответственно либо приходиться ради единообразия решений в проекте выбирать решения одних программистов и ущемлять других, что не очень хорошо с точки зрения обстановки в коллективе. Либо мириться с тем, что каждый программист имеет свой зоопарк стандартных решений, что плохо с инженерной точки зрения. При использовании кодеров такой проблемы нет, кодер наоборот рад, что ему предлагают решение с помощью которого он может выполнять свои задачи проще.
Второй, т.е. традиционный производственный подход этих недостатков лишен, хотя естественно в нем есть свои проблемы. Однако как мне кажется эти проблемы существенно меньше, чем в первом подходе, а сегодняшнее доминирование первого подхода объясняется не его эффективностью, а молодостью профессии, в силу которой специализация труда в программировании еще не успела развиться.
Здравствуйте, FR, Вы писали:
FR>Ну и даже квалификация "подсобного рабочего" в программировании или "кодера" требуется достаточно высокой, для других областей работник с таким требуемым временем обучения и требуемыми навыками считается достаточно высококвалифицированным специалистом.
Глупости. "Квалификация подсобного кодера" — это излишки нашей системы образования, которая до сих пор клепает программистов на уровне университетов. А это — уровень техникума и полугодичных курсов.
> Т.е. если человек тупой, то он ремесленник, если человек умный, то он инженер, а если особо умный, то ученый. Исключительно глубокая мысль.
если человек имеет низкое абстрактное мышление — то он рабочий,
если более высокое — то инженер,
если имеет очень развитое абстрактное мышление — то он ученый.
навык декомпозиции — это часть абстрактного мышления.
U>Управленец занимается обеспечением разработки продукта ресурсами: кадрами, материалами, финансами
этим занимается снабжение, а не управленец(менеджер). т.е. устранением противоречий между возможностями поставщиков и требованиями организации — занимается снабжение.
U>, а также оцениваем нужность и качество продукта с точки зрения заказчика.
этим занимается маркетинг, а не управленец. т.е. устранением противоречий между желаниями заказчика и возможностями организации — занимается маркетинг.
> Собственно разработкой управленец не занимается, для этого у него нет достаточной квалификации, разработкой занимаются инженеры.
у меня складывается впечатление, что ты всю непроизводственную составляющую стрижешь под одну гребенку.
на самом деле деле там проблемы и задачи разные, и решаются разными людьми, разными способами.
и еще раз повторю, что основная задачу управленца — это устранить противоречия между людьми
DG>>ты кстати сколько можешь назвать требований к хорошо сделанной форме?
U>В смысле? Это к чему вопрос?
я утверждаю, что требований к форме слишком много, они очень противоречивы. готовой инструкции по разрешению этих противоречий нет,
поэтому для создания хорошей формы требуется человек со значительно развитым навыком абстрактного мышления — а это и есть инженер(программист), а не рабочий(кодировщик).
U>Вот тот человек, который декомпозицию задачи умеет делать только в голове, это ремесленник. А тот кто способен сделать декомпозицию задачи понятной другим людям это инженер.
уметь объяснить другим, то что уже есть в голове — это довольно простой навык, которому легко обучить (за год точно можно справиться)
U>Т.е. Монро был не просто умный, а очень умный, значит, он даже не инженер, а цельный ученый. Глубина мысли поражает.
вот быть умным (уметь развитый навык абстрактного мышления и соответственно уметь решать сложные задачи) — учить намного сложнее.
обучение абстрактному мышлению на текущий момент занимает 15 лет. и школа, и институт — наивным образом пытаются развить именно этот навык.
кстати, абстрактное мышление — это один из немногих навыков — который отличает человека от животного.
и получается, что важнее уметь выделять умных (а потом их учить формулировать свои знания для других), чем делить людей на "ремесленников" и "конструкторов", и фактически руководствоваться тем, что способности людей даны от рождения, менять их нельзя, и поэтому нефига людей вообще ничему обучать.
U>Такой недоконструктор может в лучшем случае выступать в роли эксперта, но никак не руководить разработкой.
более верное утверждение, что такая пара будет менее эффективна, чем один человек, за счет затрат на коммуникацию между ними.
и руководить разработкой сможет, просто чуть менее эффективно.
Здравствуйте, DarkGray, Вы писали:
DG>если человек имеет низкое абстрактное мышление — то он рабочий, DG>если более высокое — то инженер, DG>если имеет очень развитое абстрактное мышление — то он ученый.
И какие практические выводы следуют из этого гениального наблюдения? Что-то типа, если у вас работа над проектом идет плохо, увольте программистов и наберите более умных? Очень глубокий и полезный вывод.
Вот из индустриальной организации труда в программировании следуют следующие практические выводы:
1) В проекте необходимо выделить конструктора, т.е. человека, который будет освобожден от рутинной работы и за счет этого все свои усилия сможет тратить на понимание задачи как единого целого. Такая работа требует следующих навыков: а) способность понять задачу как единое целое б) способность разбить задачу на слабо связанные между собой подзадачи в) способность доступным языком донести имеющееся в голове разбиение общей задачи на подзадачи до других программистов
2) В проекте необходимо выделить технолога, т.е. человека, который будет освобожден от рутинной работы и за счет этого все свои усилия сможет тратить на выделение типовых задач в проекте и разработки типовых решений для таких задач. Также задачей технолога является помощь программистам-рабочим в сложных местах решаемых задач.
3) В проекте должны быть программисты-рабочие различной квалификации, от невысокой — для выполнения рутинной работы, до очень высокой — для написания, к примеру, сложных алгоритмов.
DG>и получается, что важнее уметь выделять умных (а потом их учить формулировать свои знания для других), чем делить людей на "ремесленников" и "конструкторов", и фактически руководствоваться тем, что способности людей даны от рождения, менять их нельзя, и поэтому нефига людей вообще ничему обучать.
Не понял откуда следует, что для рабочего должен быть закрыт путь в конструкторы или технологи? Вон у Форда вообще все нанимаемые инженеры должны были в начале пару лет отработать рабочими. Это оттого, что Форд ничего не понимал в индустриальном методе производства или оттого, что рабочий не может стать инженером?
U>И какие практические выводы следуют из этого гениального наблюдения? Что-то типа, если у вас работа над проектом идет плохо, увольте программистов и наберите более умных? Очень глубокий и полезный вывод.
теперь можно целенаправленно подбирать людей на проект.
т.е. можно еще до начала проекта на основе оценки сложности проекта — оценить люди с какой квалификацией нужны для его выполнения.
также можно прикинуть что нужно делать если людей нужной квалификации не хватает.
можно каждую работу измерить сколько единиц каждого навыка необходимо для ее исполнения, смотреть какие есть кандидаты и принимать решения кого куда поставить, чему научить и т.д.
U>Вот из индустриальной организации труда в программировании следуют следующие практические выводы:
U>1) В проекте необходимо выделить конструктора .. U>2) В проекте необходимо выделить технолога .. U>3) В проекте должны быть программисты-рабочие различной квалификации, от невысокой — для выполнения рутинной работы, до очень высокой — для написания, к примеру, сложных алгоритмов.
вот только опыт показывает, что хорошие изобретения были сделаны когда и конструкторское мышление, и технологическое мышление, и изготовление были сконцентрированы в одном человеке.
автомат калашникова, ил-2, форд-т и т.д. были сделаны людьми, которые совмещали в себя и конструктора, и технолога, и исполнителя.
форд еще это смешивал с менеджерскими навыками.
в тоже время форд совсем упускал из виду и игнорировал маркетинговую составляющую (и на этом его сделал крайслер)
специализация имеет серьезные минусы, возрастают затраты на коммуникацию.
в идеальном мире (где люди могут развиваться бесконечно) — хотелось бы, чтобы каждый человек имел и конструкторское мышление, и технологическое, и менеджерское, и маркетинговое, и экономическое и т.д.
невозможно сконструировать хорошее изделие, если конструктор
не думает о том насколько хорошо это изделие будет решать проблемы заказчика (это маркетинговые навыки),
не думает о том — как это изделие будет проще сделать (это технологические навыки),
не думает о том как конструктор сможет окупить свои затраты (это экономические навыки)
и т.д.
проблема специализации видна на примере текущей науки:
смежные области развиваются очень медленно: например, гениальный программ в биологии, химии и т.д. не видно, просто потому что талантливый биолог(химик и т.д.) не знает программирование и не может объяснить программисту свои проблемы,
а программист не понимает химии, биологии и не может донести свои знания и умения до биологов и химиков.
в реальном мире хочется, чтобы конструктор обладал хотя бы общим маркетинговым, технологическим и т.д. видением,
технолог — конструкторским, маркетинговым, менеджерским и т.д.
маркетолог — конструкторским, технологическим, менеджерским и т.д.
DG>>и получается, что важнее уметь выделять умных (а потом их учить формулировать свои знания для других), чем делить людей на "ремесленников" и "конструкторов", и фактически руководствоваться тем, что способности людей даны от рождения, менять их нельзя, и поэтому нефига людей вообще ничему обучать.
U>Не понял откуда следует, что для рабочего должен быть закрыт путь в конструкторы или технологи? Вон у Форда вообще все нанимаемые инженеры должны были в начале пару лет отработать рабочими. Это оттого, что Форд ничего не понимал в индустриальном методе производства или оттого, что рабочий не может стать инженером?
логика непонятная в абзаце.
оттого что от инженера требуется сначала работать рабочим, совсем не следует, что рабочий может стать инженером
это даже с точки зрения типизации не проходит
(new инженер() as рабочий) as инженер — отработает, а вот new рабочий() as инженер — упадет.
форд посылал инженеров на производство, чтобы они понимали технологическую составляющую.
и этим он из конструкторов — делал конструкторов с навыками технологов. опять же интуитивно понимая, что специализация в чистом виде — это зло.
U> На работу всех принимаем на общих основаниях, далее те кто имеют способности продвигаются в конструкторы, технологи или высококвалифицированные рабочие, а те кто такими способностям не обладают остаются кодерами, благо рутинные задачи тоже кому-то надо решать.
у этого варианта есть ряд минусов:
1. если инженера ставить на рутинную работу — то он начинает тупеть, а не развиваться (т.к. бытие влияет на сознание)
2. есть наблюдение, что активность снижается с возрастом (пик где-то в районе 25-30), поэтому если человека прогонять через все карьерные ступеньки, то наверх он уже приходит в том возврасте, когда ему ничего не хочется
т.е. в идеале: ученого стоит ставить сразу на место ученого, инженера на место инженера, а рабочего на место рабочего.
зы
в идеале, с точки зрения развития, человека стоит ставить на задачи — которые на 5-15% сложнее, чем тот уровень задач, которые он умеет решать.
если ставить на более простые: то идет снижение умственной активности и демотивация по линии самореализации,
если ставить на более сложные: то идет сильная демотивация по линии достижений.
и исходя из этого — будущего инженера неэффективно ставить токарем, его необходимо ставить как минимум помощником инженера.
U>Естественно лучше всего когда в человеке все эти навыки совмещены. Только вот проблема, что таких людей очень немного. Соответственно если на должность программиста-конструктора найти такого человека еще можно, то заполнить должности рядовых программистов такими людьми никогда не получится.
до этого ты утверждал, что если в человеке все навыки совмещены и ему никто не нужен, то он в лучшем случае ремесленник.
а если люди глупые, сами решить задачу не могут и для этого нанимают других, которым ставят задачи — то они сразу становятся конструкторами.
зы
я до сих пор утверждаю, что квалификация человека определяется сложностью решаемых лично им задач: и не важно делается это в одиночку или есть при этом коммуникация с другими людьми.
Здравствуйте, divergo, Вы писали:
D>К слову, начинающие программисты точно по такому же принципу составляют свои резюме.
Я именно это и имею ввиду, могу например список форумов РСДН себе в резюме написать, толку то если: D>Большинство вакансий именно для кодеров, и для этой скучной, рутинной, не требующей большого ума работы ищут гениев
Самая большая в мире ложь — "Я прочел и согласен с условиями пользовательского соглашения".
Л>Подумал поработать, что не вакансия так минимум похоже я буду один операционную систему писать, судя по количеству необходимых знаний, ну я например много технологий знаю, причем не по книжкам, а реально сталкивался, разбирался, писал. Например работал с MSXML, но задай мне вопрос с которым я не сталкивался, я ноль, хотя за пару минут найду и примеры и пойму алгоритм решения. Т.е. если перечислить то что я "знаю" большой список получится, но если начать меня по нему тестировать завалить меня нечего делать. Л>Собственно вот и возникает вопрос, а просто кодеры сейчас не нужны что-ли? Который может и не гуру в 20 темах, но решать вопросы нехватки знаний умеет. Или студенты эту нишу забивают?
Не очень понятно при чем здесь "кодер". Не всем конторам нужно очень глубокое знание технологий, достаточно просто хорошего знания. В чем проблема?
Здравствуйте, Niemand, Вы писали:
N> А потом все скатывается в i++++i и зачем нужен виртуальный деструктор (кстати на этом вопросе закончилось мое самое короткое 3х-минутное собеседование в CDD).
А допустим так, имеет ли моральное право следующий подход, записываюсь на собеседование и сразу влоб начинаю рассказывать по пунктам:
У вас здесь знание MySQL, я умею подключаться клиентом, читать и писать, больше ничего не делал.
MSXML чтение запись, выбор, перебор, поиск, больше ничего не делал и т.д.
Разумеется по поводу узких технологий.
Эта тактика изначально провальная?
Или она честная и мы не будем тратить время друг друга понапрасну?
Самая большая в мире ложь — "Я прочел и согласен с условиями пользовательского соглашения".
Здравствуйте, Ларик, Вы писали:
Л>А допустим так, имеет ли моральное право следующий подход, записываюсь на собеседование и сразу влоб начинаю рассказывать по пунктам: Л>У вас здесь знание MySQL, я умею подключаться клиентом, читать и писать, больше ничего не делал. Л>MSXML чтение запись, выбор, перебор, поиск, больше ничего не делал и т.д. Л>Разумеется по поводу узких технологий. Л>Эта тактика изначально провальная? Л>Или она честная и мы не будем тратить время друг друга понапрасну?
Следуя предельно точно именно этой тактике, я уехал в Австралию в мегакорпорацию Но с русскими это не прокатывает — национальная подозрительность а-ля "у всех 10летних иномарок всегда скручен пробег".
aik>Но с русскими это не прокатывает — национальная подозрительность а-ля "у всех 10летних иномарок всегда скручен пробег".
Увы, так и есть.
Я пытался все это написать в резюме — не работает, приглашают и начинают с вопросов типа: Назовите принципы ООП или Чем отличается класс от структуры
Здравствуйте, Niemand, Вы писали: N>Еще интересный момент который заметил (много общаюсь со знакомыми на эту тему). Собеседования типа "встретились, попили пива, поговорили о жизни" практикуются как правило в стартапах. А потом все скатывается в i++++i и зачем нужен виртуальный деструктор (кстати на этом вопросе закончилось мое самое короткое 3х-минутное собеседование в CDD).
Эт еще что, в паралелзе на собеседовании на сеньерскую позицию спрашивают чем отличается оператор "=" от оператора "=="
Здравствуйте, aik, Вы писали:
aik>Но с русскими это не прокатывает — национальная подозрительность а-ля "у всех 10летних иномарок всегда скручен пробег".
Здравствуйте, aik, Вы писали:
aik>Но с русскими это не прокатывает — национальная подозрительность а-ля "у всех 10летних иномарок всегда скручен пробег".
Вообще странно, тут наверное проблема в том что проводящий собеседование и сам не знает что им нужно, а так бы намного быстрее и честнее было, как супер вариант еще бы и сказали что им не хватает, я бы для интереса почитал, а потом оп, а вакансия-то еще открыта.
Самая большая в мире ложь — "Я прочел и согласен с условиями пользовательского соглашения".
Здравствуйте, Nik_1, Вы писали:
N_>Эт еще что, в паралелзе на собеседовании на сеньерскую позицию спрашивают чем отличается оператор "=" от оператора "=="
количеством знаков?
If the message above is in English — means I'm wasting my work time and work computer to post here. No hard feelings
Здравствуйте, Ларик, Вы писали:
Л>Песли начать меня по нему тестировать завалить меня нечего делать.
Откуда постоянно лезет употребление слова “завалить” применительно к собеседованиям? С чего вы взяли, что вас хотят завалить? Вы от университетских экзаменов до сих пор не оправились, что-ли?
Здравствуйте, Кодёнок, Вы писали:
Л>>Песли начать меня по нему тестировать завалить меня нечего делать.
Кё>Откуда постоянно лезет употребление слова “завалить” применительно к собеседованиям? С чего вы взяли, что вас хотят завалить?
Здравствуйте, MxMsk, Вы писали:
MM>Да всё те же программеры и определяют.
Чтобы потом в курилке нескучно было какую-нить новую багу в Х-технологии обсудить что-ли? PS Может показаться что это сарказм, но такое ощущение что пытаются набрать людей одного уровня.
Самая большая в мире ложь — "Я прочел и согласен с условиями пользовательского соглашения".
Здравствуйте, Nik_1, Вы писали:
N_>Здравствуйте, SE, Вы писали: SE>>2. Интернета под рукой может и не оказаться в самый ответственный момент.
N_>Ага, слышал про компании где разработчикам умышленно инет не дают. Стараюсь такие конторки закилометр обходить.
Я тоже
Но, я написал не "постоянно", а "в самый ответственный момент". На RSDN, помнится была история фрилансера, у которого прямо во время демонстрации заказчику вырубился интернет, а два резервных мибильных оказались в реальности не рабочими.
И такие вещи бывают не только со фрилансерами.
Здравствуйте, aik, Вы писали:
aik>Я лет 10 назад собеседовал чувака одного — нужен был человек, знакомый с ядром линукса. Пришел товарищ и наплел что он в ядре какой то драйвер пишет-поддерживает (ntfs или что то похожее). После я написал парням, которые в драйвере упомянуты — они говорят "ну да, приходил такой то полгода назад, предлагал помощь, дали работу — а он и пропал напрочь". Такие сказочники попадаются
Почему сразу сказочники? Может он для какого нибудь дистриба этот драйвер пилит, а в апстрим его изменения не попадают.
Здравствуйте, MxMsk, Вы писали:
MM>На сабжевый вопрос захотелось ответить, что программеры в этом сами и виноваты, превратив понятие простого кодинга в нечто унизительное и оскорбительное, словно этим какие-то недочеловеки занимаются. Далеко ходить не надо. На этом форуме то и дело проскакивают соответствующие фразенки в стиле "я же не кодер" или "да эту херню может просто кодер написать". Вот и фирмах теперь также: "нам простой кодер не нужен". Ну, а раз не нужен, то на тебе списочег на 500 наименований.
Вообще-то не кодер от кодера отличается вовсе не знанием конкретных технологий.
Здравствуйте, Undying, Вы писали:
U>Вообще-то не кодер от кодера отличается вовсе не знанием конкретных технологий.
Скорее всего ты хочешь сказать об умении, или даже желании думать/не_думать, расти/не_расти. Ну, а как это отразить в вакансии? "Кодеры не нужны"? Я подозреваю, что логика здесь такая: раз кодер тупо исполняет приказы, значит он не растет и знает мало. Если же чувак шарит много в чем, то скорее всего он не кодер.
Здравствуйте, Ларик, Вы писали:
Л>Здравствуйте, MxMsk, Вы писали: MM>>Да всё те же программеры и определяют. Л>Чтобы потом в курилке нескучно было какую-нить новую багу в Х-технологии обсудить что-ли? PS Может показаться что это сарказм, но такое ощущение что пытаются набрать людей одного уровня.
Я скорее процесс описал, в которым ключевое, что не HR определяет требования к вакансиям. Почему выдвигают такие требования, для меня тоже секрет.
Здравствуйте, MxMsk, Вы писали:
MM>Скорее всего ты хочешь сказать об умении, или даже желании думать/не_думать, расти/не_расти.
Некодер от кодера отличается уровнем архитектурных навыков, т.е. способностью делать сложное простым, и уровнем программистских навыков, т.е. способностью работать со сложным.
MM>Ну, а как это отразить в вакансии?
Отразить сложнее. Но смысла упирать в вакансии на технологии нет вообще, т.к. знание технологий ничего не говорит о уровне программиста и его способности решать реальные бизнес-задачи.
Здравствуйте, Undying, Вы писали:
MM>>Скорее всего ты хочешь сказать об умении, или даже желании думать/не_думать, расти/не_расти. U>Некодер от кодера отличается уровнем архитектурных навыков, т.е. способностью делать сложное простым, и уровнем программистских навыков, т.е. способностью работать со сложным.
Откровенно говоря, я не люблю это деление и мне не нравится, когда слово "кодер" употребляют в уничижительном смысле.
MM>>Ну, а как это отразить в вакансии? U>Отразить сложнее. Но смысла упирать в вакансии на технологии нет вообще, т.к. знание технологий ничего не говорит о уровне программиста и его способности решать реальные бизнес-задачи.
Я с этим согласен. Как согласен и с FRED
-ом. Просто привожу возможные причины, почему требования так составляют. "Нам не нужен простой кодер. Нужно, чтобы он знал X и Y, разбирался в паттернах" и т.д. Вот требования и нарастают, пускай реально они не нужны.
Здравствуйте, Nikolay.TS, Вы писали:
NT>Здравствуйте, Ларик, Вы писали:
Л>>что не вакансия так минимум похоже я буду один операционную систему писать, судя по количеству необходимых знаний, NT>Обычно просто пишут с чем может быть придется столкнуться — не обязательно полностью подходить
Но это будет поводом предложить зп пониже, мол вы нам подходите, но надо бы поднабраться опыта. Вы же понимаете...
Л>>но если начать меня по нему тестировать завалить меня нечего делать. NT>Как правило, достаточно рассказать что и как делал, а на адекватных собеседованиях цели завалить не ставится.
Адекватное собеседование обычно вообще проходит в русле беседы чем занимался раньше кандидат и чем занимается компания.
Здравствуйте, MxMsk, Вы писали:
MM>Я скорее процесс описал, в которым ключевое, что не HR определяет требования к вакансиям. Почему выдвигают такие требования, для меня тоже секрет.
В РФ крайне редко встречается компетентный HR, обычно там работаю девочки — вчерашние студентки, которые даже грамотно составить приглашение на собеседование не умеют .
Здравствуйте, divergo, Вы писали:
D>Здравствуйте, Ларик, Вы писали:
Л>>Подумал поработать... D>Здравая мысль
D>HR пишут в объявлениях названия всех технологий подряд, которые хоть каким боком могут пригодиться. D>К слову, начинающие программисты точно по такому же принципу составляют свои резюме.
D>Большинство вакансий именно для кодеров, и для этой скучной, рутинной, не требующей большого ума работы ищут гениев
В чём смысл слова кодер? При найме работодатель хочет себя максимально обезопасить. Проверить опыт — сложно, серьёзное тестовое задание далеко не каждый согласится выполнять, а оплачивать жаба душит. Приходится проверять формальные знания.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, MxMsk, Вы писали:
MM>>Скорее всего ты хочешь сказать об умении, или даже желании думать/не_думать, расти/не_расти.
U>Некодер от кодера отличается уровнем архитектурных навыков, т.е. способностью делать сложное простым, и уровнем программистских навыков, т.е. способностью работать со сложным.
MM>>Ну, а как это отразить в вакансии?
U>Отразить сложнее. Но смысла упирать в вакансии на технологии нет вообще, т.к. знание технологий ничего не говорит о уровне программиста и его способности решать реальные бизнес-задачи.
Проблема в том что покупаешь кота в мешке. Как например проверить, что кандидат не зная веба сможет за два месяца войти в струю и начать приносить пользу?
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, Aviator, Вы писали:
MM>>>Я скорее процесс описал, в которым ключевое, что не HR определяет требования к вакансиям. Почему выдвигают такие требования, для меня тоже секрет. A>>В РФ крайне редко встречается компетентный HR, обычно там работаю девочки — вчерашние студентки, которые даже грамотно составить приглашение на собеседование не умеют . MM>Гы. Отвечу тебе глазами HR MM>В РФ крайне редко встречается компетентный программист, обычно там работаю мальчики — вчерашние студенты, которые даже грамотно составить резюме не умеют .
Как частично выполнявший роль HR, не могу с этим согласиться .
Здравствуйте, Aviator, Вы писали:
A>>>Здравствуйте, SE, Вы писали:
A>Да, я не вижу какие знания для собеседования можно подцепить за два дня гугла.
И я не вижу
A>Если работодатель смотрит на общий опыт то ему на это пофик, если ему важно знание конкретных технологий, то твоя двухдневная глубина знаний будет моментально вскрыта.
Безусловно.
A>Или ты не видишь разницы между знанием и знакомством?
А, так ты из темы выпал
Я Ларику отвечал на
Например работал с MSXML, но задай мне вопрос с которым я не сталкивался, я ноль, хотя за пару минут найду и примеры и пойму алгоритм решения.
И посоветовал, потому, погуглить превентивно то, что у него спросить могут. Т.е. он знает, но с некоторыми вопросами незнаком
Видишь разницу?
A>Ты студент?
А на твой вопрос можно узнать ответ за "несколько минут гугла"
Здравствуйте, Aviator, Вы писали: MM>>В РФ крайне редко встречается компетентный программист, обычно там работаю мальчики — вчерашние студенты, которые даже грамотно составить резюме не умеют . A>Как частично выполнявший роль HR, не могу с этим согласиться .
В одной американской книге упоминалось, что проблемы у HR
возникают даже с недавними выпускниками МИТ...
Полагаю, что речь идет о HR уровня Fortune 100 или как
это у них называется.
Здравствуйте, Ларик, Вы писали:
aik>>Но с русскими это не прокатывает — национальная подозрительность а-ля "у всех 10летних иномарок всегда скручен пробег". Л>Вообще странно, тут наверное проблема в том что проводящий собеседование и сам не знает что им нужно.
Он как раз знает. Только он не знает как избежать на*бок, поэтому пытается проверить общую профпригодность как умеет.
Здравствуйте, Miroff, Вы писали:
aik>>Я лет 10 назад собеседовал чувака одного — нужен был человек, знакомый с ядром линукса. Пришел товарищ и наплел что он в ядре какой то драйвер пишет-поддерживает (ntfs или что то похожее). После я написал парням, которые в драйвере упомянуты — они говорят "ну да, приходил такой то полгода назад, предлагал помощь, дали работу — а он и пропал напрочь". Такие сказочники попадаются M>Почему сразу сказочники? Может он для какого нибудь дистриба этот драйвер пилит, а в апстрим его изменения не попадают.
Ну воспоминания были такие, что он заявил что пилит для апстрима.
Здравствуйте, dilmah, Вы писали:
P>>Ну так может это они думают, что пропал, а он на самом деле пишет-поддерживает. Только никому не показывает. D>Вот они -- прелести распределенных систем контроля версий
Поясни ка. Они всегда распределенные по сути, потому что всегда есть куча незакоммиченого кода, который у людей лежит в локальных tar.gz, cvs, git, svn, блаблабла. Популярная штука, ядро.
Здравствуйте, MxMsk, Вы писали:
MM>Скорее всего ты хочешь сказать об умении, или даже желании думать/не_думать, расти/не_расти.
Ну а допустим я не хочу "расти" т.е. в будующем отвечать за других людей, хочу тупо работать и получать свою копеечку, вот нет у меня амбиций лидера, да и желания.
Самая большая в мире ложь — "Я прочел и согласен с условиями пользовательского соглашения".
U>Второй, т.е. традиционный производственный подход этих недостатков лишен, хотя естественно в нем есть свои проблемы. Однако как мне кажется эти проблемы существенно меньше, чем в первом подходе, а сегодняшнее доминирование первого подхода объясняется не его эффективностью, а молодостью профессии, в силу которой специализация труда в программировании еще не успела развиться.
что производственный подход мало пригоден в разработке софта.
Ну и профессия не молода, уже 50 с лишим лет существует, авто и авиастроение за гораздо меньшее время индустриализовалось.
Попыток индустриализации было за это время предпринято немало, но не одна толком не прижилась.
что производственный подход мало пригоден в разработке софта.
Gaperton описывает не производственный подход, а лишь его часть в виде изготовления серийных изделий. Естественно этот подход не пригоден для разработки программ, равно как он не пригоден и для разработки автомобилей. Т.к. технологическая карта это результат работы конструкторов и технологов, а не методика описывающая как конструкторам и технологам надо работать. Соответственно все эти IDEF0/SADT пригодны для описания работы рабочего на конвейере, но не пригодны ни для описания работы рабочих опытных цехов, ни уж тем более для описания работы конструкторов и технологов.
FR>Ну и профессия не молода, уже 50 с лишим лет существует, авто и авиастроение за гораздо меньшее время индустриализовалось.
Еще двадцать лет назад программисты были очень сильно лимитированы в ресурсах, соответственно требования эффективности не позволяли широко использовать универсальные решения, поэтому тогда перейти к специализации труда возможности не было. И только в последние двадцать лет ситуация поменялась, соответственно программирование в его современном виде очень молодая профессия.
что производственный подход мало пригоден в разработке софта.
Т.е. я утверждаю, что разработка программы принципиально не отличается от разработки автомобиля и изготовления его опытного образца. Соответственно подходы применяемые в разработке автомобилей и изготовлении опытных образцов автомобилей вполне могут работать и в программировании. Как, к примеру, программистские шаблоны проектирования появились на основе изучения архитектурных шаблонов проектирования. А вот между изготовлением серийного образца программы и серийного автомобиля нет ничего общего, т.к. серийная программа изготавливается по нажатию F5, а для изготовления серийного автомобиля надо еще пахать и пахать. Соответственно подходы пригодные для изготовления серийных изделий, совершенно не пригодны для изготовления программ.
Здравствуйте, Undying, Вы писали:
U>Т.е. я утверждаю, что разработка программы принципиально не отличается от разработки автомобиля и изготовления его опытного образца. Соответственно подходы применяемые в разработке автомобилей и изготовлении опытных образцов автомобилей вполне могут работать и в программировании. Как, к примеру, программистские шаблоны проектирования появились на основе изучения архитектурных шаблонов проектирования. А вот между изготовлением серийного образца программы и серийного автомобиля нет ничего общего, т.к. серийная программа изготавливается по нажатию F5, а для изготовления серийного автомобиля надо еще пахать и пахать. Соответственно подходы пригодные для изготовления серийных изделий, совершенно не пригодны для изготовления программ.
Угу вот только опытные образцы как раз изготавливаются высококвалифицированными разработчиками, (и это не только конструкторы и дизайнеры, но и слесаря) места для индусов там нет, практически получается описанный тобой первый вариант. Правда ты почему-то считаешь что он исключает специализацию, но это не так.
Здравствуйте, Undying, Вы писали:
U>Gaperton описывает не производственный подход, а лишь его часть в виде изготовления серийных изделий. Естественно этот подход не пригоден для разработки программ, равно как он не пригоден и для разработки автомобилей. Т.к. технологическая карта это результат работы конструкторов и технологов, а не методика описывающая как конструкторам и технологам надо работать. Соответственно все эти IDEF0/SADT пригодны для описания работы рабочего на конвейере, но не пригодны ни для описания работы рабочих опытных цехов, ни уж тем более для описания работы конструкторов и технологов.
Угу только очень большая часть IT управленцев даже этого не понимает.
U>Еще двадцать лет назад программисты были очень сильно лимитированы в ресурсах, соответственно требования эффективности не позволяли широко использовать универсальные решения, поэтому тогда перейти к специализации труда возможности не было. И только в последние двадцать лет ситуация поменялась, соответственно программирование в его современном виде очень молодая профессия.
Спорно, в том же автомобилестроении скудность ресурсов не мешала, не помешала она и японцам организовывать фабрики программирования на ассемблере, там все было заиндустриализировано до предела, что не помешало им пролететь, они кстати вполне аналог и по времени и по организации фордовского конвейера. Да и 20 лет срок более чем достаточный.
Здравствуйте, FR, Вы писали:
FR>Угу вот только опытные образцы как раз изготавливаются высококвалифицированными разработчиками, (и это не только конструкторы и дизайнеры, но и слесаря) места для индусов там нет, практически получается описанный тобой первый вариант. Правда ты почему-то считаешь что он исключает специализацию, но это не так.
Для изготовления опытного образца обычно нужны работники самой различной квалификации, от токаря 6 разряда, которого действительно нужно готовить дольше, чем основную массу конструкторов и технологов, до подсобного рабочего, от которого по большему счету кроме исполнительности ничего не требуется. В программирование все тоже самое.
Здравствуйте, FR, Вы писали:
FR>Угу только очень большая часть IT управленцев даже этого не понимает.
Это их проблемы.
FR>Спорно, в том же автомобилестроении скудность ресурсов не мешала, не помешала она и японцам организовывать фабрики программирования на ассемблере, там все было заиндустриализировано до предела, что не помешало им пролететь, они кстати вполне аналог и по времени и по организации фордовского конвейера. Да и 20 лет срок более чем достаточный.
Я еще раз повторяю, что конвейер это отличный способ производства серийного изделия, в программировании серийных изделий нет в принципе, есть только опытные. Соответственно было бы странным, если бы у японцев что-то получилось.
Здравствуйте, Aviator, Вы писали:
A>Проблема в том что покупаешь кота в мешке. Как например проверить, что кандидат не зная веба сможет за два месяца войти в струю и начать приносить пользу?
Я правильно понимаю, что мы ведем речь о случае, когда специалисты по вебу у нас есть и решения типовых задач уже написаны?
В этом случае если нужен кодер, то нас должны интересовать следующие качества: определенный уровень (не особо высокий) алгоритмических и архитектурных навыков, способность решать задачи по аналогии, умение работать с документацией, исполнительность, здравый смысл. Собственно опыт работы с вебом будем бонусом, но не особо большим.
U>Для изготовления опытного образца обычно нужны работники самой различной квалификации, от токаря 6 разряда, которого действительно нужно готовить дольше, чем основную массу конструкторов и технологов, до подсобного рабочего, от которого по большему счету кроме исполнительности ничего не требуется. В программирование все тоже самое.
Конечно, но проблема в том, что подсобных рабочих много не требуется, часто даже меньше чем квалифицированных, и схема пять высокооплачиваемых инженеров плюс 100 низкоквалифицированных и соответственно низкооплачиваемых рабочих не работает.
Ну и даже квалификация "подсобного рабочего" в программировании или "кодера" требуется достаточно высокой, для других областей работник с таким требуемым временем обучения и требуемыми навыками считается достаточно высококвалифицированным специалистом.
Здравствуйте, Undying, Вы писали:
U>Я еще раз повторяю, что конвейер это отличный способ производства серийного изделия, в программировании серийных изделий нет в принципе, есть только опытные. Соответственно было бы странным, если бы у японцев что-то получилось.
Ну так они по сути и воплотили то что ты предложил:
пойти по пути других производственных профессий, разделяя программистов на конструкторов, технологов и рабочих(кодеров)
Здравствуйте, FR, Вы писали:
FR>Конечно, но проблема в том, что подсобных рабочих много не требуется, часто даже меньше чем квалифицированных, и схема пять высокооплачиваемых инженеров плюс 100 низкоквалифицированных и соответственно низкооплачиваемых рабочих не работает.
Так и в непрограммной разработке все то же самое. Опытные цеха обычно по численности как бы не меньше, чем ИТР будут.
FR>Ну и даже квалификация "подсобного рабочего" в программировании или "кодера" требуется достаточно высокой, для других областей работник с таким требуемым временем обучения и требуемыми навыками считается достаточно высококвалифицированным специалистом.
А что в других производствах не бывает высококвалифицированных рабочих? Того же высококлассного токаря нужно готовить лет пятнадцать, куда там программистам. Деление на конструкторов, технологов и рабочих это в первую очередь не деление по квалификации и времени подготовки, а деление по классу решаемых задач.
Здравствуйте, FR, Вы писали:
FR>Ну так они по сути и воплотили то что ты предложил: FR>
FR>пойти по пути других производственных профессий, разделяя программистов на конструкторов, технологов и рабочих(кодеров)
Ты вроде только что утверждал, что они пытались внедрить в программирование аналог конвейера, а не просто ввести разделение на конструкторов, технологов и рабочих. Если не сложно опиши в общем в чем состояла идея японцев.
Здравствуйте, Undying, Вы писали:
FR>>Конечно, но проблема в том, что подсобных рабочих много не требуется, часто даже меньше чем квалифицированных, и схема пять высокооплачиваемых инженеров плюс 100 низкоквалифицированных и соответственно низкооплачиваемых рабочих не работает.
U>Так и в непрограммной разработке все то же самое. Опытные цеха обычно по численности как бы не меньше, чем ИТР будут.
Тогда не вижу плюсов твоей второй схемы.
FR>>Ну и даже квалификация "подсобного рабочего" в программировании или "кодера" требуется достаточно высокой, для других областей работник с таким требуемым временем обучения и требуемыми навыками считается достаточно высококвалифицированным специалистом.
U>А что в других производствах не бывает высококвалифицированных рабочих? Того же высококлассного токаря нужно готовить лет пятнадцать, куда там программистам. Деление на конструкторов, технологов и рабочих это в первую очередь не деление по квалификации и времени подготовки, а деление по классу решаемых задач.
Бывает, но почти нигде нет такого что совсем неквалифицированные работники вовсе не требуются.
Проблема в том что у нас "рабочему" требуются навыки "конструктора" и наоборот.
U>1) Трудности с набором сотрудников. Понятно, что точно также как и в любой другой профессии количество высококвалифицированных работников много меньше, чем общее число работников. Соответственно высококвалифицированных работников на всех не хватет и хватать не может. Если же мы берем (по ошибке или потому что других нет) работника менее квалифицированного, то он оказывается малополезен, т.к. при такой организации труда нет явно выделенных конструкторов и технологов, задачей которых было бы переформулирование исходной задачи в понятную менее квалифицированному программисту форму.
Вот тут кстати одна проблемка, часто это переформулирование занимает времени сопоставимо с тем которое требуется чтобы просто ее самому решить.
А в результате то, что первовариантный программист сделает скажем за N человеко-часов "технолог" и "рабочие" затратят 2N тех же человеко-часов.
При этом у первого качество наверняка будет лучше.
Схема архитектор — разработчики (это "технолог" + "рабочий" в одном флаконе) мне кажется более адекватной для
совтостроения чем "конструктор" + "технологи" + "рабочие".
Насколько я понял идея заключается в следующем. Используйте наши мегакрутые и мегауниверсальные решения и для разработки программного обеспечения вам понадобится только главный конструктор (архитектор) и толпа рабочих (кодеров). Это примерно тоже самое, что разрабатывать автомобиль не имея своего конструкторского бюро и используя только универсальные решения разработанными другими КБ. Честно говоря я сильно удивляюсь как такой подход хоть у кого-то работает. Для того, чтобы кодеры были эффективны, необходимо наличие прослойки конструкторов и технологов, которые будут переводить исходную задачу на понятный кодерам уровень.
FR>http://www5d.biglobe.ne.jp/~y-h-m/An%20Approach%20to%20Cell-Based%20Software%20Factory-v.01.pdf FR>В результате у них получалось надежное ПО с достаточно предсказуемыми сроками, но при этом сами эти сроки разработки были FR>в разы дольше чем у американцев и требовали в те же разы больше рабочих ресурсов.
Здесь в чем фишка вообще не понял, осталось только впечатление как о чем-то крайне зарегулированном. В творческой работе зарегулированность обычно работает плохо, и если это не взлетело даже у японцев с их специфическим менталитетом, то у остальных не взлетит подавно.
даже на реальном производстве рабочих поджимают станки, автоматы и т.д.
т.е. как только появляется значительный объем одинаковой рутиной работы он заменяется на специализированный станок, или на автомат.
в программированием с заменой рутиной работы на автоматику еще проще. если в реальном мире продвижение автоматики упирается в сложность распознавания картинки, сложность манипуляции с реальным миром, то внутри компьютера таких проблем нет.
можно зайти и с другой стороны:
больше всего программистов занято в прикладном программировании аля 1с и сайт-морда компании. но здесь основная трудность — это понять заказчика и переложить это на компьютер, и здесь требуется очень малый объем кодирования.
т.е. даже в самой распространенной группе нет потребности в кодировщиках, а есть высокая потребность в специалистах, которые могут поговорить с другими людьми, а потом это формализовать в той мере, которую понимает текущий уровень компьютеров.
если смотреть на рынок программирования, то в кодировщиках заинтересованы только крупные интеграторы — задачей которых является решать простые, но большие задачи.
у них из-за того, что задачи простые — нет потребности нанимать крутых программистов, и в тоже время из-за того, что задачи большие, тот человек который общался с заказчиком самостоятельно не может это закодить, а вынужден прибегать к помощи кодировщиков.
Здравствуйте, DarkGray, Вы писали:
DG>в программированием с заменой рутиной работы на автоматику еще проще. если в реальном мире продвижение автоматики упирается в сложность распознавания картинки, сложность манипуляции с реальным миром, то внутри компьютера таких проблем нет.
Так кто должен заниматься рутинными задачами? К примеру, клепать формочки на основе GridSynchronizer'а? Что такой работы мало? Для нее нужна высокая квалификация? Или ты такую работу уже автоматизировал?
Здравствуйте, DarkGray, Вы писали:
DG>первая работа — это работа постановщика задачи, а не кодировщика DG>второй работы, после того как сделана первая работа — очень и очень мало.
Я бы сказал, наоборот, первая часть работы это в типовых случаях 10% времени, а реализация — 90%.
DG>и если первое делается с помощью какого-то специализированного инструмента, а не с помощью paint-а, то вторая работа вообще нивелируется
Ты эти специализированные инструменты уже используешь или восхищаешься ими издали?
можно выделить три уровня исполнителей:
рабочий,
инженер,
ученый.
рабочий — гонит объем по инструкции(алгоритму), если произошло что-то выходящее за рамки инструкции, останавливает свою работу.
инженер — выполняет задачу разрешения противоречий (задачу оптимизации) на основе готовых наработок. так же формирует инструкции для рабочих
ученый — исследует классы задач, формируя готовые наработки по их решению.
этой классификации соответствуют уровни образования:
рабочий — колледж (реже только школа)
инженер — институт
ученый — университет+аспирантура
задача размещения элементов на форме — это оптимизационная задача, где необходимо свести воедино кучу противоречий и критериев.
в общем виде — эта задача не имеет пошагового алгоритма. (есть частные варианты, легко алгоритмизирующиеся, но обычно они сразу же и автоматизируются)
все это нас приводит к тому — что эта проблема требует уровня инженера, а не рабочего.
кодировщик — это уровень рабочего, а не инженера, и для данной задачи не подходит.
Здравствуйте, MxMsk, Вы писали:
MM>вчерашние студенты, которые даже грамотно составить резюме не умеют .
А я подержу — тут, на РСДН, у многих, даже у компететных, с руским ну-просто беда.
Здравствуйте, DarkGray, Вы писали:
DG>рабочий — гонит объем по инструкции(алгоритму), если произошло что-то выходящее за рамки инструкции, останавливает свою работу.
Это по твоему определение рабочего в общем случае? Вот к тебе сантехник пришел. Он рабочий? Ты что для него инструкцию как работать пишешь? Нет. Ты ему ставишь задачу как заказчик, т.е. в общих словах и не вдаваясь в специфику сантехники, т.к. ничего в этом не понимаешь. И принципиально постановка заказчиком задачи сантехнику ничем не отличается от постановки заказчиком задачи программисту. Соответственно вовсе не работа по инструкции является ключевым отличием рабочего от инженера.
Никаких инструкций у сантехника нет, сантехник руководствуясь требованиями заказчика сам принимает решения что ему делать, как ему делать и сам же выполняет собственно работу. Пока программист работает над задачей заказчика в одиночку его действия принципиально ничем от действий сантехника не отличаются. Различие начинается, когда мы сталкиваемся с более сложной задачей, которую невозможно (слишком долго) решать в одиночку. Вот когда над задачей работает несколько рабочих (например, программистов), тогда и возникает потребность в человеке, который будет способен охватить решаемую задачу целиком и за счет этого сможет координировать деятельность рабочих, т.е. возникает потребность в конструкторе. И тогда же возникает потребность в человеке, который будет думать как какую-то операцию можно сделать в принципе и как ее можно упростить, чтобы ее мог выполнять рабочий с меньшей квалификацией и/или с меньшими трудозатратами, и который будет заниматься формализацией действий рабочих, чтобы сделать возможным передачу опыта другим рабочим, т.е. возникает потребность в технологе.
Соответственно само понятие инженера имеет смысл только при наличии вертикального разделения труда. Если же в коллективе программистов вертикального разделения труда нет, а есть только горизонтальное, то инженеров в таком коллективе нет, в нем есть только рабочие, хотя возможно и очень высокой квалификации. В материальном производстве такое тоже было всего лишь полтысячелетия назад, называлось это ремесленничество.
Если же в коллективе программистов вертикального разделения труда нет, а есть только горизонтальное, то инженеров в таком коллективе нет, в нем есть только рабочие, хотя возможно и очень высокой квалификации.
Выделенное нужно заменить на ремесленники, т.к. рабочие это тоже продукт вертикального разделения труда, и если нет такого разделения, то нет и рабочих.
U>> который будет способен охватить решаемую задачу целиком и за счет этого сможет координировать деятельность рабочих, т.е. возникает потребность в конструкторе.
DG>вот только это уже управленец (менеджер), а не конструктор.
Ключевые навыки конструктора: 1) способность охватить задачу целиком (т.е. включая детали) 2) способность формализовать задачу и разбить ее на подзадачи таким образом, чтобы для понимания подзадачи не требовалось понимания задачи в целом.
DG>конструктор — устраняет противоречия и оптимизирует конструкцию изделия. рабочих еще может никаких не быть.
DG>управленец — устраняет противоречия и оптимизирует деятельность группы людей (и не надо управленца мешать с конструктором в единое целое)
Чистый управленец не способен ни охватить задачу целиком, ни формализовать ее и разбить на подзадачи. Его работа заключается в том, чтобы подобрать людей, которые смогут это сделать. К примеру, толковый управленец товарищ Сталин для разработки пушки привлекает толкового конструктора товарища Грабина, т.к. сам товарищ Сталин при всех своих способностях управленца не может ни охватить задачу разработки пушки целиком, ни разбить ее на подзадачи.
DG>тот же берт монро — конструктор, хотя никаких рабочих у него не было.
Берт Монро это ремесленник. Все до последнего винтика он изготавливал понимая задачу целиком, т.е. он не занимался вопросами формализации и разбиения задачи на подзадачи.
DG>есть такой человек — как прораб, он ставит задачи другим, но при этом он инженером не является.
Прораб не обладает ни способностью охватить задачу целиком, ни способностью формализовать задачу и разбить ее на подзадачи. Координировать деятельность рабочих прораб может только за счет того, что разбиение на подзадачи за него уже произвели конструкторы и технологи.
DG>сантехник не устраняет никаких противоречий, и не проводит никакой оптимизации, он берет имеющуюся деталь, и прикручивает ее туда куда написано.
Про большинство программистов можно сказать тоже самое. Само по себе умение писать код человека инженером не делает.
DG>торвальдс, брин/пейдж, цукерберг и т.д. — даже в начале своей карьеры точно были конструкторами, а не рабочими, хотя и работали в одиночку без всякого вертикального разделения труда.
Если человек способен формализовать задачу и разбивать ее на подзадачи таким образом, что для их понимания не требуется понимания задачи в целом, то да у него есть задатки конструктора, даже если он работает в одиночку. Но убедиться в том, что человек действительно обладает способностями конструктора можно только тогда, когда решать задачу начинает несколько человек. Т.е. если человек в одиночку успешно решает сложные задачи, то из этого безусловно следует, что он ремесленник высокой квалификации, но вовсе не факт, что этот человек способен быть конструктором.
U>> И тогда же возникает потребность в человеке, который будет думать как какую-то операцию можно сделать в принципе и как ее можно упростить, чтобы ее мог выполнять рабочий с меньшей квалификацией и/или с меньшими трудозатратами, и который будет заниматься формализацией действий рабочих, чтобы сделать возможным передачу опыта другим рабочим, т.е. возникает потребность в технологе.
DG>технолог — устраняет противоречия и оптммизирует удешевление производства изделия. рабочих опять же может не быть.
DG>например Матти Хольцберг — технолог, но рабочих у него нет.
Хольцберг выполнял работу и конструктора, и технолога, и рабочего, т.е. являлся ремесленником.
DG>можно взять и обратный пример — медицину. там врачи почти все поголовно инженеры при минимальном вертикальном разделении труда.
С чего ты взял, что врачи инженеры? Из-за того, что у них диплом есть? А филолог с дипломом тоже инженер что ли?
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, Ларик, Вы писали:
Л>>Подумал поработать, что не вакансия так минимум похоже я буду один операционную систему писать, судя по количеству необходимых знаний, ну я например много технологий знаю, причем не по книжкам, а реально сталкивался, разбирался, писал. Например работал с MSXML, но задай мне вопрос с которым я не сталкивался, я ноль, хотя за пару минут найду и примеры и пойму алгоритм решения. Т.е. если перечислить то что я "знаю" большой список получится, но если начать меня по нему тестировать завалить меня нечего делать. Л>>Собственно вот и возникает вопрос, а просто кодеры сейчас не нужны что-ли? Который может и не гуру в 20 темах, но решать вопросы нехватки знаний умеет. Или студенты эту нишу забивают? MM>На сабжевый вопрос захотелось ответить, что программеры в этом сами и виноваты, превратив понятие простого кодинга в нечто унизительное и оскорбительное, словно этим какие-то недочеловеки занимаются. Далеко ходить не надо. На этом форуме то и дело проскакивают соответствующие фразенки в стиле "я же не кодер" или "да эту херню может просто кодер написать". Вот и фирмах теперь также: "нам простой кодер не нужен". Ну, а раз не нужен, то на тебе списочег на 500 наименований. Думаете HR-ы определяют запросы вакансии? Да всё те же программеры и определяют, HR просто передает.
Программисты тут ни при чем, это наследие страшных времен, когда стандартным устройством компании были дизайнеры/архитекторы, которые дизайнили структуру программы и рисовали спецификации разной степени подробности, и кодеры, которые по этим спецификациям все делали, не отступая ни на шаг. Работа последних, по большому счету, требует исключительно низких знаний, ибо спецификации были типа "класс с именем А, поля с типами Б и В и именами Г и Д....", которые может написать любой освоивший синтаксис языка и умеющий бороться с ошибками компиляции. После чего написанный код проходит через несколько стадий ревью и тестирования, так что совсем уж даунский код отсекается. Соответственно, можно набрать почти что бесплатных "индусов"-(быдло)кодеров и сэкономить на зарплатах. Если не ошибаюсь, в Микрософте как раз такой подход рулил, не знаю, как сейчас.
говоря все это: ты явно или неявно выстраиваешь модель. но ты можешь ответить почему выстраиваемая тобой модель хорошая?
модели сравниваются по предсказательной силе — чем больше можно предсказать по модели, тем она лучше.
я не виже в твоей модели предсказательной силы. и соответственно не могу назвать твою модель хорошей.
есть определенный участок работы. туда надо посадить человека. как по твоей модели определить какого человека туда посадить?
при чем уже есть готовое наблюдение — посадишь одного человека, он не тянет; посадишь другого — а он выше на голову, чем проблемы на участке.
Здравствуйте, мыщъх, Вы писали:
М>если вы говорите, что вы это не умеете, то это это минус, но небольшой; М>если вы говорите, что вы это умеете, но валитесь на первом же вопросе -- это два минуса, образующих крест; М>если вы говорите, что вы это умеете, но вас через полчаса все равно валят -- это два минуса, оборазующих плюс (нащупали границы ваших познаний); М>если вы говорите, что вы это умеете и завалить вас не удается -- вы вылетаете по исключению, обрабатываемому (или необрабатываемому) вышестоящим манажментом;
Если собеседующий пытается меня "валить", то это те самые два минуса, образующие крест. На конторе.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
aik>>Я лет 10 назад собеседовал чувака одного — нужен был человек, знакомый с ядром линукса. Пришел товарищ и наплел что он в ядре какой то драйвер пишет-поддерживает (ntfs или что то похожее). После я написал парням, которые в драйвере упомянуты — они говорят "ну да, приходил такой то полгода назад, предлагал помощь, дали работу — а он и пропал напрочь". Такие сказочники попадаются
P>Ну так может это они думают, что пропал, а он на самом деле пишет-поддерживает. Только никому не показывает.
На работе он тоже так делать будет? Что-то там писать, но не выкладывать?
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>Здравствуйте, мыщъх, Вы писали:
E__>Если собеседующий пытается меня "валить", то это те самые два минуса, образующие крест. На конторе.
каждый волен сам выбирать с кем ему работать, особенно когда есть выбор. мне как-то все равно пытаются меня валить или нет. сейчас вот начальство точно меня завалить решило, а подчиненные дружно устроили саботаж. ну да испортили настроение... зато есть возможность научиться разруливать такие ситуации...
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, samius, Вы писали:
S>Конечно, они решали разные задачи, но связка 3 в одном оказывалась более плодовита чем команда людей с разными специализациями. Случаев явно маловато для того чтобы говорить о каких-то правилах, но они имеют место.
Ровным счетом ни о чем не говорит — бардак с тем же успехом организовывается и в собственной голове "3 в 1". С тем же успехом на всех без исключения научных производствах (не знаю как назвать: производящих науку в общем — научными исследованиями занимающихся) можно выгонять лаборантов и техников и пускай "умы" занимаются рутиной всякой в т.ч. — ведь им легче "самим с собой договориться"?
TL>Глупости. "Квалификация подсобного кодера" — это излишки нашей системы образования, которая до сих пор клепает программистов на уровне университетов. А это — уровень техникума и полугодичных курсов.
Индусы пошли этим путем, результат не радует, во всяком случае нам (Россия, СНГ, Восточная Европа) не подходит.
Здравствуйте, The Lex, Вы писали:
TL>Насчет японцев не скажу, но у немцев я могу заказать машину, накликав в конфигураторе нужный мне комплект опций из немаленького такого списка вариантов. Да и по опыту часть задач в программировании действительно решается как "опытное производство", но в общем объеме производства она в целом не настолько велика на сегодняшний день и даже более того: программирования как такового остается все меньше, а все больше — "интеграции". Пусть даже в это слово включается и "создание дополнительных программных модулей в ходе кастомизации общего решения под конкретное приложение" — общего положения вещей это не отменяет: большая часть задач при этом — обыкновенный конвейер и серийное производство давно разработанных деталей и узлов и схем их сложения в готовую машину.
Здравствуйте, DarkGray, Вы писали:
DG>ремесленный подход — характеризируется наивной формой накопления опыта. когда улучшения делаются случайно, передача опыта делается методом делай также. DG>паре сотен лет назад в пику этому появился производственный(научный) подход, когда накопление опыта (улучшения) — делаются целенаправленно: формируются критерии, выстраиваются модели, проводятся исследования и ставятся эксперименты.
Т.е. если человек тупой, то он ремесленник, если человек умный, то он инженер, а если особо умный, то ученый. Исключительно глубокая мысль.
U>>Ключевые навыки конструктора: 1) способность охватить задачу целиком (т.е. включая детали) 2) способность формализовать задачу и разбить ее на подзадачи таким образом, чтобы для понимания подзадачи не требовалось понимания задачи в целом.
DG>разбиение целого на части (она же декомпозиция) — это есть общая часто используемая задача. DG>ее делает и конструктор (разбивая изделие на части), и технолог (разбивая процесс изготовления на части), и сантехник (формируя образ что за чем крутить), и прораб(и сержант) — разбивая задачи по подчиненным DG>уж точно декомпозию делают дизайнеры, художники, ландшафтные дизайнеры, землеры и т.д. и т.п.
Ты мысль целиком можешь воспринимать? Где сантехник или художник формализует разбиение задачи на подзадачи, делая их доступными для понимания другими людьми? Где прораб понимает задачу целиком? Он что может объяснить, почему здесь балка в 10 см, а не в 15 см? Нет, не может, все что он может это следовать чертежу.
DG>декомпозиция автомобиля на узлы не меняется последние лет 20(если не последние лет 80), но несмотря на это — конструкционно задача все равно остается очень сложной, т. к. требуется устранить и оптимизировать кучу критериев.
Опять же ты воспринимаешь только полмысли. Разбиение задачи на подзадачи не отменяет необходимость увязывания подзадач как единого целого, а это само по себе очень сложная задача в случае автомобиля. Т.е. для конструктора типового автомобиля требования ко второму навыку (разбиение на подзадачи), благодаря имеющимся наработкам, может быть и не такие высокие, а требования к первому навыку (способность охватить задачу целиком) по прежнему очень высокие.
>> Чистый управленец не способен ни охватить задачу целиком, ни формализовать ее и разбить на подзадачи. Его работа заключается в том, чтобы подобрать людей, которые смогут это сделать.
DG>подбор людей автоматически подразумевает декомпозицию задачи (как минимум декомпозируются сферы ответственности, сферы полномочий, бюджет и т.д.): вот этот будет отвечать за пушки, этот за армию, этот за транспорт, а этот будет бумажки перебирать.
Управленец занимается обеспечением разработки продукта ресурсами: кадрами, материалами, финансами, а также оцениваем нужность и качество продукта с точки зрения заказчика. Собственно разработкой управленец не занимается, для этого у него нет достаточной квалификации, разработкой занимаются инженеры.
DG>это возможно лишь при целенаправленном производственном подходе, и это не возможно при ремесленном подходе. DG>если читать более полные статьи о нем: то там видно, что Монро даже ближе к ученому чем к инженеру — он активно проводил исследования, ставил эксперименты, целенаправленно искал как сделать так, чтобы мотоцикл двигался еще быстрее.
Т.е. Монро был не просто умный, а очень умный, значит, он даже не инженер, а цельный ученый. Глубина мысли поражает.
U>>Про большинство программистов можно сказать тоже самое. Само по себе умение писать код человека инженером не делает. DG>ты кстати сколько можешь назвать требований к хорошо сделанной форме?
В смысле? Это к чему вопрос?
DG>1. человек либо умеет делать сложную декомпозицию/либо не умеет DG>2. человек делает это либо осознанно, либо не осознанно. DG>3. человек либо умеет отслеживать как он думает, либо не умеет DG>4. человек либо умеет формулировать для других свои образы, либо не умеет.
DG>решение сложные задач требует декомпозиции задачи хотя бы в голове, хотя бы не осознанно.
Вот тот человек, который декомпозицию задачи умеет делать только в голове, это ремесленник. А тот кто способен сделать декомпозицию задачи понятной другим людям это инженер.
DG>самая банальная — это приставление наблюдателя-аналитика, с параллельным использованием техник вопрошания. DG>т.е. из одного человека получался только недоконструктор (по твоей терминологии), а тут глядишь из двух человек — получился уже целый конструктор. DG>вот это как раз пример задачи, которую решает управленец (как скомбинировать неидеальных людей в хорошую систему).
Такой недоконструктор может в лучшем случае выступать в роли эксперта, но никак не руководить разработкой.
Здравствуйте, FR, Вы писали:
TL>>... обыкновенный конвейер и серийное производство давно разработанных деталей и узлов и схем их сложения в готовую машину.
FR>Выделенное в программировании вообще невозможно, все серийное производство это нажатие F5 и команда "copy" FR>Вообще тут http://www.rsdn.ru/forum/philosophy/3808250.1.aspx
Здравствуйте, DarkGray, Вы писали:
DG>говоря все это: ты явно или неявно выстраиваешь модель. но ты можешь ответить почему выстраиваемая тобой модель хорошая? DG>модели сравниваются по предсказательной силе — чем больше можно предсказать по модели, тем она лучше.
DG>я не виже в твоей модели предсказательной силы. и соответственно не могу назвать твою модель хорошей.
были показаны 4 конкретных проблемы, которые являются следствием ремесленного подхода в программировании. Ты с чем там не согласен?
DG>есть определенный участок работы. туда надо посадить человека. как по твоей модели определить какого человека туда посадить? DG>при чем уже есть готовое наблюдение — посадишь одного человека, он не тянет; посадишь другого — а он выше на голову, чем проблемы на участке.
Часть ответа на этот вопрос есть в исходном сообщении.
Кстати, действительно "про меня" — только не с той стороны. Ты сам-то читал что там написано и где именно я противоречу этому, если вообще противоречу?
Здравствуйте, FR, Вы писали:
TL>>Не вопрос. Что именно в современном решении задач ИТ используется "несерийного"?
FR>Я не про решение задач IT я про производство софта, это в чистом виде ОКР, который если и требует "рабочих" то FR>высококвалифицированных.
Я ж не против. И вообще не надо программистов обижать: они ре "рабочие" и не "ремесленники" и даже не "инженера" — они "художники"!
Здравствуйте, The Lex, Вы писали:
TL>Здравствуйте, samius, Вы писали:
S>>Конечно, они решали разные задачи, но связка 3 в одном оказывалась более плодовита чем команда людей с разными специализациями. Случаев явно маловато для того чтобы говорить о каких-то правилах, но они имеют место.
TL> Ровным счетом ни о чем не говорит — бардак с тем же успехом организовывается и в собственной голове "3 в 1". С тем же успехом на всех без исключения научных производствах (не знаю как назвать: производящих науку в общем — научными исследованиями занимающихся) можно выгонять лаборантов и техников и пускай "умы" занимаются рутиной всякой в т.ч. — ведь им легче "самим с собой договориться"?
Я ведь ничего не предлагал, только привел факты. Более того, могу сказать что там, где я работал, таких 3в1 лишь единицы на несколько сотен узких спецов.
Кстати, для некоторых задач требуется не 3 типа специалистов, а 4! Есть так называемые расчетчики — люди, которые знают как задачу запустить, куда положить начальные данные, где взять результаты промежуточных вычислений, куда и как их подсунуть, и в конце концов откуда забрать результаты. Для некоторых задач существуют целые отделы расчетчиков (со своими начальниками, замами и т.п.), которые в несколько смен много лет "считают" задачу. И я не предлагаю оставить их без работы. Мне немного не нравится, куда идут налоги, но это не самый вопиющий случай
Здравствуйте, Niemand, Вы писали:
N>Еще интересный момент который заметил (много общаюсь со знакомыми на эту тему). Собеседования типа "встретились, попили пива, поговорили о жизни" практикуются как правило в стартапах.
Из стартапов выстреливает один из десяти
>А потом все скатывается в i++++i и зачем нужен виртуальный деструктор (кстати на этом вопросе закончилось мое самое короткое 3х-минутное собеседование в CDD).
А потом надо и деньги зарабатывать.
Материал из Википедии — свободной энциклопедии, -_*
про тебя похоже.
TL> Гапертон — тренер.
не, он занимался какими-то биржевыми роботами, там типо того что чудеса — его гуру летал и у него один раз получилось
но сейчас эту муть об'ли два норвежца http://profi-forex.org/news/entry1008056551.html и кажется это может любой д..
Здравствуйте, DarkGray, Вы писали:
DG>вот только опыт показывает, что хорошие изобретения были сделаны когда и конструкторское мышление, и технологическое мышление, и изготовление были сконцентрированы в одном человеке. DG>автомат калашникова, ил-2, форд-т и т.д. были сделаны людьми, которые совмещали в себя и конструктора, и технолога, и исполнителя.
Естественно лучше всего когда в человеке все эти навыки совмещены. Только вот проблема, что таких людей очень немного. Соответственно если на должность программиста-конструктора найти такого человека еще можно, то заполнить должности рядовых программистов такими людьми никогда не получится.
DG>специализация имеет серьезные минусы, возрастают затраты на коммуникацию.
У специализации есть свои плюсы, есть свои минусы. Кто с этим спорит-то? Но когда задачи превышают определенный порог сложности специализация это единственный способ их решить, соответственно хочешь — не хочешь, а применять специализаю надо, но естественно при этом надо помнить о том какие проблемы специализация несет.
DG>в идеальном мире (где люди могут развиваться бесконечно) — хотелось бы, чтобы каждый человек имел и конструкторское мышление, и технологическое, и менеджерское, и маркетинговое, и экономическое и т.д.
Естественно лучше быть здоровым и богатым, чем бедным и больным. Вот только мы живем не в идеальном, а в реальном мире, в которым этих самых бесконечно развитых людей как-то не наблюдается, поэтому приходится работать с тем, что есть. Соответственно в реальном мире нужна такая форма организации, которая позволит приносить пользу и программистам с не столь широкой и высокой квалификацией.
DG>проблема специализации видна на примере текущей науки:
Во многом проблема со специализацией возникла как раз потому, что инженерами стали называть всех кого ни попадя. Соответственно потерялся главный смысл профессии инженера — способность широкого взгляда на проблему, т.к. на это способны очень не многие, а инженером стали называть чуть ли не каждого второго, по факту прочтения человеком десятка умных книжек и наличия диплома. Как результат профессия выродилась.
DG>т.е. можно еще до начала проекта на основе оценки сложности проекта — оценить люди с какой квалификацией нужны для его выполнения. DG>также можно прикинуть что нужно делать если людей нужной квалификации не хватает.
Ценнейшее наблюдение. Капитан-очевидность отдыхает.
DG>форд посылал инженеров на производство, чтобы они понимали технологическую составляющую. DG>и этим он из конструкторов — делал конструкторов с навыками технологов. опять же интуитивно понимая, что специализация в чистом виде — это зло.
Сейчас и так всех начинающих программистов принимают на работу как рабочих. Или ты студентам разработку архитектуры доверяешь? И что это сильно мешает тем вчерашним студентам, которые имеют способности развивать навыки конструкторов и технологов? Я же нигде не говорил, что обучать инженеров-программистов и рабочих-программистов надо по разному. На работу всех принимаем на общих основаниях, далее те кто имеют способности продвигаются в конструкторы, технологи или высококвалифицированные рабочие, а те кто такими способностям не обладают остаются кодерами, благо рутинные задачи тоже кому-то надо решать. Где здесь можно увидеть то, что программист-рабочий не может стать программистом-инженером и уж тем более то, что "способности людей даны от рождения"?
Здравствуйте, DarkGray, Вы писали:
DG>а если люди глупые, сами решить задачу не могут и для этого нанимают других, которым ставят задачи — то они сразу становятся конструкторами.
Цитату, пожалуйста, в которой я утверждал, что конструктор это человек, который сам не может решить задачу.
Ты читать точно умеешь? Первый пункт навыков конструктора гласит: способность понимать задачу как единое целое (включая детали). Как можно понимать задачу и при этом быть не способным ее решить? Конструктор выделяется вовсе не потому, что он не может решать задачи за рабочих, а потому что тратить его время на решение тех задач, с которыми вполне могут справиться рабочие, это забивание гвоздя микроскопом.
Здравствуйте, DarkGray, Вы писали:
DG>1. если инженера ставить на рутинную работу — то он начинает тупеть, а не развиваться (т.к. бытие влияет на сознание)
Так при современной организации труда в программировании и приходится инженера ставить в том числе на рутинную работу. Т.к. рутинной работы много, а отработанной организации труда, которая позволила бы эту работу передавать менее квалифицированным работникам, для которых такая работа как раз достаточно сложная и способствующая их развитию, нет. Ты с чем споришь-то вообще?
DG>и исходя из этого — будущего инженера неэффективно ставить токарем, его необходимо ставить как минимум помощником инженера.
Кто такой токарь и кто такой помощник инженера в программировании?
Здравствуйте, 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 — это когда тебе вместо туалетной бумаги дают топор, рубанок и карту близлежащего леса
Здравствуйте, catBasilio, Вы писали:
N>>> А потом все скатывается в i++++i и зачем нужен виртуальный деструктор (кстати на этом вопросе закончилось мое самое короткое 3х-минутное собеседование в CDD). _>>Не ответил? B>А какой правильный ответ кстати?
Смеётесь?
Undefined behavior при удалении объекта через указатель на базовый класс, не имеющий виртуального деструктора.
Здравствуйте, Aviator, Вы писали:
A>Проблема в том что покупаешь кота в мешке. Как например проверить, что кандидат не зная веба сможет за два месяца войти в струю и начать приносить пользу?
Смотришь код кандидата. Если у кандидата стоит упор на то, чтоб все сложности заинкапсулировать в одном месте, и затем повторно использовать, можно со значительной долей вероятности полагать, что и в любой предметной области (веб это тоже предметная область) будет аналогично. А вот если у него навороты технологий размазаны по проекту, скорее всего ничего хорошего из человека не выйдет, даже если он технологией в совершенстве владеет. Вот, например, любимую всеми многопоточность возбмем, в качестве ЯП возьмем Java. Вменяемый разработчик не будет везде в бизнес логике всякие локи ставить и все такое. Там, где локи нужны, напишет аспектами, и потребуются в коде только аннотации, все же мегазнание технологии будет заинкапсулировано в либах. И в случае ошибки, поправить надо будет либы, а не прыгать по всему коду. Ошибаются все. И если ошибется тот, кто стремится сложные вещи скрыть, то цена его ошибки будет на порядок меньше, чем у того, кто в совершенстве знает все тонкости, но размазывает эти тонкости по всему коду, и если и ошибется, то считай весь проект переписывать придется. Но на собеседованиях код смотреть не принято, и вообще не принято проверять способность кандидата писать код, отсюда и все проблемы с проверкой.
Здравствуйте, artem_korneev, Вы писали:
_>Здравствуйте, catBasilio, Вы писали:
N>>>> А потом все скатывается в i++++i и зачем нужен виртуальный деструктор (кстати на этом вопросе закончилось мое самое короткое 3х-минутное собеседование в CDD). _>>>Не ответил? B>>А какой правильный ответ кстати?
_>Смеётесь? _>Undefined behavior при удалении объекта через указатель на базовый класс, не имеющий виртуального деструктора.
я про i++++i; а то ни разу на приходилось пользоваться на практике, поэтому реально не знаю что будет.
UNIX way — это когда тебе вместо туалетной бумаги дают топор, рубанок и карту близлежащего леса
Здравствуйте, catBasilio, Вы писали:
B>>>А какой правильный ответ кстати? _>>Смеётесь? _>>Undefined behavior при удалении объекта через указатель на базовый класс, не имеющий виртуального деструктора. B>я про i++++i;
В таком виде оно не соберётся. Я так понимаю, имелась в виду задача вида:
i = i++ + ++i;
B>а то ни разу на приходилось пользоваться на практике, поэтому реально не знаю что будет.
Это тоже Undefined behavior, потому как идёт двойное изменение переменной в одной точке следования.
Посмотрел на ваш профиль. Насколько я помню, задачка из этой серии есть в тестах для соискателей на С++ в компании, в которой вы работаете.
Гапертон — тренер.
и изначально провальная.
