Oczekiwania absolwentów a rzeczywistość [zamknięte]


50

Wybierając to, co chcemy studiować i robić z karierą i życiem, wszyscy mamy pewne oczekiwania co do tego, jak to będzie. Teraz, kiedy pracuję w branży od prawie dekady, zastanawiam się trochę nad tym, co myślałem (kiedy studiowałem informatykę), jak będzie wyglądało życie zawodowe w programowaniu i jak się to właściwie kończy być.

Moimi dwoma największymi wstrząsami (a raczej, mówiąc, złamanymi oczekiwaniami) są sama ilość prac konserwacyjnych związanych z oprogramowaniem oraz ogólny brak profesjonalizmu:

  1. Konserwacja : W uni wszyscy powiedziano nam, że większość prac programowych polega na konserwacji istniejących systemów. Więc wiedziałem, że mogę oczekiwać tego w sposób abstrakcyjny. Ale nigdy nie wyobrażałem sobie, jak by to było przytłaczające. Być może jest to coś, co przemknęło mi przez myśl i miałam nadzieję, że będę budować nowe fajne rzeczy od zera. Ale tak naprawdę jest tak, że większość zadań w przeważającej mierze wymaga konserwacji, naprawy błędów i wsparcia.

  2. Brak profesjonalizmu : na uniwersytecie zawsze miałem wrażenie, że oprogramowanie komercyjne jest bardzo zorientowane na proces i rygorystycznie zaprojektowane. Miałem zdjęcia procesów ISO, ryz dokumentacji technicznej, ściśle opisane wszystkie cechy i błędy oraz ogólnie profesjonalne środowisko. Ogromnym szokiem było uświadomienie sobie, że większość firm programistycznych nie działa inaczej niż zespół studentów pracujących nad dużym semestralnym projektem. Pracowałem zarówno w małym, zwinnym sklepie hakerskim, jak i średniej wielkości korporacji. Chociaż nie powiedziałbym, że zawsze było to „nieprofesjonalne”, zdecydowanie wydaje się, że branża oprogramowania (ogólnie) jest daleka od silnej dyscypliny inżynieryjnej, której się spodziewałem.

Czy ktoś jeszcze miał podobne doświadczenia? W jaki sposób Twoje oczekiwania dotyczące tego, jak wyglądałby nasz zawód, różniły się od rzeczywistości?


4
Jako student prawie z uniwersytetu jest to bardzo interesujące pytanie! Nie mogę się doczekać, aby zobaczyć odpowiedzi
Mike42

8
To, co teraz widzisz, jest rzeczywistością. Inne zabawne fakty, które również należą do rzeczywistości, to: miliardy ludzi bez jedzenia, analfabetów, pod ciągłym zagrożeniem wojną, zapaść rynku finansowego, itp. Innymi słowy, college jest wspaniałym polem zniekształcania rzeczywistości, a ludzie mogą poznaj wiele podręczników w zakresie ochrony tego pola.
rwong 18.10.10

Powinieneś oczekiwać, czego chcesz. Jeśli okaże się, że jest to coś mniejszego niż oczekiwane, nie akceptuj tego jako rzeczywistości. Bądź pionierem i spełnij swoje oczekiwania!
Atomix

1
Uwielbiam programować. Nienawidzę rzeczywistości tworzenia oprogramowania w „prawdziwym” świecie. To, co opisujesz, jest dość dokładnym opisem stanu rzeczy w branży oprogramowania.
Captain Sensible

Jako inżynier oprogramowania Fresh Jr. Również tego doświadczam, myślałem, że to tylko w moim kraju, teraz dostaję niepisaną funkcję programowania.
parman i

Odpowiedzi:


27

Czuję cię człowieku. Właśnie ukończyłem szkołę nieco ponad rok temu, skorzystałem z pierwszej oferty pracy, która pojawiła się na mojej drodze i doznałem największego szoku w moim życiu.

Czego się nie spodziewałem:

Stres w szkole i stres w pracy nie są takie same - stres związany z pracą nad projektem szkolnym z przyjaciółmi lub pracą w pojedynkę, nawet z tym zbliżającym się terminem pracy dyplomowej lub specjalną obroną projektu nie jest porównywalny do stresu wynikającego z pozornie nieuzasadnionych terminów pracy, problemów z komunikacją , (trochę polityki biurowej) i czasy kryzysu.

Brak najlepszych praktyk - tak samo jak Twoje doświadczenie w zakresie profesjonalizmu. Przed podjęciem pierwszej pracy i podczas szkolenia zacząłem przeglądać i czytać o najlepszych praktykach zarówno w programowaniu, jak i inżynierii oprogramowania. Nie są one przestrzegane tak dobrze, jak powinny, z niepraktycznych i, szczerze mówiąc, praktycznych powodów. A czasami twoja wiedza ma bardzo małe znaczenie dla innych, którzy jedynie boją się nieznanego i traktują te praktyki z pogardą.

To, czego nauczyli w szkole, było tylko wierzchołkiem góry lodowej. Myśląc, że to, czego nauczyłem się samokształcenia i na zajęciach, wystarczyło, aby mnie przejść, byłem zszokowany, mówiąc co najmniej, gdy byłem oszołomiony pierwszym fragmentem kodu, którym byłem powinien utrzymać. Wiele umiejętności, których teraz używam, nauczyłem się w pracy lub w trakcie pracy i wciąż zastanawiam się, czy nie dałbym rady w ogóle. XD

Znaczenie komunikacji - uświadomiłem sobie, do czego służą te wszystkie zajęcia z języka angielskiego. Przed prawdziwym światem nie widziałem znaczenia posiadania od trzech do czterech różnych klas języka angielskiego w college'u, gdy uczy się go, odkąd byliśmy w pierwszej klasie. Nie ma sensu w pracy, gdy można rozmawiać z komputerem, ale nie można rozmawiać z ludźmi.


5
+1 Znaczenie komunikacji. Jeśli chodzi o # 2, to nie jest brak najlepszych praktyk; to (i) zbyt wiele najlepszych praktyk oraz (ii) powszechny brak zainteresowania ich przestrzeganiem.
rwong 18.10.10

1
+1 za wierzchołek góry lodowej! Tak wielu absolwentów uważa, że ​​wiedzą wszystko, teraz czuję, że wiem mniej niż kiedykolwiek!
billy.bob 18.10.10

+1 Kilka dobrych punktów tutaj. Często przyczyną braku najlepszych praktyk / systemów / procedur są z góry „koszty” (tj. Wymagają nakładów inwestycyjnych na zakup) - ale cena za ich brak to zwiększona konserwacja lub, co gorsza, awaria produktu z powodu niekontrolowanych list błędów lub niespełniające wymagań .. których dobra komunikacja mogłaby pomóc uniknąć :-)
JBRWilkinson 18.10.10

2
Podoba mi się ta odpowiedź. Ten jest dobry. I zastanawiam się: dlaczego nie ma czegoś takiego jak „staż”, jak wszyscy lekarze muszą przejść? Długa poważna profesjonalna strefa przejściowa, w której można się zaangażować, ale nie przeszkadzać w krytycznej ścieżce jakiegokolwiek projektu. Niektóre duże firmy mogą to mieć, ale nie jest to uniwersalny standard w tym zawodzie. Jednak praca wielu programistów / programistów SW / inżynierów SW jest tak samo niebezpieczna i krytyczna dla wszelkiego rodzaju organizacji, jak to, co lekarze robią dla poszczególnych osób.
DarenW

1
Jeśli to możliwe, dałbym dodatkowe +1 za wierzchołek góry lodowej!
DarenW

18

Większość pracy, którą wykonujesz, nie jest przełomowa

W Uni pracowałem nad procedurami sztucznej inteligencji do sterowania robotami do gry w piłkę nożną, budowałem kompilatory i hakowałem jądra systemu operacyjnego.

Ale w prawdziwym świecie 99% * opracowywania oprogramowania jest dość nudne. Zawsze podziwiałem architektów lub budowniczych, którzy na pytanie „czym zarabiasz na życie?” może wskazać budynek lub cokolwiek i powiedzieć „Zrobiłem to ”. Ale większość programistów nie może tego zrobić. Na pytanie „co zarabiasz na życie?” najbliżej tego, do jakiej kiedykolwiek mogłem przyjść, było to, że pracowałem dla firmy, która tworzyła oprogramowanie przetwarzające wiadomości SMS dla stacji radiowych i tym podobne ... mógłbym powiedzieć: „wiesz, kiedy piszesz stacji radiowej, która zagłosuje na piosenkę, napisałem oprogramowanie przetwarzające te głosy i tak dalej. ” Nadal nie jest tak fajnie, jak być w stanie wskazać budynek i powiedzieć „Zbudowałem to”.

Oczywiście ludzie, którzy mogą powiedzieć „pracowałem na systemie Windows” lub cokolwiek innego, ale jestem pewien, że tak naprawdę nikomu nie mówią, że w obawie przed następnym pytaniem brzmi: „Nie mogę uruchomić drukarki, możesz to dla mnie naprawić? ”


* i 62% wszystkich statystyk jest sporządzanych na miejscu


1
to prawda, ale brak przełomu nie oznacza, że ​​nie jest to kluczowe ani ważne. Istnieje wiele aplikacji, które nie są przełomowe, które bez wsparcia i poprawek, mogą zawieść, mówiąc, że nasza gospodarka (skrajna strona ...) ... a ponadto zawsze będą wprowadzane innowacje w zależności od projektu ...
aggietech 18.10.10

3
Wielu z nas każdego dnia rozpoczyna nowe działania. Być może nie jest to lekarstwo na raka, ale świętujemy małe triumfy z piątkami dookoła, rundą ciast / babeczek / pączków itp., Aby zaznaczyć ten moment. Wiele zadań, nie tylko programowanie, nie ma danych wyjściowych, które możesz pokazać znajomym / rodzinie, ale to kwestia sformułowania: możesz powiedzieć „Konfiguruję przełączniki sieciowe, serwery DNS i zapory ogniowe” lub możesz ponownie sformułować to jako „Znasz internet - Facebook, YouTube, Twitter i tak dalej? Pomagam, żeby działał”.
JBRWilkinson

1
@JBRWilkinson: +1. Najlepszy przypadek „ponownego kadrowania”, jaki miałem, to moja poprzednia praca, w której pracowałem przy oprogramowaniu dźwiękowym szpitala NurseCall. Można powiedzieć o tym coś ogólnego: „Napisałem programy uruchamiające sygnały dźwiękowe”. OTOH, możesz także powiedzieć „Napisałem oprogramowanie, które pomogło szpitalom działać lepiej i prawdopodobnie uratowałem życie !!”. Do tej pory o tym nie myślałem ... ale statystycznie to prawdopodobnie prawda. Teraz czuję się znacznie lepiej w tej pracy. to znaczy, że moje oprogramowanie weszło wcześniej do produkcji itp. Może naprawdę uratowało życie. :)
Tabele Bobby

1
@Guzica: To, że możesz / przyczyniasz się do ratowania życia na co dzień, jest prawdopodobnie najlepszą satysfakcją z pracy, jaką może mieć każdy - dobra robota!
JBRWilkinson

1
Haha, doskonała odpowiedź i +1 za poczucie humoru!
Captain Sensible

17

Jeśli spojrzysz na oprogramowanie dzisiaj, z perspektywy historii inżynierii, z pewnością jest to swego rodzaju inżynieria - ale jest to rodzaj inżynierii, którą zrobili ludzie bez koncepcji łuku. Większość dzisiejszego oprogramowania przypomina egipską piramidę z milionami cegieł ułożonych jeden na drugim, bez strukturalnej integralności, ale zrobionymi przez brutalną siłę i tysiące niewolników. -Alan Kay, 2004

pełny wywiad: http://queue.acm.org/detail.cfm?id=1039523

Nie jestem weterynarzem branżowym; Wręcz przeciwnie, jestem niedawnym absolwentem, ale z czołowej szkoły CS w USA. Ale instynktownie mam wrażenie, że sposób, w jaki tworzymy oprogramowanie, jest zły. Zamiast naciskać przycisk pauzy i ponownie analizować podstawy tego, jak programujemy, pospieszyliśmy naprzód, używając przestarzałych modeli z lat 50. i 60. ciągle dodając trochę cukru na wierzchu. Jeśli będziemy tak postępować, nigdy nie przejdziemy tam, gdzie jesteśmy. Ludzie po prostu nie są w stanie poradzić sobie ze złożonością rzeczy wielkości bazy kodu MS Windows. Potrzebujemy nowego sposobu. Nie wiem co to jest.

Myślę, że to jest podstawowa przyczyna przekonania, że ​​duże i małe sklepy z oprogramowaniem wydają się tworzyć oprogramowanie poprzez zhakowanie go razem bez głębokiego zrozumienia podstawowych zasad.


Jako stosunkowo nowy absolwent mam wrażenie, że sposób, w jaki wiele miejsc robi oprogramowanie, jest zły, ale moje obecne miejsce pracy nie jest ... idealne, ale próbują i działa znacznie lepiej . Z pewnością wydaje się, że istnieje całkiem sporo miejsc, które przyjmują okropne podejście „brutalnej siły” ... ale jeśli jesteś w jednym z tych miejsc, zastanów się, czy nie szukać czegoś innego.

1
Rozwój oprogramowania jako całości jest procesem ewolucyjnym, a nie rewolucyjnym. Oczywiście, możesz zbudować strukturę piramidy z nanorurek węglowych w teorii, która jest mocniejsza, trwalsza i lżejsza niż piramidy egipskie w teorii. Ale nie jest to ani praktyczne, ani wykonalne. Jeśli miejsce, w którym pracujesz, jest naprawdę złe, znajdź nową pracę. W przeciwnym razie nie daj się zbytnio wciągnąć w perfekcję, ponieważ prawdziwe zadania programistyczne mają prawdziwe ograniczenia (takie jak czas / finansowanie). Pamiętaj, że „w teorii teoria i praktyka są takie same. W praktyce nie są”.
Evan Plaice,

>>> Potrzebujemy nowego sposobu. Nie wiem co to jest. - Nikt też nie, dlatego trwa!
Gary Willoughby

5

Nie dostałem dyplomu, ale trochę podniosłem w bibliotekach i laboratoriach uniwersyteckich.

  • Big Iron - Technologie, których nauczali, to przede wszystkim komputery mainframe i minikomputery. Dziekan jednego z college'ów powiedział mi, że nie będę w stanie znaleźć pracy, bo nawet nie wiedziałem, co to jest masterfile. Nie miałem zamiaru pracować na komputerach mainframe, ponieważ nie było mnie stać, ale nie zamierzałem być tak głupi, żeby nie być lekko przygotowany. VAXen były fajne i nie mogłem się doczekać, aż dostanę wynagrodzenie za kodowanie na własnym Micro VAX w mojej szafie. Jaka szkoda, że ​​ten rynek całkowicie się rozsypał. (Jak się okazało, miałem dwie pozycje związane z komputerami mainframe… jako wykonawca dla IBM.)

  • Inżynieria oprogramowania - w ślad za programowaniem strukturalnym, SASD i innymi metodami projektowania, moglibyście pomyśleć, że będziemy prawdziwymi inżynierami. Zrobiłem. Ale nauczyciele udzielali bardzo mało wskazówek na temat technik projektowania, które czytałem w bibliotece. Studenci zostali zmuszeni do samodzielnej walki, a mikroskopy sprawiły, że zbyt łatwo było sflashować kod, dopóki nie otrzymali odpowiedzi, z której byli zadowoleni. Nie zdawałem sobie sprawy, jak gorzej było na rynku pracy. Jakoś musiałem napisać całkiem sporo nowego kodu, więc nie było tak nudno. Ale też dużo przejęłam i były wystarczająco złe, to było jak nowy projekt, ponieważ musiałem naprawić dużo kodu. Było to połączenie badania istniejącej funkcjonalności i stworzenia nowego kodu (jego zastąpienia); narzędzia do pisania w celu uproszczenia procesu i ustanowienia lepszego zarządzania projektami.

  • Zaawansowana kariera - to jedno, gdy szkoły mają stare budynki i wyposażenie (wyposażenie w karty dziurkacza zostało zastąpione semestrem, zanim zacząłem… w 1984 roku), ale kiedy pracujesz w słabo oświetlonym magazynie lub dla szefa, który się rozłącza kiedy klienci dzwonią na linię wsparcia, zaczynasz zdawać sobie sprawę z tego, że opis pracy prawdopodobnie nie obejmuje gotowania popcornu za pomocą 5-megawatowego lasera.


5
  • Rozwój polega głównie na pracy zespołowej. Oznacza to, że komunikacja (mówiona i czytana), czytanie kodu innych osób i ponowne wykorzystywanie poprzednich modułów (zarówno wewnętrznych, jak i zewnętrznych) jest czymś, z czym można się spotkać prawie codziennie. Na studiach przynajmniej w kilku przypadkach musiałem kodować z większą liczbą osób, więc pomyślałem, że główną częścią pracy było kodowanie samemu na pustyni. Nie jest.
  • Wyjaśnianie rzeczy osobom, które nie są programistami, jest trudne (dotyczy to również pierwszego punktu) i Twoim obowiązkiem jest zdobycie punktów (nie z innych 99% świata).
  • Dobry test to test, który się nie udaje. (przynajmniej za pierwszym razem) I oczywiście nie ma czegoś takiego jak kod wolny od błędów. Nie jesteś złym programistą, jeśli masz błędy. Błędy są tylko (bardzo ważną i czasochłonną) częścią twojej pracy.
  • Nie ma srebrnych kul. Każda technologia ma swoje zalety i wady.
  • College nie uczy Cię najnowszych technologii. Ale również 90% prac wykorzystuje całkiem stare technologie. Co, nawiasem mówiąc, czasami jest potrzebne.
  • Osoby nietechniczne podejmują decyzje dotyczące rozwiązań technicznych , głównie z powodów ezoterycznych, takich jak utrzymanie, partnerstwo, dostępność pracownika ...
  • Właśnie zaczynasz , młody padawanie .

Od tego czasu zacząłem zdawać sobie sprawę z tego, że kodowanie to praca, którą wykonujesz w połączeniu z większą liczbą ludzi, szczególnie teraz, gdy otwarte oprogramowanie jest bardziej widoczne. Ale kiedy byłem na studiach (pod koniec lat dziewięćdziesiątych), byłem przekonany, że będę robił rzeczy od zera i nigdy nie zajrzę do kodu innych osób ani nie będę musiał koordynować z innymi ...

Patrząc wstecz, dla mnie jedną z najlepszych części jest uczenie się i nauczanie innych .


„College nie uczy najnowszych technologii.”: Tak i nie. W niektórych dziedzinach środowisko akademickie wyprzedza przemysł o 20-30 lat, a niektórych można się nauczyć na studiach.
Giorgio

3
  • Programowanie komputerowe jest niefizyczne i nieintuicyjne.
    • Kiedy budowniczy domu zakończy pracę, może przejść się i od razu zobaczyć / poczuć, czy coś jest nie tak. Błąd programowania komputera nie może zostać wykryty w ten sam sposób i może czaić się w systemie przez miesiące, a nawet dekady.
    • Podczas gdy programista może przeglądać / wyczuwać fragment kodu źródłowego poprzez przegląd kodu, nie ma gwarancji wykrycia każdego błędu zawartego w kodzie. Komputer byłby jednak w stanie dokładnie odtworzyć błąd za każdym razem, wykonując program z określonymi danymi wejściowymi. Zatem ludzkie rozumienie fragmentu kodu źródłowego jest zawsze niedoskonałym modelem esencji tego, że jest instrukcją dla komputera.
  • Kodowanie programu, który obsługuje najczęstsze przypadki, jest bardzo łatwe, ale całkowicie nie obsługuje przypadków skrajnych.
    • W innych dyscyplinach stosunkowo łatwo jest zastosować działanie naprawcze po fakcie. Może nawet istnieć zasób wiedzy poświęcony działaniom naprawczym. W tworzeniu oprogramowania nie ma czegoś takiego.
    • Na szczęście rozwój oparty na testach pomaga kodyfikować przypadki brzegowe, które ma obsługiwać kod.
    • Dodane Z drugiej strony niektóre metody opracowywania oprogramowania wydają się sugerować, że możemy wydobyć wartość biznesową (szybszy czas wprowadzenia produktu na rynek itp.), Świadomie decydując się nie zajmować przypadkowymi przypadkami i przekazać te decyzje klientom.
  • Klienci mogą znaleźć wartości biznesowe w oprogramowaniu, które obsługuje tylko najczęstsze przypadki, dlatego dostawcy oprogramowania nie przejmują się zbytnio rzadkimi przypadkami.
    • Klienci po prostu uczą się unikać szorstkich krawędzi.

Dodany

  • Elegancja kodu źródłowego nie jest ceniona.
    • Klienci nie widzą elegancji kodu źródłowego. Widzą tylko elegancję interfejsu użytkownika i interakcji.
    • Z drugiej strony programiści zwykle nie cenią elegancji interfejsu użytkownika i zwykle nie pozostają w jednym projekcie przez wystarczająco długi czas, aby zacząć doceniać elegancki projekt oprogramowania.
    • Ponieważ ani klienci, ani programiści nie cenią elegancji kodu źródłowego, nie będą one również cenione przez firmy.

Dodany

Moje dwa centy: przyzwyczaj się do tego.


8
budowanie domu w porównaniu do naprawiania błędów, hmm? „Hej, właśnie przekręciłem klamkę w niewłaściwym kierunku, a dom po prostu zniknął!”
xor_eq

3

Obrazy procesów ISO, ryz dokumentacji technicznej, wszystkie cechy i błędy są ściśle dokumentowane, a ogólnie profesjonalne środowisko dość dobrze opisuje moją firmę. Zajmujemy się jednak tworzeniem oprogramowania / sprzętu o krytycznej infrastrukturze, więc cóż, presja jest na jakość (na przykład mamy certyfikat ISO 9001).


1
@Guzica: Jedna z firm, w których pracowałem, była dość zorientowana inżynieryjnie. Brak certyfikatu ISO9001, ale dość formalne przestrzeganie dość rygorystycznych procesów wewnętrznych. Pozostali byli, cóż, jak powiedziano - nie bardziej zorganizowani niż grupa studentów CS realizujących wspólnie projekt z ostatniego roku.
Tabele Bobby

2

Po ukończeniu studiów pomyślałem, że osoby odpowiedzialne będą w stanie rozpoznać dobrą pracę po złej pracy. Po wręczeniu milionowej kopii „naprawdę świetnego kodu nasz najlepszy programista zmontował” i wyglądał tak:

def lf(p, q, r):
    x = 4
    xx = 4.5
    t = {1:p, 2:p+2, 3:p*4} #I think there's a bug in here but I don't know
    .
    .
    .

Prawie zrezygnowałem z próby zrozumienia, co dzieje się między uszami spiczastego włosa szefa. „Wielki” oznacza koszmar utrzymania, „dobry” oznacza awarie w łagodnym wietrze, a „okropny bałagan” oznacza albo dobrze skonstruowaną bazę kodu, której inżynierowie najwyraźniej odmówili przestrzegania nieprzyzwoitych terminów tylko po to, by zachować zdrowie psychiczne.


1

Słyszałem, jak argumentuje, że cała inżynieria oprogramowania po pierwszym wierszu kodu to utrzymanie. I to z pewnością wydaje się pasować do moich doświadczeń. Jedynym kodem, który napisałem, a który nie kosztował większości utrzymania, był kod, który był tak nieudany, że nigdy nie był używany lub tylko na krótko.

Myślę, że można znaleźć zespoły inżynierów, którzy opracowują i postępują zgodnie z silnymi procesami, które prowadzą do wydania solidnego kodu, w który zespół może mieć wysoki poziom zaufania (chociaż nie zawiłbym tego przy dużej ilości dokumentacji). Uważam, że obecnie pracuję w takim zespole. Chociaż z pewnością doświadczyłem innego rodzaju rozwoju.

Doceniam jednak to, że wyzwaniem nie zawsze jest znalezienie idealnego algorytmu lub najczystszego rozwiązania problemu. Ale często wymienia się wszelkiego rodzaju ograniczenia (zasoby, wiedza, pieniądze, czas, umiejętności, ryzyko, wcześniej istniejące szkolenia użytkowników itp.), Aby osiągnąć najwyższy zwrot z dostępnej inwestycji. To buduje system, który najlepiej pasuje do wszystkich tych czynników, a nie tylko wpływów technicznych.


Bardzo dobre punkty. Dwa średnie / duże przedsiębiorstwa, w których pracowałem, wykazały wyraźny kontrast między tymi dwoma przypadkami. Jeden był silnie zorientowany inżynieryjnie, a drugi działa bardziej jak grupa zespołów studentów CompSci wykonujących osobne projekty z ostatniego roku we własnych bańkach - a potem jakoś musi to później zintegrować. (Uwaga: Zarząd faktycznie obsługuje te „bańki” - tak naprawdę nazywa się - myśląc, że zespołom jest bardziej wydajnie pracować osobno niż martwić się integracją podczas programowania. Nie żartuję.)
Tabele Bobby'ego

1

Wiele programów po prostu nie wystarcza do tego, aby się wystarczająco wykorzystać / kupić. Kiedy się go robi, ma tendencję do pozostawania w pobliżu i jest „zawalony” podczas konserwacji.

Oczekiwania użytkowników rosną każdego dnia w stosunku do funkcji, ale w wielu obszarach są niższe w obszarach inżynierii. Załóżmy, że oprogramowanie do transakcji bankowych jest tak solidne i profesjonalnie zaprojektowane jak nowoczesny samochód. Obsługa wolumenu jest nowoczesnym cudem, ale co nad niezawodnością każdej transakcji? Nie tak bardzo. Twój post o pierwszym gównie szczeniaka na dywanie został odrzucony, więc co. To bardziej jak małe plastikowe torby w sklepie spożywczym. Robią ich miliardy, rozdzierają i łzą i zostają wyrzuceni. Większość ludzi nie dba o to, aby wymagać lepszej torby.

Myślę, że w końcu powstaje oprogramowanie wysokiej jakości. Niektóre z nich trafiają na rynek wcześniej niż większość komercyjnych produktów. Kto może prowadzić samochód w wersji beta?

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.