Czy moje negatywne doświadczenia z praktyk reprezentują rzeczywisty świat? [Zamknięte]

85

Jestem ciekawy, czy moje obecne doświadczenia jako stażysty są reprezentatywne dla rzeczywistej branży.

Jako tło przeszedłem przez większą część dwóch kierunków komputerowych i matematyki na dużym uniwersytecie; Pokonałem wszystkie klasy i uwielbiałem wszystkie, więc chciałbym myśleć, że nie jestem okropny w programowaniu. Otrzymałem staż w jednej z największych firm programistycznych i w połowie byłem zszokowany wyjątkowo niską jakością kodu. Komentarze nie istnieją, to wszystko kod spaghetti, a wszystko, co może być złe, jest jeszcze gorsze. Zrobiłem mnóstwo korepetycji / TAing, więc jestem bardzo przyzwyczajony do czytania złego kodu, ale najważniejsze produkty branżowe, które widziałem, przebiły to wszystko. Pracuję 10-12 godzin dziennie i nigdy nie czuję, że nigdzie się dostaję, ponieważ „ niekończące się godziny prób znalezienia nieudokumentowanego API lub ustalenia zachowania jakiejś innej części (całkowicie nieudokumentowanego) produktu. Do tej pory codziennie nienawidziłem pracy i desperacko chcę wiedzieć, czy to właśnie czeka mnie do końca życia.

Czy zwróciłem uwagę na staże (absurdalnie duże wypłaty sugerują, że nie jest to pozycja niskiej jakości), czy też taki jest prawdziwy świat?

próbaAnonimowość
źródło
22
Częściej niż powinno być. Wiele miejsc jest po prostu zupełnie nieświadomych robienia czegoś dobrze.
Wayne Molina
35
to, co postrzegasz jako negatywne, jest w rzeczywistości pozytywne, lepiej jest uzyskać doświadczenie w prawdziwym świecie wcześniej niż później, a to, czego doświadczasz, jest bardziej realnym światem niż twoje doświadczenie akademickie według rzędów wielkości.
69
Pamiętaj, że programiści nienawidzą kodu innego programisty. Szanse, że ludzie, którzy później pracują nad kodem, który napisałeś, powie to samo. Wiem, że uważasz, że jesteś dobrym programistą, i być może, ale szanse są dość duże, że każdy, kto napisał kod, na który patrzysz, również tak uważał. Ale nie, nie zawsze jest tak źle, jak to opisujesz. Być może po części nie w pełni nauczyłeś się poprawnie czytać i oceniać kod świata rzeczywistego, a gdy już to zrobisz, będzie on wydawał się nieco lepszy.
psr
22
Jeśli kod, który widziałeś na uniwersytecie, nie był niskiej jakości kodem spaghetti, twoje doświadczenie było inne niż moje ... Zbyt często kod w projektach akademickich wychodzi jako dowód koncepcji, bez względu na łatwość konserwacji.
Michael Borgwardt
10
@psr: Nie zgadzam się, że programiści nienawidzą ogólnie kodu innych programistów. Jeśli masz jakieś parametry jakościowe, takie jak czytelność, dobra dokumentacja, prostota itp., Możesz je docenić nawet w czyimś kodzie, nawet jeśli ich styl kodowania jest inny niż twój. Z drugiej strony, jeśli widzisz złożony, chaotyczny, improwizowany kod, nie lubisz go jako takiego, nie dlatego, że jest to kod innej osoby. BTW, nienawidzę również własnego kodu, gdy jestem zmuszony pisać coś w pośpiechu, a wynik nie spełnia moich standardów jakości.
Giorgio

Odpowiedzi:

128

Nie bez powodu nazywają to Real World ™.

99% tego, co napotkasz w prawdziwym świecie korporacyjnym, będzie uważane za gówno i nie bez powodu to wyjaśnię. 1%, który nie jest uważany za badziewia, w końcu stanie się badziewiem.

# 1 Napisz kod, # 2 ????, # 3 Zysk!

Po pierwsze, istnieją firmy, które przynoszą zysk, nie istnieją, aby generować góry o idealnie teoretycznie czystym, zaprojektowanym i nieskazitelnym kodeksie akademickim, mieszczącym się w złotych repozytoriach doskonałości. Nawet blisko, nawet tych zajmujących się sprzedażą kodu źródłowego, który produkują.

W świecie biznesu kod jest środkiem do celu . Jeśli jakiś kod rozwiązuje problem biznesowy i zarabia więcej niż kosztuje jego utworzenie i utrzymanie, jest to pożądane dla firmy. Zatrudnianie Ciebie do pisania kodu to tylko jeden ze sposobów uzyskania kodu przez firmę.

Teoria 0 - Ćwicz ∞

Idealna konserwacja powinna być większym problemem, ale zwykle nie jest, ponieważ w krótkim okresie nie wygrywa finansowo. W dłuższej perspektywie oprogramowanie zwykle ma stosunkowo krótki cykl życia, zwłaszcza aplikacje internetowe, szybko się dezaktualizują i częściej zapisują.

Wewnętrzne aplikacje biznesowe to te, które są postrzegane jako niekończące się projekty zombie z wielu powodów opartych na pędu. Projekty te są w rzeczywistości sukcesami, które kontynuują, ponieważ nadal przynoszą firmie zysk.

Teoretycznie nie ma różnicy między teorią a praktyką. W praktyce jest. - Yogi Berra

Teoretycznie idealnie zaprojektowane absolutnie czyste, nieskazitelne bazy kodu ze 100% pokryciem kodu powinny zaoszczędzić pieniądze firmom, w praktyce nie jest nawet bliskie dostarczenia rzeczy zbliżonej do prawidłowego zwrotu z inwestycji.

Fizyka cyklu życia oprogramowania

W świecie oprogramowania działa również bardzo potężna siła entropii. Jest to czarna dziura nieuchronności, która skazuje wszystkie programy na degenerację w Wielką Kulę Błota .

Im dalej zaczniesz od BBM, tym lepiej, ale każdy system oprogramowania w końcu się tam dostanie, mając wystarczająco dużo czasu. To, jak szybko zbliżysz się do 100% entropii, zależy od tego, od czego zaczynasz i jak szybko nakładasz zadłużenie techniczne oraz jak wysokie są na nim odsetki.

Systemy oprogramowania degenerują się i gniją z powodu konserwacji, a nie z powodu jej braku. System działający od lat bez zmian kodu z definicji spełnia wszystkie jego wymagania i cele i odnosi sukces.

To systemy wymagają ciągłej zmiany, ponieważ zaczęły się bliżej maksymalnej entropii, są to systemy, które są ciągle szturchane i szturchane, a konserwacja przyspiesza negatywną zmianę.

Good Enough to Good Enough

Systemy z krótkim cyklem życia, takie jak strony internetowe, które ciągle się zmieniają, nie korzystają z drogiego, dużego projektu z góry 100% pokrycia kodu w testach jednostkowych, ponieważ czas amortyzacji jest zbyt krótki, aby odzyskać koszty.

Systemy o długim cyklu życia, takie jak wspomniana wyżej wewnętrzna linia aplikacji biznesowych, również nie korzystają z ogromnych inwestycji w 100% testy jednostek pokrycia kodu, ponieważ tempo zmian w trakcie trwania projektu zbliża się do stałej bliskiej zeru w moda nieliniowa.

Dlatego plany wycofania z eksploatacji są ważniejsze, a systemy zastępcze powinny być planowane tak, jak coś jest wypuszczane na rynek, a nie po tym, jak minęło kilka lat i jest nieobsługiwane, więc nowy system musi zostać wdrożony.

O ile mi wiadomo, nie uczą o BBM, nigdy nie spotkałem niedawnego absolwenta CS, który wiedziałby, co to jest, a tym bardziej dlaczego tak się dzieje.

Właśnie dlatego Good Enough jest Good Enough , nic więcej nie jest.

Oprogramowanie Slumlords

Nie bez powodu są lordowie slumsów, którzy czerpią zyski z zaniedbanych szantowych budynków. Zarób więcej niż wydają na stopniowe utrzymanie zaniedbanej nieruchomości. Jeśli tego nie zrobią, zburzą budynek i zastąpią go. Ale nie robią tego, ponieważ koszty przyrostowe są znacznie mniejsze niż remont lub wymiana całego budynku. Są też klienci (najemcy), którzy są skłonni zapłacić za zaniedbaną nieruchomość.

Żaden właściciel budynku, pan slumsów, czy nie, nie wyda pieniędzy na nieruchomość tylko z powodu akademickiego pojęcia doskonałości, która nie przekłada się na znaczny zysk w stosunku do związanych z tym kosztów.

Żaden klient nie zapłaci za uaktualnienia systemu oprogramowania, który działa dla niego akceptowalnie. Żadna firma nie wyda pieniędzy na samo pisanie i ponowne pisanie kodu, bez żadnego wymiernego znacznego zysku.

Microsoft jest najbardziej dominującym i odnoszącym sukcesy lenistwem oprogramowania. System Windows zaczął otrzymywać podstawowe podstawowe zapisy dopiero od niedawna. I nadal nie usunęli całego starszego kodu z jądra. Nie ma to dla nich sensu biznesowego, ludzie są bardziej niż gotowi zaakceptować niski poziom oczekiwań, jaki postawili w ciągu ostatniej dekady.

Rokowanie

Jest to wzór od ponad 20 lat, gdy zajmuję się programowaniem. To się wkrótce nie zmieni. To nie tak ludzie chcą, żeby wyszedł z jakiegoś systemu wierzeń, to rzeczywistość sił zewnętrznych działających na biznes. Biznes napędza podejmowanie decyzji, zyski nie są złe, płacą twoją pensję, krótkoterminowa lub długoterminowa wizja jest nieistotna, jest to branża krótkoterminowa z ciągłą zmianą z definicji. Każdy, kto spiera się na tyle dobrze, by osiągnąć zysk , nie rozumie biznesu.

Spędziłem 15 lat na konsultacjach i bardzo szybko nauczyłem się, że wystarczy, że wszystko inne kosztuje mnie pieniądze. Tak, chciałem, żeby wszystko było idealnie, ale jeśli nie sprzedajesz bazy kodu, co stanowi 99,99999% czasu, gdy sprzedajesz rozwiązanie , cały ten prefekt czysty, uporządkowany elegancki kod jest tracony i po prostu tracisz czas, za który nigdy nie otrzymasz zwrotu .

Postęp i nadzieja

Metodologie zwinne są dobrym krokiem we właściwym kierunku, przynajmniej filozoficznie. Zajmują się chaosem i ciągłymi zmianami jako obywatele pierwszej klasy i akceptują to. Odrzucają praktyki dogmatyczne, uznając, że metodologie i praktyki powinny ulec zmianie, a także wymagania i technologie.

Akceptują entropię, którą wprowadza brak czasu lub zmieniające się wymagania, zmieniający się personel i żywotność oprogramowania z koncepcją długu technicznego.

Ale Agile nie jest panaceum, nie zmieni podstawowych praw fizyki, a podstawy kodu będą gnić niezależnie od tego. Od zarządu zależy, czy poradzisz sobie ze zgnilizną, zanim całkowicie wymknie się ona spod kontroli i stanie się niemożliwe do opanowania.

Zwinne, gdy wykonane poprawnie, pomaga zarządzać entropią, spowalnia ją, śledzi, mierzy i radzi sobie z nią w zaplanowany sposób. To nie zatrzyma!

Decyzja o karierze

Jeśli jest to dla ciebie prawdziwy problem filozoficzny, prawdopodobnie powinieneś rozważyć inne wybory zawodowe, ponieważ sposób, w jaki działa praca, ma uzasadnioną wartość biznesową. Projekty Open Source nie mają lepszych osiągnięć, aw wielu przypadkach kod jest nawet gorszy niż większość kodu firmowego, jaki widziałem.

7519
źródło
2
Nie mam z tym filozoficznych problemów, frustracja nie była możliwa. Ale to zdecydowanie ma sens; wiele kodu, z którym mam do czynienia, ma prawie 20 lat i 3 poziomy interoperacyjności ...
próbaAnonimowość
8
„nie istnieją, aby generować góry idealnie teoretycznie czystego i nieskazitelnego kodu akademickiego mieszczącego się w złotych repozytoriach doskonałości.”: Ale nie zdają sobie sprawy, ile pieniędzy zaoszczędziliby, gdyby dali programistom więcej czasu na oczyszczenie kodu, więc że później nie muszą spędzać tygodni na szukaniu błędu lub przepisywaniu kodu, którego nikt już nie rozumie. Myślę, że to krótkoterminowe myślenie wielu firm zmniejsza ich zyski w perspektywie długoterminowej. Ale to IMO jest oznaką złego zarządzania.
Giorgio
22
Co zabawne, wydaje się, że firma, dla której pracuję , uzyskuje zwrot z inwestycji dzięki bardzo dużemu pokryciu kodu, rygorystycznemu sprawdzaniu kodu, codziennym 30-minutowym sesjom projektowym itp. Na początku programowanie może trwać nieco wolniej, ale zwraca się dziesięciokrotnie późniejsze etapy, w których baza kodu inaczej stałaby się niewygodna.
Max.
4
Widziałem dość niepowodzenia projektu, by nie wiedzieć, że odpowiedź jest nieprawidłowa. Opisujesz, w co wierzy większość ludzi w branży. Wiara nie jest dobrą jakością w świecie inżynierii, zwłaszcza gdy nauka już dawno udowodniła, że ​​takie przekonanie jest błędne.
deadalnix
27
-1 Chociaż niektóre punkty są prawidłowe, jest wiele błędów. Np. Rzeczą „idealnie zaprojektowanego czysto teoretycznie” jest klarowny mężczyzna; Planowanie przepisywania zamiast refaktoryzacji nie jest dobrym pomysłem, a nawet wielu w branży to rozumie. A podstawy kodu nie gniją nieuchronnie, gniją z powodu braku konserwacji.
sleske
44

Jestem ciekawy, czy moje obecne doświadczenia jako stażysty są reprezentatywne dla rzeczywistej branży.

Nie, nie jest. Jest reprezentatywny dla twojego poziomu kariery i doświadczenia. To część uczenia się o tym, jak działają firmy z perspektywy wewnętrznej kontroli jakości.

Jako tło przeszedłem przez większą część dwóch kierunków komputerowych i matematyki na dużym uniwersytecie; Pokonałem wszystkie klasy i uwielbiałem wszystkie, więc chciałbym myśleć, że nie jestem okropny w programowaniu. Otrzymałem staż w jednej z największych firm programistycznych i w połowie byłem zszokowany wyjątkowo niską jakością kodu.

Twoje umiejętności, doświadczenie, wykształcenie nie mają wpływu na jakość pracy wykonywanej przez innych. Po prostu dlatego, że nie masz uprawnień do zmiany tych praktyk. Nie ma znaczenia, czy byłeś dobry czy zły na uniwersytecie. Nie zmienia to sposobu, w jaki obecnie działa firma, dla której pracujesz. Chociaż jest świetnie, masz całe to tło. To naprawdę dla własnej korzyści, a nie dla nich. Dlatego ważne jest, aby studiować to, co kochasz.

Otrzymałem staż w jednej z największych firm programistycznych i w połowie byłem zszokowany wyjątkowo niską jakością kodu. Komentarze nie istnieją, to wszystko kod spaghetti, a wszystko, co może być złe, jest jeszcze gorsze. Zrobiłem mnóstwo korepetycji / TAing, więc jestem bardzo przyzwyczajony do czytania złego kodu, ale najważniejsze produkty branżowe, które widziałem, przebiły to wszystko.

Nauczyłem się podczas wielu lat programowania, że ​​istnieje różnica między „jakością kodu” a „akceptowalnym kodem”. Prawda jest taka, że ​​albo ktoś z autorytetem znajdzie kod źródłowy w akceptowalnym stanie, albo uzna go za niedopuszczalny, ale konieczny. Chociaż byłoby miło, gdybyśmy wszyscy mogli posprzątać projekty, w które się angażujemy. Często przeznaczanie zasobów na wykonywanie tej pracy nie leży w interesie firmy ani w budżecie. Można argumentować logicznie, dopóki następnego dnia nie wstanie słońce, dlaczego warto to naprawić, ale kiedy kierownictwo zdecyduje, że obecny stan jest „akceptowalny”, niewiele można zrobić. Wszystko to jest bezpośrednio związane z tym, kto prowadzi rzeczy. Albo cenią sobie dobrą jakość wewnętrzną, albo nie. Wyraźnie to cenisz i dlatego niepokoi Cię ten obecny stan.

Przykłady tego typu problemów znajdziesz w każdej branży zależnej od wewnętrznej kontroli jakości. Począwszy od rozwoju oprogramowania po produkcję. Musisz nauczyć się postrzegać to nie jako problem, ale po prostu jako obecny stan ich kodu źródłowego. Tak to jest, potrzeba X liczby minut, aby znaleźć coś, zajmuje X liczby minut, aby coś naprawić.

Firma albo nie przejmuje się tym dodatkowym czasem, albo uważa, że ​​jest to do przyjęcia.

Pracuję 10-12 godzin dziennie i nigdy nie czuję, że nigdzie się nie dostaję, ponieważ to niekończące się godziny próbowania znalezienia nieudokumentowanego API lub określenia zachowania jakiejś innej części (całkowicie nieudokumentowanego) produktu. Do tej pory codziennie nienawidziłem pracy i desperacko chcę wiedzieć, czy to właśnie czeka mnie do końca życia.

Dlaczego można było spędzać długie godziny na studiach, ale teraz nie jest dopuszczalne, aby studiować kod źródłowy? Jestem pewien, że powodem, dla którego pracodawca cię zatrudnił, było przekonanie, że możesz sobie z tym poradzić.

Pozwól, że dam ci radę. Dobrzy programiści wiedzą, kiedy poprosić o pomoc swoich towarzyszy. Nie myśl, że odpowiedzi są zawsze w kodzie. Zaoszczędziłem godziny czasu, po prostu zadając ludziom kilka pytań. Wygląda na to, że potrzebujesz szybkiej pomocy.

Po drugie, nie znamy warunków pracy. Długie godziny pracy są faktem w wielu branżach. Musisz rozwiązać samodzielnie, ale mogę ci powiedzieć. Nienawiść do pracy nigdy nie jest dobrym znakiem. Powinieneś sobie poradzić z tym uczuciem i dotrzeć do jego źródła. Przykro mi, że uważasz to doświadczenie za negatywne.

Czy zwróciłem uwagę na staże (absurdalnie duże wypłaty sugerują, że nie jest to pozycja niskiej jakości), czy też taki jest prawdziwy świat?

W szkole radziłeś sobie bardzo dobrze, ale teraz masz staż i nie radzisz sobie tak dobrze. Wygląda na to, że jesteś już w prawdziwym świecie. To część życia. Pytanie brzmi: co zamierzasz z tym zrobić? Że mój przyjaciel jest jedyną rzeczą, która ma znaczenie. Nie możemy ci powiedzieć, co masz robić. Musisz podjąć decyzję.

Mogę powiedzieć, że brzmi to tak, jakby twoje doświadczenia w twoim wieku były znacznie lepsze niż wszelkie możliwości, jakie miałem. Życie dla mnie w latach 90. było walką o zapłacenie czynszu i znalezienie mojej kolejnej umowy. Uważaj się za szczęściarza.

Reactgular
źródło
3
Dziękujemy za wgląd! Wybacz mi, jeśli zabrzmiałem chrapliwie lub pretensjonalnie, doskonale zdaję sobie sprawę, że miałem szczęście i wciąż muszę się wiele nauczyć. I chyba dobrze sobie radzę (prawdopodobnie dostaję ofertę w pełnym wymiarze godzin), po prostu nie wiedziałem, czy to doświadczenie powinno mnie przekonać, by szukać gdzie indziej. Doceniam zrozumienie branży bardziej!
próbaAnonimowość
9
Jak powiedział mi mój ojciec, kiedy zaczynałem. „Nigdy nie przestajesz szukać gdzie indziej”. Zawsze powinieneś być w sieci z innymi ludźmi z branży. Zawsze aktualizuj swoje CV i zawsze ucz się nowych języków programowania. Żyj swoim życiem, jakbyś był bezrobotny i zawsze będziesz dobrze zatrudniony.
Reactgular
Nie widzę siebie, że nie uczę się ciągle, biorąc pod uwagę, jak bardzo mi się to teraz podoba. Cieszę się, że to powinno mi pomóc!
próbaAnonimowość
5
+1 za „Dobrzy programiści wiedzą, kiedy poprosić o pomoc swoich obserwujących członków drużyny”. Pracuję w małej firmie i mam tylko jednego kolegę z zespołu, który jest dla mnie młodszy w programowaniu, ale często ma jasność w kwestii, w której utknąłem. ZAPYTAĆ!
TecBrat
2
@Jodrell zmieniający „działający” kod to ogromne ryzyko, „sprzątanie” to zmiana z dobrymi intencjami, ale droga do piekła jest wybrukowana dobrymi intencjami. Niewielu właścicieli / kierowników projektów zgodziłoby się na zmiany tylko ze względu na zmiany, zbyt duże ryzyko.
25

Po 25 latach i różnych firmach i branżach mogę powiedzieć:
Tak, to dość powszechne.
To dlatego inżynierowie są zwykle wynagradzani dość dobrze, muszą być dobrzy w radzeniu sobie z bałaganiarskimi podge i wciąż być w stanie wprowadzać zmiany, opierając się jednocześnie palącemu pragnieniu przeforsowania całej tej cholernej rzeczy i dowiedzenia się, co to do cholery powinno być robić. Wrzuciłem tam dla ciebie emocje - to normalne, że tak się czujesz w związku z napotkanym kodem!

Kod, który widzisz, często przechodził niekończące się iteracje przez różnych programistów z różnymi podejściami i standardami oraz różnymi konwencjami nazewnictwa itp. Itp.

Jednak dzieje się tak, że presja $ jest zawsze włączona. Zawsze kusi opisanie, w jaki sposób i dlaczego lepszy kod jest jedynym sposobem na dłuższą metę, ale w wielu pracach zegar tyka na krótkoterminowe rozwiązanie szybkiej naprawy. Zniszczenie standardów w projekcie zajmuje tylko 1 inżynierowi. Potrzeba bardzo dobrego menedżera, który wie, jak temu zapobiec i obronić właściwe podejście (gdy jest to rozsądnie możliwe), aby naprawdę sobie z tym poradzić.

Jedno jest pewne, termin „dobry kod” jest zbyt subiektywny, aby był użyteczny. Oczywiście nie jest to subiektywne, możesz wymienić konkretne powody / elementy. Jednak inne osoby wymieniają różne pozycje i priorytety, niektóre nawet nie techniczne, które ich zdaniem są ważne, a zatem są subiektywne.

Podobnie jak Drekka, zaczyna to brzmieć przygnębiająco, więc postaram się zmienić nieco bardziej pozytywnie, ponieważ z pewnością to prawda, że:

  • Istnieją organizacje, często te z największych elementów technicznych, które robienie właściwych rzeczy.
  • Nowsza firma ... i kod ... sprzątaczka to ma tendencję do być. spaghetti rośnie z czasem i ludźmi.
  • Niektórzy ludzie robią TDD i BDD, inni nie. Zasięg jest ogromny.
  • Obecnie, po około 10 latach, zmienia się cała baza technologiczna, więc ci, którzy pozostają w branży, mogą mieć równie trudny czas, jak nowicjusze.

Wreszcie, jak zauważa Anthony Blake, zawsze istnieją 3 czynniki - czas, koszt i jakość.
Podoba mi się powiązane wyrażenie: „wybierz 2” !

Michael Durrant
źródło
Cieszę się, że inni tak się czują, haha. Zrozumienie, że jest to normalne, z pewnością będę pracować nad większą tolerancją na to. Dziękuję Ci!
próbaAnonimowość
6
Masz szczęście, jeśli dostaniesz „Wybierz 2”, ponieważ „Wybierz 1” jest częściej normą.
Nie sądzę, by „dobry kod” był w ogóle subiektywny. Upuść przeciętnego programistę w projekcie i poproś go o utworzenie często żądanej funkcji. Jeśli zajmie to godziny, Twój kod jest dobry. Jeśli zajmie to dni (lub tygodnie), twój kod jest zły.
kubi
kubi, nie sądzę, że to dobra zasada. Trzeba wziąć pod uwagę to, co powstaje. Wolniejszy kod może zawierać o wiele więcej testów jako jeden przykład. Szybki kod może (choć nie zawsze) być dużym problemem związanym z konserwacją.
Michael Durrant
Także „przeciętny deweloper” jest trochę subiektywny ...;)
Michael Durrant
16

Jest na ten temat wiele opinii, ponieważ doświadczenia każdego są inne.

Moim zdaniem około połowa programistów, z którymi się spotykam, ma dobre intencje, ale przeciętne umiejętności. Na górze jest mała grupa błyskotliwych ludzi, a na dole mała grupa, która próbuje, ale zasadniczo powinna zrobić coś innego, ponieważ tak naprawdę tego nie rozumie. Niestety istnieje jeszcze jedna niewielka grupa niekompetentnych głupców, którzy myślą, że są o wiele sprytniejsi niż wszyscy inni i zwykle mają dość tego, jak powinieneś ich śledzić.

Jeśli chodzi o projekt, podjąłem się wielu zadań i od razu poproszono mnie o „opiekę” nad pewnym ustalonym projektem, zwykle takim, który firma właśnie odkryła, że ​​naprawdę potrzebuje po utracie ostatniego dewelopera. Zazwyczaj znajduję dokładnie to, co nakreśliłeś powyżej - nieudokumentowane, przepracowane, błędne spaghetti. Czasami mogę to naprawić, czasem po prostu zaczynam od nowa. To nawet nie musi być stary kod, znalazłem to w nowych projektach, o które poproszono mnie również o „pomoc”.

Musisz wziąć pod uwagę fakt, że większość firm zapewnia stażystom nieudolną pracę. Zabawne pojawiają się po tym, jak zrobiłeś dwie rzeczy: 1 - sprawdziłeś siebie i 2 - poświęciłeś trochę czasu na pracę nad innymi rzeczami niż naprawianie błędów innych ludzi. Innymi słowy, musisz wykazać zdolność i inicjatywę.

Prawdziwą sztuczką w radzeniu sobie ze złym kodem jest ustalenie, co można odzyskać, a co nie. Wynika to z doświadczenia i badań.

Inną opcją kariery, którą masz, jest zaprzestanie pracy dla uznanych firm i poszukiwanie pracy w startupach. Wtedy nie będzie już żadnego bzdurnego starszego kodu do utrzymania, więc będziesz miał szansę pomóc zbudować coś lepszego. Minusem jest to, że presja dostarczania wywierana na projekty startowe często oznacza, że ​​skróty i hacki są używane, gdy nie powinny.

Programiści zbyt często są gotowi wziąć na siebie dług technologiczny, aby dostarczyć go wcześnie lub na czas. Niestety wpływ długu technologicznego jest często pomijany, minimalizowany, ignorowany lub odrzucany przez deweloperów i kierownictwo, dopóki nie będzie za późno i będą mieli kłopoty.

Przepraszam, jeśli to brzmi przygnębiająco. Jestem pewien, że ktoś inny może zrobić coś bardziej pozytywnego. :-)

drekka
źródło
Wcale nie przygnębiające, dobrze wiedzieć, że to doświadczenie nie jest nieuniknione i trwałe!
próbaAnonimowość
8
Uruchomienie są tylko tworzenie kodu, który nie jest uważany za bzdury jeszcze ...
To prawda :-), a także pracowałem w startupie wypełnionym niektórymi z moich wspomnianych niekompetentnych głupców, którzy na początku stworzyli dużo bzdur.
drekka
12

Jest tu kilka świetnych odpowiedzi, ale dodam trochę;

Witamy w prawdziwym świecie - niestety jest to bardzo częste.

Zobacz poniższy schemat;

wprowadź opis zdjęcia tutaj

W oprogramowaniu korporacyjnym możesz wybrać tylko 2 lub więcej i musisz poświęcić jeden.

Jak się wydaje, większość świata korporacyjnego podąża za szybkością i ceną.

AnthonyBlake
źródło
17
Będziesz miał szczęście wybrać nawet 2, większość miejsc po prostu wybierz 1
softveda
1
W rzeczywistości jest ich więcej niż trzy - jest też zakres (aka funkcje), kompatybilność, bezpieczeństwo, użyteczność, żeby wymienić tylko kilka. Jak zawsze, uzyskanie dobrego wyniku polega na wybraniu najlepszego kompromisu (tak jak zawsze w życiu ...).
sleske
Zgadzam się z obydwoma komentarzami, ale jest to przykład na bardzo wysokim poziomie. W tym przykładzie możesz po prostu umieścić zakres (aka funkcje), kompatybilność, bezpieczeństwo, użyteczność pod nagłówkiem „jakość”.
AnthonyBlake
1
@AnthonyBlake: Tak, wiem. Przepraszam, nie chciałem zrujnować ładnego przykładu :-).
sleske
+1 za tę konkurencyjną odpowiedź do mojej. Czas, koszt i jakość to ważny trójkąt do zapamiętania. Użycie trzech słów ułatwia promocję, udostępnianie i dyskusję z innymi.
Michael Durrant
6

Nie do końca świadczy o branży, ale z mojego ograniczonego doświadczenia 5+ lat. Przepracuję twój staż i wezmę jak najwięcej lekcji z tego doświadczenia. Poszukaj znaków rozpoznawczych i wskaźników. Na przykład na następnej pozycji bez wątpienia musisz przejść szereg wywiadów. Ten proces jest drogą dwukierunkową i daje szansę na poznanie firmy. Jest to niezwykle ważne i prawdopodobnie doprowadzi do twojego własnego szczęścia i dobrego samopoczucia.

Podsumowując, zauważ znaki ostrzegawcze;

  • Kto prowadzi firmę? Czy jest to pojedynczy menedżer, zespół marketingu (jeśli tak, trzymaj się z daleka), zespół programistów itp. Ten kąt oznacza, że ​​możesz uzyskać większą lub mniejszą dźwignię na projekty, czas poświęcony na projekty itp.
  • Czy istnieje uznanie techniczne? Zobacz, jak kierownictwo, przełożony i członkowie zespołu traktują się nawzajem. Byłem w wywiadzie, w którym menadżerowie wykonują wszelkiego rodzaju ruchy brwiami, kiedy kierownik techniczny zaczął mówić. Po tym i nauce nie używali kontroli źródła - nie można było wystarczająco szybko pokazać drzwi.
  • Cel biznesowy Czy firma żyje z dnia na dzień, tak jak w przypadku codziennych celów finansowych, czy też ma długoterminowy plan, którego jesteś częścią. Tworzenie oprogramowania odbywa się zwykle przez miesiące, więc posiadanie firmy o schizofrenicznym charakterze zwykle prowadzi do bałaganu.
  • Grzebać ciężko - zadając pytania techniczne i sprawdzać, czy ludzie się tasują. Kontrola źródła, kontrola dokumentów, proces wydawania, raporty o błędach, styl zarządzania, warunki użytkowania itp.

Żyj więc i ucz się, i pomyśl o swojej następnej roli. Złe doświadczenie nie jest wcale takie złe, ponieważ będziesz lepiej edukowany na temat świata pracy i biznesu.

wonea
źródło
4

Cóż, kończę swoją drugą dekadę w branży i mogę powiedzieć, że doskonały czysty kod zdarza się bardzo rzadko, a kiedy to się dzieje, długo tak nie jest. Ogólnie rzecz biorąc, będziesz ciągle próbował naprawiać błędy z przeszłości, a (niestety) zmuszony przez ograniczenia czasowe i słabe przywództwo do popełniania błędów teraźniejszości.

O ile nie prowadzisz bardzo szczególnego rodzaju działalności programistycznej, presja, aby wyciągnąć funkcjonalny produkt za drzwi, zastępuje wszystkie inne obawy, a optymalizacja wykraczająca poza pewien punkt jest uważana za bezcelową. Jeśli program działa w ciągu 5 minut, a potrzebujemy go tylko w ciągu 5 minut, nikt nie da ci kilku tygodni na obniżenie czasu działania do 2 minut.

Jeśli jakimś cudem masz doskonałe połączenie kompetentnego zarządzania, wyraźnego celu, pieniędzy, talentu i czasu, a także produkujesz czysty, super produkt ... Jedynym sposobem, aby tak pozostało, jest to, że nigdy nie dotkniesz to znowu . Utrzymanie i rozszerzenie prawie zawsze ma bardzo niski priorytet, zmiany są zawsze potrzebne w przypadku skutecznego zerowego powiadomienia, a ostatecznie zostają zakłócone błędnie.

Wczoraj myślałem o tym jednym projekcie. To było dla mnie tak oczywiste marzenie o fajce, że wyskoczyłem z drzwi naprawdę minimalnie funkcjonalny badziew. Widziałem to jako stratę czasu i zasobów.

Cóż, niespodzianka, niespodzianka, wszyscy to uwielbiali i wszystko wyszło dobrze. Więc wróciłem do deski kreślarskiej i zrobiłem to dobrze. Nowa wersja była niesamowita! Ale potem nastąpił obrót w zarządzaniu i cała sprawa została odrzucona na korzyść „nowego kierunku biznesu”.

Druga iteracja miała naprawdę w połowie zaimplementowane wdrożenie w firmie i nigdy nie słyszałem o tym nic innego, co jest zabawne, ponieważ wiem, że przynajmniej ~ 10 jednostek biznesowych nadal z niej korzysta (oprogramowanie, które zlecamy do wykonania zadania jest prawie 2 lata opóźnione) i najwyraźniej nigdy się nie psuje.

To prowadzi nas do mojej ostatniej kwestii. Nawet jeśli wytworzysz coś cudownego, fakt, że działa on tak dobrze, oznacza, że ​​ŻADNY nie będzie się z nim w najmniejszym stopniu zaznajomił, a kiedy się zepsuje (zwykle dlatego, że zrobili coś głupiego), przeklną twoje imię gorzej niż oni przeklinać tego idioty, który napisał coś, co psuje się co trzeci wtorek.

Satanicpuppy
źródło
2

Trudno powiedzieć, co uważasz za okropnie niskiej jakości kod, ale tak, niewielu programistów jest bardzo dobrych (z definicji). W miarę rozwoju oprogramowania ludzie popełniają błędy. Z czasem narastają, a presja biznesowa (i lenistwo / ignorancja programisty) powoduje, że refaktoryzacja ... jest rzadkością.

Telastyn
źródło
Cóż, dla porównania, zwykle koduję dość szybko, ale w ciągu ostatnich 6 tygodni napisałem o stronie kodu, ponieważ tak długo zajmuje rozszyfrowanie, co oznacza jakakolwiek podstawa kodu. Brak komentarzy jest uzupełniany dowolnymi nazwami zmiennych i funkcji (moje zmienne nazwane po azjatyckich lokalizacjach były moimi ulubionymi ...).
próbaAnonimowość
1
Ponadto, czy programowanie zajmuje 50–60 godzin tygodniowo?
próbaAnonimowość
2
Tylko w złych firmach.
Wayne Molina
2
Wcale nie i dlatego jest to pytanie „zależy”. Przy startupach i tym podobnych? Pewnie. Plus wiele więcej! W Higher Education lub Governmnet, no. W konsultacjach tak. Plus więcej. Wszystkie różnią się w innych obszarach i korzyściach i oczywiście $
Michael Durrant
1
tak, przekonasz się, że będziesz potrzebować różnych umiejętności kompensacji stylu życia w miejscu pracy. Ustalone godziny, pora obiadowa, późne spanie są bardzo różne. Znajdź małe rzeczy w ramach ograniczeń, które mogą pomóc i pamiętać, że biorąc pod uwagę czas i dobre nastawienie, dostosujesz się, a wraz z upływem czasu zyskasz większy szacunek i będziesz mieć większą moc i autorytet do robienia rzeczy po swojemu i / lub dostać zmiany.
Michael Durrant
2

Naprawdę nie mogę mówić za wszystkich, ale oto, co mogę powiedzieć.

Nie mam ponad 30 lat pracy w tej dziedzinie, ale widziałem wystarczająco dużo, aby powiedzieć kilka rzeczy. Projekt ma życie prawie jak człowiek. Wstępny projekt może nie odpowiadać obecnym potrzebom, powiedzmy, jednego projektu po 20 latach rozwoju. To powiedziawszy w tym czasie, wiele osób zmieniło zepsuty kod i dodało rzeczy, które na początku nie byłyby możliwe.

Nie jest trudno wyobrazić sobie brzydki kod w starszych projektach lub dość starych projektach. Nie możemy oczekiwać, że wszyscy w pełni zrozumieją wstępne projekty. To smutne, ale tak już jest.

To powiedziawszy, musisz pamiętać, że refaktoryzacja starszego projektu nie zawsze jest możliwa i czasami nawet nie jest pożądana. Pracowałem w firmie, w której pracowali nad zamiennikiem projektu, nad którym pracowałem. Nie pozwolono mi za bardzo zrefaktoryzować mojego projektu w obawie, że zadziała on lepiej niż nowy projekt. Jestem prawie pewien, że nie ma sposobu, aby ten projekt kiedykolwiek działał lepiej niż nowy, świeży. wyrażenie było trochę jak „Nie poprawiaj, po prostu spraw, aby działało”.

W końcu nie będziesz miał często tego rodzaju projektów, ponieważ często czytam i słucham. Powinieneś spróbować znaleźć pracę ze startupami zamiast z dużymi korporacjami. Startupy są dość interesujące i możesz w końcu iść szybko, jeśli zauważysz, że nie idzie tak, jak chcesz.

Jedną rzeczą, którą możesz zrobić, naprawdę nic nie obiecuję, ale jeśli uważasz, że kod jest tak zły i wymaga refaktoryzacji. Udostępnij to zespołowi. Pamiętaj, że ludzie, którzy napisali ten brzydki kod, mogą z tobą współpracować. Nie chodzi o zranienie ludzi, ale jeśli zauważysz, że projekt, nad którym pracujesz, po pewnym czasie zawali się, a ludzie spędzą więcej czasu na zrozumieniu tego, co robi, zamiast go ulepszać. Lepiej zabrać głos i zgłosić problem, niż zachować go dla siebie. Jeśli masz szczęście, możesz sfinalizować projekt.

Jeśli zakończysz refaktoryzację projektu, możesz być osobą wskazaną na złe wybory projektowe! I wtedy możesz zrozumieć, dlaczego refaktoryzacja nie zdarza się tak często. Mam nadzieję, że jeśli cały zespół będzie musiał dokonać refaktoryzacji, nikt nie zostanie wskazany. Po prostu zwolnią wszystkich =)

Loïc Faure-Lacroix
źródło
2

Próbowałbym podsumować odpowiedź na te pytania prostym cytatem:

All code turns to crap given enough time and hands.

Reszta to tylko historie ...

Alexandru C.
źródło
A kod, który działa, bez względu na to, jak brzydki, pozostanie w produkcji DUŻO dłużej niż pierwotni producenci.
Jennifer S
2

Jakość kodu zależy głównie od dwóch czynników.

Po pierwsze zawsze są pieniądze. Firmy, które mają wysoką presję przetrwania, zwykle płacą niskie płace, angażują mniej doświadczonych programistów, mają napięte harmonogramy i nie mają czasu ani pieniędzy, aby wykorzystać swoich programistów.

Drugi to ludzie. Przede wszystkim ci, którzy decydują o budżetach, muszą wybrać wydatki na jakość kodu, a następnie muszą zaangażować ludzi, którzy chcą je „przeżyć”. Jak możesz sobie wyobrazić, może okazać się trudne przekształcenie dobrze płatnego pięćdziesięcioletniego programisty Delphi (bez zamiaru stereotypów, przepraszam) w aktualnego programistę Java, który zajmuje się kompilacją i produkcją CI luźno powiązany kod. Wielu programistów ma niechęć do lekcji przez (być może młodszych) kolegów, nie lubią, gdy ktoś łowi w stawie - lub grzechota na tronie.

Biorąc to pod uwagę, a także biorąc pod uwagę fakt, że masz starszy kod w każdej firmie, powiedziałbym, że dostajesz dużo tego w prawdziwym życiu. Możesz zachowywać się jak harcerz: idź do lasu, weź śmieci i wyczyść je. Następnym razem będziesz miał mniej bałaganu do przejścia.

Sebastian Edelmeier
źródło
2

Witamy w kodzie z budżetem! Istnieje wielka różnica, gdy zarządzanie jest popychane przez kierownictwo do rozwoju, który odbywa się zbyt wcześnie, bez planowania i skracania narożników. Miałem podobne doświadczenie szoku w prawdziwym świecie, kiedy dostałem pierwszą pracę programistyczną po studiach. Brak dokumentacji! Z czasem wiele się nauczyłem, pisanie i aktualizowanie formalnej dokumentacji to tylko strata czasu. Na szczęście był to niesamowity zespół. Prowadził go facet, który wiedział, co robi, a pozostałym członkom zespołu bardzo zależało na pisaniu kodu we właściwy sposób. Od tego czasu moje doświadczenia są podobne do twoich. Dużo okropnego kodu, dużo złego kodu, mnóstwo nieświadomych „programistów”. Wydaje się, że na każdego dobrego programistę przypada 100 złych.

Nie jesteś skazany na nienawidzenie swojej pracy na zawsze. Musisz tylko znaleźć firmę wystarczająco inteligentną, aby dostrzegać długoterminowe korzyści, które są skłonne zainwestować trochę z góry. Udało mi się udowodnić, że robienie rzeczy we właściwy sposób zamiast najszybszego jest korzystne i zyskałem szacunek i zaufanie do tego w firmach, w których pracowałem. Z czasem kod spaghetti zostaje naprawiony lub staje się przestarzały, a Twój kod przejmuje kontrolę. Po prostu bądź przygotowany na kompromis. Czasami najfajniejszym lub najsolidniejszym sposobem programowania jest po prostu przesada i można to zrobić w szybki i brudny sposób.

xr280xr
źródło
1

Otrzymałem staż w jednej z największych firm programistycznych

Nie wszystkie firmy są takie same. W większości firm znajdziesz gówniane zespoły i głupie bazy kodu oprogramowania. Ale możesz także znaleźć świetne zespoły i świetne bazy kodu.

Myślę, że chłopaki z Solaris bardzo dobrze i uczciwie opisali rodzaj kodu, który można znaleźć w dużych firmach: http://hub.opensolaris.org/bin/view/Community+Group+on/dev_solaris

Do tej pory codziennie nienawidziłem pracy i desperacko chcę wiedzieć, czy to właśnie czeka mnie do końca życia.

Nie, koduję od ponad 15 lat i nadal to kocham.

Nie oznacza to, że wszystko było idealne. Widziałem kilka okropnych baz kodu, a także kilka świetnych. Sztuką jest znalezienie odpowiedniego miejsca dla siebie.

Duża firma bardzo różni się od małej. W ramach tej samej firmy zespół A czasami różni się od zespołu B. Znajdź ten, który ma dla Ciebie odpowiednią równowagę (np. Ambitne projekty, kultura, którą lubisz, dobra płaca itp.)

Powodzenia!

Hector Correa
źródło
Nie tylko wszystkie firmy nie są takie same, ale w większych firmach nie wszystkie grupy są takie same. Czasami różne grupy są związane całkowicie odmiennymi procesami przeglądu. Należy pamiętać, że można bez ogródek zapytać bezpośrednio menedżerów przeprowadzających rozmowy (a jeśli masz do nich dostęp, programistów przeprowadzających rozmowy), jakie najlepsze praktyki stosują. (Zauważ, że odpowiedzi programisty będą bezużyteczne, jeśli szef będzie z nimi w pokoju.)
Novak
1

Widziałem podobne rzeczy jak ty. Mam dwa doświadczenia przypadków, kiedy to nastąpi.

  1. Gdy rozwój jest zbyt ukierunkowany na projekt. Jedyne, co się liczy, to terminowe dostarczenie funkcjonalności, a następnie wylogowanie się. Następnej zmiany dokona ktoś inny, inny zespół / kierownik projektu z nowym budżetem.
  2. Kiedy tylko kilka osób zarządza oprogramowaniem przez długi czas, programiści stają się leniwi, ponieważ i tak znają się na swoim oprogramowaniu. Zasady akademickie są daleko.

To smutne, ale tak jest w niektórych miejscach.

Sprawdź, czy możesz dokonać drobnej zmiany na lepsze, przyzwyczaić się do niej lub zmienić firmę i poprosić o sprawdzenie kodu podczas rozmowy kwalifikacyjnej :-)

Petter Nordlander
źródło
1

To będzie krótka odpowiedź.

Edukacja jest bardzo przydatna, abyś poczuł się wykwalifikowany i idealistyczny. To dobra rzecz i powinieneś spróbować trzymać się idealizmu.

Jeśli w ogóle jesteś obiektywny i możesz spojrzeć wstecz na swoją pracę w przyszłości, nie będzie to bardzo satysfakcjonujące doświadczenie. Jeśli nie okłamiesz siebie lub niczego się nie nauczysz, zobaczysz wiele sposobów na ulepszenie tego, co zrobiłeś.

Ogólnie rzecz biorąc, cały świat robi to wokół ciebie. Kiedy więc spojrzysz na pracę z przeszłości, pomijając wyjątki, będzie ona gorsza i wymaga poprawy. Jeśli nie czujesz się w ten sposób, oznacza to, że wykonujesz niewłaściwą pracę lub jej płacenie jest zbyt dobre.

Dobrą wiadomością jest to, że możesz czerpać korzyści z błędów innych i z porównania z przeszłością. Gdyby wszystkie aplikacje działały dobrze i były łatwe w utrzymaniu, nowi programiści nie byliby potrzebni. Moim zdaniem utrzymanie niektórych innych cruft programistów jest przydatnym doświadczeniem edukacyjnym i powinno być obowiązkowym elementem szkoleniowym dla wszystkich programistów blue sky.

Jodrell
źródło
1

Twoje negatywne doświadczenia są nazbyt typowe dla dużych, znanych firm markowych, do których wielu programistów uczy się podchodzić z większą ostrożnością i niepokojem niż wtedy, gdy mieli okazję pracować w jednym z nich. Zasadniczo, im więcej masz warstw zarządzania, tym więcej przeciętności jest wspierana. Kierownicy średniego szczebla nie informują kierowników wyższego szczebla o jakości kodu. Raportują o funkcjach dostarczonych w X czasie i przedstawiają prezentacje Powerpoint na temat interfejsu neato UI, które, jak mają nadzieję, działają wystarczająco długo, aby je przejść. Jeśli wszystko się załamie miesiąc później, zwykle jest to problem kogoś innego i oni o tym wiedzą.

Więc tak, twórcy, którzy są żywicielami w takich miejscach, nie przejmują się zbytnio. Nie mogliby tam przeżyć, gdyby to zrobili. Słyszałem o Dolinie Krzemowej, że jeśli chcesz być leniwy, pracuj dla jednego z wielkich nazwisk. Jeśli chcesz ekscytującej pracy, poszukaj nowszego startupu, który nie jest jeszcze marką. Pracuję w Chicago i mogę tutaj ręczyć za podobne zjawisko.

Zasadą ogólną (z pewnymi wyjątkami jestem pewien), większe uznanie dla jakości kodu w firmach mniejszych i zarządzanych lub będących własnością osób, które również nadal piszą kod. Rekompensata jest często mniejsza, ale moim zdaniem praca jest często znacznie bardziej satysfakcjonująca.

Jako początkujący deweloper prawdopodobnie nie będziesz miał dużej kontroli nad tym, dla kogo pracujesz, ale powiem, że posiadanie dobrego imienia w swoim CV przez rok lub dłużej zdecydowanie ekscytuje rekruterów i pracowników HR. Możesz także nauczyć się czegoś, czego nie nauczyłbyś się, inaczej pracując dla kogoś całkowicie okropnego przez pierwsze sześć miesięcy, a także pomaga lepiej kontrolować, które najlepsze praktyki są tak naprawdę ważne i dlaczego, a które tylko mody.

I oczywiście, pracując z bardziej popularnymi narzędziami korporacyjnymi w głównym nurcie, zwykle zauważysz, że mediana poziomów talentów będzie dość kiepska. Jeśli twoje podstawowe umiejętności to kombinacja Java i C #, nieco poszerz swoje horyzonty. Możesz znaleźć szczęśliwszą niszę na poziomie średnim, pisząc Erlang lub Python lub: o JavaScript.

I nie pozwól nikomu powiedzieć ci nic innego. Być może nie masz wyboru, jak postępować, ale kod bzdury jest! @ # $ Ing drogi.

Erik Reppen
źródło
-2

Twoje pytanie dotyczyło staży. Nigdy nie miałem programistycznego, ale stażysta w stacji radiowej, tak naprawdę tutaj nie ma zastosowania.

Twoje pytanie dotyczyło również twoich doświadczeń podczas staży. Twoje doświadczenia związane ze stażem i odpowiedzi, które otrzymałeś do tej pory, podsumowują moje doświadczenia po dwudziestu siedmiu latach pisania oprogramowania (rozpoczęte w połowie czerwca 1985 r.).

Nigdy nie wierzyłem w to w szkole, kiedy nasi instruktorzy mówili, że jest więcej myślenia niż pisanie kodu. Mieli rację. A jeśli próbujesz dowiedzieć się czyjś kod, jest gorzej bez komentarzy i prawie tak samo źle z komentarzami. Spróbuj utrzymać domowy system poboru podatków komunalnych bez komentarzy, dokumentacji, formalnej kompilacji i kontroli kodu źródłowego.

Ilekroć możesz zrobić dobrze bez bezpośredniego naruszenia standardowych zamówień, zrób to dobrze. Zawsze pamiętaj, że łatwiej jest przeprosić za zrobienie czegoś, o co nie poprosiłeś o pozwolenie, niż nieudzielenie pozwolenia i sprzeczne z bezpośrednim rozkazem.

Nie zapomnij o standardach, których nauczyłeś się w szkole. Nie są bezużyteczne, ale bardziej niż prawdopodobne, że normy te są asymptotami w granicach rachunku różniczkowego. Zawsze możesz spróbować do nich podejść, ale nigdy nie osiągniesz ich wartości.

Powodzenia.

octopusgrabbus
źródło