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