EE против компьютерных наук: влияние на подходы разработчиков, стили? [закрыто]


11

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

Под электронным фоном я имею в виду степень EE, или самоучку по электронике, другие типы инженеров и физиков-экспериментаторов.

Мне интересно, если переход в профессии производителя программного обеспечения из глубоких знаний триггеров, трехсторонних буферов, времени повышения частоты и т. Д., Как правило, приводит к четкому подходу к проблемам, мышлению или превосходным навыкам в определенных специальностях и нехватке навыков у других, по сравнению с типами информатики, которые полны таких понятий, как абстрактные типы данных, объектная ориентация, нормализация базы данных, которые говорят о «замыканиях» в языках программирования - вещах, которые не имеют большого смысла для толпы паяльников, пока они выучить достаточно программирования.

Я уверен, что реальный мир предлагает широкий спектр индивидуальных исключений, но по большей части, можете ли вы сказать, что есть общие различия? Будут ли они иметь последствия при найме, например (чтобы что-то придумать), «никогда не нанимать электронного спорщика для разработки базы данных»? Может ли знание каких-либо различий помочь соискателям более эффективно найти что-то подходящее? Или дать просветление или какой-нибудь практический совет тем, кто оказался не в своей роли?

(Между прочим, я никогда не брал никаких уроков информатики; мое впечатление от того, что они охватывают, нечеткое. Я сам являюсь электронщиком / физиком / художником).

Ответы:


5

Имея степень EE и степень CS, я работал с обеими группами академически. У меня никогда не было работы, где я разрабатывал продукты в стиле EE, но я потратил много из них, работая в компаниях с такими вещами, как PLC, и поэтому смог понять (с точки зрения образования), что происходящее было приятно , Поэтому я не могу сказать, что знаю на 100% о поведении и характеристиках на рабочем месте, но я могу описать academicразличия между ними в некоторой степени.

EE люди, как правило, сосредоточены на деталях, и они, как правило, знают точную реализацию. Если он не на 100% сопоставим, им это не нравится. EE люди будут оптимизировать вниз, чтобы удалить ненужные детали, если они могут.

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

Обе люди знают о таких вещах, как карты Карно, поэтому в этих областях много совпадений. Сокращение логики и тому подобное.

Итак, это мой субъективный ответ. Надеюсь, поможет.


Этот ответ дает мне понимание моего текущего проекта. Мне нужно сменить карьеру!
ДаренВ

1
Я почти на 100% согласен с вами, кроме части о функциональном программировании. Например, я считаю, что чистая лестничная логика - это почти 100% декларативный синтаксис. Функциональная блок-схема также популярна у EE, которая также, очевидно, функциональна.
Скотт Уитлок

@ Scott W. ~ 2 мысли ... ;)это субъективный ответ, я могу ошибаться ... в отношении функциональной логики я имею в виду, как этот код LISP ((lambda (arg) (+ arg 1)) 5)... они действительно будут использовать что-то "подобное", но будет логика будет то же самое для EE? Не в моем личном опыте. Конечно, я не знаю, что многие профессиональные ЭЭ проектируют чипы, большинство из которых я знаю, это больше обслуживающий персонал. И лестничная логика, которую они вводят в компьютерный терминал, выглядит буквальной лестницей на их экране. Пойди разберись.
Jcolebrand

1
Я думаю, что вы говорите о функциональных конструкциях, таких как лямбды и т. Д., И я имею в виду функциональные концепции, такие как неизменяемость и декларативный синтаксис. Я согласен, что такие вещи, как монады и тому подобное, довольно абстрактны. Я не думаю, что ЭЭ обычно сталкиваются с такими вещами.
Скотт Уитлок

Я думаю, что EE сталкиваются с монадами чаще, чем люди SE. У Haskell даже есть расширение монады, которое позволяет моделировать монады как блоки ввода / вывода, как хлеб инженеров DSP.
Адитья

12

Если бы мне пришлось обобщить, вот каков мой опыт:

  • Инженеры (или просто EE), как правило, добиваются большего успеха в «совершенстве малого». Учитывая небольшую задачу программирования, они очень долго и усердно думают обо всех крайних случаях и с большей вероятностью в конечном итоге создадут очень надежное программное обеспечение. Обычно он основан на нисходящем подходе «дизайн все это впереди», потому что это то, к чему они привыкли в аппаратном обеспечении. Обычно это связано с использованием конечных автоматов, потому что они привыкли проектировать их для аппаратного обеспечения, и это соответствует подходу «большого дизайна». С другой стороны, они не так много думают о масштабируемости или удобстве обслуживания.

  • Ваши традиционные разработчики лучше справляются с большими сложностями, в основном потому, что обучение разбивает проблемы на более мелкие, более управляемые части. Их учат избегать большого дизайна, просто разделять проблемы, писать тесты и делать тесты успешными. Как правило, есть много маленьких пропущенных крайних случаев, просто из-за сложности и времени, но те в конечном счете покрываются. Разработчики, как правило, пользуются тем, что это просто программное обеспечение, и его легко (или легко) изменить. Когда EE работает с аппаратным обеспечением, у них нет этого преимущества, и я думаю, что для перехода потребуется время.

Как я уже сказал, это мой обобщенный опыт. Это не правда в каждом случае.


Хороший ответ, с контрастом между ними. Теперь, чтобы увидеть, сколько других согласны с тем, что это правильно или близко, путем голосования.
ДаренВ

3

По моему опыту - типы EE, кажется, проектируют линейные программы и не включают уровни абстракции, с которыми CS-типы удобны.

Нет комментариев о различиях в качестве или их отсутствии.


1

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

Компьютерные науки (в отличие от компьютерной инженерии) - это преимущественно математика, так как (на более высоких уровнях) это различные другие науки, такие как физика, но это совсем другой вид математики. Если вы занимались другой наукой, то вы также занимались математикой, и поэтому должны найти возможность набрать скорость в отличие от тех, у кого нет математического фона. Конечно, очень немногие программисты когда-либо действительно должны знать о теории множеств, big-O или о чем-то еще - конечно, не на высоком уровне в любом случае.


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

1

Я начал с BSEE, приступил к разработке логических схем для большой телефонной лаборатории исследований и разработок, и (это было около 40 лет назад) понял, что большая часть того, что я строил, могла быть в конечном итоге сделана с помощью компьютерной программы. Поэтому я вернулся и получил степень MSCS.

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

Без моего опыта в CS, я думаю, у меня было бы гораздо больше проблем с пониманием более абстрактных концепций. Помимо множества различных языков ассемблера, я использовал C, C ++, C #, Pascal, Delphi, Perl, PHP и некоторые Lisp. В настоящее время я пытаюсь выучить Ruby и Python. ОО дизайн мне довольно удобен. Функционального программирования у меня нет (пока).

То же самое для баз данных. Я понимаю нормализацию. У меня проблемы с некоторыми из более эзотерических СОЕДИНЕНИЙ и я их избегаю. Мне не очень удобно с чем-то, если я не понимаю, что происходит под капотом.

Я хочу, чтобы я мог видеть, как компьютер запускает программу в моей голове.


1
«Мне не очень удобно с чем-то, если я не понимаю, что происходит под капотом». - это знак ответственного инжиниринга. +1 вам, сэр.
luis.espinal
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.