Здравствуйте, Aviant, Вы писали:
A> мне кажется, что челоеку с опытом в 7-8 лет проще что-то обьяснить и о чем то с ним договориться, чем с опытом в 1-2 года.
моё мнение, что дело здесь совсем не в стаже работы, а в умении "договариваться" вообще...
Aviant wrote: > Человеку была поставлена задача: за 2 недели нужно сделать то-то и > то-то. Это ДОЛЖНО работать и на экране я хочу увидеть вот такую то > функциональность. Причем, если я увижу это через 2 недели, то мы будем > использовать его задумку. Если нет — нет. Через 2 недели мне показали > solution из 12 проектов, штук 50 классов и форму с одной кнопкой. > Рассказали, что за этим скрывается мега-механизм, надо его только > доработать. > > Как и было обещано, при таком результате от его предложения отказались в > пользу более простого решения. С человеком случилась истерика, и он > сказал, что "к проекту в целом у него пропал интерес" (цитирую). И он > уволился. Удерживать не стал. > > PS: штука в том, что "генальная" идея отнюдь не нова и не гениальна. Ей > уже лет 8 как и она всегда, всегда возникает при разработке системы с > определенной архитектурой. Юное дарование не обладает каким-то особым > "даром". Обычный неплохой программист, с отсутствием опыта и > уверенностью, что он "творит".
Лично я бы уволил тут же менеждера этого человека.
Не понимаю, как можно дать подчиненному задачу, зная заранее, что он
собирается повторить туже ошибку, что уже совершали 8 лет назад.
Не понимаю, как можно потратить 2 недели труда "неплохого программиста"
(ваши слова), только на то, чтобы он убедился в том, что ошибается и
после этого фактически уволить его.
По крайней мере так я понял ваш пост.
P.S.
Ну а фраза "Юное дарование не обладает каким-то особым "даром".Обычный
неплохой программист, с отсутствием опыта и уверенностью, что он
"творит"." ???????
Ни в коем случае не хочу обидеть, но может вы поспешили стать
руководителем. Люди, однако, не винтики и не муравьи, они — личности, со
всеми вытекающими отсюда плюсами и минусами.
Здравствуйте, kittown, Вы писали:
K>Итого три желания: денег, еще денег, и еще 100 желаний.
Тут вы бесспорно правы — желаний даже не сотни, а тысячи, но к
разработке программного обеспечения они имеют малое отношение, если имеют вообще
K>Вас, скорее всего, интересует гораздо больше чем просто три K>величины, вы просто спрятали большинство из них под одним K>словом "качество". Да и со стоимостью непросто — речь K>идет о стоимости производства, стоимости поддержки, или K>общей стоимости владения ? В последних случаях, на какой K>срок использования это все рассчитывается ? И т.д. и т.п.
Этот "треуголник величин" не мною придуман. Конечно же, его составляющие
образы "собирательные", скажем так. Но не совсем понимаю: вы хотите сказать, что
я за словами "качество" и "стоимость" спрятал рояль(читай Марью искусницу от программерского рода)?
Отнюдь, ничего я там не прятал
Суть моей мысли заключалась в том, что к исскуству это отношения не имеет.
K>Если речь только о соответствии спецификациям и низкой K>стоимости исходной разработки, то с высокой вероятностью K>будет классический сценарий с write-only кодом и наймом K>студентов для его якобы простой поддержки. Вы уверены, K>что вас именно это интересует ? А под описание подходит.
Михаил, мы кажется начали обсуждать совсем не то. Скоро скатимся до "великие троечники vs серые краснодипломники".
Я хочу выразить своё согласие с тем тезисом статьи, который говорит, что программирование не есть искусство,
но вид деятельности, высокоинтеллекуальной деятельности.
Математику, же никто искусством не называет. Хотя, согласитесь, здесь требуется куда более "изощрённое" мышление.
"Это я вас как математик математика спрашиваю:"Что такое математика? Один из законов Божьих, или сам Бог и есть?"" (с) K>Mikhail
Здравствуйте, Andrew.W Worobow, Вы писали:
С>>Применим, ещё как применим. Меня как заказчика программного обеспечения интересуют С>>всего три величины: качество, сроки и $стоимость$.
AWW>Заиметь приимущество продукта можно только предложив новую идею, усовершенствовав или возродив старую...
Это пять! Без тени иронии. Только вот генерация серьёзных идей это удел стратегического менеджмента,
но никак не программистов, если только не считать программистом каждого, кто хотя бы пишет "электронные письма".
AWW>Да! И что очень важно надо определиться терминологически — на мой взгляд есть кодирование, а есть програмирование... Если продукт небольшой, то это выполняет один человек, ну а если большой то програмирует только небольшая группа, а кодирует (выполняя задания первых) все остальные...
Действительно, разобраться в терминологии нам просто необходимо.
Программирование — в широком смысле — процесс подготовки и составления программы деятельности, выполнение которой должно привести к
определенным целям.
Программирование — процесс подготовки задач для их решения с помощью компьютера; итерационный процесс составления программ.
Искусство — специфический вид отражения и формирования действительности человеком в процессе художественного творчества в
соответствии с определенными эстетическими идеалами.
Даже широко рассматривая термин скусство, я никак не могу назвать программирование таковым.
Увы и ах.
На редкость правильно. В прочем, все это уже здесь не раз обсуждалось, и про "программирование как профессия для избранных" и про то, что индусы якобы дешевле.
Сгибатель wrote: > > Этот "треуголник величин" не мною придуман. Конечно же, его составляющие > образы "собирательные", скажем так. Но не совсем понимаю: вы хотите > сказать, что я за словами "качество" и "стоимость" спрятал рояль(читай > Марью искусницу от программерского рода)?
Я хочу сказать, что если выражаться более точно, то общая картина будет
вырисовываться несколько иная, чем если выражаться обобщенно и
упрощенно.
> Суть моей мысли заключалась в том, что к исскуству это отношения не имеет.
Где как. Существуют типы задач, где исскуству места нет. Но эта область
сильно ограничена. Кастомизация и другие откровенно типовые задачи.
Есть и другие случаи. Интересны проблемы чрезмерно обьемных проектов,
когда их описание просто необходимо упрощать за счет введения новых
терминов и понятий, иначе трудно оценить общую картину и избежать
многократного изобретения велосипедов. Задача придумать хорошую
шаблонную конструкцию уже находится на грани исскуства.
У нас проект не сильно большой, но из-за нежелания обобщать
повторяющиеся конструкции существует куча переизобретенных
велосипедов. Тех же библиотек работы с сокетами в отдельных
частях проекта своих нагородили. Изучать различия между
ними — атас. То же самое про типичный клиенский и серверный
код. Загнать все под один стандарт и в библотеку, треть
кода стала бы проще и понятней. Однако, разработка ведется
по четко организованному процессу, и ничего такого в нем
не подразумевается. "Исскуство" исключили, получили издержки.
> Я хочу выразить своё согласие с тем тезисом статьи, который говорит, что > программирование не есть искусство, но вид деятельности, > высокоинтеллекуальной деятельности.
> Математику, же никто искусством не называет. Хотя, согласитесь, здесь > требуется куда более "изощрённое" мышление.
Когда из-за неумеренной обьемности вычислений придется
вводить новые теоремы, сразу выходим на грань технологии и
исскуства. Ситуация аналогичная приведенной выше.
Но это другая тема. Предыдущее письмо было о том, что сокращение
обсуждения до "сроки, деньги, качество" сводит дискуссию к
банальностям и иногда бессмыслицам, а все интересное остается
среди опущенных деталей. В зависимости от них те же "художники"
и "скоростные кодеры" могут быть полезны, бесполезны или вредны,
а ввиду недостатка информации непонятно о чем вообще дисскуссия.
В примере про описания дизайна упрощение — благо. А тут — зло.
Очень часто звучащий аргумент о том, что дескать у индусов "родной английский" — это очень сомнительный аргумент. Родной язык у них все же другой. Среднестатистическому индусу английский язык нужен не чаще чем среднестатистическому жителю России. И многие индусы (в том числе и программисты) по английски вообще не говорят, или говорят так, что их никто не понимает, в том числе и те, для кого английский — родной.
И уж особенно смешно видеть преимущество индусов "в вопросах ориентации на потребителя" — с чего бы это? Индусы в своей стандартной жизни не вращаются в англоязычной среде, и сокровенных знаний об анлоязычных потребителях имеют не больше россиян.
V>Лично я бы уволил тут же менеждера этого человека. V>Не понимаю, как можно дать подчиненному задачу, зная заранее, что он V>собирается повторить туже ошибку, что уже совершали 8 лет назад. V>Не понимаю, как можно потратить 2 недели труда "неплохого программиста" V>(ваши слова), только на то, чтобы он убедился в том, что ошибается и V>после этого фактически уволить его.
V>По крайней мере так я понял ваш пост.
Ребенок хочет прыгнуть с балкона, чтобы полететь.
Ему можно запретить. Тогда он обидится и будет ходить обиженный и когда-нибудь таки попробует.
Можно обьяснить, что папа прыгнул 30 лет назад и показать вмятину на асфальте и голове у папы. Ребенок может и согласится, но в душе будет уверен, что папа просто не умел прыгать и когда-нибудь таки попробует.
А можно дать прыгнуть со шкафа на матрас. Тогда он ударится, заплачет и убежит в другую комнату. Но прыгать уже не будет.
Никто никого не собирался увольнять, если вы не поняли.
Речь шла о том, чем опасны программисты, работающие "потому что интересно".
PS: с ним надо было бы после всего сесть, разобрать ситуацию и показать почему его идея была изначально гиблой. Вооруженный некоторым опытом, он бы наверное понял. Но он предпочел уволиться.
Здравствуйте, Сгибатель, Вы писали:
С>>>Применим, ещё как применим. Меня как заказчика программного обеспечения интересуют С>>>всего три величины: качество, сроки и $стоимость$.
AWW>>Заиметь приимущество продукта можно только предложив новую идею, усовершенствовав или возродив старую... С>Это пять! Без тени иронии. Только вот генерация серьёзных идей это удел стратегического менеджмента, С>но никак не программистов, если только не считать программистом каждого, кто хотя бы пишет "электронные письма".
Вам нравится слово менеджер? Тогда на здоровье, будьте менеждером... А мне нравится программист, потому как мы всё равно именно этим и занимается даже будучи на руководящей должности... Только програмируем мы без кодирования, опосредованно так сказать...
С>Искусство — специфический вид отражения и формирования действительности человеком в процессе художественного творчества в С> соответствии с определенными эстетическими идеалами.
Не удачное определение, скажем так совсем не удачное, типа из энцеклопидического словаря... чтоб всем и каждому...
Искуство это от слова искустно... То есть виртуозно, профессионально, лучше многих и т.д. ... А так получается смешно, согласитесь — "Искуство управления предприятием" ... или "Искуство дипломатии" Какое уж тут художественное творчество Или ещё смешнее — "Искуство рукопашного боя"
С>Даже широко рассматривая термин скусство, я никак не могу назвать программирование таковым.
А я могу, потому как это талант, и если вы не видели понастоящему талантлевых програмистов, то вам очень не повезло... Если бы это был не талант, то небыло бы такого кадрового дифицита, причем что характерно — во всём мире...
И тут уж как ни крути но если от бога нет, то и не научишь...
В результате, выпускники наших вузов до сих пор считают разработку ПО разновидностью искусства а не производственным процессом (о последнем они зачастую не имеют ни малейшего понятия). Отсюда проблемы с клиентами, поскольку зачастую требования клиента противоречат понятиям российского программиста об искусстве (никто не сравнится с нашими соотечественниками в постоянном желании переписать все к чертовой матери с нуля, какой бы сложности не был первоначальный продукт).
При правильной постановке процесса в компании, впрочем, эту национальную черту удается успешно нивелировать и со временем это проходит
А зачем нивелировать? Чтобы составить конкуренцию индусам? Но "как у них" не получится. Равняясь на кого-то постоянно остаёшься на шаг позади. Может лучше наоборот, стараться найти нишу, которая соответствует национальному характеру? Конечно, это не снимает проблем грамотного менеджмента, организации технологического процесса. И проблема, скорее, как раз в отсутствии в нашем национальном характере склонности к менеджменту, а не в избытке творческого потенциала.
A>PS: с ним надо было бы после всего сесть, разобрать ситуацию и показать почему его идея была изначально гиблой. Вооруженный некоторым опытом, он бы наверное понял. Но он предпочел уволиться.
Знаем мы таких "слушающих руководителей", были такие. Иногда проще уволиться чем пытаться объяснять что-то человеку, который не намерен даже пытаться понять то, о чем ты говоришь.
...Ei incumbit probatio, qui dicit, non qui negat...
Здравствуйте, kittown, Вы писали:
K>Где как. Существуют типы задач, где исскуству места нет. Но эта область K>сильно ограничена. Кастомизация и другие откровенно типовые задачи.
K>Есть и другие случаи. Интересны проблемы чрезмерно обьемных проектов, K>когда их описание просто необходимо упрощать за счет введения новых K>терминов и понятий, иначе трудно оценить общую картину и избежать K>многократного изобретения велосипедов. Задача придумать хорошую K>шаблонную конструкцию уже находится на грани исскуства.
Для вас это на грани искусства, для меня же это проявление выской степени
профессионализма и хорошей интуиции.
K>У нас проект не сильно большой, но из-за нежелания обобщать K>повторяющиеся конструкции существует куча переизобретенных K>велосипедов. Тех же библиотек работы с сокетами в отдельных K>частях проекта своих нагородили. Изучать различия между K>ними — атас. То же самое про типичный клиенский и серверный K>код. Загнать все под один стандарт и в библотеку, треть K>кода стала бы проще и понятней. Однако, разработка ведется K>по четко организованному процессу, и ничего такого в нем K>не подразумевается. "Исскуство" исключили, получили издержки.
Наличие нескольких библиотек, с одинаковой функциональностью, в рамках одного прокета
это грубая ошибка. На мой взгляд не стоит утрировать, мол такое произошло из-за
ислючения "Искусства". Думаю причины совсем другие...
K>Когда из-за неумеренной обьемности вычислений придется K>вводить новые теоремы, сразу выходим на грань технологии и K>исскуства. Ситуация аналогичная приведенной выше.
Грань? Возможно вы и правы, но те ли это грани о которых вы говорите.
Есть у меня глубокие сомнения, что будь-то теорема Ферма или Standard Template Library
имеют какую-то художественную ценность. Может я конечно и ошибаюсь.
K>Но это другая тема. Предыдущее письмо было о том, что сокращение K>обсуждения до "сроки, деньги, качество" сводит дискуссию к K>банальностям и иногда бессмыслицам, а все интересное остается K>среди опущенных деталей.
Соглашусь, факт банальный, но таки имеющий место быть.
Но и сводить всё обсуждение к наличию "велосипедов" к некотором проекте
так же неконструктивно.
Резюмирую, скажу следующее. С вашим взглядом на этот вопрос согласен только отчасти
(что и в программировании есть место для творческого подхода), но никак не готов назвать это искусством. K>Mikhail
Здравствуйте, Melo, Вы писали:
M>И многие индусы (в том числе и программисты) по английски вообще не говорят, или говорят так, что их никто не понимает, в том числе и те, для кого английский — родной.
100% верно, лапочут что-то даже не запариваясь хоть чуть-чуть с произношением поработать... И иногда смешно смотреть на носителей языка, которые примерно минут через пять начинают сообразать, что с ними оказавается по ангийски разговаривали...
E>>Писавший знал о чём пишет. J>Ну давайте научит 40 000 английскому догонит тогда рассияния по обьема аутсорсинга индию или нет?
нет конечно, тут ты прав да и опыта менеджмента проектами с большим количеством народа я так понимаю у России нет.
E>>У нас никогда не учили и не учат промышленному программированию. J>А что мешало? Почему индусов учат, а наших нет?
в статье написано — в Индии в это дело вкладывались деньги (равно как и в строительство технопарков, которые у нас еще только начинают собираться строить).
J>так у меня готовый ответ и без демагогии и п.р: — да патамушта индусская отрась в 20 РАЗ крупнее!!! J>Следовательно согласно экономич. целесообразности, они получат как минимум в 20 РАЗ больше заказов! Что бы не понять этого, а бормотать глупости по поводу английского языка, автору надо быть имбициллом.
тут еще в дешевизне дело — деньги в штатах решают оооочень многое
...Ei incumbit probatio, qui dicit, non qui negat...
AWW>100% верно, лапочут что-то даже не запариваясь хоть чуть-чуть с произношением поработать... И иногда смешно смотреть на носителей языка, которые примерно минут через пять начинают сообразать, что с ними оказавается по ангийски разговаривали...
очень знакомая ситуация
...Ei incumbit probatio, qui dicit, non qui negat...
_>Знаем мы таких "слушающих руководителей", были такие. Иногда проще уволиться чем пытаться объяснять что-то человеку, который не намерен даже пытаться понять то, о чем ты говоришь.
По-хорошему, у руководителя должен быть некий авторитет, чтобы его слушали. Какие-то удачные проекты (предыдущие), значимый опыт, ценные знания и т.д. Тогда и сотрудники (хоть с 1-2 годами опыта) будут прислушиваться.
В России же, имхо, относительно часто ситуация, когда не совсем очевидно, почему этот самый менеджер (аналитик, архитектор, руководитель, начальник — где как назвать) должен предложить лучшее техническое решение. Невсегда очевидно, за какие такие свои предыдущие заслуги этот менеджер дает указания программисту, как и что делать.
Аргументация "я менеджер, слушай меня" — далеко не лучший способ договариваться. Вот если за плечами руководителя удачные проекты (значимые модули в каких-либо проектах), и подчиненный в курсе этого, то скорее всего, ему легче будет прислушаться. Ну и договориться, соответственно, тоже легче.
Здравствуйте, Andrew.W Worobow, Вы писали:
AWW>Вам нравится слово менеджер? Тогда на здоровье, будьте менеждером... А мне нравится программист, потому как мы всё равно именно этим и занимается даже будучи на руководящей должности... Только програмируем мы без кодирования, опосредованно так сказать...
Управленец и исполнитель суть разные "должности". А-то я крановщик, но таки и космонавт, опосредованно так сказать.
С>>Искусство — специфический вид отражения и формирования действительности человеком в процессе художественного творчества в С>> соответствии с определенными эстетическими идеалами.
AWW>Не удачное определение, скажем так совсем не удачное, типа из энцеклопидического словаря... чтоб всем и каждому...
Вы правильно указали, из словаря и взято. Так как именно они дают общепринятую формулировку.
AWW>Искуство это от слова искустно... То есть виртуозно, профессионально, лучше многих и т.д. ... А так получается смешно, согласитесь — "Искуство управления предприятием" ... или "Искуство дипломатии" Какое уж тут художественное творчество Или ещё смешнее — "Искуство рукопашного боя"
А какое художественное творчество вы увидили в программировании?
Программный код, как таковой, является предметом авторского права, но вот, чтобы он ещё имел художественную ценность
AWW>А я могу, потому как это талант, и если вы не видели понастоящему талантлевых програмистов, то вам очень не повезло... Если бы это был не талант, то небыло бы такого кадрового дифицита, причем что характерно — во всём мире...
А какое отношение талантливый программист имеет к искусству по роду своей деятельности?
Код подобный полотнам Дали ещё видеть не приходилось
AWW>И тут уж как ни крути но если от бога нет, то и не научишь...
Согласен, программирование требует не только хороших знаний, но и ещё "чего-то"...
Но не боги горшки обжигают
Возможно мы с вами немного по разному это самое программирование понимаем.
Но как бы то ни было, ... не верую, что искусство
Сгибатель wrote: > > K>Есть и другие случаи. Интересны проблемы чрезмерно обьемных проектов, > K>когда их описание просто необходимо упрощать за счет введения новых > K>терминов и понятий, иначе трудно оценить общую картину и избежать > K>многократного изобретения велосипедов. Задача придумать хорошую > K>шаблонную конструкцию уже находится на грани исскуства. > > Для вас это на грани искусства, для меня же это проявление выской степени > профессионализма и хорошей интуиции.
Я осторожен в подобных фразах и оборот "на грани" вписал не зря.
Причем, что любопытно, вы упомянули интуицию, а разговоры об интуиции
начинаются примерно там же. Это можно описать также как проявление
профессионализма, одной ногой уже вплотную приближенного к исскуству.
Игра слов, конечно, но главное — об отрыве от правил промышленного
программирования речи не шло, речь скорее о работе на грани сферы
их применимости.
> Наличие нескольких библиотек, с одинаковой функциональностью, в рамках > одного прокета это грубая ошибка. На мой взгляд не стоит утрировать, > мол такое произошло из-за ислючения "Искусства". Думаю причины совсем
другие...
Просто исторически сложилось. Старые библиотеки писались под
нужды старых фич и не были достаточно гибкими, чтобы использовать
в новых, а переводить старые фичи на новые библиотеки
нецелесообразно. Новой функциональности это не даст, код
уже отлажен, а тестирование затратно (очень ограниченный
доступ к целевому железу). В итоге нет никакого способа
веско обосновать необходимость изменений. Да и необходимости
строго говоря нет, затруднения в работе с текущим кодом
ниже геморроя по его переделке.
> Резюмирую, скажу следующее. С вашим взглядом на этот вопрос согласен > только отчасти (что и в программировании есть место для творческого > подхода), но никак не готов назвать это искусством.
То, с чем вы согласились отчасти, и есть моя точка зрения. Место
есть. Как и всему, в меру.
Здравствуйте, kittown, Вы писали:
>> Резюмирую, скажу следующее. С вашим взглядом на этот вопрос согласен >> только отчасти (что и в программировании есть место для творческого >> подхода), но никак не готов назвать это искусством.
K>То, с чем вы согласились отчасти, и есть моя точка зрения. Место K>есть. Как и всему, в меру.
