В таких статьях всегда игнорируется факт, который кажется мне очень простым и понятным. Почти никакие серьёзные вопросы не решаются путем только размышления и нагугливания недостающих данных. Да, возможно, в программировании это работает. Но я - инженер. Когда у меня есть проблема, то сперва я формулирую её (от "ничего не работает" к "кажется, есть проблема в разделении фаз в реакторе Р###"). Потом следует фаза, которую правильнее назвать методом проб и ошибок. Первоначальная постановка проблемы оказывается неверной в корне или просто недостаточно точной. Мы пробуем разные способы решения проблемы и, в конце концов, решаем ее. Мы же инженеры.
У ИИ нет ручек, чтобы пройти большинство фаз решения проблемы. При том, его рекомендации часто оказываются полезными по ходу дела. Так что пока у ИИ не появится физическое тело, способное двигаться в ограниченных пространствах, в постоянно меняющейся и, временами, агрессивной среде - он будет ассистентом. Это в лучшем для нас случае. Ну или мы будем ассистентами ИИ в худшем.
При этом в медицине, математике, программировании, бухгалтерском учете и подобных местах дело может обстоять и иначе.
Не думаю, что это обязательно. Условный молодой программист пришедший в фирму, занимающуюся асучиванием производств года через три уже хорошо себе предоставляет свою работу. Он может и не знать технологии нефтедобычи или газопереработки, но пара подобных проектов и нормальный наставник и опыт получен.
Отвечая на второй комментарий — зарплата 30-60 тыс. это ключевой параметр, конечно. Мои знакомые и в 1С и в АСУчивании зарабатывают заметно больше. Поэтому узкая специализация в программировании смущает их меньше. Пусть ты не фул-стак разработчик, но найти работу по аналогичному профилю будет не сложно.
Спора не получится. Программист, который сегодня программирует микроконтроллеры, завтра SCADA система, а послезавтра — бэкенд для веб-сайта — на мой личный взгляд, источник проблем отрасли. Специализация в развитой инженерии — неизбежна.
Выше я уже приводил пример весьма эффективных и при этом не самых высокооплачиваемых разработчиков — 1Сники. Разбираясь в предметной отрасли они, как правило, выдают результат. А кто не выдаёт — выходит из бизнеса.
При этом всё это я говорю как непрограммист, который по долгу работы много взаимодействует с разработчиками АСУТП/SCADA систем, которые второй хороший пример того, как даже большие проекты реализуются в предсказуемый срок и с допустимым превышением бюджета.
Профессионал понимает будущие проблемы, так как уже ходил подобными маршрутами.
Вообще, вы конкретно правы. Я говорил об инженерных задачах. Их отличие от научных задач в том, что когда она сформулирована — решение тривиально. Поэтому когда всё сформулировано — легче уже самому написать код, потому что всё же готово.
От программистов (как и от инженеров) ожидается, что они разбираются в предметной области, могут работать по сформулированной задаче, а детали уточнить по ходу дела.
И я даже знаю программистов которые так работают, причём относительно быстро и эффективно. Это 1Сники. Они разбираются в предметной области, складском и бухгалтерском учёте, эквайринге. Но в других областях с этим туго.
Так что как везде, если заказчик и клиент говорят на разных языках — задачи решаются трудно.
Каждый раз, когда про что-то говорят «всегда» — у меня появляется чувство, что меня обманывают.
Мы никогда не можем просто взять и сделать то, что просят. Всегда нужно строить штуку, которую будет легко менять.
Нет, нет и нет. В инженерии, например, есть множество совершенно типовых задач. Почти не нужен интерфейс, многих устроил бы интерфейс на текстовом терминале. Не нужно легко менять, нужен инструмент для типовой задачи. Но опытный инженер знает — закажи решение задачи программисту, и ты его дождёшься, когда оно станет бесполезным. Поэтому решаешь в MathCAD, собственным кривым кодом на питоне или даже в Excel. С одной стороны — решение достигнуто, задача решена. С другой стороны — из-за этого по рукам ходит множество кривых до невозможности программ и листов Excel. К кривые они потому, что написаны не программистами.
Только что прочитал про ремонт дома «по Scrum». Думаю, я плохо представлял себе методику Scrum. Если всё так, как описано в книге «Scrum» Джефф Сазерленд, то это так, как начинают работать при авралах на строительстве, когда срок окончания не за горами, а сделано мало. Не всегда так, конечно. Но это и понятно. Когда строится большой промышленный объект где-то в Приморском крае и в ходе очередного утреннего обсуждения стало ясно, что нужно купить ещё кабеля, фермы перекрытий нужно укреплять и что-то ещё, не важно что, легче от этого не станет никому. Срок поставки кабеля будет около двух месяцев или он станет золотым по цене, фермы изготавливают пол-года, да и другие проблемы решаются за недели.
Я подозреваю, что проблема была в том, что методологии управления инженерными и строительными проектами, когда нужно предусмотреть необходимые ресурсы за пол-года, год, но проект по своей сути не нов, а отличается от ранее реализованных какими-то деталями, масштабом или чем-то ещё стали применять в программировании. Где всё не так.
Я не из ИТ. Занимаюсь инженерными и строительными проектами. Но всё тоже, всё также. «Политика» очень быстро начинает съедать слишком много времени. Большие инженерные команды приводят к отвратительным интерфейсам между дисциплинами. А человеко-месяц опытного инженера не равен даже человеко-году стажёра. Работу опытного инженера не выполнет отдел новичков.
Жаль, что в инженерии и строительстве метод Scrum неприменим.
Интересная статья про родной город. Пара неточностей. Ганша — в центре, но с дороги не видна от слова совсем. ТЦ находится на второй линии за улицей Ленина. Впрочем, он в торговом центре города, поэтому проходимость действительно большая.
Немецких деревень нет. В поселениях добывающих компаний живут экспаты со всего мира. У нас действительно можно купить книги на английском и англоязычные игры.
В таких статьях всегда игнорируется факт, который кажется мне очень простым и понятным. Почти никакие серьёзные вопросы не решаются путем только размышления и нагугливания недостающих данных. Да, возможно, в программировании это работает. Но я - инженер. Когда у меня есть проблема, то сперва я формулирую её (от "ничего не работает" к "кажется, есть проблема в разделении фаз в реакторе Р###"). Потом следует фаза, которую правильнее назвать методом проб и ошибок. Первоначальная постановка проблемы оказывается неверной в корне или просто недостаточно точной. Мы пробуем разные способы решения проблемы и, в конце концов, решаем ее. Мы же инженеры.
У ИИ нет ручек, чтобы пройти большинство фаз решения проблемы. При том, его рекомендации часто оказываются полезными по ходу дела. Так что пока у ИИ не появится физическое тело, способное двигаться в ограниченных пространствах, в постоянно меняющейся и, временами, агрессивной среде - он будет ассистентом. Это в лучшем для нас случае. Ну или мы будем ассистентами ИИ в худшем.
При этом в медицине, математике, программировании, бухгалтерском учете и подобных местах дело может обстоять и иначе.
Отвечая на второй комментарий — зарплата 30-60 тыс. это ключевой параметр, конечно. Мои знакомые и в 1С и в АСУчивании зарабатывают заметно больше. Поэтому узкая специализация в программировании смущает их меньше. Пусть ты не фул-стак разработчик, но найти работу по аналогичному профилю будет не сложно.
Выше я уже приводил пример весьма эффективных и при этом не самых высокооплачиваемых разработчиков — 1Сники. Разбираясь в предметной отрасли они, как правило, выдают результат. А кто не выдаёт — выходит из бизнеса.
При этом всё это я говорю как непрограммист, который по долгу работы много взаимодействует с разработчиками АСУТП/SCADA систем, которые второй хороший пример того, как даже большие проекты реализуются в предсказуемый срок и с допустимым превышением бюджета.
Профессионал понимает будущие проблемы, так как уже ходил подобными маршрутами.
От программистов (как и от инженеров) ожидается, что они разбираются в предметной области, могут работать по сформулированной задаче, а детали уточнить по ходу дела.
И я даже знаю программистов которые так работают, причём относительно быстро и эффективно. Это 1Сники. Они разбираются в предметной области, складском и бухгалтерском учёте, эквайринге. Но в других областях с этим туго.
Так что как везде, если заказчик и клиент говорят на разных языках — задачи решаются трудно.
Нет, нет и нет. В инженерии, например, есть множество совершенно типовых задач. Почти не нужен интерфейс, многих устроил бы интерфейс на текстовом терминале. Не нужно легко менять, нужен инструмент для типовой задачи. Но опытный инженер знает — закажи решение задачи программисту, и ты его дождёшься, когда оно станет бесполезным. Поэтому решаешь в MathCAD, собственным кривым кодом на питоне или даже в Excel. С одной стороны — решение достигнуто, задача решена. С другой стороны — из-за этого по рукам ходит множество кривых до невозможности программ и листов Excel. К кривые они потому, что написаны не программистами.
Я подозреваю, что проблема была в том, что методологии управления инженерными и строительными проектами, когда нужно предусмотреть необходимые ресурсы за пол-года, год, но проект по своей сути не нов, а отличается от ранее реализованных какими-то деталями, масштабом или чем-то ещё стали применять в программировании. Где всё не так.
Жаль, что в инженерии и строительстве метод Scrum неприменим.
Немецких деревень нет. В поселениях добывающих компаний живут экспаты со всего мира. У нас действительно можно купить книги на английском и англоязычные игры.