[binom 0]

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

 

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

 

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

 

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

 

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

 

 

 

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

Насколько это вообще реально быть специалистом в обоих областях.

 

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

[HARMHARM 0]

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

[wim 6]

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

Насколько это вообще реально быть специалистом в обоих областях.

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

[binom 0]

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

 

Зачем нужно, ну вот пример:

 

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

 

Хотя я понимаю, что для того чтобы назвать себя инженером надо хотя бы уметь паять. Я один раз попробовал припаять проводок к микросхеме под микроскопом :cranky: , паял 1.5 часа, после чего мое терпение кончилось с офигенным выбросом отрицательных эмоций :angry2: :angry2: . Проводок я так и не припаял, что вызвало бурю положительных эмоций у моего товарища инженера .

[SM 0]

На мой взгляд разработка устройства должна производится одним человеком. От схемы и до сдачи. Пусть это не система в целом, пусть это ее модуль, но для лучшего качества продукта разработчик должен сам отлично представлять себе, что и как будет работать, должен сам распределять задачу между аналоговой частью, если таковая есть, процессоров, ПЛИСов, и т.п. Если с чем-то не в силах справиться, то либо разобраться в этом вопросе, либо попросить другого разработчика помочь. Не раз видел, как программист разбирается с ПЛИСоделом, один говорит другому "да тебе это раз плюнуть", и в ответ слышит то-же. И полдня споров, типа что лучше - фифо или двухпортовку. Когда делает один человек, пусть даже с периодическим привлечением сторонних сил, такого не бывает никогда, и получается наиболее сбалансированная система. Не спорю, всего не узнаешь, например в RF/Microwave я не лезу, там для меня темный лес. Однако припрет - придется и туда вникать.

 

Сам так работал всегда, беря ТЗ и сдавая модуль/девайс. И по другой системе работать не желаю. Если знаешь схемотехнику (аналог), то и цифра не проблема, и далее ПЛИС. В общем - самосовершенствование должно иметь место. Вчера не знал, как работает импульсный DC/DC, сегодня-завтра почитал книжки, вник в математику и физику процессов, послезавтра разработал схему, через неделю, после пары взрывов, заработало. Зато в следующем проекте уже уверенно подходишь к аналогичной задаче. И так всегда. Через года два-три уже мастер на все руки в схемотехнике. Не надо бояться поставленных задач. Надо сразу смотреть с оптимизмом - "я справлюсь!"

Если умеешь программировать - то все равно какой процессор... Новых ядер не бояться, их надо с интересом разбирать на части и применять. С каждым новым процом приходит опыт, знания, и, самое главное, появляется возможность выбирать в следующей разработке из бОльшего списка. Да и пятое ядро дается на порядок быстрее второго. И еще считаю, что программист ОБЯЗАН знать все тонкости функционирования ядра и периферии того МП, с которым имеет дело, и обязательно уметь программить на ассемблере. Т.е. первое - это всегда ассемблер, не знаешь его - не допускаешься к работе с данным ядром. С/C++ это желаемая опция, если надо для проекта.

[current_eng 0]

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

 

Зачем нужно, ну вот пример:

 

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

 

Хотя я понимаю, что для того чтобы назвать себя инженером надо хотя бы уметь паять. Я один раз попробовал припаять проводок к микросхеме под микроскопом :cranky: , паял 1.5 часа, после чего мое терпение кончилось с офигенным выбросом отрицательных эмоций :angry2: :angry2: . Проводок я так и не припаял, что вызвало бурю положительных эмоций у моего товарища инженера .

 

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

Вот он должен быть ШИРОКО подкованным во всех областях, которые есть у него в проекте+специальные знания по проектированию систем. Но он не должен (и не может) быть ГЛУБОКО подкованным в профильных дисциплинах.

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

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

 

P.S. Уметь паять (особенно, хорошо паять) инженеру совсем не обязательно для этого есть монтажник, у меня вот вроде 7 лет стажа инженера, а нормально паять не умею (только командую чего и куда :) ), нужно делать то, что ты умеешь делать хорошо, схемы разрабатывать.

[binom 0]

 

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

 

Я так понимаю, что системные инженеры так же вырастают из каких то профильных специалистов.

[wim 6]

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

Вот он должен быть ШИРОКО подкованным во всех областях, которые есть у него в проекте+специальные знания по проектированию систем. Но он не должен (и не может) быть ГЛУБОКО подкованным в профильных дисциплинах.

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

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

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

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

[current_eng 0]

 

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

 

Я так понимаю, что системные инженеры так же вырастают из каких то профильных специалистов.

 

 

По разному бывает, просто часто системные инженеры, изначально являясь системными (по специальности ли, по складу ума ли) некоторое время работают как профильный специалист.

[Harbinger 10]

P.S. Уметь паять (особенно, хорошо паять) инженеру совсем не обязательно для этого есть монтажник,

Но очень желательно. Пусть не самому разработчику (в случае, если он - чистый теоретик :) ), а тому человеку, который конструкцию заставляет работать. Бегать к монтажникам из-за каждого резистора (мне - через несколько этажей, лифта нет) как-то не с руки ;)

[Vadim 0]

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

С какой целью выбираете? Если там, где больше денег - то это изначально неизвестно.

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

И только если Ваша работа Вам по душе и Вы стремитесь к самосовершенствованию - однозначно прислушайтесь к мнению SM.

Кстати, SM, мой Вам :a14:

[Mirabella 0]

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

И только если Ваша работа Вам по душе и Вы стремитесь к самосовершенствованию - однозначно прислушайтесь к мнению SM.

Кстати, SM, мой Вам :a14:

 

Как мне показалось, уважаемый Vadim (может быть я и не права), Вы не понимаете значения выражений типа "разработка",

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

За а-ля прощаю, сама когда-то была молодой.....

 

P.S.

Может быть обменяемся пониманием термина "разработка"?

 

D2MS

[Гость @Ark]

Я, тоже, полностью разделяю подход SM к разработке. :a14:

Замечу лишь, что подход "Разработку делает один человек" - не означает, что он обязательно все делает своими руками и, даже, своей головой! Большие проекты тоже должен "делать" один человек - главный конструктор изделия (системы). Другие участники проекта должны быть "эффективным продолжением его рук, ног и головы". Иначе успех не гарантирован. Я, лично, другие подходы к разработке не признаю и другим не советую! ;)

[yornik 0]

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

 

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

 

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

 

Да, по поводу темы топика.

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

[Vadim 0]

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

И только если Ваша работа Вам по душе и Вы стремитесь к самосовершенствованию - однозначно прислушайтесь к мнению SM.

Кстати, SM, мой Вам :a14:

 

Как мне показалось, уважаемый Vadim (может быть я и не права), Вы не понимаете значения выражений типа "разработка",

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

За а-ля прощаю, сама когда-то была молодой.....

 

P.S.

Может быть обменяемся пониманием термина "разработка"?

 

D2MS

Уважаемая Mirabella, если я задел Вас своим а-ля, прошу прощения.

И если Вы были столь любезны, что простили мне это, надеюсь Вы простите меня и за то, что я не намерен обмениваться с Вами пониманиями термина "разработка", ибо занят сейчас более серьезным делом - непосредственно ей самой.