Программисты и электроники Опции

[_alex__]

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

[Plain]

Автор предложил обсудить кажущуюся ему угрозу перекоса продолжающегося удорожания программирования в сравнении с остающимися практически постоянными затратами на разработку аппаратуры.

[Николай Семёнови...]

Автор предложил обсудить кажущуюся ему угрозу перекоса продолжающегося удорожания программирования в сравнении с остающимися практически постоянными затратами на разработку аппаратуры.

А чего тут обсуждать?
Это факт: при разработке электронных девайсов и систем доля затрат на разработку софта растет.
Она уже сейчас во многих случаях превышает 80% себестоимости изделия

Только встаёт вопрос: кто должен писать этот софт?
"Чиста программисты", которые "ни ухом ни рылом" ни в железе ни в предметной области?
Или "чиста электронщики", которые "ни ухом ни рылом" во всех этих ООП, GUI, драйверах, багтрекерах, CVS и т.п.?

И у тех и у других получается откровенно ПЛОХО.

Нужны какие-то ГИБРИДНЫЕ спецы, В СОВЕРШЕНСТВЕ знающие и то и то.
Но таких очень мало. Голова-то одна - всё в неё не затолкаешь

Сообщение отредактировал Николай Семёнович - Sep 12 2017, 14:10

[Фрол Кузьмич]

Нужны какие-то ГИБРИДНЫЕ спецы, В СОВЕРШЕНСТВЕ знающие и то и то.

Ну опять же, если работа делается тяжело, значит она делается неправильно. А правильная работа не бывает без правильной постановки задачи. А для программиста правильная задача - это задача максимально формализованная. Что и должно быть в ТЗ программиста, а не всяка биллетристика. Последнее, к сожалению, типично.

Сообщение отредактировал Фрол Кузьмич - Sep 12 2017, 21:21

[Николай Семёнови...]

Ну опять же, если работа делается тяжело, значит она делается неправильно. А правильная работа не бывает без правильной постановки задачи. А для программиста правильная задача - это задача максимально формализованная. Что и должно быть в ТЗ программиста, а не всяка биллетристика. Последнее, к сожалению, типично.

Чтобы написать ТЗ на "птичьем языке", понятном программисту, пишущий сам должен быть программистом. Поэтому ТЗ пишется инженером на обще техническом инженерном языке.

В расчете на то, что программист как минимум владеет физикой и математикой в объёме средней школы, плюс прослушал курсы высшей математики и физики в институте.

Т.е. предполагается, что программист знает, что такое упомянутое выше"скользящее среднее", что такое интеграл и производная, основные законы механики и электричества и прочее.

А в реале оказывается, что большинство программистов не владеют физикой и математикой даже в объеме 9-го класса средней школы.

И вот тогда начинается нытьё "Это не мы плохие программисты, это Ваше ТЗ дурацкое, непонятное. Напишите его на понятном нам языке".

И на каком "понятном языке" его писать? На языке для идиотов?

P.S. Блин. Мне реально приходилось объяснять программистам как найти гипотенузу в прямоугольном треугольнике и почему для определения всех коэффициентов уравнения прямой на плоскости XY нужны две, а не одна точки

Сообщение отредактировал Николай Семёнович - Sep 13 2017, 04:19

[Фрол Кузьмич]

Чтобы написать ТЗ на "птичьем языке", понятном программисту, пишущий сам должен быть программистом.

Ну и нафига быть программистом, чтобы дать перечень сигналов и их описание, их раскладку по пинам/входам/выходам и формальные диаграммы алгоритма? И зачем для этого разбираться "во всех этих ООП, GUI, драйверах, багтрекерах, CVS и т.п."?

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

Я вот тоже не знаю, что такое это самое "скользящее среднее". Но оно видимо как-то вычисляется, йа угадаль? Может просто дать программисту формулу, по которой его нада сосчитать?

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

Похоже что-то или кто-то заставляет вас считать программистами тех, кто ими просто не является. Возможно под дулом пистолета. И проблема именно в этом, а не в программистах и ТЗ.
ЗЫ. Кстати, я не программист.

Сообщение отредактировал Фрол Кузьмич - Sep 13 2017, 05:21

[Kibi]

Ну и нафига быть программистом, чтобы дать перечень сигналов и их описание, их раскладку по пинам/входам/выходам и формальные диаграммы алгоритма? И зачем для этого разбираться "во всех этих ООП, GUI, драйверах, багтрекерах, CVS и т.п."?

Я вот тоже не знаю, что такое это самое "скользящее среднее". Но оно видимо как-то вычисляется, йа угадаль? Может просто дать программисту формулу, по которой его нада сосчитать?

Похоже что-то или кто-то заставляет вас считать программистами тех, кто ими просто не является. Возможно под дулом пистолета. И проблема именно в этом, а не в программистах и ТЗ.
ЗЫ. Кстати, я не программист.

Блин начал комментарий за здравие, продолжил за упокой)))

Программист должен знать основные математические алгоритмы, будь то "плавающее среднее"(хотя тут автору темы минус, должна быть расшифровка, это в статистике или это в плане фильтра, считать можно по разному, плюс не указана точность, {1,2,3,4,5,6,7} (1+2)/2,((1+2)/2)+3 и т.д. или (1+2+3)/3
этого судя по всему не указано) Напомню, ТЗ это четкое описание системы, а набор требований это ТУ, вот в ТУ пожалуйста пишите общими словами, а говоря уже о ТЗ, в ТЗ все алгоритмы, используемые в системе, должны быть описаны, именно поэтому ТЗ пишется как правило в процессе разработки, до начала разработки есть только ТУ. Есть Гост ЕСПД, там четко даны указания на состав документации, и поэтапно необходимые документы.
Но программист таки должен сам подбирать/разрабатывать алгоритмы на основе ТУ, а если заказчику вдруг захотелось поменять цвет шрифта на серобурмалиновый, то это уже должно быть согласовано в ТЗ уже во время разработки.
Скажу так, если мне заказчик например, будет приказывать обрабатывать нормальное распределение, без большой выборки, скажем не хи2 а использовать какой то свой алгоритм который он обозвал "супер хаха" и которого нет в инженерных справочниках под таким названием, то разумеется я нихрена незнающий программист и мне пора в школу, потому как именно в средних классах, для простоты понимания, так обзывают другой алгоритм)))
Я бы не стал говорить о том, что программистами считают тех кого нельзя считать программистом, просто разноплановость программирования сейчас уже очень велика, ну к примеру автослесарь врятли починит лифт или тепловоз, выходит он не механик? или все таки дебил тот кто автослесарю поручает чинить турбину реактора?

Все верно: к примеру, несколько лет назад (в 2012) я разработал плату, к которой можно подключать
некоторое множество периферии; сделал для нее прошивку. Но время идет, функционал
растет, а его в основном делаешь за счет софта. Редко модернизируется и плата - крайняя версия 3 от 2014.
Итого: месяц на хард, 5+ лет на софт, и софт постоянно дополняется хотелками.

Кто должен все это делать?
Либо один грамотный спец, если силенок и времени на все хватит.
Либо один грамотный спец нарезает задания узкоспециализированным спецам-помощникам,
с периодическими разжовываниями и вкладываниями в рот, для повышения их квалификации.
Я не понимаю как там Н.С. периодически рассказывает про Ома, по-моему дело не только
в ученике, но и преподавателе - мои все усваивают с первого раза, а закон Ома вообще
не помню, чтоб кому-то приходилось объяснять.

Тут скажу даже больше, на многих объектах стоят платы разработанные еще в 2001 году, прошивку основную я правил в последний раз где то в 2008-2009, а хотелки и корректировки под конкретику в 2014, плата же не менялась с 2001.

[Фрол Кузьмич]

Но программист таки должен сам подбирать/разрабатывать алгоритмы на основе ТУ

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

В первом на софт ушло две недели, с отладкой. Во втором - три месяца.

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