EE проти інформатики: вплив на підходи розробників, стилі? [зачинено]


11

Чи існують систематичні відмінності між розробниками програмного забезпечення (інженери, архітектор, незалежно від посади) з електронікою чи іншим технічним досвідом, порівняно з тими, хто вступив до професії через інформатику?

Під фоном електроніки я маю на увазі ступінь ЕЕ або майстра з електроніки самоучки, інших типів інженерів та фізиків-експериментаторів.

Мені цікаво, якщо входження в професії, що виробляють програмне забезпечення, із сильних знань тригерів, трифазних буферів, часів підйому краю та ін., Як правило, призводить до чіткого підходу до проблем, настроїв мислення або вищої майстерності на певних спеціальностях та нестачі навичок у інших, якщо порівнювати з типами інформатики, які сповнені таких понять, як абстрактні типи даних, орієнтація на об'єкти, нормалізація бази даних, які говорять про "закриття" в мовах програмування - речі, які мало сенсу для натовпу паяльника, поки вони не навчитися достатньому програмуванню.

Реальний світ, я впевнений, пропонує широкий спектр окремих винятків, але, здебільшого, чи можете ви сказати, що існують загальні відмінності? Чи матимуть це наслідки для найму, наприклад, (щоб щось скласти) "ніколи не наймайте електронного скрутника, щоб займатися дизайном баз даних"? Чи могли б знання будь-яких відмінностей допомогти шукачам роботи знайти щось підходяще більш ефективно? Або надати просвітлення чи якісь практичні поради для тих, хто виявляє недоліки у певній ролі роботи?

(До речі, я ніколи не приймав жодних занять з інформатики; моє враження про те, що саме вони охоплюють, нечітке. Я сам електроніка / фізика / мистецтво.)

Відповіді:


5

Маючи неповнолітнього середнього шкільного віку та спеціального колективу, я академічно працював з обома групами. Я ніколи не займався роботою, де розробляв продукти в стилі EE, але я спожив багато з них, роблячи роботу для компаній з такими речами, як PLC, і, таким чином, міг зрозуміти (з освітньої точки зору), що як це було добре . Тому я не можу сказати, що я знаю на 100% про поведінку та характеристики на робочому місці, але я можу academicпевною мірою описати відмінності між ними.

EE люди сфокусовані на деталях, і вони, як правило, знають точну реалізацію. Якщо це не 100% відображається, їм це не подобається. EE люди оптимізують вниз, щоб видалити непотрібні деталі, якщо зможуть.

Людям SE, як правило, подобаються шари і поділ логіки. ЮЛ не проти роздутих проектів. Люди, що займаються ДП, дуже орієнтовані на математику. Вони схильні думати через рівняння і як вирішити задачі за схемою. Приєднання до цієї групи більш інтуїтивно зрозуміло, як робота з базами даних. Чим далі ви йдете, тим більше ви схильні бачити людей, які вільно володіють такими речами, як функціональне програмування. Це просто не є безпечним підґрунтям для людини із ЗН.

Обидва люди знають про такі речі, як карти Карнау, тому в цих областях є багато перекриттів. Зниження логіки, така річ.

Гаразд, так це моя суб'єктивна відповідь. Сподіваюся, це допомагає.


Ця відповідь дає мені уявлення про мій поточний проект. Мені потрібно переключити кар’єру!
DarenW

1
Я майже на 100% згоден з вами, за винятком частини про функціональне програмування. Наприклад, я вважаю, що чиста логіка сходів - це майже 100% декларативний синтаксис. Функціональна блок-схема також популярна серед ЕЕ, яка, очевидно, є функціональною.
Скотт Вітлок

@Scott W. ~ 2 думки ... ;)це суб'єктивна відповідь, я дозволяю помилятися ... під посиланням на функціональну логіку я маю на увазі, як у цьому коді lisp ((lambda (arg) (+ arg 1)) 5)... вони дійсно будуть використовувати щось "подібне", але логіка буде однаковою для EE? Не в моєму особистому досвіді. Зрозуміло, я не знаю, що багато професійних мікросхем, що розробляють ЕЕ, більшість із тих, кого я знаю, - це більш сервісний персонал. І логіка сходів, яку вони вводять в комп'ютерний термінал, схожа на буквальну драбину на екрані. Піди розберися.
jcolebrand

1
Я думаю, ви говорите про такі функціональні конструкції, як лямбда та ін., І я думаю про такі функціональні поняття, як незмінність та декларативний синтаксис. Я згоден, що такі речі, як монади тощо, досить абстрактні. Я не думаю, що ЕЕ звичайно наштовхуються на подібні речі.
Скотт Вітлок

Я думаю, що ЕЕ стикаються з монадами частіше, ніж люди з ДП. У Haskell навіть є розширення монади, яке дозволяє моделювати монади як блоки вводу / виводу, хліб та масло інженерів DSP.
Адітя

12

Якщо мені довелося узагальнити, ось який мій досвід:

  • Інженери (або просто ЕЕ) прагнуть зробити краще в «досконалості малого». Завдяки невеликому завданню програмування, вони дуже довго і наполегливо думають про всі крайові випадки, і, швидше за все, в кінцевому підсумку створюють програмне забезпечення, яке є дуже надійним. Зазвичай, це спрямовано на підході дизайн зверху вниз - це все-напроти, оскільки це те, до чого вони звикли в техніці. Зазвичай це передбачає використання державних машин, тому що вони використовуються для їх проектування для апаратних засобів, і це відповідає підходу "великого дизайну". З іншого боку, вони не так багато думають про масштабованість або ремонтопридатність.

  • Традиційні розробники краще керують великими складностями, в основному тому, що навчання підштовхує розбиття проблем на більш дрібні керовані біти. Їх навчають уникати великого дизайну, а просто відокремлюють проблеми, пишуть тести та проводять тести. Зазвичай є багато маленьких пропущених крайових кейсів, лише через складність та час, але з часом вони закриваються. Розробники схильні скористатися тим, що це лише програмне забезпечення, і його слід (або є) легко змінити. Коли EE працює з обладнанням, вони не мають цієї переваги, і я думаю, що для здійснення переходу потрібен час.

Як я вже сказав, це мій узагальнений досвід. Це неправда в кожному випадку.


Приємна відповідь, з контрастом між ними. Тепер, щоб побачити, як багато інших погоджуються, що це правильно або наближається, шляхом виклику.
DarenW

3

На мій досвід - типи ЕЕ, здається, розробляють лінійні програми, а не включають шари абстракції, типу CS.

Немає коментарів щодо відмінностей у якості та їх відсутності.


1

Я сумніваюся, що ви побачите велику різницю у звичайному бізнесі чи веб-додатках, над якими більшість людей закінчує роботу, коли обидва мають кілька років досвіду роботи. Усі речі, які ви перераховуєте як заплутані для "натовпу паяльника", - це звичайні навички програмування. По суті, ви відповідаєте на власне запитання - хтось, хто не має програми програмування, може вчитися програмуванню, але поки вони цього не роблять, вони не програміст. Комусь із логічним та аналітичним розумом буде набагато легше навчитися добре програмувати, ніж комусь, хто цього не робить - це була б єдина перевага, яку я можу подумати для саморобного майстра з електроніки.

Інформатика (на відміну від комп’ютерної інженерії) є переважно математикою, оскільки (на вищих рівнях) - це різні інші науки, такі як фізика - але це математика зовсім інша. Якщо ви займалися іншою наукою, то ви також будете займатися математикою, і тому ви повинні знаходити можливість швидко досягати швидкості на відміну від того, хто не має математичного походження. Звичайно, дуже мало програмістів коли-небудь дійсно повинні знати про теорію множин, big-O або що-небудь ще - звичайно, не на високому рівні все одно.


Цікава відповідь. Можливо, я принизив навички програмування людей з електроніки - досвідчені можуть бути де завгодно за шкалою від манекена до рок-зірки. Чи можете ви сказати, що це правда, що EE можуть навчитися програмуванню на професійно грамотному рівні, легше, ніж чиста програмна особа може підібрати електроніку?
DarenW

1

Я почав з BSEE, зайнявся розробкою логічних схем для великої телефонної науково-дослідної лабораторії, і (це було близько 40 років тому) зрозумів, що більшість того, що я будував, врешті-решт можна зробити за допомогою комп'ютерної програми. Тому я повернувся і отримав ступінь MSCS.

Мене завжди цікавила комп'ютерна архітектура та те, що відбувається на апаратному рівні. Більшу частину своєї кар'єри я витратив на розробку вбудованих систем мікроконтролерів, де я намагаюся знайти найкращий збіг між тим, що робиться в апараті, і тим, що робиться в прошивці. Однак я дуже багато займався веб-програмуванням та деяким дизайном баз даних.

Без мого досвіду роботи в CS, я думаю, у мене було б набагато більше проблем зі зрозумінням більш абстрактних понять. Окрім багатьох різних мов асемблера, я використовував C, C ++, C #, Pascal, Delphi, Perl, PHP та деякі Lisp. Зараз я намагаюся вивчити Рубі та Пітона. OO дизайн, з яким я досить комфортний. Функціонального програмування я ще не є.

Те саме для баз даних. Я розумію нормалізацію. У мене проблеми з деякими езотеричними ПРИЄДНАЮТЬСЯ та уникаю їх. Мені щось не дуже комфортно, якщо я не розумію, що відбувається під капотом.

Я хочу вміти "бачити", як комп'ютер запустив би програму в моїй голові.


1
"Мені щось не дуже комфортно, якщо я не розумію, що відбувається під капотом". - це знак відповідальної інженерії. +1 вам, сер.
luis.espinal
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.