Jak wyjaśniłbyś, że inżynieria oprogramowania jest bardziej wyspecjalizowana niż inne dziedziny inżynierii? [Zamknięte]

Współpracuję z kimś, kto twierdzi, że każdy dobry inżynier oprogramowania może rozwijać się w dowolnej technologii oprogramowania, a doświadczenie w konkretnej technologii nie ma znaczenia przy tworzeniu dobrego oprogramowania. Jego analogią było to, że nie trzeba mieć wiedzy na temat budowanego produktu, aby wiedzieć, jak zbudować linię montażową, która wytwarza wspomniany produkt.

W pewnym sensie komplementem jest patrzenie okiem, że „jeśli jesteś dobry, jesteś dobry we wszystkim”, ale w pewnym sensie trywializuje on także zawód, jak w „Codemonkey, idź na temblak”. Bez doświadczenia w pracy z niektórymi platformami programowymi możesz szybko wpaść w kłopoty, a to ważne.

Próbowałem to wyjaśnić, ale nie kupił tego. Jakieś inne poglądy lub przemyślenia na ten temat, aby wyjaśnić, że moje doświadczenie w jednej rzeczy nie przekłada się na wszystkie rzeczy?

ale w pewnym sensie trywializuje także zawód, jak w „Codemonkey, idź na procę”.

Byłbym przeciwny. Dobry inżynier oprogramowania będzie w stanie konceptualizować, projektować i projektować oprogramowanie wysokiej jakości niezależnie od technologii. Przeciwnym końcem tego spektrum jest „klucz kodowy” .NET, Java lub PHP, który dobrze nadaje się do nadawania kierunku lub specyfikacji i korzystania z narzędzia do wdrażania oprogramowania.

Inżynier oprogramowania nie musi być mistrzem wszystkich narzędzi, ale powinien mieć dość dobre zrozumienie na wysokim poziomie, co to jest większość z nich, co wnoszą do stołu i co prawdopodobnie będzie najbardziej odpowiednie dla danego projektu . Spodziewałbym się, że małpa kodowa będzie jedynie mistrzem ich głoszonej wiedzy specjalistycznej w zakresie konkretnego narzędzia.

Nie ufałbym inżynierowi Forda, który nie wie, jak wykonać pracę Mechanika.

Mimo to inżynieria oprogramowania jest jedną z tych dziedzin, w których w wielu przypadkach oczekuje się, że będziemy jednocześnie Inżynierem, Konstruktorem i Mechanikiem.

Zgadzam się w pewnym stopniu z osobą, z którą współpracujesz. Dobry inżynier oprogramowania zajmuje się ogólnymi zasadami projektowania i produkcji oprogramowania. Rzeczywiste języki i ramy są szczegółami.

Nie ma to na celu zbanalizowanie łatwości, z jaką możesz wybierać nowe języki i frameworki. Zawsze wiąże się z nimi krzywa uczenia się, ale chodzi o to, że jest to krzywa, a nie pionowa ściana dla dobrego inżyniera oprogramowania.

Dobry inżynier oprogramowania ma szerokie doświadczenie w wielu różnych narzędziach i technologiach. Jeśli nie, w jaki sposób może wybrać najlepsze narzędzie do pracy? Aby wyrzucić starą frazę, do człowieka, który umie posługiwać się młotem, każdy problem wygląda jak gwóźdź. Nawet jeśli nie jesteś ekspertem w dziedzinie śrubokrętów, warto je dobrze zrozumieć, abyś mógł rozpoznać śrubę jako nie tylko śmiesznie wyglądający gwóźdź.

Wersja TLDR: inne dziedziny inżynierii potrzebują wiedzy o materiałach, których używają (np. Architekci muszą wiedzieć, ile obciążenia mogą znieść materiały, których używają w swoich projektach ). Języki i frameworki, których używamy do inżynierii oprogramowania, mają pewne ograniczenia i musimy się z nimi zapoznać, aby skutecznie je projektować i rozwijać.

Istnieją dwa odrębne etapy tego, co robimy. Pierwszy to projekt koncepcyjny. To jest projektowanie systemu wysokiego i niskiego poziomu (np. Przy użyciu UML). Projekty wysokiego poziomu mogą teoretycznie być niezależne od implementacji (chociaż czasami projektowanie wysokiego poziomu musi uwzględniać takie cechy, jak platforma bazy danych, gotowe oprogramowanie pośrednie itp.). Projekty niskiego poziomu są nieco trudniejsze. Możesz zaprojektować specyfikę logiki biznesowej bez umieszczania w nich szczegółów infrastruktury i znowu, teoretycznie mogą one być niezależne od platformy.

Drugi etap to faktyczne programowanie. Podczas gdy niektórzy postrzegają programowanie jako konstrukcję, inni (w tym ja) twierdzą, że kodowanie jest nadal dyscypliną projektową (w PPP , Bob Martin odnosi się do artykułu, w którym autor przedstawia bardzo dobry argument na ten temat, nie mam tego z ja teraz, ale zaktualizuję tę odpowiedź linkiem do tego artykułu). Rzeczywista konstrukcja ma miejsce po naciśnięciu kompilacji i jest w rzeczywistości darmowa.

Tak jak architekt musi brać pod uwagę takie rzeczy, jak wytrzymałość na rozciąganie i ściskanie materiałów budowlanych, których używa, tak inżynier oprogramowania musi znać możliwości platformy, na której się rozwija, pisząc kod. Twierdziłbym, że niskopoziomowa konstrukcja systemu nie jest zbyt skuteczna, jeśli nie uwzględnia również wyborów platformy.

Jako osoba, która ukończyła program inżynierii oprogramowania, mogę powiedzieć, że twój współpracownik ma częściowo rację. Dobry inżynier oprogramowania koncentruje się na zastosowaniu matematyki, statystyki, informatyki i doświadczenia w dziedzinie domen w celu zbudowania systemu. Metody stosowane przez inżyniera oprogramowania są zazwyczaj niezależne od technologii i języka - narzędzia nie mają tak dużego znaczenia, jak podstawowe zasady.

To powiedziawszy, analogia twojego współpracownika jest błędna. Zrozumienie problemów domenowych jest niezbędne dla każdej dyscypliny inżynierskiej. Jeśli nie w pełni rozumiesz problem, który próbujesz rozwiązać, i ludzi, których próbujesz zaspokoić, nieskończenie trudniej jest zbudować najlepsze możliwe rozwiązanie ich problemów.

Ostatecznie inżynieria oprogramowania (i każda dziedzina inżynierii) polega na zastosowaniu szeregu koncepcji w celu rozwiązania problemu. Jeśli często korzystasz z tych samych narzędzi, staniesz się z nimi bardziej biegły. Łatwiej będzie ci zidentyfikować problemy, które te narzędzia mogą rozwiązać, ryzyko lub pułapki związane z użyciem tych narzędzi, a następnie za pomocą tych narzędzi do skonstruowania rozwiązania.

Jego analogią było to, że nie trzeba mieć wiedzy na temat budowanego produktu, aby wiedzieć, jak zbudować linię montażową, która wytwarza wspomniany produkt.

Jest to prawie na pewno niepoprawne. Wyspecjalizowani inżynierowie produkcji muszą sporo zrozumieć na temat produktów będących pod ich opieką.

W każdym razie lepszą analogią są absolwenci kursów inżynierii mechanicznej: chociaż wszyscy zaczynają (zarówno w mechu, jak i oprogramowaniu) z tymi samymi umiejętnościami, nikt nie pozostaje „inżynierem mechanikiem”, ale zamiast tego specjalizuje się w rzeczy, które budują. Podobnie rozwój oprogramowania ma również bardzo wyraźne podpola.

Aby powrócić do analogii linii montażowej, każda linia montażowa jest inna dla każdego produktu, a różne rodzaje rozwoju oprogramowania wymagają różnych metodologii - nie zbudowałbyś oprogramowania zabezpieczającego w taki sam sposób jak gra.

Istnieje krzywa uczenia się związana z różnymi specjalizacjami. Mówię o różnicach między programowaniem osadzonym / w czasie rzeczywistym, programowaniem aplikacji internetowych, programowaniem systemów / systemów operacyjnych, programowaniem grubego klienta, programowaniem mobilnym itp.

Ktoś, kto jest ekspertem w jednym rodzaju programowania, może nie być w stanie przejść od razu do innego z powodu różnych wymagań. Pewnie, inżynier oprogramowania ma do tego podstawy, ale specjalizacja w czymś zajmuje trochę czasu.

Zgadzam się z założeniem, które sugeruje twój kolega, chociaż dodam zastrzeżenie.

Dobry inżynier oprogramowania będzie w stanie zbudować dobre oprogramowanie w dowolnej technologii ... po odrobinie nauki nowej technologii.

Mogą pojawić się pewne dziwactwa, które na początku nie są oczywiste, ale dobry inżynier oprogramowania wkrótce się ich nauczy.

Myślę, że tak naprawdę miał na myśli to, że tylko dlatego, że programista ma 2-letnie doświadczenie w C #, nie oznacza to lepszego inżyniera oprogramowania z doświadczeniem w języku Java, który nigdy wcześniej nie pracował w C #, nie mógł przyjść, nauczyć się C # i szybko zostać lepszym programistą C # niż pierwszym facetem.

Innymi słowy, niekoniecznie powinieneś dyskontować gościa Javy za pracę, JUST, ponieważ „wykonał czas” w C #.

Przykład: platforma oprogramowania, która Twoim zdaniem jest tak ważna, aby mieć specjalistyczne doświadczenie, prawdopodobnie nie istniała 10 lat temu lub uległa znacznej transformacji, jeśli tak się stało. Sama natura naszego zawodu uniemożliwia specjalizację przez cały okres kariery. W zależności od poziomu umiejętności, specjalizacja daje przewagę na okres od 1 do 6 miesięcy nad kimś, kto nigdy nie korzystał z twojego konkretnego środowiska. Potem jesteś na równi.

Pracuję dla firmy zajmującej się helikopterami, a inżynierowie lotniczy specjalizują się w typach samolotów, z którymi mogą współpracować. Muszą mieć „ocenę typu”. Technicznie mogliby pracować na wszystkim, od Robinsona R22 po Jumbo Jet, ale nie bez szkolenia konwersji.

Myślę, że jest to bardzo podobne do inżynierii oprogramowania, z wyjątkiem tego, że „szkolenie w zakresie konwersji” jest bardziej nieformalne dla inżynierów oprogramowania.

Czy rozmawiając z malarzem powiedziałbyś mu, że nie będzie miał problemów z rzeźbieniem?

Nauka nowego języka lub specyfiki nowej domeny jest podobna do artysty, który przede wszystkim zajmuje się ołówkiem i tuszem, uczy się malować (lub odwrotnie). Właśnie o tym mówi większość innych odpowiedzi, w jaki sposób twój przyjaciel jest częściowo poprawny - stosuje się wiele takich samych pojęć.

Ale nauczenie malarza, jak rzeźbić obiekt 3D lub napisać powieść (obie formy ekspresji artystycznej) to zupełnie inna bestia. Z tego punktu widzenia pochodzisz.

Oprogramowanie internetowe wymaga zupełnie innego sposobu myślenia niż oprogramowanie komputerowe. Oba są całkowicie różne, gdy są stosowane do gier, w porównaniu do środowiska pracy. Podejrzewam, że praca na systemie operacyjnym lub systemach zintegrowanych również wymaga myślenia w inny sposób (ale nie mam z nimi doświadczenia). I nie mam wątpliwości, że istnieją inne dziedziny, które również wymagają innego sposobu myślenia.

Podsumowanie i przykłady:

„Sztuka” obejmuje rzeźby, powieści, komiksy i obrazy. Nakładanie się umiejętności obejmuje:

• Forma ciała i teoria kolorów: rzeźby, komiksy i obrazy
• Komunikacja tekstowa: powieści i komiksy

... I tak dalej. Ale jak wspomniano powyżej, mało prawdopodobne jest, by komiks artysta dobrze sobie radził z pierwszą powieścią. Muszą myśleć inaczej.

Podobnie, nakładają się na siebie różne dziedziny programowania / inżynierii oprogramowania, ale większość z nich jest zbyt wyraźna, aby można było po prostu wskoczyć. Na przykład:

• Algorytmy: OS / zintegrowane systemy, gry i inne miejsca, które często trzeba optymalizować pod kątem szybkości lub pamięci. Rzadko duża sprawa w tworzeniu stron internetowych
• Projektowanie: Wszędzie w rozwoju sieci, ale niezbyt ważne w zintegrowanych systemach bez interfejsu użytkownika.
• Oprogramowanie klient / serwer: mentalność „nie ufaj klientowi”, która niekoniecznie istnieje w niektórych domenach (gry dla pojedynczego gracza i inne samodzielne oprogramowanie komputerowe, które przyznaję, że obecnie jest rzadsze).

Czy wszyscy pracownicy budowy dróg są w stanie korzystać z każdego sprzętu i maszyn w miejscu pracy? Odpowiedź brzmi nie. Istnieją maszyny, które znają i prawdopodobnie znają inne. To samo powinno być prawdą dla inżynierów oprogramowania, istnieje x liczba języków i struktur, które znasz, ponieważ pracujesz z nimi na co dzień, ale nie należy oczekiwać, że znają dokładne działania innych bez odpowiedniego przeszkolenia. To tak, jakby wziąć robotnika młot pneumatyczny i powierzyć mu zadanie prowadzenia betoniarki.

Języki programowania i frameworki to tylko narzędzia w pasku narzędzi inżynierów oprogramowania. Istnieje kilka narzędzi, które poznasz lepiej niż inne dzięki doświadczeniu. Ostatecznie najlepszym narzędziem jest zrozumienie podstawowych pojęć i zasad obliczeniowych. Wybór języków i ram po prostu wybiera, który śrubokręt ma zostać użyty na której śrubie.

Takie rzeczy zdarzają się często w miejscu pracy.

Lubię porównywać się do zawodu wuja mojej żony - mechanika samochodowego.

On specjalizuje się w Mercedes, potrafi zastosować swoją wiedzę do innych marek samochodów, a on robi - niektóre z nich dość rzadko, ale to nie znaczy, że można natychmiast naprawy make X, bo mówią, że to hałasuje.

Programuję w kilku językach, ale to nie znaczy, że wiem, dlaczego Safari na twoim MacBooku ładuje strony za każdym razem, gdy zmieniasz zakładkę (dzisiejsze dziwne połączenie). Spróbuję dowiedzieć się, dlaczego, ale nie zamierzam tego wiedzieć od góry, ponieważ pole komputerowe jest OGROMNE .

W obu przypadkach po spędzeniu czasu na analizowaniu naszych dziedzin prawdopodobnie moglibyśmy znaleźć odpowiedź, ale nie w ciągu dziesięciu sekund, które ludzie myślą, ponieważ „ale pracujesz z samochodami” lub „ale pracujesz z komputerami”.

Czy ludzie mówią takie rzeczy swojemu miejscowemu lekarzowi (np. „Boli mnie głowa, jaką mam chorobę?”) - założę się, że tak, ponieważ większość ludzi tak naprawdę nie rozumie, że w jednym zawodzie jest coś więcej niż ich bezpośrednie oczekiwania wspomnianego zawodu.