Czy starsze programiści radzą, aby zawsze używać książek, to dobry pomysł? [Zamknięte]

Jestem młodszym programistą i jestem w branży dopiero od 5 lat. W mojej obecnej firmie jest starszy, nazwijmy go Infestus. Czasami mam okazję zabłysnąć i zrobić coś zupełnie nowego od zera.

Jednym z najnowszych przykładów było to, że musiałem utworzyć singleton w aplikacji wielowątkowej. Zdecydowałem się użyć tej metody. Gdy tylko Infestus to zobaczył, szybko zaczął nazywać mnie głupcem i powiedział, żebym użył tego podejścia . Na pytanie, dlaczego właśnie to odrzucił, bo tak jest lepiej, i tak właśnie ta i ta książka o Javie mówi, że jest lepiej.

I jest to powszechny wzorzec: ilekroć mam szansę zrobić coś nowego, szybko zostaję zestrzelony przez Infestus, a jedynym powodem, dla którego jego metoda jest lepsza, jest to, że te książki zostały napisane przez znanych programistów. Zawsze stara się dać mi książki do przeczytania, abym mógł „nauczyć się”, jak programować.

Programuję pieniądze tylko od 5 lat, ale czy zawsze dobrym pomysłem jest ślepe podążanie za książką na temat najlepszych sposobów rozwiązania problemu, czy powinienem próbować eksperymentować co jakiś czas? Ciągła fala skarg od Infestus zaczyna powodować, że nigdy nie próbuję niczego nowego i nie podążam za przykładami w książkach.

EDYCJA : Jestem całkowicie zagubiony. Tak, wiem, że ślepe podążanie za czymś jest złym pomysłem. Ale ten boski programista Infestus, który wydaje się dużo wiedzieć, mówi mi, że jedynym sposobem na prawidłowe zaprogramowanie jest czytanie książek i podążanie za literą T. Wszystkie zasady, które narzuca, są zapisane w książkach, więc zastanawiam się jeśli książki są jedynym prawidłowym sposobem.

EDYCJA 2 : Infestus nie jest moim szefem. Jest tylko jednym ze starszych programistów odpowiedzialnych za przegląd kodu. I większość jego komentarzy po recenzjach składa się z nazw książek, w których taka i taka metoda jest niewłaściwa.

Przez całą karierę spotkasz takich programistów. Nie ma nic złego w eksperymentowaniu i uczeniu się na własną rękę. Pewne książki są świetne. Wiele razy przykłady działają w czystym środowisku, ale jeśli jesteś programistą dla innej firmy, nie ma czegoś takiego jak czyste (bez ingerencji innych) środowisko.

Zawsze miło jest wiedzieć, jak robić rzeczy „we właściwy sposób”, ale opinie zmieniają się z roku na rok. Dowiedz się, co możesz. Weź wszystko, co możesz od starszego programisty, połącz to ze swoją wiedzą, której uczysz się sam. W końcu będziesz starszym programistą i będziesz czerpać z tych doświadczeń i uczyć młodszych programistów.

Po prostu nie przejmuj się tym.

Czy naprawdę nazwał cię głupcem, czy po prostu zdyskredytował kod? Nazywanie czegokolwiek głupim jest nietaktowne, ale to nie unieważnia sugestii. Myślę, że Infestus przedstawił cenną sugestię, a w przyszłości powinieneś poważnie rozważyć jego sugestie. Wydaje się, że dużo czyta, a przynajmniej w tym przypadku jego opinia jest dobrze poinformowana. Synchronizacja jest zarówno droga, jak i trudna. Jego zalecana implementacja jest bardziej wydajna i prostsza niż twoja i gwarantuje działanie.

Zawsze stara się dać mi książki do przeczytania, abym mógł „nauczyć się”, jak programować.

To miło z jego strony. Aktywnie próbuje ci pomóc, ale wydaje się, że pozwalasz swojemu ego przeszkodzić. Nie krytykuj swojego kodu osobiście. Kod jest tani w produkcji i łatwy do zmiany. Jeśli ktoś pokaże ci prostszy sposób robienia czegoś, podziękuj mu.

I tak, czytanie uczyni cię znacznie lepszym programistą. Wszyscy eksperci, których znałem, czytali obszernie. Jeśli nie czytasz dużo, to jesteś w najlepszym razie mierny, a za kolejne pięć lat może się okazać, że nie możesz już sprzedawać.

Czytanie książki nie powinno być ślepe: autor powinien spróbować przekonać cię o zaletach swojego podejścia, gdy ją przedstawia. Jest rozsądne, aby senior wskazał ci książkę wyjaśniającą jego preferowane podejście, zamiast prosić go o wyjaśnienie go sam: chociaż powinien być w stanie wyjaśnić zalety swoich preferencji bez polegania na książce, jest to również powielanie wysiłku, który autor książki już zrobił.

Więc przeczytaj książkę, zobacz, co mówi autor książki, a jeśli cię to dezorientuje lub chcesz potwierdzić swoje zrozumienie lub nie zgadzasz się, to porozmawiaj o tym z seniorem, ale teraz będziesz w stanie prowadzić bardziej produktywną dyskusję.

Istnieją trzy kluczowe elementy każdego zdrowego związku. Komunikacja, uczciwość i zaufanie. Dotyczy to wszystkich relacji, nawet relacji roboczych. Powinieneś porozmawiać ze swoim przełożonym na temat tych obaw.

Jeśli nie rozumiesz powodów, dla których popiera on określony projekt, powiedz mu o tym . Powiedz mu, że nie przeczytałeś książki i że chcesz zrozumieć, dlaczego jego sposób na zrobienie tego jest lepszy. Kluczem jest to, że powinieneś starać się zrozumieć jego sposób robienia rzeczy.

Myślę, że powinieneś traktować tę osobę z większym szacunkiem. W twojej głowie nazywasz go obraźliwymi imionami i krytykujesz jego podejście do tego, co uważasz za „uczenie się”. Uważaj na to. Z drugiej strony powiedziałeś, że nazwał cię głupcem. To nie jest fajne i powinieneś mu powiedzieć, że nie jest fajnie nazywać kogoś głupcem.

Pomysły mogą być głupie. Wszyscy popełniamy błędy i tęsknimy za wszystkim, nawet starsi faceci. Kiedy w projekcie jest jakaś wada, najlepszym pytaniem jest: „Dlaczego robisz to w ten sposób? Czy nie złamie się w sytuacji X, Y, Z? Czy projekt B nie będzie lepszy?”

Pamiętaj, że pracujesz nad tym oprogramowaniem z innymi ludźmi. To trudna umiejętność do nauczenia się. Nie ma znaczenia, że ​​nie piszesz niczego od zera, zawsze jest miejsce, aby zabłysnąć, czyniąc swój kod najlepszym kodem, jaki możesz.

„Najlepsze” bardzo często oznacza czytelne i zrozumiałe . My, programiści, spędzamy dużo czasu na czytaniu kodu innych osób. Jeśli ten kod jest przejrzysty i czytelny, to czyni go naprawdę wartościowym. Jednym ze sposobów, w jaki uczymy się pisać świetny kod, jest czytanie dużej ilości dobrego kodu. Bardzo często znajdziesz bardzo dobry kod w książkach. Czytanie jednej lub dwóch dobrych książek o programowaniu prawdopodobnie uczyni cię lepszym programistą.

W firmie, w której pracujesz, prawdopodobnie tak jest. Właśnie tego wymagają od ciebie.

Inżynier Infestus wykonuje bardzo słabą pracę, kształcąc młodszych programistów, mówiąc im: „jest to napisane w książce i dlatego”. Nie jest kaznodzieją, jest inżynierem i powinien być w stanie go rozbić i przedstawić koncepcje, aby juniorzy mogli uczyć się na podstawie jego doświadczenia.

Zachęcam do porozmawiania z doświadczonymi programistami w Twojej firmie, zadawania im pytań o wady i zalety różnych technik programowania itp. To wraz z czytaniem książek i blogów (polecam Joel on Software - po prostu Google, to musi) powinien dać ci lepsze zrozumienie.

IMHO, są tutaj 2 aspekty, z którymi powinieneś poradzić sobie osobno:

• Fakt, że facet jest palantem, nazywa cię imionami i tak po prostu dlatego, że może (jest starszy, nie jesteś, jeśli którykolwiek z was narzeka na drugiego, dostanie wątpliwości) jest po prostu bully-like zachowanie i po prostu złe.

Staraj się nie schylać do tego poziomu. Nie próbuj go zastraszać ani „mówić mu” szefowi ani nic takiego. Staraj się zignorować ten aspekt jego zachowania, pamiętając, że staje się on zbyt ekstremalny (tj. Jeśli wpływa to na twoją produktywność i tak dalej) powinieneś coś z tym zrobić.

• Fakt, że mówi ci, że twój kod jest zły (i jak to zrobić poprawnie). Szczerze mówiąc z tego, co opisujesz, ignorując ton faceta, ten aspekt jego zachowania nie jest taki zły. Uczysz się rzeczy dużo szybciej i widzisz je we właściwym kontekście, gdy masz kogoś bardziej doświadczonego w poprawianiu cię i mówieniu nie tylko o tym, co zrobiłeś źle, ale także o tym, jak to zrobić dobrze (w porównaniu do samodzielnego uczenia się ich wszystkich samodzielnie) z osobistych prób / eksperymentów z błędami itp.).

Wielokrotnie miałem kogoś, kto poprawił to, co początkowo myślałem, że to „mój idealny kod” i po prostu denerwowałem się, że facet mówił mi, co mam robić, aby później uświadomić sobie, że ma rację przez cały czas, moja wersja była zła, jego była dobrze i dzięki Bogu to widział! :) Więc nauczyłem się tłumić moje początkowe impulsy: „hej, nie mów mi, co mam robić, mista!” i zamiast tego, za każdym razem, gdy ktoś mnie poprawia, najpierw naprawdę, obiektywnie, ponownie sprawdzam mój kod, a następnie sprawdzam jego i upewniam się, że nie ma racji, a to ja popełniam błąd. Jeśli to moja wina, dziękuję mu za pomoc i upewniam się, że naprawdę rozumiem, jak działa jego rozwiązanie (a nie tylko kopiowanie / wklejanie).

Hej, czasami zdarza mi się, że oferowana korekta była w rzeczywistości gorsza niż początkowo, w którym to momencie próbuję rozmawiać o tym z drugim facetem. Szczerze mówiąc, zauważyłem, że nic nie zyskuje szacunku innych szybciej niż wtedy, gdy widzą, że możesz zaakceptować poprawienie, gdy popełniłeś błąd, ale jednocześnie nie bój się powiedzieć, że jesteś tym jedynym kto ma rację, kiedy tak myślisz, biorąc pod uwagę, że możesz od razu udowodnić, że opierasz swoją afirmację na rzeczywistych badaniach, a nie tylko na ego.

W tej kwestii uważam, że powinieneś naprawdę spróbować porozmawiać z facetem o tym, co on proponuje, co proponujesz i tak dalej. Pokaż mu, co myślisz, jak dostałeś się do konkretnego rozwiązania i dlaczego uważasz, że jest ono lepsze niż jego (kiedy szczerze i obiektywnie uważasz, że tak jest). Lub, jeśli dowiesz się, że jego propozycja jest lepsza od twojej, powiedz mu tak, wyrażając wdzięczność za pomoc. Może to odbudować niektóre spalone mosty.

Eksperymentuj sam i naucz się wszystkiego, co możesz. Po przeczytaniu wystarczającej liczby książek odkryjesz, że istnieje wiele książek na określone tematy i mogą one być ze sobą sprzeczne. Wypróbuj ten, który uważasz za najlepszy i wypróbuj oba, jeśli masz czas lub chcesz porównać / skontrastować.

Radzenie sobie z szefem to zupełnie inny temat i podejście. Gdybym chciał, żeby ktoś zrobił coś dokładnie tak, jak to było w książce, powiedziałbym im. To tylko ja, ponieważ nie kojarzę się z czytnikami myśli. Twój szef sprawia, że ​​jest to nawyk, po prostu zapytaj, czy poleca jakieś książki lub referencje, kiedy dostaniesz nowy projekt.

Cokolwiek robisz, nie przestawaj pracować nad nowymi projektami. Wiem, że wszystkim nam łatwo dać wskazówki, jak poradzić sobie z tą sytuacją i mogą one działać lub nie, ale to ty musisz z tym żyć i cierpieć z powodu negatywności. Będziesz lepszy, ale zwykle wynika to z pisania większej ilości kodu na nowe rzeczy, uczenia się na podstawie sukcesów i porażek.

Ślepe podążanie za książkami to zły pomysł, ale istnieje różnica między dokładnym podążaniem za książką a ślepym podążaniem za nią .

Kiedy próbujesz zrozumieć pewne rzeczy w książce, na ogół dobrze jest postępować dokładnie tak, jak na początku, podczas gdy masz poczucie, czego próbuje cię nauczyć. Szanse są takie, że nadal nie zrozumiesz wszystkiego, kiedy skończysz - tak zwykle wyglądają takie rzeczy - ale przestrzeganie książki dokładnie na początku da ci coś do eksperymentowania, gdy spróbujesz zrozumieć swoje pytania. Szanse są znowu dobre, że znajdziesz sposoby, by nie zgodzić się z tym, co jest w książce, ale zrozumiesz problemy, które książka próbowała rozwiązać, dzięki czemu, gdy przyjdzie czas na napisanie własnego kodu, możesz rozwiąż je na swój własny sposób (a może na swój sposób, przynajmniej częściowo), zamiast pozostawiać te problemy do ukąszenia później.

Jeszcze jedna rzecz, która nie jest z natury specyficzna dla Javy, ale jest jednak szczególnie powszechna w tej społeczności. Myślę, że mogę zgadnąć, o których książkach mówisz, a one stanowią znaczną część leksykonu społeczności Java. Zrozumienie ich i sposobu, w jaki opisują różne rzeczy, ogromnie pomoże, gdy będziesz musiał zrozumieć inny znaleziony kod Java. To cenna umiejętność sama w sobie.

Czytanie książek i postów na blogu jest bardzo pomocne w programowaniu. Jest kilka książek, które wszyscy programiści powinni przeczytać.

Jednak książki nie są jedynym źródłem do nauki różnych koncepcji programowania i technologii. W dzisiejszych czasach szkolenia oparte na wideo stają się bardzo popularne. Możesz sprawdzić Pluralsight , który zapewnia wysokiej jakości szkolenie dla profesjonalistów.

W rzeczywistości, jeśli czytasz tylko książki, które również nie pomogą. Oprócz czytania są też inne rzeczy, które musimy zrobić. Więcej informacji znajdziesz tutaj .

Powinieneś zapytać go, co jest szczególnie złe w twojej metodzie. Jeśli nie jest w stanie udzielić jednoznacznej odpowiedzi, możesz być całkiem pewien, że to zwykły facet, który lubi czuć się lepszy.

W książkach chodzi o to, że - przeważnie - przechodzą zmiany, które mają większą szansę na wykrycie złych praktyk i nieporozumień. „Wielkie nazwiska” to także doświadczeni ludzie, którzy polegają na tym, że są dobrzy, aby zarabiać dodatkowe pieniądze na sprzedaży książek, dlatego istnieją pewne minimalne zapewnienia jakości dotyczące ich wypowiedzi.

To powiedziawszy, czytanie książek, artykułów i innych źródeł jest dobrym sposobem na rozwój zawodowy, oczywiście po potwierdzeniu przez praktykę. Warto więc przeczytać te książki (nawet te zalecane przez Infestus). Jednak książki muszą przede wszystkim poszerzyć twoje zrozumienie na ten temat, ponieważ prawie zawsze będą inne sposoby rozwiązania tego samego problemu.

Jeśli chodzi o twoje podejście „idź sam”, chodzi o to: czy możesz podtrzymać swój punkt widzenia? Jak udowadniasz, że Twoje rozwiązanie jest lepsze od innych? Czasami możesz samodzielnie opracować jasne rozwiązania, ale w porównaniu z innymi znanymi rozwiązaniami musisz być w stanie argumentować powód, dla którego twoje jest lepsze, ponieważ inni mają na ich korzyść, przynajmniej przypadki użycia. Bądź więc kreatywny i rozważny, ale co najważniejsze, bądź skuteczny.

Gdybym tak był, czytałbym te książki. Pomoże ci to, dając ci więcej argumentów, a jednocześnie może się okazać, że Infestus - być może - niesłusznie traktuje te książki jako argumenty i nie został jeszcze zauważony, ponieważ nikt nie zna treści tych książek. Lub może się okazać, że on faktycznie k

Z mojego doświadczenia wynika, że ​​jeśli chodzi o programowanie tematyki, jakość i prezentacja informacji z odpowiednimi objaśnieniami w książkach jest o wiele lepsza niż w przypadku wyszukiwania informacji o tym samym temacie w Internecie. Internetowi często brakuje odpowiedniego wyjaśnienia, kontekstu i jakości.

Ilość tych informacji w Internecie jest wyższa.

Tak więc moją ogólną strategią jest uczenie się z książek, aby uzyskać głębsze zrozumienie, a następnie uczenie się z Internetu, aby być narażonym na różne implikacje i poszerzać moje doświadczenie (i często zobaczyć, jak tego nie robić).

Zbadam zalety każdego podejścia i osądzę. Jeśli uważasz, że twoje podejście jest lepsze, przedyskutuj to z Infestus, dopóki jedno z was nie przekona drugiego. Jeśli nie możesz dojść do porozumienia, możesz poprosić o drugą opinię lub po prostu zaakceptować podejście Infestus, w zależności od tego, jak silnie się z tym czujesz.

W przypadku singletonów jednym argumentem przeciwko metodzie enum jest to, że enumy nie mogą rozszerzać klas. Często piszę taki kod:

public class DateSerializer extends AbstractSerializer<Date> {
  public static final DateSerializer SINGLETON = new DateSerializer();

  private DateSerializer() {}

  public byte[] serialize(Date date) { ... }
}

Nie można tego zrobić za pomocą wyliczeń. Ponieważ metoda wyliczania nie działa we wszystkich przypadkach, można argumentować, że ze względu na spójność należy jej unikać nawet wtedy, gdy nie jest wymagana extendsklauzula.

Kilka innych argumentów, które można by argumentować przeciwko użyciu wyliczeń:

• to hack - używa enum do czegoś, do czego nie były przeznaczone
• jest to mylące dla czytelników, którzy nie widzieli go wcześniej

W dużej mierze polegam na książkach jako źródle wiedzy - są to doskonałe fundamenty i myślę, że Infestus ma rację, ponieważ powinieneś spożywać znaczne ilości książek w wolnym czasie, ponieważ naprawdę przyspieszają twoje umiejętności. Książki nie są jednak jedynym źródłem informacji, które moim zdaniem powinieneś konsumować - dołącz do lokalnej grupy użytkowników, otrzymuj odpowiednie biuletyny technologiczne dostarczane do skrzynki odbiorczej, czytaj blogi.

Nie zgadzam się jednak z twierdzeniem, że ponieważ jest ono napisane w pewien sposób w książce, że tak należy to zrobić. Tak, książki dostarczają świetnych porad i są napisane przez ekspertów i recenzowane przez ekspertów, ale będąc zaangażowanym w stosunkowo prostą książkę, mogę powiedzieć, że zwykle zajmuje to co najmniej dwa lata, zanim zaczną pisać, edytować i wydać książkę . Tempo zmian technologii jest szybkie, a rada sprzed dwóch lat może nie być już właściwą radą na dziś. Ogólne zasady często znoszą próbę czasu, ale optymalizację konkretnego działania można unieważnić za pomocą nowego sprzętu lub nowej wersji oprogramowania.

Sugestia zwrócenia się do Infestus z prośbą o zapoznanie się z tobą jest doskonała - odejdź, przeczytaj wszystko i wróć z mnóstwem przemyślanych pytań, na które już próbowałeś sam odpowiedzieć / rozwiązać, wraz z dowodami potwierdzającymi twoje metoda.

Pojawiły się pytania, czy po 5 latach nadal jesteś młodszy. Dla mnie kluczową miarą tego, czy ktoś jest młodszy, nie jest wieloletnie doświadczenie, ale to, jak bardzo wymagają karmienia łyżeczką. Oczekuję, że programista średniego szczebla będzie względnie samowystarczalny, rozważny konsument źródeł wiedzy, który może na nim działać i rozszerzyć go na swoją sytuację. Powinny one także znajdować się na etapie, w którym mogą rozpocząć naukę juniorów, ponieważ dobrze rozumieją swój temat, aby mogli jasno wyjaśniać różne rzeczy. Drugą podstawową kompetencją jest zaufanie - jeśli wykonałeś pracę, przeczytałeś materiał i stworzyłeś coś przyzwoitego, nie bój się stanąć w obronie przed nim w sądzie debatowym, ponieważ junior wymaga potwierdzenia, deweloper prosi o konsensus.

Odkładając na bok maniery w miejscu pracy, odkładając na bok rolę mentora, którą pełnią starsi programiści, odkładając na bok własne pragnienie eksploracji, odrażając obraźliwe zachowania i odkładając fetysze na książki ...

Celem przeglądu kodu w zespole jest 1) sprawdzenie poprawności kodu i 2) upewnienie się, że osoba pisząca kod rozumie znaczenie poprawy kodu. To nie jest miejsce na powiedzenie „zmień to, bo Martin Fowler tak powiedział w książce GoF”. Można jednak powiedzieć „zmień to, ponieważ [krótkie wyjaśnienie]; więcej szczegółów na ten temat znajduje się w książce GoF”.

Jeśli twój starszy programista, przynajmniej w prosty i subtelny sposób, nie wyjaśnia wyjaśnienia zmiany i nalega na użycie słowa „z powodu [książki]”, jest trochę mądry i palantem. Jak sobie z tym radzisz? Wspominaj o tym na spotkaniu zespołu, werbalnie, i poproś kolegów z drużyny o przedstawienie oświadczenia lub dwóch wyjaśnień krótko wyjaśniających zaletę lub konieczność zmiany, wraz z tym przydatnym odniesieniem do książki. Podziękuj mu za odniesienie do książki.

Spójrz prawdzie w oczy, Twoim celem jest docenić sugestię zmiany i nie być zdemotywowanym do swojego zadania lub pracy. Powiedz mu to. „Byłbym bardziej wdzięczny za sugestię zmiany, gdybyś mógł krótko opisać zaletę lub konieczność zmiany podczas przeglądania mojego kodu; ponieważ uważam, że same odniesienia do twojej książki są nieco demotywujące”.

Jeśli nadal odmawia podania prostego wyjaśnienia w swoich odniesieniach do książek, jeśli możesz podać inną książkę lub zasób o równie lub większym znaczeniu w branży z inną opinią i pasuje to do twojego scenariusza, możesz dodać własną książkę odniesienie w komentarzu do recenzji w związku z zachowaniem oryginalnego kodu. Zrób to wystarczająco dużo razy, może się wycofać. Uważaj, aby kontrargument był słuszny i znacznie ważniejszy; w porządku jest pozwolić, aby starszy programista się mylił i nadal miał swój sposób, to jest coś, czego się nauczyłem i muszę się uczyć.

Powiedziałbym, że nauka programowania tylko z książek jest niemożliwa, ale te dobre zapewnią ci ogromny zastrzyk. To jak karate - czarny pas nie będzie tylko o nim czytać;) Wierzę, że w tym przypadkowym przypadku pan Infestus miał na myśli „Effective Java” Joshua Blocha. To naprawdę świetna książka o programowaniu w Javie i zdecydowanie powinieneś ją przeczytać, jeśli jeszcze tego nie zrobiłeś.