EE a informatyka: wpływ na podejście twórców, style? [Zamknięte]

Czy istnieją jakieś systematyczne różnice między twórcami oprogramowania (inżynierami SW, architektem, bez względu na stanowisko) z elektroniką lub innym doświadczeniem inżynieryjnym, w porównaniu do tych, którzy podjęli ten zawód poprzez informatykę?

Pod pojęciem elektroniki mam na myśli stopień EE lub samodzielnego majsterkowicza elektroniki, innych typów inżynierów i fizyków eksperymentalnych.

Zastanawiam się, czy wchodzenie do zawodów związanych z tworzeniem oprogramowania z dużą wiedzą na temat klapek, buforów trójdzielnych, czasów narastania zegara i tak dalej, zwykle prowadzi do wyraźnego podejścia do problemów, sposobu myślenia lub lepszych umiejętności w niektórych specjalizacjach i brak umiejętności innych w porównaniu z typami informatyki, które są pełne pojęć, takich jak abstrakcyjne typy danych, orientacja obiektowa, normalizacja bazy danych, którzy mówią o „zamknięciach” w językach programowania - rzeczy, które nie mają większego sensu dla tłumu lutowniczego, dopóki naucz się wystarczająco dużo programowania.

Jestem pewien, że prawdziwy świat oferuje szeroki zakres indywidualnych wyjątków, ale w większości czy możesz powiedzieć, że istnieją ogólne różnice? Czy miałoby to implikacje związane z zatrudnieniem, np. (Aby coś wymyślić) „nigdy nie wynajmuje elektronowego sprantera do projektowania baz danych”? Czy wiedza o różnicach może pomóc osobom poszukującym pracy znaleźć coś bardziej efektywnego? Czy może zapewnić oświecenie lub praktyczne porady dla tych, którzy nie pasują do określonej roli zawodowej?

(Przy okazji, nigdy nie brałem udziału w zajęciach z informatyki; moje wyobrażenie o tym, co obejmują, jest rozmyte. Sam jestem typem elektroniki / fizyki / sztuki.)

Mając EE moll i CS-dur, pracowałem z obiema grupami naukowo. Nigdy nie miałem pracy, w której projektowałem produkty w stylu EE, ale pochłonąłem wiele z nich, pracując dla firm z takimi rzeczami jak PLC, a więc mogłem zrozumieć (z wykształcenia), co było miłe . Nie mogę więc powiedzieć, że wiem w 100% o zachowaniu i cechach w miejscu pracy, ale academicdo pewnego stopnia potrafię opisać różnice między nimi.

Ludzie z EE zwykle skupiają się na szczegółach i znają dokładną implementację. Jeśli nie można go w 100% zmapować, nie podoba im się to. Ludzie EE zoptymalizują w dół, aby usunąć niepotrzebne szczegóły, jeśli mogą.

Ludzie z SE lubią warstwy i przedział logiki. Ludzie z SE nie mają nic przeciwko rozdętym projektom. Ludzie z SE są bardzo zorientowani na matematykę. Mają tendencję do myślenia w kategoriach równań i rozwiązywania problemów z koncepcji wzorca. Połączenia są bardziej intuicyjne dla tej grupy, podobnie jak praca z bazą danych. Im dalej SE, tym częściej spotykasz ludzi biegle posługujących się programowaniem funkcjonalnym. To po prostu nie jest bezpieczny grunt dla osoby EE.

Obaj wiedzą o takich rzeczach jak mapy Karnaugh, więc w tych obszarach wiele się nakłada. Redukcja logiki, tego rodzaju rzeczy.

Ok, więc to moja subiektywna odpowiedź. Mam nadzieję, że to pomoże.

Gdybym musiał uogólnić, oto moje doświadczenie:

• Inżynierowie (lub tylko EE) mają tendencję do radzenia sobie lepiej w „perfekcji małych”. Biorąc pod uwagę małe zadanie programistyczne, bardzo długo i intensywnie myślą o wszystkich przypadkach brzegowych, a bardziej prawdopodobne jest, że zbudują oprogramowanie, które jest bardzo solidne. Zwykle jest to oparte na odgórnym podejściu do projektowania od początku, ponieważ do tego są przyzwyczajeni w sprzęcie. Zazwyczaj wiąże się to z użyciem maszyn stanowych, ponieważ są one przyzwyczajone do projektowania ich pod kątem sprzętu i jest to zgodne z podejściem „dużego projektu”. Z drugiej strony, nie myślą tak dużo o skalowalności i łatwości konserwacji.

• Twoi tradycyjni programiści lepiej radzą sobie z dużą złożonością, głównie dlatego, że szkolenie popycha rozkładanie problemów na mniejsze, łatwiejsze do zarządzania bity. Nauczono ich, aby unikali dużego projektu, po prostu rozdzielali obawy, pisali testy i przeprowadzali testy. Zazwyczaj jest wiele małych przypadków pominiętych krawędzi, tylko ze względu na złożoność i czas, ale te ostatecznie się pokrywają. Programiści zwykle korzystają z faktu, że jest to tylko oprogramowanie i powinno być (lub jest) łatwe do zmiany. Kiedy EE pracuje ze sprzętem, nie mają tej przewagi i myślę, że przejście zajmuje trochę czasu.

Jak powiedziałem, to moje ogólne doświadczenie. To nie jest prawda w każdym przypadku.

Z mojego doświadczenia - typy EE wydają się projektować programy liniowe i nie zawierają warstw abstrakcji typy CS wydają się być wygodne.

Brak komentarza na temat różnic w jakości lub ich braku.

Wątpię, czy zobaczyłbyś dużą różnicę w typowych aplikacjach biznesowych lub internetowych, nad którymi większość ludzi kończy pracę, gdy oboje mają kilka lat doświadczenia pod pasem. Wszystkie rzeczy, które uważasz za „mylące” dla „tłumu lutowniczego”, to normalne umiejętności programistyczne. W gruncie rzeczy odpowiadasz na własne pytanie - ktoś bez doświadczenia w nauce może nauczyć się programowania, ale dopóki tego nie zrobi, nie jest programistą. Ktoś z logicznym i analitycznym umysłem łatwiej będzie nauczyć się dobrze programować niż ktoś, kto tego nie robi - byłaby to jedyna zaleta, jaką mogę sobie wyobrazić dla majsterkowicza elektroniki.

Informatyka (w przeciwieństwie do inżynierii komputerowej) to głównie matematyka, ponieważ (na wyższych poziomach) są różne inne nauki, takie jak fizyka - ale to zupełnie inny rodzaj matematyki. Jeśli zrobiłeś inną naukę, to również wykonasz matematykę, więc powinno być możliwe przyspieszenie w przeciwieństwie do kogoś, kto nie ma wiedzy matematycznej. Oczywiście, bardzo niewielu programistów naprawdę musi wiedzieć o teorii mnogości, wielkiej-O lub cokolwiek innego - z pewnością nie na wysokim poziomie.

Zacząłem od BSEE, zacząłem projektować układy logiczne dla dużego telefonicznego laboratorium badawczo-rozwojowego i (to było około 40 lat temu) zdałem sobie sprawę, że większość tego, co buduję, można w końcu zrobić za pomocą programu komputerowego. Więc wróciłem i uzyskałem stopień MSCS.

Zawsze interesowałem się architekturą komputerową i tym, co dzieje się na poziomie sprzętowym. Większość mojej kariery poświęciłem projektowaniu wbudowanych systemów mikrokontrolerów, w których staram się znaleźć najlepsze dopasowanie między tym, co dzieje się w sprzęcie, a tym, co dzieje się w oprogramowaniu układowym. Wykonałem jednak sporo programowania internetowego i zaprojektowałem bazę danych.

Bez mojego doświadczenia w CS myślę, że miałbym o wiele więcej problemów z uchwyceniem bardziej abstrakcyjnych koncepcji. Oprócz wielu różnych języków asemblera, użyłem C, C ++, C #, Pascal, Delphi, Perl, PHP i niektórych Lisp. Obecnie próbuję nauczyć się Ruby i Pythona. Projekt OO, z którym czuję się całkiem dobrze. Programowanie funkcjonalne Nie jestem (jeszcze).

To samo dotyczy baz danych. Rozumiem normalizację. Mam problem z niektórymi bardziej ezoterycznymi połączeniami i ich unikam. Nie czuję się naprawdę dobrze z czymś, chyba że rozumiem, co się dzieje pod maską.

Chcę móc „zobaczyć”, jak komputer uruchomiłby program w mojej głowie.