TwitterНеужели программисты – ленивые капризные псевдоинтеллектуалы?
Заголовок статьи выбирал не я, а автор статьи, рекомендованной мне моим другом Алексеем Николаевым. Тем не менее, статья крайне полезна и поучительна. Disclaimer: перевод сделан в моей манере.
В программировании крайне мало художников; большинство из них – просто маляры.
Закон Тима Брайса.
Консультант по вопросам управления [MK: буду благодарен за более грамотный перевод словосочетания management consultant] Тим Брайс не любит программистов, и чувство это взаимно. Точка зрения Брайса на программистов состоит в том, что:
- программисты часто вводят окружающих в заблуждение и превозносят свою значимость
- IQ программиста ниже, чем у любого другого работника, закончившего вуз
- программисты неряшливы и ленятся думать
- они выглядят неорганизованными, чтобы было сложно судить, как они продвигаются в рабочем процессе и обнаружить дефекты в их работе
- типичный программист плачется, что он (она) перерабатывает, ему мало платят, и к тому же – не ценят
- к чести программистов, они обычно интересуются технологическими новшествами, но эти порывы менеджмент должен аккуратно гасить: избыток информации отвлекает программистов от основной работы.
Разумеется, отклики на данные [МК: довольно спорные] тезисы указывают на многократные ошибки Брайса. Но он тоже в чём-то прав. В конце концов, что-то привело человека с 30 годами опыта работы в этой области к подобным выводам? И не надо предполагать (по Фрейду), что какой-то неизвестный программист обидел Брайса, когда тот был маленьким (причина проста: в то время программистов было крайне мало, и мы их всех знаем).
Целевая аудитория Брайса – не программисты (чей IQ, вероятно, всё равно не позволит понять его теорию), а менеджеры IT и люди, принимающие бизнес-решения. Базовый принцип теории P состоит в том, что “чем более эффективно мы управляем людьми, программирующими компьютеры, тем более эффективно мы будем использовать информационные системы, чтобы удовлетворить информационные нужды бизнеса“. Эта теория не говорит о живых людях, а вместо этого концентрируется на прагматизме в бизнесе, и позволяет рассмотреть теорию с этой точки зрения.
- Программисты – не “Творцы Программ”, а просто переводчики. Согласен с этим термином, т.к. программисты действительно переводят. Правда, я не согласен с тем, что они переводят. Брайс пишет, что они переводят “спецификации, понятные людям, в инструкции, понятные машине”. На самом деле, программисты переводят абстрактные требования и идеи, которые зачастую сильно отличаются от хорошо написанных спецификаций. [МК: А вот у нас все продукты делаются по спецификациям, которые пишут люди с опытом больше, чем у программистов, которые их будут реализовывать] Порой разница колоссальна – как между Пикассо, переводящего человеческие чувства на холст, и маляром, красящим дом по приказу заказчика. Если обмен идеями между заказчиком и программистом страдает, страдать будет и “перевод”, и продукт, и в конце концов, программист будет виноват.
- Очень многие программисты – не системные аналитики. К сожалению, это часто именно так. Брайс пишет: “Настоящий Системный Инженер/Аналитик изучает бизнес-требования и преобразует их в спецификации, понятные программистам, чтобы они их реализовали. К сожалению, слишком мало людей занимаются этой работой, и, соотственно, задача ложится на программиста, который необязательно обладает необходимыми навыками для выполнения этой задачи“. [МК: поглажу себя по голове: у меня в отделе работает два системных аналитика, и скоро все (больше десяти) наших продукты будут правильно документированы]. Я знаю многих программистов, не умеющих или даже не желающих понимать бизнес-требования. Тем не менее, в отличие от Брайса, я верю в то, что программисты должны научиться разговаривать на языке бизнеса, напрямую общаться с клиентами и уметь понимать их потребности. Я верю в то, что работа программиста не ограничивается написанием инструкций для компьютера. Профессиональные программисты должны стать эффективными переводчиками сложных концепций, находящихся в мозгу заказчика, в код. В противном случае, неправильная интерпретация бизнес-концепций приведёт к продукту, решающему неправильные задачи; программисты окажутся плохими, а мистер Брайс опять окажется прав.
- Программисты склонны к модным, но непрактичным решениям. Брайс пишет: “Элегантное решение неправильной задачи ничего не решает. Программистам необходимо подтверждать технические рекомендации интересами бизнеса”. Так и есть, многих программистов больше интересуют технические и даже модные решения без анализа того, что нужно бизнесу. Случается ли это из-за того, что зачастую технология – это область, где программисты могут приложить свой интеллект и желание творить? Или это случается из-за того, что руководство не привлекает программистов для принятия решений, связанных с бизнесом и с пониманием потребностей клиентов? Или это случается из-за того, что программисты очень часто оторваны от насущных бизнес-потребностей и целей проектов? Избыточно реализованные [МК: как перевести over-engineered?] решения, сделанные с использованием модной технологии, но без практической необходимости, – плохи. Однако, если программисты работают напрямую с клиентами, понимают их потребности и переводят это в код – у них просто не будет времени и желания использовать модные технические решения, и они будут стремиться создать прагматичный продукт без лишних функций, ориентированный на потребности клиента.
Выводы Теории P. Брайс рассматривает программистов как стадо диких компьютерщиков, нуждающихся в сильной менеджерской руке. Менеджеры-надсмотрщики должны контролировать ленивую, псевдоинтеллектуальную и капризную натуру. Также проекты требуют армию бизнес-аналитиков, которые могут разжевать задачу для программистов (поскольку низкий IQ, очевидно, не даёт программистам сделать это самостоятельно). И, разумеется, все софтверные проекты нуждаются в людях типа Брайса, которые могут рассказать, как правильно относиться к программистам и как строить модели программистского поведения.
Есть и другой способ: уважать программистов и относиться к ним как к ответственным людям, позволять им работать напрямую с клиентами и давать им возможность принимать решения, связанные с проектом. Это требует довольно серьёзного изменения стереотипов в сознании менеджмента и самих программистов. Но это возможно!
Filed under: Бизнес
Подписаться по Email
Кажется, чувак нашел, кого можно обо…ть и срубить на этом денег.
Про программистов – так бывает с любой профессией (в самом общем смысле этого слова), это все-таки как никак достаточно “прибыльная” профессия.
over-engineered = заумные 🙂
Все правильно написано. Просто в нашей дикой реальности (не могу сказать про дальнее зарубежье) часто нарушают путем объединения функций иерархию:
Менеджмент
Инжениринг
Кодинг (уровень программиста)
если бы после развала Совдепа окончательно не похерили гордое звание ИНЖЕНЕРА, то и у нас были бы точно такие выводы.
Это я заявляю, как квалифицированный Инженер-Конструктор-Технолог, который успел поработать в разваливающемся Институте Кибернетики.
Эта статья хороша, особенно последний вывод. А вот оригинал – популизм чистой воды, конечно. Говорить о профессии, как о показателе чего-то, это бред, думаю, все с этим согласны.
Вот на примере моей конторы, я например сталкиваюсь с дикой некомпетентностью менеджмента. Причём с диким не желанием это осознавать и учиться на своих же ошибках. Можно как часто и делается, валить всё на девелоперов, но это опять таки глупо – при теперешнем рынке труда девелоперу найти работу – дело недели. Так что всему градусник – маркет. Он рассудит. Кому делать нормальные продукты, кому строить девелоперов в стройные ряды сертифицированных автоматов и потом закрывать проекты.
И ещё это странное человеческое желание “рулить”. И не важно, что его никто не уважает ни за знания, ни за этитйуд, ни за харизму. Почти каждый рвётся порулить. Потом и пишутся такие статьи.
Я всё же уверен, что его обидили и именно “по-фрейду”. Точнее на нашёл общий язык с программистами.
Вспоминается “старый французский анекдот”. Точнее владелец пэйпала, владельцы гугла, создатель амазона, создатель ебая, создатели ютуба, Стив Джобс и наконец САМ Билли Гейтс. Вот уж точно: ленивые капризные псевдоинтеллектуалы. Куда им до аффтара.
Ой как общо все. Под программистом в статье подразумевается какой-то странный персонаж – обычный кодер, но от которого почему-то ожидается взаимодействие с заказчиком, бизнес-анализ, а заодно, видимо, и написание спецификаций. А если это один человек, то, значит, обсуждается написание систем “на коленках”. А чего там обсуждать?
На сколько я встречался с реальной разработкой, кодеров за километр не допускают до мест где _принимаются решения_ – кодер действительно не должен думать, он должен писать код по требованиям, которые ему принесут готовые, написанные людьми с другим образованием и квалификацией. Так что кого облили в статье грязью, мне не понятно.
Сергей.
HoarFrost: не во всех компаниях такое практикуется, к сожалению. Особенно часто правильный процесс отсутствует в стартапах, даже успешных.
Максим: есть адекватный перевод over-engineered в данном контексте: “хитро-…мммм..-вздрюченные решения” :)))
с тезисами _почти_ согласен: производство программного продукта есть технологический процесс, такой же, как изготовление шестеренок или выращивание клюквы. 🙂
Очевидно, что господин Брайс просто не понимает технической стороны дела. Низкий IQ и ошибки в ДНК не позволяют. То, чего не понимаешь- боишься (не знаю, как там оно по Фрейду- мне лично пофиг). А если нужно рулить тем, чего боишься- значит, нужно прогнуть всё и вся под себя, рулить в меру своей убогости и рубить бабло. Сколько коммерчески успешных инновационных проектов реально с нуля поднял этот кретин? Думаю, ни одного…
management consultant ты перевел вполне адекватно: в России не было таких должностей, нет и “местного” названия. это как мерчендайзер 🙂
Max Kraynov: Полностью согласен, хотя именно в стартапах я насаждал бы (и буду, как только перестану лентяйничать) предельно жесткий процесс разработки.
Макс, большое спасибо за отличный перевод
Хорошая статья, провоцирующая 😉 Подпишусь на комменты, пожалуй.
Думается с течением времени у “человека – кодера” зашориваются мозги. И в обычных ситуациях, когда надо применить интуитивное решение, он ищет рацио. В этом то и есть ошибка.
А про тупость и низкий интеллект – перегиб.
У меня в компании не смотря на порядочный размер нет постановщика задачи. Как следстви производительность труда падает на порядки. Любая мысль зафиксированная в письменной форме уже формализированна, чего нельзя сказать о устной и других формах постановки задачи.
Кстати у нас например в порядке вещей изменение архитектуры решения в середине проекта. Поэтому строки выше о наличии требований которые просто достаточно перевести в код для меня звучат как буржуинская утопия )))
Dekus, у меня в группе процесс поставлен так, что почти все продукты делаются по спецификации. Общение с заказчиками-бизнесом упростилось на порядки.
dekus: а как же вы работаете? особенно порадовало “в порядке вещей изменение архитектуры решения в середине проекта”…
Макс понимаешь людей которые способны поставить такой процесс не так уж и много.
То что это путь упрощение и ускорения разработки это факт. Как бы сторонники XP не кричали про итеративность разработки, но если архитектура изначально не позволяет реализовать бизнес-требования заказчика, то разработка продукта с навешиванием разных хомутов и шаманских бубнов займет довольно много времени.
Вся беда в том что у нас (моя фирма) уверены, что программист может все и даже “завалить” свинью, а ведь по большому счету, системный аналитик(или лицо в его роли выступающее) должен иметь хотя бы базовые знания в области задачи для взаимопонимания с заказчиком.
Что имеем в итоге:
1. Требования выставляются заказчиком (кстати, с такой позиции автор изначальной статьи не так уж и не прав)
2. Для получения результата весь тот поток видения, который на вас низвергает заказчик нужно преобразовать в понятную кодерам форму.
3. Аналитик, владеющий навыками программирования и предметной области, осуществляет этот самый перевод
4. Вот здесь только на 4 шаге вступают кодеры, которые в идеале действительно должны всего лишь преобразовать требования и описания в устойчивый и надежный код.
В заключение. Я думаю, никто из присутствующих не будет отрицать, что от итеративной циклической разработки никуда не деться на данный момент. Но базовый фундамент системы закладывается до начала кодирования и при нормальных раскладах кодер к этому должен иметь отношения только на уровне озарений и свежих идей по улучшениям в рамках имеющейся концепции.
PS
В свое время еще до смены работы делал выкладки по применению методов информационного дизайна при разработке программных продуктов в области автоматизации. Там была идеалистическая картина, когда при постановке задачи мы используем не видение заказчика (во многом субъективное и ограниченное той или иной точкой зрения), а наблюдение за процессом как таковым, причем несколькими наблюдателями с последующим обобщением и анализом полученной информации. И вот тут всплыл один маленький нюанс, программисты представляют собой стадо (факт представляют) в тот момент, когда просто не понимают что от них хотят. Возможно, это и не учитывается, а Фрейд совсем не причем…
SGerr: А вот так и работаем. Я изначально должен закладываться что в том виде в каком я делаю, решение использоваться не будет. Поэтому закладываемся либо на максимальную гибкость и возможность изменения, либо на скорость прототипирования, а дальше угадал не угадал, пока не попадешь в то что хочет заказчик. Единственное что спасает относительная однотипность, благодаря чему весь базовый функционал уже давно вынесен в библиотеку, что позволяет собирать прототипы буквально в течении пары часов.
Dekus: согласен, что грамотных системных аналитиков немного: ещё одного аналитика я недавно искал себе 3 месяца. Но посмотри на реалии разработки: проекты всегда нужно сделать быстрее-быстрее, без планирования, и когда неоттестированный код сразу бросается в бой. Почему? Либо из-за политики (или давления бизнеса на разработку), либо по незнанию, либо из-за ограниченного бюджета. И поскольку в большинстве компаний разработка в частности и IT в целом – убыточные области, “плодить дармоедов” в виде QA, аналитиков и т.п. никто не хочет.
dekus: мама дорогая… 🙁
Максим: Это ты что описАл? “…проекты всегда нужно сделать быстрее-быстрее…” Ты имел ввиду “программы” (в смысле — софт)? Проекты нужно делать не быстрее и не медленнее, а _вовремя_. При этом тебе ли не понимать, что “проект” — штука комплексная, и успех проекта на 90% зависит от умения менеджера “свести в одну точку во времени” производство и маркетинг.
Макс:
>в частности и IT в целом – убыточные области, “плодить дармоедов” в >виде QA, аналитиков и т.п. никто не хочет
Вот в том то и беда. Как мне заявил слава богу мой предыдущий шеф. “Нам платят за то что мы код пишем, а не за бумагомарание”. Вот в итоге и получается, что я 2 дня сижу думаю что же мне нужно сделать и трачу на реализацию 30 минут.
“Плодить дармоедов” это вообще отдельная тема… Впринципе ситуация описанная Ашмановым в его “Пузыре”. Она ведь не только в одном всем нам известном поисковике была. Она сохраняется на рынке в целом. Возможно именно это и приводит в конце концов к убыточности. Отсутствие навыков управления в области ИТ проектов и замена их на странное “я здесь начальник”. В итоге выходит что большая часть менеджеров в индустрии такое же стадо, если еще не хуже и в любом случае во много раз опаснее.
SGerr, ты прав только когда есть нормальное управление проектами, и когда есть менеджер проекта. Когда есть проект, и непонятно, когда его сдавать (пример: новый релиз внутреннего продукта), и возникает подобная проблема.
Максим: внутренний проект — это тоже проект. И у него также есть заказчик. Только внутренний. И работать с ним следует так же, как и с “внешним” проектом (не доходя, разумеется до маразма). В частности, в большинстве случаев маркетинг выступает с заказом “новой возможности”. И, все мы понимаем, – не просто так, “чтобы технари потренировались”. Они собираются эту возможность _продавать_. И, — ой, сюрприз! — им тоже нужно время на запуск, а также нужно планировать, скажем, рекламный бюджет, etc.
Вообще говоря, внутренний заказ предоставляет больше возможностей проделать работу качественно: предметная область знакома, люди под рукой, “жести” (вроде несовпадения графиков, взглядов, целей… да отпусков, в конце концов) меньше…
SGerr. мой опыт разительно отличается. Я прекрасно знаю, что внутренние проекты тоже имеют заказчиков. Проблема в том, что большинство внутренних проектов, с которыми приходилось встречаться, не имели никакого отношения к маркетингу, и маркетинг про них просто ничего не знал.
Но я видел и грамотные проекты, которые, правда, делались по всем правилам, потому что бюджеты на них были по 300-500к.
Максим: “…не имели никакого отношения к маркетингу, и маркетинг про них просто ничего не знал…” это смерть. Ты спрашиваешь у кандидатов, когда убивать “проект-уродец”. Так вот в данном случае я бы _настоял_ на аборте! 🙂
“…видел и грамотные проекты, которые, правда, делались по всем правилам, потому что бюджеты на них были по 300-500к.” Думаю, глупо спрашивать: “таки что же тебе больше нравится?” ;)))))
SGerr: в том и суть, что проекты-уродцы – это дитя кого-то из топ-менеджмента, поэтому убить ребёнка-урода практически нереально. Т.е. это сделать можно, но ценой серьёзной политики.
Насчёт грамотных проектов – тут дело сложнее. 300-500к – это среднего размера проекты, и за них случается максимальная конкуренция. Мне такие проекты не очень нравится, т.к. процесс выбора вендора на проектах от 100к до 1М – это кошмар: все мелкие компании занимаются ценовой конкуренцией, а для серьёзных компаний это слишком мелкие проекты, и они занимаются ими исключительно чтобы получить нового клиента.
Максим: “…дитя кого-то из топ-менеджмента”. Скорее — игрушка. Ты и сам знаешь, подобные выходки могут леГко угробить компанию. И, разумеется, виноват будет исполнитель. Посему с таких тем нужно соскакивать. Жестко, вплоть до смены компании.
Выбор подрядчика — тоже проект. 🙂 Есть вполне известный перечень действий, способствующих минимизации рисков. И грамотное ведение подрядчиком проектов в прошлом — немаловажная деталь. 😉
SGerr: кто бы спорил? Просто не всегда ты можешь спрыгнуть с корабля. Кто-то всё равно должен им рулить. Вот тогда-то и появляется стимул думать 🙂
Максим: эт точно :)))
Decus: основная идея моей статьи (для которой Max сделал отличный перевод) в том что профессиональный программист должен быть больше не кодером, а системным бизнес аналистом. Качество решений намного улучшится, так как оно в основном зависит от правильного восприятия и трансляции идей заказчика. У меня есть отдельная статья про поток идей: http://softwarecreation.org/2007/software-development-is-the-flow-of-ideas-the-rest-is-secondary/
И я убежден, что Agile / XP, самый эффективный процесс разработки для программных продуктов 🙂
Андрей, Agile/XP часто бывает процессом по умолчанию, особенно в компаниях, где разработка является чем-то второстепенным, а также в стартапах. Таких компаний, в принципе, большинство 🙂 Проблема с этим подходом состоит в том, что очень и очень редко первая версия продукта, построенная с использованием agile, выбрасывается и переписывается с нуля.
Андрей,
извини, я сразу не сообразил, что ты – автор изначальной статьи, которую я не удержался и стащил 🙂 Надеюсь, ты на меня не в обиде за это.
А давайте начнем еще спорить про преимущества подходов к разработке. Я вот участвовал в проекте, который начался как XP-based, потом был переписан с нуля в стиле Agile и все равно в результате был завален. Но это ж не значит, что оба подхода – отстой, даешь msf.
И все-таки программист должен программировать – писать код по спецификации. Если ему будет интересно,то со временем он приобретет нужную квалификацию и станет эти спецификации делать, перестав быть программистом. А мешать все функции в кучу в одном человеке – наколенство, имхо.
Сергей.
HoarFrost: абсолютно согласен с твоими тезисами 🙂 Я бы не хотел превращать этот блог, который в последние полгода превращается в мою площадку по информации, связанной с созданием и развитием малых бизнесов, в место для религиозных споров 🙂 Несмотря на то, что я профессиональный продуктовод и с методологиями знаком, мягко сказать, не понаслышке.
to Andriy Solovey:
Во первых я Dekus а не decus.
Во вторых это равносильно как учить ребенка плавать бросив его в воду. Для перехода из разряда кодеров в раздел архитекторов\аналитиков нужно не только время и богатый опыт, но и хорошее понимание методов проектирования. Я не могу расписаться за всех но на сегодняшний день программист может и должен им быть, а вот реально добыть знаний в этом направлении он может только собственным упорством, трудом и наглостью, потому как преподавать такие вещи (по крайней мере в тех вузах о которых я знаю) никто не хочет. Вы не поняли моей основной мысли аналитик\архитектор это специальность на стыке. По моим прикидкам оптимально вообще 2 образования или опыт работы на стыке областей. Это не продолжение программиста в развитии это следующая ветка эволюции. В то время как программист (обыкновеннус) должен просто писать код как верно подметил HoarFrost.
Все Макс мои извинения закругляюсь с религией. )) Уж больно живую тему подняли.
Макс, я не только не в обиде за перевод, но считаю это честью.
Dekus, извини за неправильное написание имени.
Я не хочу начинать здесь религиозные войны, поэтому коротко о наболевшем и все :).
1. Agile – метод только для хороших девелоперов – outsource и стадо кодеров не будет хорошо с ним работать.
2. Для Agile очень важен дисциплинированный подход с прямым вовлечением программистов в бизнес анализ и постоянным общением. Бизнес эксперты и аналисть должны помогать пониманию, а не решать.
3. Это правда – в Agile легко сбиться на разработку системы как большую кучу мусора. Только эволюционный дизайн как сложного организма, постоянный рефакторинг и автоматизированное тестирование всего того что движется и дышит может помочь.
4. Я против больших команд со средне и низко квалифицированными кодерами (я не про знания и новичков, а способности). Высоквалифицированными программисты тоже бывают разные – некоторые делают из мухи высокотехнологического слона, другие делают юзеров счастливыми даже со средней идеей. Мне больше нравятся последние, но они должны понимать бизнес
К стыду своему обнаружил что понятия не имею что означает Agile. )). Погуглил, просветился )). Чувствую себя пионэром удачно заглянувшим на огонек )).
Андрей. Еще пару вопросов если Макс не будет против ))
1. Вы пишете что гибкие методики разработки неприменимы в стаде кодеров. Вопрос в каком случае кодеры формируют стадо? Это ошибка менеджмента или недостаточная мотивированность? т.е. какие причины формирующие подобную ситуацию вы знаете?
2. Что вкладывается в понятие “понимать бизнес”? На сколько я понимаю в ряде случаев и ниш есть несколько звеньев отвечающих каждый за свое направление и охватить все их одному человеку крайне сложно…
3. Не могли бы вы привести требования к высококвалифицированному программисту как вы их видите?
Заранее спасибо за ответы.
to Крайнов: это ж нужно было создать такой разноплановый и полезный блог…
Dekus:
1. Рецепт для стада очень простой – программисты не понимают что поьзователю нужно и строго следуют спецификациям (которые являются частным случаем игры в испорченный телефон), менджемент не понимает сущности программирования и нанимает большое количество дешевых и думающих прямолинейно кодеров для механистической переработки требований – почти как для сборки картошки в колхозе – дело то не хитрое.
2. Одному человеку сложно, но воможно с помощью экспертов. 5 высокласных спецов программистов хорошо разбирающихся в бизнесе, говорящих с клиентом на их языке стоят бригады из 50 непонимающих бизнес задачи кодеров. Эта бригада навернет много кода, приймет много проектных и технологических решений, будет иметь много митингов где будут пытаться понять что творится, а чаще всего даже не будут. Просто будут что то програмировать. Какой будет результат? Вбивание текстов програм в компьютер не самая сложная задача.
3. Умный, дисциплинированый, творческий, неравнодушный, понимающий предметную область, способный видеть сущность проблем и проект в целом. Ну и конечно умеющий хорошо програмировать и учащийся на своих ошибках 🙂 Спецназ почти. Мне повезло – я с такими работаю.
[…] вы следите за комментариями к статье “Неужели программисты – ленивые капризные псевдоинтелл…?”, вы не могли не заметить, что там высказался Andriy […]
Andriy Solovey, по поводу дисциплинированный и творческий немного перегнули палку 😉 Коллизия получается.
Такой спецназ дорого стоит и тренируется годами. Как пример, 6 лет назад работал в маленькой телефонной компании единственным программистом. Технический директор не знал ничего про “Менеджмент Инжениринг Кодинг”. Зато он знал “как это должно быть”. Для того чтобы “это” дошло и до меня, он просто заставлял месяц работать вместо сотрудника (для которого писался АРМ). Скажу честно – софтом пользуются по сегодня (просто, быстро, удобно, а главное все правильно и ничего лишнего). К сожалению сегодня такие методики очень дороги и никто их не использует.
“Такой спецназ дорого стоит и тренируется годами.”
Без такого спецназа думается, и начинать не стоит, особенно там, где мера ответственности измеряется миллионами.
Не подумайте что я проповедую элитизм и какие-то особые способности. Любой человек с определенным складом ума – аналитическим и систематическим – может стать хорошим программистом. Не все могут, точно также как не все могут быть хорошими музыкантами, балеринами или учеными. Большинство русских программистов в Канде отличные специалисты. Я работал также с прекрасными программистами из Китая, Ливана, Гон Конга, Франции, Канады, Сербии и т.д.
Проблема в 3 вещах:
1. Менеджмент устанавливает такие условия (иногда просто из-за желания все контролировать), что программистам просто не дают работать с бизнесом и принимать решения. Они просто кодеры – винтики в большой машине.
2. Для многих программирование это просто возможность заработать хорошие деньги и кормить себя, семью и банки – и ребята принимают неоптимальные для конечного пользователя решения, чтобы подольше поработать на проекте или завязать на себе решения из-за того что другие плохо понимают из-за сложность (job security).
3. Некоторые не хотят смотреть вокруг себя, учиться, понимать бизнес и пробывать более эффективные подходы к тому как они работают. Они продолжают работать в привычном стиле многие годы и не адаптируются. Хорошие программисты учаться не только программировать.
И последнее, Toyota продала больше автомобилей чем General Motors в Америке в этом году благодарю именно такому подходу (высоко классные команды рабочих ответственные за весь процес), который они практикуют несколько десятков лет (Toyota Production System).
Я прочитал эту статью и меня охватил порыв гнева! Это просто кошмар! У меня нет слов! Я дико извиняюсь, но Брайс полный ПРИДУРОК! Я не предвтавляю где он мог увидеть таких программистов. У программистов самый высокий уровень интеллекта из всех людей населяющих нашу планету, они самые образованные люди, их речь развита и поставлена куда больше, чем речь выпускника филологического факультета, они чтают столько литературы за всю жизнь, сколько не читал не один “книжный пьяница”. Чего стоит прочитать унигу по C#, страниц в которой больше чем в библии. А ведь C# не единстенный язык и не единственная технология программирования и знанием его никто из нас (программистов) не ограничевается. Это у бизнесменов, экономистов и любых других специальностей курсы, читаемые в университете не переписывалиь годами, а у учащихся на IT- смежных дисциплинах они переписываются чуть ли ни каждый новый семестр! Объёмы материала не перечесть. Этот Брайс хоть раз видел учебный план по специальности “Прикладная математика и информатика” или по “Математическое обеспечение вычислительной техники” и т.д.? Я могу предположить, что у него голова кругом пойдёт от количества мтематических дисциплин и дисциплин IT-цикла, которые на этих специальностях изучаются. Скорее всего мы(программисты) на ходимся на более высокой ступени развития, чем обычные люди => я могу предположить, что у нас с простыми людьми именно по этому возникают “неясности”. Мы полностью логичны, логично мыслить можем только мы, а все остальные нет! Один математик сказал: “Логика – это один из способов быть не понятным другим”. Я могу продалжать эту “лекцию” и приводить доказательства еще очень долго, но ограничусь эти. Надеюсь мои мысли вам ясны.
[…] интересную и очень спорную статью, называющуюся “Неужели программисты – ленивые капризные псевдоинтелл…“. Как можно понять из заголовка, автор статьи явно […]
Почти все верно, за исключением слова «программист». Описанный в статье переводчик (или «пиривотчег») называется коротким и емким словом КОДЕР. А Программист (или даже ПРОГРАММИСТ) — штучная единица, и на дороге не валяется, либо входит в число Основателей, либо управляет КОДЕРами. Разница как раз в наличии/отсутствии творческого подхода. ПРОГРАММИСТ видит перед собой никак не формализированную задачу (например, OCR-распознавание) и думает, как ее можно решить с помощью имеющихся средств (из арсенала теории программирования, а не языка). КОДЕРу такое не по силам, ему нужно четкое ТЗ и языковые/алгоритмические требования. Все знаменитые алгоритмы придуманы, естественно, ПРОГРАММИСТами. КОДЕР тоже может стать ПРОГРАММИСТом — если чуть-чуть напряжет свой моск — но чаще не делает этого, чем делает. Никто никого не заставляет РАБотать на конвейере.
З.Ы. Если какой-нибудь КОДЕР сейчас начнет размахивать классификатором профессий, где он именуется гордым словом ПРОГРАММИСТ, то пускай махает — охладит себе моск от жары.