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

9

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?

Spencer Kormos
źródło
7
Jeśli masz zamiar głosować, czy mógłbyś chociaż skomentować, dlaczego? Zwłaszcza, że ​​Twój wkład może pomóc w przeformułowaniu / zmianie ostrości pytania.
Spencer Kormos
11
po pierwsze jest to rant, a nie pytanie, a po drugie jest to błędne założenie, że należy to przegłosować i zamknąć.
6
@JarrodRoberson Myślę, że istnieje uzasadnione pytanie. Prosi o dobre wyjaśnienie, które prosi o wyjaśnienie, dlaczego niektórzy uważają inżynierię oprogramowania za mniej lub bardziej specjalistyczną niż inne dziedziny inżynierii.
wałek klonowy
7
@SpencerK Twoje pytanie brzmi: „jakiś przypadkowy koleś zrobił złą analogię, jak mam odpowiedzieć”, i cóż, to naprawdę nie jest pytanie. Po prostu poproś o solidne dowody i / lub referencje, które potwierdzą jego pozycję, nie jesteś tym, który musi się tutaj udowodnić.
yannis
5
-1, ponieważ nie zgadzam się z twoją przesłanką. Inżynieria oprogramowania nie jest bardziej wyspecjalizowana niż inne dziedziny inżynierii. Oba mogą być wysoce wyspecjalizowane i uogólnione. Dobry inżynier elektromechaniczny może nie być dobrym inżynierem biomedycznym. Z drugiej strony dobry elektryk może pracować zarówno w domach, jak i w samochodach.
zzzzBov

Odpowiedzi:

23

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.

wałek klonowy
źródło
8
Chciałbym również podkreślić znaczenie zrozumienia pojęć i zasad w stosunku do języków i narzędzi.
Oded
+1 Jednym z moich pomysłów jest to, że ludzie mówią: „Jestem programistą C # ...”. A potem po prostu wypij kool-pomoc i przyjmij wszystko od stwardnienia rozsianego jako ewangelię. 10 lat programowania Nauczyłem się ponad 11 języków programowania i każdy z nich znacznie poprawił sposób, w jaki programuję w innych językach. Dowiedz się inżynierii oprogramowania! Nie platformy, które znikną za 2 lata.
Timothy Baldridge
+1 za odniesienie do Inżyniera Forda. Nigdy wcześniej nie myślałem w ten sposób o Software Engineers vs. Programmers.
Dalin Seivewright
Programista jest podzbiorem inżyniera, a nie na odwrót.
Spencer Rathbun
11

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ź.

JeremyP
źródło
„Dobry inżynier oprogramowania zajmuje się ogólnymi zasadami projektowania i produkcji oprogramowania”. Produkcja wbudowanych systemów sterowania i aplikacji internetowych jest prawie dokładnie taka sama , prawda?
Marcin
@Marcin: Niektóre zasady są, tak. Poitn, które stworzyłem, to (na przykład) projektowanie systemu osadzonego w C lub asemblerze, stosując te same zasady, nawet jeśli narzędzia są różne.
JeremyP,
Narzędzia te nie różnią się tak bardzo i dotyczą bardzo podobnych dziedzin problemów. Dlatego jest to całkowicie nieprzydatne.
Marcin
1
@Marcin: najwyraźniej albo nie programowałeś w asemblerze, albo nie programowałeś w C. Zapewniam cię, że pomimo powszechnego mitu C nie jest asemblerem, a programowanie w tych narzędziach jest tak różne, jak (powiedzmy) programowanie w C i Ruby.
JeremyP
1
@Marcin, oczywiście, a kręgle to tylko kwestia powalenia wszystkich szpilek. Kawałek ciasta naprawdę. Podczas gdy programowanie sieciowe i programowanie wbudowane mogą mieć wspólne zasady i najlepsze praktyki na wysokim poziomie, tak naprawdę w codziennej pracy obowiązują ograniczenia regulujące ich wdrażanie. Podczas może ostatecznie być w stanie się przekwalifikować programista WWW jak i osadzone inżynier i odwrotnie, nie są one zamienne.
Charles E. Grant,
5

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.

Michael Brown
źródło
5

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.

Thomas Owens
źródło
Podstawowe zasady mogą się znacznie różnić.
Marcin
1
@Marcin Nie, nie robią tego. Informatyka nie zmienia się, jeśli zmieniają się technologie. Matematyka się nie zmienia. Statystyki się nie zmieniają. Ani nie analizuj wymagań, projektu systemu, praktyk zarządzania konfiguracją, strategii weryfikacji i walidacji, zasad jakości ...
Thomas Owens
W rzeczywistości „analiza wymagań, projektowanie systemu, praktyki zarządzania konfiguracją, strategie weryfikacji i walidacji, zasady jakości” zmieniają się między domenami problemowymi. Jeśli tego nie zauważysz, prawdopodobnie wykonasz bardzo, bardzo słabą pracę, pracując w nieznanej domenie, ponieważ jesteś zbyt arogancki, aby zrozumieć to, czego nie wiesz. Również obowiązująca matematyka bardzo się zmienia, ale założę się, że wyobrażasz sobie, że wiesz wszystko o matematyce.
Marcin
@Marcin Pracowałem we wszystkim, od systemów wbudowanych po aplikacje internetowe. Nie zmieniają się tak bardzo. Cechy dobrego wymagania nie zmieniają się w zależności od domeny. Narzędzia użyte do zaprojektowania systemu nie ulegają zmianie. Sposób, w jaki mierzysz i osiągasz systemy wysokiej jakości, nie zmienia się.
Thomas Owens
1
Tak, masz rację, każdy projekt oprogramowania na świecie jest taki sam i wymyśliłeś, jak zarządzać każdym projektem. Prawdopodobnie powinieneś napisać książkę wyjaśniającą One True Way na pisanie i zarządzanie całym oprogramowaniem.
Marcin
4

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.

Marcin
źródło
1
konstrukcja oprogramowania na tym samym poziomie jest taka sama bez względu na oprogramowanie. Po prostu nazywamy je metodologiami zamiast linii montażowych , ale są one koncepcyjnie tym samym.
1
@JarrodRoberson Nie. Linie montażowe nie są jednolite, a metodologie nie mają ogólnie zastosowania.
Marcin
2
Zgadzam się z Marcinem, musisz mieć wiedzę o produkcie, aby stworzyć linię montażową dla produktu. Musisz być w stanie dokładnie wybrać narzędzia, które zostaną użyte, aby uzyskać prawidłowy wynik końcowy. W oprogramowaniu metodologia byłaby konkretnym narzędziem lub zadaniem. Jeśli Twoim jedynym zadaniem jest wykonanie określonego zadania, możesz nie potrzebować wiedzy o całości. Ale jesteś operatorem, a nie inżynierem. Wybór odpowiedniego zestawu metodologii, aby utworzyć linię montażową, czyni cię inżynierem, podobnie jak inne techniki. Nie jest już bardziej wyspecjalizowany ani inny.
RJay75
2

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.

Atif
źródło
1

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 #.

ozz
źródło
Myślę, że to jest pewne, ale tak naprawdę dotyczy ROI. Nie zatrudniłbym inżyniera z podstawową znajomością języka Java, jeśli chcę uzyskać projekt C ++ za drzwi w 6 miesiącach. Chociaż jeśli masz projekt Swing, który musi wyjść w ciągu 6 miesięcy, główny inżynier po stronie serwera może nadal się kwalifikować.
Spencer Kormos,
@SpencerK absolutnie się zgadza. To zależy od tego, jak szybko potrzebujesz ROI. Jeśli masz dłuższy okres oczekiwania, lepszy inżynier oprogramowania powinien „wygrać”.
ozz
Również surowy minus, jeśli to byłeś ty!
ozz
1
Nie, nie ja. Nie głosuję bez komentarza, dlaczego. Mam lepsze maniery niż to!
Spencer Kormos
1

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.

Karl Bielefeldt
źródło
2
Naprawdę? Rozumiem, że można się spodziewać, że inżynier bezpieczeństwa będzie gotowy do pisania gier za 6 miesięcy i będzie nie do odróżnienia od doświadczonego specjalisty.
Marcin
Zgadzam się z Marcinem, to nie tylko znajomość języka programowania lub platformy. Pracowałem w dwóch różnych obszarach i spędziłem kilka lat w każdym z nich: minęło trochę czasu, zanim jesteś wystarczająco znajomy, aby być naprawdę profesjonalnym i produktywnym w jednym obszarze. Oczywiście bycie doświadczonym specjalistą od oprogramowania przyspiesza, ale uważam, że 2, 3 lata, a nie 6 miesięcy.
Giorgio
1

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.

Jaydee
źródło
1

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).
Izkata
źródło
Zawsze twierdziłem, że programowanie i projektowanie oprogramowania to zarówno sztuka, jak i nauka czy inżynieria. To chyba kolejny przykład tego, jak są do siebie podobne.
Izkata,
Aha, i zanim ktoś mnie ugryzie, przez „Algorytmy” mówię o CS-y wysokiego poziomu. Kupy Fibonacciego i Timsort to dwa, które przychodzą na myśl. (Prawie nigdy nie pracuję na tym poziomie złożoności algorytmicznej, więc w ogóle niewiele wiem na ten temat)
Izkata,
0

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.

Colin D.
źródło
2
To zła analogia, mówią o inżynierii, a nie o pracownikach budowlanych, nawet jeśli łączą w sobie metafory. W tym celu oczekuje się, że wszyscy inżynierowie budujący drogi będą w stanie zbudować każdą drogę! Tak jak każdy kierowca wywrotki ciągnącej asfalt na wspomniane miejsce budowy powinien być w stanie prowadzić każdy rodzaj wywrotki.
1
@JarrodRoberson Zgadzam się, że to kiepska analogia, ale nie jestem pewien, czy twoje twierdzenie inżyniera budownictwa jest lepsze. Jasne, każdy inżynier budownictwa powinien być w stanie odczytać plany każdej drogi. Ale jeśli budujesz pas startowy lub drogę lodową, czy chcesz zatrudnić kogoś, kto spędził lata na budowie autostrad, czy też chcesz kogoś, kto ma określone doświadczenie z pasami startowymi lub lodowymi drogami?
Caleb
0

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.

Reuben Mallaby
źródło