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

А какая цель у этой темы?

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

И этот пузырь когда-то лопнет и программирование из искусства превратится в рутину в процентном отношении 10 к 90 (рутины). Как это произошло у механиков, а потом и у электронщиков. Правда пока наблюдается бум искусства у твердотельных электронщиков, каковый наблюдался в 70-е - 80-е у аппаратурных электронщиков.

Среднестатистический погромист - это школьник, поверхностно освоивший пыхпых. И как он будет микроконтроллеры программировать? Я уж молчу о том, что развести плату можно лишь после того, как будет описано назначение всех ног МК, т.е. погромист еще и в электронике хоть поверхностно должен разбираться...

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

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

Ну так чтобы это понимать - тоже читать нужно. А это не укладывается в жизненную позицию "Monkey see. Monkey do".

Где подтверждающее это утверждение статистика?




:D посмеялся от души! аффтар пиши ещё!



и загивающий запад!

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

Т.е. "там" (вы же вроде в США?) ситуация таже самая?

А программисты не тыкали вас носом в неверно подключенную периферию или другие смехотехнические баги?

Конечно находились и мои ляпы. Но, например сейчас, я работаю с 3-мя программистами микроконтроллеров и 2-мя системными программистами одновременно над разными проектами. Так что они еле поспевают править. Кроме того, все понимают, что программное обеспечение можно дорабатывать даже после поставок пользователям, а аппаратура должна работать корректно к моменту поставок и желательно к моменту создания программного обеспечения. Мой секрет простой. Стараюсь разрабатывать электронику максимально податливую для модернизаций.
Но разговор не об этом. А о том, что программисты не хотят читать документацию. И относятся к документации так же, как и к коду, написанному другими. Исправить это невозможно.

Ребята, давайте жить дружно)))) Сейчас должно быть понятно, что практически ни одна железка сложнее кувалды не может обойтись без симбиоза программного обеспечения и электроники.

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

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

Дико плюсую. Именно так.
Приходится объяснять "глубокие теории". Уж такие "глубокие"...Как то "Закон Ома", что такое "ток" и что такое "напряжение", почему для определения всех коэффициентов уравнения прямой на плоскости XY нужны координаты двух точек, а не одной... И прочее такой же "глубины" на уровне школьной программы 9-го класса средней школы

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

п.с тут кто то писал про дергание кусков программы из инета, таки ведь электронщики ничем не отличаются, схема на 99% из кусков на компоненты из инета слита, и вот как раз электронщики крайне любят путать ноги, для них что TX, что RX все одно, неважно зачем этот вход, главное закон Ома он знает)))

Да таких большинство. Спросите, ради интереса, у программистов на своей работе, что такое медианный фильтр, что такое скользящее среднее, что такое метод Ньютона-Рафсона и, как вишинка на торте, что такое z^(-1).

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

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

Это мелочь. Смотрите на лес, а не на деревья.

Буквально сейчас я инсталлирую Win 10.
B что я вижу. Они там в лицензии заставляют меня отказаться от всякой гарантии работоспособности Windows, принять ее как есть и весь ущерб взять на себя если она его доказанно нанесет.
Более того, я даже должен отказаться от возможности подать на них в ихний американский суд, а могу все улаживать только через некоего "независимого" арбитра.
Баги в софте узаконены. И узаконено отсутствие ответственности за них.

Как это могло случится если бы программеры производительно работали, а именно отлаживали и ловили баги?
Программеры почти слились.
Только мы разработчики realtime систем и мелкой встроенной электроники еще держим уровень.

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

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

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

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

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

Все устаканится. Когда-то электронщики мотали катушки литцендратом, меняли лампы в панельках подбирая для симметрии пушпулов, крутили подстроечники в фильтрах. Вот для напоминания как было с конструкторами. Сейчас такого нет. Обычно на всем предприятии несколько инженеров-конструкторов. Тоже будет и с другими специальностями.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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




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

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


Судя по описанному вами - в обоих случаях monkey-coder

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

А задачу кто ставит? Его время/зарплата - не в счёт? Если такой человек есть - да, тогда ему нужны операторы САПР и monkey-coder'ы. Вопрос в том сколько продержится ведущий, если его "схемотехники" не способны посчитать резистивный делитель, а "программисты" - два байта переслать без чёткого указания в ТЗ как это сделать, ведь если не написано - это беллетристика.

Я.

В счёт.

Тогда он и сам решит, что и кто "ему нужны".

Ай-яй-яй... Тупой "ведущий" и не подозревает, над какой пропастью он висит на уже последней соломинке... Нада ему срочно раскрыть глаза!

А вот жопкой вилять не нужно.

И так, сказав ранее, что все программисты = быдлокодеры, теперь вы утверждаете что уже не все, и начинаете делить программистов уже на под категории, что уже прогресс)))
Прогрессом считаю и то, что вы наконец подошли к тому, что программист должен сам себе формулировать задачу, правда не уточнили, почему использование тех или иных алгоритмов программисту спускают "сверху", но спишем это на то, что таков уровень у вас постановки задач, и по определению вы работаете не с программистами, а с кодерами, раньше стенографистки такие были, печатали под диктовку. Исходя из этого, любые ваши заявления на счет программистов считаю безосновательными, т.к. основаны не на личном вашем опыте.

Кстати, вы правильно указали "ведущий", но можно вопрос, по вашему все должны быть ведущими? так и представил себе стройку, где обычных строителей нет, одни прорабы да начальники)))

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

Я вот долго не следил за развитием СВЧ приемников и недавно открыл для себя, что уже появились микросхемы, способные цифровать спектр вплоть до нескольких гигагерц. Задача электроников сводится к доставке сигнала с антенны на вход АЦП микросхемы System on Chip.
А дальше огромное поле деятельности для программистов. Которые одну физическую систему могут запрограммировать для приема и обработки чего угодно в широчайшем диапазоне частот.
Тенденция такова, что задача аналоговой элекроники, да и вообще электроники, кратчайшим путем преобразовать любой сигнал в поток битов и отправить этот поток программистам.

_alex__, а как же тёплый ламповый звук?

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


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




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


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

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

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

Вы очень плохо ориентируетесь в обязанностях программиста. Кроме алгоритма в прошивке еще много чего нужно
сделать, не говоря уже о некоторых нетривиальных особенностях из ES, жизненного опыта или тонких моментов
компилятора, среды и рабочего окружения вообще, пачки утилит, самописных утилит, контроля версий и средств документирования.
На фоне всего указанного, закодировать готовый алгоритм действительно не сложно, но обезьяна этого не сделает,
т.к. только алгоритм в изделии никому не нужен и работать не будет. Обычно на 99% у меня весь функционал прошивки
не имеет никакого отношения к "новым алгоритмам" - все кирпичи уже есть, нужно соединить их в нужной Заказчику
последовательности и при необходимости подкрасить в выбранный в ТЗ цвет.

"Проблемы негров не волнуют белого шерифа"©
В конце концов мы же им платим деньги за что?
А за то. Чтобы не вникать во всю их "внутреннюю кухню"

Это не согласуется с вашим же утверждением

Идею можно найти в сказке "Каша из топора" или в соседней ветке про
DC/DC без дросселя и диода.
По поводу закона Ома: в школе в кружке радиолюбителей ремонтировал
ламповый телевизор. Решил померить напряжение после детекторного диода:
китайский мультиметр зашкаливало на пределе 2000DC, хотя по осциллограммам
из схемы там единицы вольт. Лучше говорить о "закон Ома для постоянного тока".

Это если важен процесс, а не результат. По ходу сочинения алгоритма они большую часть времени потратят на изучение устройства и работы системы. Зачем, если есть люди, которые УЖЕ всё это знают лучше них? А для составить алгоритм программистом быть не нужно.


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

Это работа ВСЕГДА составляет большую часть времени (что у электронщика, что у программиста, называется она "предпроектные исследования"). Но это не значит, что она не нужна. Потому что
когда программист пишет программу не понимая как работает железо и совсем не разбираясь в прикладной области - результаты всегда плачевны.

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

А как иначе? Ведь софт сейчас КЛЮЧЕВАЯ составляющая системы. Если софт кривой - то вся работа псам под хвост. И даже самое замечательное железо с таким софтом не продашь.

Да-да, я уже приводил пример плачевных результатов:

"Молодцы", повелись на вброс и устроили срач прямо на день программиста. Срамота!

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

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

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