Программист или инженер, куда двигаться дальше Опции

[binom]

Доброго всем времени суток.

Хотельсь бы узнать мнение специалистов по следующему вопросу:

При изготовлении микропроцессорной техники по моему мнению можно выделить две роли - это программист и инженер(скажем схемотехник).

Наверное хороший, высокооплачиваемый руководит проекта по разработке микропроцессорной техники должен быть специалистом в обоих областях.

Пример из жизни: у меня на работе есть отличный инженер - схемотехник, но он просто панически боиться С, С++. А я программирую то железо которое он сваял, но ничего не понимаю в его резисторах и конденсаторах(ну условно ничего, в детстве ходил на радиокружок. Я понимаю но на это уходит время и приходится консультироваться).



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

Спрашиваю потому, что стою перед выбором в дальнейшем развитии - либо углубляться в программирование драйверов устройств и ОС реального времени, либо потратить время на то, чтобы изучить инженерные вопросы.

[yornik]

1) Дадим определения. Устройство [радиоэлектроннопрограммное] простое - то, которое может быть разработано одним человеком за время его жизни. Устройство сложное - все остальные устройства.

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

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

Да, по поводу темы топика.
Имхо, программные части систем сейчас гораздо сложнее схемотехнических. Или так: по крайней мере, все сложные цифровые схемы сейчас описываются в стиле программирования (VHDL/Verilog/SystemC). Т.е. к выбору Вас в !какой-то небольшой! мере может подтолкнуть, что Вас привлекает больше (сложность -> ближе к программированию и работе в коллективе) или простота. Но помнить, что любая простота в любом деле еще должна быть доказана практикой, и на кону - Ваша жизнь как разработчика (ну или разочарование заказчика ;) ) И программирование, и схемотехника - подмножества гораздо более могучего термина "конструирование". Если Вы на начальном этапе выберете схемотехнику и Вас заинтересует сложность, Вы непременно придете и (или) к тепловым расчетам, и (или) к оптическим схемам, акустике, ..., да чему угодно еще. Если начнете с программирования, то его может хватить и одного ("программирование есть процесс управления сложностью" - не помню, чей (с) ); возможно, Вы придете к (условно!) "программированию людей" - управлению коллективом разработчиков.