Программирование как профессия в гонке на дно? [закрыто]

Мне кажется, что индустрия программирования находится в гонке на дно. Если мы возьмем практику:

1. Не тратить время на внедрение лучших практик
2. Максимально используя чужой код (пользовательский код как обязательство)
3. Использование языков более высокого уровня для повышения производительности
4. «Инструменты» разработки на основе графического интерфейса, которые значительно упрощают «программирование» и не требуют, чтобы люди понимали, как работает код.

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

Моя точка зрения здесь такова: а) есть ли несоответствие между навыками и экономическими интересами работодателя? и б) если есть, как вы смягчаете его, чтобы обеспечить соблюдение профессиональных стандартов?

Я думаю, что вы задали очень острый вопрос.

Создание инструментов кодирования GUI выводит программистов из работы так же, как роботы выводят работников сборочной линии из работы. По моему мнению, в то время как происходит потеря рабочих мест, также происходит сдвиг в том, где находятся следующие рабочие места.

Технология для выполнения задачи меняется, но задача все еще должна быть завершена: автомобили все еще должны быть изготовлены / собраны, прежде чем их можно будет водить; код / ​​бизнес-логика все еще должны быть собраны вместе, чтобы приложение работало.

Изменения в технологии представляют выбор для программистов: изучите программирование на основе графического интерфейса или инструменты графического интерфейса программы ... или ... что-то еще полностью.

Может быть несоответствие между навыками работников и интересами работодателя, но ненадолго, особенно если работодатель подкован. Поэтому в интересах как работодателя, так и работника преследовать то, что им выгодно. Но одно неизбежно будет впереди другого. Надеюсь, это вы (-:

С наилучшими пожеланиями,

KM

К трендам, о которых вы упомянули, я бы добавил еще одну, которая объясняет их ИМХО

Программистов гораздо больше (нужно), чем когда-либо.

Количество задач, которые требуют или включают программирование, постоянно увеличивается, и даже с большей скоростью, чем число программистов. В настоящее время в среднем автомобиле есть несколько микрочипов. Через 5 лет в вашем холодильнике и тостере может появиться чип. Через 10 лет ваше нижнее белье? ... И кто-то должен произвести все это программное обеспечение, чтобы заставить их работать. Поэтому прилагаются все возможные усилия для автоматизации всего, что может быть автоматизировано, и для повышения «производительности» (как бы она ни была определена). И все больше и больше свежих мозгов набирается.

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

Позвольте мне сыграть адвоката дьявола против ваших пунктов выше:

Не тратить время на внедрение лучших практик

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

Максимально используя чужой код (пользовательский код как обязательство)

В отличие от чего? Изобретая колесо? Или используя чужой код, чтобы избежать этого?

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

Использование языков более высокого уровня для повышения производительности

В отличие от кодирования всего в сборке? ;-)

«Инструменты» разработки на основе графического интерфейса, которые значительно упрощают «программирование» и не требуют, чтобы люди понимали, как работает код.

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

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

• общий объем кода и
• шансы посторонних когда-либо видеть такой код

было намного намного меньше.

Теперь, благодаря Интернету и Daily WTF, мы ежедневно сталкиваемся с худшими примерами. Это все равно, что смотреть все новости о терроризме и землетрясениях, разводить знаменитостей и плакать, насколько опасным и аморальным стал этот мир.

Вы правильно суммируете ситуацию, но совершенно неверно истолковываете смысл.

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

Позвольте мне сказать, что через 100 лет будет просто настроить такую ​​сложную систему, как Facebook или Google. Я не говорю об их веб-страницах, я имею в виду их центры обработки данных. Любой сможет это сделать. Он будет встроен в телефоны, при условии, что мы их еще используем. НО, все еще будут программисты, и хотя они могут не работать над такими «тривиальными» системами через 100 лет, они будут работать над системами, настолько более сложными и изощренными, что никто здесь не сможет даже понять их масштабы и масштаб. И эти системы, как и те, что сейчас, будут недоступны для среднего офисного работника, потому что некоторые люди, называемые программистами, предпочтут специализироваться на продвижении технологий той эпохи до крайностей.

Я читал такие вещи уже сорок лет, и я не был в начале предсказаний. Это еще не произошло.

COBOL был оригинальным инструментом разработки, предназначенным для устранения необходимости в бизнес-программистах, и был языком более высокого уровня, чем ассемблер. Библиотеки кода (чтобы не писать собственный код) имеют аналогичную древность.

Время от времени появляется что-то, что позволяет непрограммистам делать что-то более похожее на программирование. Это были «языки четвертого поколения» 1980-х годов, такие необычные электронные таблицы, как Excel, генераторы отчетов и тому подобное. То, что они сделали в случае успеха, это то, что они избавились от программирования и позволили программистам делать другие, более интересные вещи.

Эта модель не будет длиться вечно, но мне понадобится нечто большее, чем теоретические аргументы и предсказания, чтобы убедить меня, что программирование действительно идет в гору.

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

Программисты на ассемблере и фортране, вероятно, говорили то же самое, когда в дело входили структурированное программирование и широко распространенные интерпретаторы.

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

Для рендеринга фильмов Pixar требуется больше времени, чем когда-либо прежде. Несмотря на огромное увеличение скорости вычислений, наряду с этим, аниматоры требовали все возрастающей сложности и детализации в своих сценах. Анимация калибра Toy Story неприемлема в 2010 году, как это было в 1995 году. По мере того, как их инструменты развивались, их возможности и, соответственно, ожидания.

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

Хотя я согласен с большинством ответов, которые указывают на то, что предстоит еще много работы, я дам вам другой ответ:

Да, так и должно быть

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

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

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

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

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

Независимо от того, что вы можете автоматизировать или снять с полки, большинство упакованного программного обеспечения делятся на две категории:

1. Он прост в использовании, но не совсем соответствует потребностям бизнеса.
2. Это очень настраиваемый, но требуется специалист, чтобы понять и использовать настройки

Наверное, я забыл третий. Это стандартное программное обеспечение для повышения производительности (электронная почта, браузер, Word Pro и т. Д. Программное обеспечение в категории 1 приводит к тому, что компании нанимают разработчиков программного обеспечения для настройки готового программного обеспечения (если это возможно). Программное обеспечение категории 2, хорошо с тем же успехом они могут нанять разработчика, потому что человек, который знает, что настраиваемая система внутри и снаружи, либо пользуется большим спросом (например, SAP, PeopleSoft и т. д.), либо умирает (подумайте о любой системе, похожей на SAP и PeopleSoft, которая не совсем имеют одинаковое проникновение на рынок).

Всегда будет необходимость для разработчиков. Что я вижу, так это то, что большая часть того, что раньше было ручной, утомительной, повторяющейся работой, стала автоматизированной (например, написание кода для доступа к данным вручную, а не с использованием O / RM). Это позволяет разработчикам приносить больше пользы бизнесу с меньшими усилиями.

Я не принимаю ваши аргументы:

1. Не тратить время на внедрение лучших практик

Кроме этого.

1. Максимально используя чужой код (пользовательский код как обязательство)

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

1. Использование языков более высокого уровня для повышения производительности

Производительность неплохая сама по себе - не так ли?

1. «Инструменты» разработки на основе графического интерфейса, которые значительно упрощают «программирование» и не требуют, чтобы люди понимали, как работает код.

Если инструмент выполняет работу: используйте его. Если нет: откажись. Если обещание выполнено, и людям действительно не нужно понимать код - молодец! Вы, кажется, говорите, что это обещание не выполняется?

(Числа здесь автоматически пересчитываются неправильно. :))

Визуальное программирование не менее актуально или заслуживает презрения, чем текстовое программирование.

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

Если у вас есть возможность попробовать Labview, вы можете увидеть потенциал (или даже специализированный вариант в среде Lego NXT). Хотя не без недостатков или недостатков, есть наследственные преимущества. Видеть значит верить.

Практика программирования не только повышает производительность и снижает затраты на определенные типы разработки (ваша гонка на дно), но и увеличивает возможности приложений и ожидания клиентов (таким образом, поощряя гонку на вершину). Обратите внимание на бонусы, которые Goole и Facebook платят, чтобы получить лучших технологов.

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

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

Если мы возьмем практику:

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

Если мы возьмем практику: