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

[_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.

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

Напомню, ТЗ это четкое описание системы, а набор требований это ТУ, вот в ТУ пожалуйста пишите общими словами

Вы случаем не попутали ТУ и ТТ?

в ТЗ все алгоритмы, используемые в системе, должны быть описаны

Нет. Если все алгоритмы будут описаны, то нафига нужен программист?
Просто закодировать готовый алгоритм и обезьяна сможет. Мы нанимаем программистов для того, чтобы они алгоритм придумали.
Тем более что Вы сами же пишете:

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

А вообще потребность в хайлевел-профи часто отпадает всего лишь из-за более чёткой постановки задачи.

Я об этом и сказал выше: если алгоритм придуман и детально описан, то закодить его и обезьяна сможет. Ведь в этом-то и вся работа программиста - придумать алгоритм. А если алгоритм придуман, то как бы и программист не особо нужен

п.с. на счет электронщиков согласен, а вот насчет программистов тут вы сели в лужу, вы не указали протокол передачи для начала, вам как эти 2 байта переслать? по GSM? по CAN? по I2C? по SPI? программист гадать должен? и какой формат пересылаемых байт? сколько 8 бит? а может 9 или 7? четность есть? программист гадать должен? а вы ему кофейную гущу выдаете?

А посмотреть какая микросхема используется и полистать даташит никак?
А окружающую систему поизучать никак?
Ведущий обязательно должен всё разжевать и в рот положить программисту?
Тогда уж проще самому написать код как два байта передавать, чем долго и муторно все разжёвывать программисту, который в результате все равно сделает не то, что требовалось

И вообще. Общепринятой практикой считается, когда ТЗ пишет сам ИСПОЛНИТЕЛЬ.
Т.е. программист на основании наших хотелок пишет ТЗ для самого себя. А мы читая ТЗ только соглашаемся или не соглашаемся с тем, как ОН предлагает решить нашу задачу.

Если бы мы сами знали как решить задачу и имели все детальные алгоритмы её решения, то нафига нам платить бапки программисту? Тогда мы и сами всё сделаем

[Kibi]

А посмотреть какая микросхема используется и полистать даташит никак?
А окружающую систему поизучать никак?
Ведущий обязательно должен всё разжевать и в рот положить программисту?
Тогда уж проще самому написать код как два байта передавать, чем долго и муторно все разжёвывать программисту, который в результате все равно сделает не то, что требовалось

И вообще. Общепринятой практикой считается, когда ТЗ пишет сам ИСПОЛНИТЕЛЬ.
Т.е. программист на основании наших хотелок пишет ТЗ для самого себя. А мы читая ТЗ только соглашаемся или не соглашаемся с тем, как ОН предлагает решить нашу задачу.

Если бы мы сами знали как решить задачу и имели все детальные алгоритмы её решения, то нафига нам платить бапки программисту? Тогда мы и сами всё сделаем

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

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

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

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

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

"70 летние дяди(тети)" получают 25.
А сторонним программистам мы платим от 150.
И Вы при таких раскладах хотите, чтобы они (эти дяди/тёти) ещё и бОльшую часть работы программиста сделали?