Czy ciągłe szukanie przykładów kodu jest oznaką złego programisty? [Zamknięte]

Jestem studentem CS z kilkuletnim doświadczeniem w C i C ++, a od kilku lat stale pracuję nad tworzeniem aplikacji w Javie / Objective C, a teraz przerzuciłem się na tworzenie stron internetowych i koncentruję się głównie na ruby ​​na do szyn i doszedłem do wniosku, że (tak jak w przypadku tworzenia aplikacji, naprawdę) zbyt wiele odwołuję się do innego kodu. Ciągle funkcjonuję w Google dla wielu rzeczy, które, jak sądzę, powinienem być w stanie zrobić od zera, a to naprawdę trochę podważyło moją pewność siebie.

Podstawowe podstawy nie są problemem, nie chcę tego używać jako przykładu, ale mogę biegać przez javabat zarówno w java / python w sprincie - oczywiście nie jest to osiągnięcie, ale chcę powiedzieć, że mam silną bazę do podstaw Myślę?

Wiem, czego zwykle potrzebuję, ale ciągle używam składni referencyjnej. Chciałbym uzyskać porady i informacje na ten temat, ponieważ powstrzymywało mnie to dość solidnie od szukania pracy w tej dziedzinie, mimo że kończę studia. Głównym powodem, dla którego pytam, nie jest tak naprawdę zatrudnienie, ale przede wszystkim to, że nie chcę być jedynym facetem w hackathonie, który nie rozwija kodu non-stop i siedzi tam z otwartymi 20 kartami Google / github, i powstrzymałem się od uczestnictwa w jakichkolwiek z powodu lekkiego braku zaufania ...

Czy osoba jest złym programistą, stale szukając przykładów kodu dla zadań od średnich do złożonych?

Kopiuj i wklej na ślepo: źle.

Przejrzyj dokumentację, przeczytaj przykłady kodu, aby lepiej zrozumieć: dobrze.

Wolę pracować z kimś, kto cały czas sprawdza rzeczy i upewnia się, że wszystko działa zgodnie z przeznaczeniem, niż z kimś, kto uważa, że ​​wie wszystko, ale nie wie. Ale najgorsze jest to, że ktoś, kto nie zadaje sobie trudu zrozumienia, jak to działa, i po prostu bezkrytycznie kopiuje kod z sieci (a wtedy, gdy raporty o błędach zaczynają padać, nie jest w stanie niczego naprawić)

Jeśli kodujesz swoje rozwiązania w sposób możliwy do utrzymania i faktycznie ZROZUMIESZ co kopiujesz / wklejasz / modyfikujesz, to nie ma problemu.

Umieram w środku za każdym razem, gdy zadaję starszemu programistowi pytania, dlaczego to zrobił, a odpowiedź brzmi: „Nie wiem, skopiowałem wklejony kod i zadziałał w danym momencie”.

Podobnie jak w przypadku umiejętności programowania w / poza dokumentacją API , szukanie przykładów kodu jest oznaką nie złego programisty, ale tego, któremu brakuje płynności ...

... Mówię tutaj o płynności. O byciu nie tylko zdolnym do czegoś, ale płynnym.

Czy wiesz, co to znaczy być płynnym? To dla kogoś, kto na ciebie patrzy, wygląda to tak, jakbyś pisał podczas pisania ...

• ... Jakby właściwy kod po prostu płynął z twoich palców na ekran. Jakby nie sprawdzać dokumentów API, samouczków i instrukcji. Właściwie to zrobić sprawdzić je wszystkie, ale to jest niewidoczne, ponieważ wszystko jest w twojej głowie. Masz całą wiedzę, której potrzebujesz w swoim mózgu - naładowany, załadowany i gotowy do użycia.

... To płynna wiedza. To wtedy zajmuje ci minutę, aby zrobić to, co nowicjusz zajmuje godzinę. Naprawdę warto. Pachnie zwycięstwem.

... a praktyka jest dla mnie jedynym niezawodnym sposobem na opanowanie płynności.

Istnieje teoria uczenia się zwana cyklem Kolba (od osoby, która ją opisała). Wpisy w tym cyklu to:

Concrete experience -> Reflective observation
    ^                        |
    |                        v
Active experimentation <- Abstract conceptualisation

Różni ludzie lubią zaczynać w różnych miejscach cyklu. Można więc całkowicie uczyć się, szukając próbek (faza obserwacji odbiciowej), a następnie opracowując te próbki do dużego obrazu poprzez abstrakcję.

Inni uczą się na różne sposoby: niektórzy lubią zaczynać od prób (czyli eksperymentów), a potem zastanowić się, co poszło dobrze lub źle. Chodzi o to, że są to po prostu różne sposoby atakowania problemu uczenia się rzeczy: żaden z nich nie jest nieprawidłowy.

Pełne ujawnienie - jestem starszą osobą, która została przeszkolona w innym przed-internetowym dostępnym w erze pracy. Obserwowałem, jak umiejętności młodszych programistów stale się pogarszają, głównie dlatego, że nie zatrzymują informacji ani nie rozumieją rozwiązania, które wzięli z Internetu. Zauważyłem, że poziom kompetencji, który ktoś miał po 1-2 latach doświadczenia, 20 lat temu, jest teraz poziomem kompetencji, który ktoś ma po 5-7 latach doświadczenia. (Tak, to osobista obserwacja, ale dużo się zatrudniłem, nie mam danych statystycznych na ten temat i tak, czasami jestem stary i zepsuty, weź to oświadczenie z odrobiną soli. I trzymaj się z daleka. )

Wyszukiwanie wszystkiego jest nieefektywne pod względem czasu. Jest to również objaw osoby, która nie ma dużej głębi wiedzy. Ludzie z głęboką wiedzą mogą pisać kod szybciej niż ludzie, którzy nie wiedzą, jak rozwiązać problem bez szukania rzeczy. Warto więc nauczyć się obsługiwać więcej rzeczy bez ciągłego sprawdzania.

Teraz nie mówię, że nigdy nie powinieneś szukać rzeczy, mówię, że powinieneś nauczyć się zachować wiedzę i musisz tylko szukać rzeczy, których używasz rzadko lub gdy napotykasz naprawdę nowy problem, język lub paradygmat. I nie mówię, że nie powinieneś czytać, aby nadążyć za nowymi rozwiązaniami, narzędziami i językami.

Moja prawdziwa troska o programistów, którzy zbyt często szukają rzeczy, że zbyt wielu z nich (niekoniecznie Ty) nigdy nie rozwija umiejętności analitycznych, aby zrozumieć problemy, jakie mają, i potrzebne rozwiązania. Przeczytaj, ile jest pytań, w których osoba umieszcza komunikat o błędzie, którego wyraźnie nie rozumie, ale które powinny być dość jasne dla każdego, kto działa na poziomie zawodowym. Lub te, w których osoba mówi: „to nie działa, dlaczego?” bez odniesienia do komunikatu o błędzie lub sposobu jego działania, a kod jest poprawny pod względem składniowym. Lub ci, którym podano fragment kodu, który powinien działać,

Jeśli więc szukasz rzeczy, które są częścią podstawowej funkcjonalności języka (ów) (BTW powinno to obejmować SQL, jeśli korzystasz z baz danych), którego używasz przez ponad sześć miesięcy, podejrzewam, że też szukasz wiele. Jeśli szukasz zaawansowanych funkcji, zwłaszcza tych, z których możesz rzadko korzystać, masz się dobrze.

Ale jak nauczyć się zachować więcej informacji? Najpierw zrozum, dlaczego kod się zepsuł. Nawet jeśli ktoś da ci działające rozwiązanie, jeśli nie rozumiesz, dlaczego to zadziałało, a twoje nie, to zapytaj. Jeśli nie rozumiesz komunikatu o błędzie, zapytaj, co to znaczy, a następnie spróbuj go rozwiązać samodzielnie.

I nigdy nie wycinaj i wklejaj rozwiązania, którego nie rozumiesz. W rzeczywistości nie należy w ogóle wycinać i wklejać. Jeśli chcesz zachować informacje, musisz je wpisać. Właściwie fizyczne pisanie kodu pomaga go nauczyć. To dobrze znana technika uczenia się.

Ćwicz ogólne rozumienie kodu. Widziałem, jak ludzie zadają podobne pytania w miarę upływu czasu, ponieważ nie rozumieją, że rozwiązanie problemu ABC, które dostali miesiąc temu, jest tym samym rozwiązaniem nowego problemu DEF.

Więc kiedy coś zbadałeś, poświęć trochę czasu na zastanowienie się, jakie rodzaje problemów byłoby dobre do rozwiązania, i napisz sobie notatki na ten temat. Następnie, gdy masz problem do rozwiązania, najpierw sprawdź własne notatki, aby zobaczyć, że zauważyłeś już możliwą technikę. Jeśli ocenisz wiele sposobów rozwiązania problemu, zanotuj rodzaj problemu, możliwe rozwiązania, na które spojrzałeś, a także zalety i wady każdego z nich. Ponownie robienie notatek pomaga utrwalić wiedzę w twoim mózgu, masz już swój własny proces myślowy w kategoriach zalet i wad i nie musisz tego robić ponownie (lub przynajmniej nie tak głęboko, możesz nadal szukają więcej możliwych technik) dla następnego podobnego problemu.

Przy podejmowaniu decyzji, czego się uczyć, przejdź do jednej z głównych technologii, zanim zaczniesz uczyć się kolejnej technologii na pierwsze 30 dni (zakłada to, że masz wystarczającą wiedzę, aby faktycznie wykonywać swoją pracę, jeśli potrzebujesz użyj 6 technologii - najpierw zapoznaj się ze wszystkimi sześcioma, zanim przejdziesz do głębi). Następnie idź tam i z powrotem, ucząc się nowych rzeczy na poziomie podstawowym, ucząc się czegoś bardziej dogłębnie, a następnie ucząc się nowych technologii na poziomie podstawowym. Jeśli zrobisz to z czasem, przekonasz się, że twój podstawowy poziom tego, czego chcesz od nowej technologii, jest znacznie głębszy, ponieważ rozumiesz bardziej zaawansowane pytania, które o to pytasz.

Innym sposobem na naukę zachowania wiedzy jest nauczenie jej kogoś innego. Odpowiadaj na pytania w takich miejscach, przedstawiaj zespołowi tematy szkoleniowe, twórz prezentacje w lokalnych grupach użytkowników, pisz wpisy na blogach i pomagaj w utrzymywaniu wiki informacji w Twojej firmie, aby pomóc innym programistom.

Poszukiwanie przykładów kodu nie jest oznaką złego programisty. Rzadko potrzeba tak niewielu rzeczy, aby dokładnie zapamiętać wszystkie potrzebne im interfejsy, więc naturalnie jest to sprawdzać, a przykłady kodu są zwykle najłatwiejszym w użyciu.

To, czego nie powinieneś robić, to kopiuj i wklej przykłady, ponieważ tam działają, więc one też muszą tu działać, nie rozumiejąc, jak działają. To zwykle prowadzi do wielu bezużytecznych bitów, które zostały przypadkowo skopiowane, a wynik jest trudny do utrzymania, ponieważ jeśli nie wiedziałeś, jak to działa, gdy go napisałeś, nie będziesz wiedział sześć miesięcy później i nie będziesz w stanie napraw to.

Ale dopóki rozumiesz kod, który kopiujesz z przykładu, jest to prawidłowy sposób na szybsze wykonanie pracy, i zwykle jest to dobra rzecz.

Te odpowiedzi są całkiem dobre. Ale cierpisz na znacznie głębszy problem niż kopiowanie / wklejanie lub brak „umiejętności”.

Porównanie jest śmiertelne. Im bardziej porównujesz się z innymi ludźmi i pozwalasz ich talentowi wpływać na sposób, w jaki się postrzegasz, tym bardziej będziesz się skurczył i umarł w środku. Nie chodzicie na hackatony z obawy, że ludzie zobaczą, jak jesteście bez uzdrowienia. Jedynym powodem, dla którego uważasz, że nie masz talentu, jest to, że porównujesz się z hakerami, którzy szybciej i szybciej wykręcają więcej kodu.

Nawet jeśli „Linie kodu na minutę” były dobrym miernikiem do mierzenia umiejętności, musisz zaakceptować fakt, że zawsze będą lepsi programiści niż ty . I możesz okazywać innym, że brakuje ci umiejętności.

Nie musisz być tak dobry, ani lepszy niż ktokolwiek inny. Musisz zadowalać się faktem, że zawsze czegoś ci brakuje, i że ciągle się uczysz. Jeśli nie możesz być zadowolony z bycia gorszym programistą, NIGDY nie będziesz zadowolony.

I jeszcze jedno: lęk przed odrzuceniem przez ludzi, których uważasz za „lepszych”, dokładnie to, co powstrzymuje cię przed ocieraniem się o ramiona lepszych programistów i uczeniem się od nich. Tak więc twój strach uniemożliwia ci wzrost, który podtrzymuje twój strach. Co uniemożliwia ci wzrost. Widzisz cykl? Musisz gdzieś przerwać cykl.

Myślę, że wiele z tego zależy od tego, jak działa twój umysł. Moja pamięć śmierdzi, więc wolałbym raczej pobrać kod, który jest tak blisko, jak to tylko możliwe, i przerobić go, aby wykonał nową pracę. Służy jako przykład i przypomnienie wszystkich rzeczy, które muszę zrobić. Na przykład używam prostego SQL od 20 lat, ale nigdy nie pamiętam układu instrukcji SELECT lub UPDATE. (Myślę, że trzeba nawiasów, ale nie pamiętam, które.) Z drugiej strony, kilka rzeczy, które pamiętam; Mogę złożyć razem implementację Java Iterator z zamkniętymi oczami.

Większość kodu, który kopiuję, jest moja, ale z pewnością kopiuję inne, kiedy uczę się czegoś nowego.

Nie wiem o hackathonach. Mogą czerpać z podzbioru programistów z pamięcią fotograficzną. Spróbuję i zobaczę. Jeśli przeszkadza ci wyglądanie jak idiota, nie powinieneś programować.

Zachęcam do dokładnego zrozumienia całego kodu, który kopiujesz i modyfikujesz, ale dopóki nie przeczytam innych odpowiedzi, nigdy nie przyszło mi do głowy, że ktoś może skopiować bez zrozumienia. (Wydaje mi się, że cały czas uczę się nowych wad na tej stronie ...)

... doszedłem do wniosku, że ... zbyt wiele odwołuję się do innego kodu. Ciągle używam funkcji Google do wielu rzeczy, które, jak sądzę, powinienem być w stanie zrobić od zera, a to naprawdę trochę podważyło moją pewność siebie.

Wtedy się zatrzymaj. Kieruj się na chwilę w innym kierunku. Wykonaj wszystko sam, nawet jeśli wiesz , że możesz znaleźć dokładnie to, czego potrzebujesz w znacznie krótszym czasie.

Stało się tak, że twój mięsień rozwiązujący problemy (łacińska nazwa gluteus mojo ) zanikł z użycia i teraz go unikasz, ponieważ wiesz, jak słaba. Musisz zacząć budować i tonować ten mięsień, tak jak na bicepsie na siłowni. Zacznij od wysokich powtórzeń i niskiej odporności - wiele łatwych problemów. W miarę budowania pewności siebie przejdź do dłuższych, trudniejszych problemów.

Stopniowo poczujesz, że Twój Mojo powraca, a twoja potrzeba polegania na Google zmniejszy się. Ćwicz jednak ten mięsień i upewnij się, że nie wrócisz na swoje stare sposoby. Podejmij wyzwanie, aby najpierw rozwiązać problem, a dopiero potem poszukaj innych rozwiązań. Czasami okaże się, że inni znaleźli lepszy sposób na zrobienie tego samego, innym razem zdecydujesz, że twoje własne rozwiązanie jest lepsze.

Czy osoba jest złym programistą, stale szukając przykładów kodu dla zadań od średnich do złożonych?

Osoba, która nie jest w stanie nic zrobić bez znalezienia przykładów, jest złym programistą. Chodzi o to, że nie będziesz wiedział, czy jesteś w stanie, dopóki nie spróbujesz.

Jesteś młody i pracowałeś z wieloma językami programowania. Zgaduję, że prawdopodobnie poznajesz nowe języki szybciej niż stare. Nadal nie masz wystarczająco dużo czasu na jeden język w wystarczająco dużej aplikacji, aby rozwinąć płynność.

Czy szukasz za każdym razem szerokich rozwiązań, takich jak: cały proces łączenia sieci z tabelą bazy danych lub mniejszy element, taki jak formatowanie ciągu połączeń (muszę to sprawdzać prawie za każdym razem, odkąd piszę około czterech rocznie. )?

Zawsze będziesz szukać odniesień do składni różnych linii kodu lub funkcji. Im więcej programujesz, tym więcej wyzwań i różnych środowisk i zmian języka napotykasz. Jeśli potrzebujesz całego samouczka za każdym razem, gdy coś robisz, masz problem.

Miałem profesora, który zwykł mawiać, że nie znosi przeprowadzania testów opartych na próbie zachowania wielu informacji, które napchałeś poprzedniej nocy, ponieważ i tak dużo z nich zapominasz. Lepiej jest znać swoje zasoby i odpowiednio je wykorzystać, aby znaleźć informacje, których nie znasz. Lubię stosować podobną zasadę do wszystkiego, co robię, w tym do pracy.

Myślę, że najważniejszymi narzędziami, jakie masz, są twoje zasoby, o ile odpowiednio je wykorzystujesz. Więc kiedy piszę kod, docieram tak daleko, jak to możliwe z moją obecną wiedzą, a następnie przeprowadzam badania, pytając innych programistów lub przeszukując Internet, aby lepiej zrozumieć odpowiednie rozwiązanie. Wiedza będzie się powiększać z czasem, a po pewnym czasie będziesz w stanie lepiej poznać i zrozumieć umiejętności. Nieustannie szukam informacji, czy rzeczywiście potrzebuję tych informacji, i mogę szczerze powiedzieć, że każdego dnia uczę się czegoś nowego.

Jeśli rozumiesz problem, który próbujesz rozwiązać, i rozumiesz, jak chcesz go rozwiązać, wyszukiwanie poprawnej składni nie jest moim zdaniem wielkim problemem.

Ukończyłem szkołę około dwa lata temu i zostałem rzucony wilkom, kiedy dostałem pracę. Musiałem nauczyć się, utrzymywać i aktualizować dużą aplikację napisaną w języku, którego nigdy wcześniej nie dotykałem. Dostaję raport o błędzie, przeglądam kod i dowiaduję się, jak chciałem to naprawić, a potem muszę wyszukiwać w Google przykładów, jak robić rzeczy, które chciałem w tym języku.

Jeśli załatwiasz sprawy i rozumiesz to na tyle, aby nie powodować niepotrzebnej rezygnacji, prawdopodobnie nie masz nic przeciwko.

Czyste, bezkrytyczne kopiowanie i wklejanie, jak podano wielokrotnie w tych odpowiedziach, jest złe. Ale tak samo jest pisanie wszystkiego od zera. Jeśli nie jest to kluczowy element, który stanowi rdzeń Twojej firmy, poszukaj biblioteki lub fragmentu kodu, aby to zrobić w pierwszej kolejności. Wyjątkiem od znalezienia fragmentu jest to, że problem jest bardzo prosty, masz bardzo jasny obraz tego, jak to zrobić, a jeśli nie korzystasz z biblioteki: że raczej nie będziesz musiał nic więcej robić.

Wiem osobiście, że jeśli napiszę coś, co jest wspólne, prawdopodobnie będę mieć kilka subtelnych błędów i być może jeden lub dwa nie tak subtelne błędy bez wielu testów. Poszukuję podobnego rozwiązania, modyfikuję i testuję je, aby zaoszczędzić trochę czasu na testowaniu i rozwoju. Ponieważ w końcu jestem odpowiedzialny za dostarczenie produktu, który działa, jest rozszerzalny, ma lub nie ma budżetu i dotrzymuje terminów. Ponowne użycie kodu i bibliotek jest dobrym krokiem w tym kierunku.

Myślę, że czytanie przykładów kodu i po prostu czytanie kodu źródłowego tego, co opracowali inni ludzie, to najlepszy sposób na poprawę swoich umiejętności. Naprawdę myślę, że to otwiera drzwi w twoim mózgu, które inaczej by nie zostały otwarte.

Jeśli wymyślisz rozwiązanie A, a ktoś inny wymyśli rozwiązanie B, kiedy każdy z was podzieli się swoimi rozwiązaniami, można zrealizować rozwiązanie C, które może być nawet lepsze niż A lub B.

Myślę, że istnieje wiele poziomów biegłości w programowaniu. Właśnie dlatego, że istnieje wiele poziomów biegłości w dokumentacji oprogramowania . Szczerze mówiąc, w dzisiejszych czasach systemy są o rząd wielkości bardziej złożone niż wtedy, gdy zacząłem programować komputery w połowie lat osiemdziesiątych.

Następnie musiałeś wiedzieć, co chcesz zrobić z komputerem, i napisałeś dokumentację o grubości 6 cali, informującą o tym, jak komputer zrobił pewne bardziej podstawowe rzeczy. Przekształcenie tego, co chciałeś, w formę, którą mógł przyjąć komputer, polegało na znajomości zawartości indeksów tych książek i języka programowania (lub dwóch. Naprawdę, po nauczeniu się czterech lub pięciu języków pozostałe są tylko dialektami).

Dziś to zadanie wymaga znajomości języka, znajomości systemu, paradygmatu, modelu programowania i co najmniej jednego zestawu API, z których wszystkie są ruchomymi celami.

Tak więc osoba o pewnym poziomie podstawowej wiedzy, która się pyta, nie jest dobrym programistą. Jest najlepszym programistą, biorąc pod uwagę dzisiejsze środowiska i bezinteresowne firmy, takie jak Microsoft, w rzeczywistości stosują jakikolwiek rygor wobec własnej dokumentacji fundamentalnej. Większość z nich to odnośniki i niektóre bardzo zły przykładowy kod. (Dwa przypadki, z którymi się spotkałem, to „Instalator Windows” i interfejsy API do tworzenia plików filmów WMV.)

Ponieważ Microsoft, Google i, w mniejszym stopniu, Apple, wszyscy polegają na „społeczności”, aby zrekompensować ten bardzo realny niedobór, zadawanie pytań jest nie tylko ważne, ale ważne. Bycie osobą, której można zapytać i która może udzielić rzetelnych odpowiedzi i informacji zwrotnych w dzisiejszym środowisku, jest równie ważne. Dlatego strony, takie jak strony stackexchange.com , są tak samo pomocne, jak są.

Zadawaj więc pytania (proś inteligentnie!) O próbki i szanuj ludzi, którzy udzielają odpowiedzi, a robienie tego nie będzie postrzegane jako oznaka „złego programisty”.

I jeszcze jedno: dostarczanie złych próbek jest naprawdę oznaką złego programisty. Ułatwia to wykrycie złych programistów, ale także przyspiesza wyszukiwanie w Google. Jeśli brakuje ci zaufania do prostych, jednoznacznych, konkretnych próbek kodu, nie dawaj ich.

I proszę, nie kpij z tych, którzy pytają.

Wydaje mi się, że problem polega na tym, że nie rozumiesz, do czego się odnosisz, a bardziej z problemami z infrastrukturą i pamięcią. Jeśli to osłabia twoją pewność siebie, to tak, to problem - ale na pewno można go rozwiązać!

Dla mnie tego rodzaju wyzwania pojawiają się w wielu różnych aspektach mojego życia. Na przykład, aby być dobrym w wykonywaniu utworu muzycznego, muszę rozwinąć swoją niezależność od nuty, którą otrzymałem - jak naprawdę możesz poczuć muzykę, jeśli twój nos jest nadal zakopany w książeczce? Czasami, jeśli będę miał czas, zapamiętam cały utwór muzyczny - nawet jeśli nie jest to wymagane na moim koncercie. Dlaczego? Po usunięciu partytur znacznie łatwiej jest mi skoncentrować się na bardziej wymagających i nadrzędnych aspektach muzyki, które muszę poprawnie wykonać, i znacznie łatwiej jest mi wejść w tę niesamowitą strefę tworzenia muzyki. Uważam więc, że często warte dodatkowych kłopotów.

Moje doświadczenia z programowaniem były podobne. Myślę, że klucze to:

1. ćwicz język - wpisz go, uruchom, mów, jeśli pomoże; rób to wielokrotnie.
2. zbuduj swój obiekt - użyj tej samej funkcji lub wzoru w różnych sytuacjach; połączyć funkcje; tworzyć programy.
3. daj wystarczająco dużo czasu między powtórzeniami, aby upewnić się, że rzeczy naprawdę trafiają do twojej pamięci długoterminowej.

Te zasady wydają się obowiązywać podczas nauki dowolnego języka! Zobacz na przykład, jak zapamiętywać nowe słowa . Metoda Pimsleur również działa w ten sposób.

Przekonałem się, że prawie wszystkie zasady, składnia i wspólne biblioteki języka i technologii, z których regularnie korzystam, można całkowicie zapamiętać, używając tych kluczy. Mimo to ciągle przeszukuję Internet w poszukiwaniu przykładów i mądrości! Ale w tym momencie szukam potwierdzenia problemu, który próbuję rozwiązać, różnych podejść, narzędzi, które mogą pomóc, i konsultacji dla rzadziej używanych bibliotek. Jest to zupełnie inny rodzaj wyszukiwania niż ten, którego używam, kiedy uczę się języka i sięgam po szyję w tutorialach i instrukcjach.

Z twojej historii, oto kilka konkretnych przeszkód, które mogą Cię spotkać.

1. Jeśli masz problemy ze składnią, być może nie masz wystarczającej praktyki. Jest to szczególnie prawdziwe, jeśli kopiujesz i wklejasz bezpośrednio do swojego kodu, zamiast rozwijać powtarzanie i - czy mogę powiedzieć? - pamięć mięśni , która pomoże ci naprawdę dobrze. Aby temu przeciwdziałać, po prostu rozwijaj ćwiczenia i dyscyplinę, koncentrując się na powtarzalności i czasie, które poprawią twoją łatwość w wybranych obszarach. Propozycje:
   • Codziennie pisz prosty program w tym samym języku.
   • Wpisz przykłady zamiast je kopiować i wklejać.
2. Jeśli masz problemy z budowaniem rozwiązań problemów średniej wielkości, być może nie masz wystarczającego doświadczenia w budowaniu. Spróbuj tych:
   • Rozpocznij projekt średniej wielkości w technologii lub języku, w którym chcesz być dobry. Lub spróbuj swoich sił w chunkier w projekcie open source, który Cię interesuje. Zrób to trochę każdego dnia. (Pamiętaj, że kiedy wybierasz się na większe projekty: idź do nich cegła po cegle. Nie próbuj budować całości na raz!)
   • Korzystaj z tej samej nowej funkcji przez cztery kolejne dni, w czterech różnych kontekstach.
   • Podejmij wyzwanie, aby zakodować coś przy wyłączonej przeglądarce internetowej!
   • Właściwie rób notatki na temat rzeczy, których się uczysz. Zsyntetyzuj to, czego się uczysz, i zapisz swoje obserwacje. (Właściwie spisywanie rzeczy i zmuszanie się do wyrażania czegoś własnymi słowami bardzo mi pomaga).
   • Napisz odpowiedzi i zweryfikuj je w przypadku pytań StackOverflow dotyczących technologii, którą absorbujesz. (Często ma to dodatkową zaletę, że zyskujesz trochę reputacji podczas nauki. :-))
3. Być może zbyt cienko rozpowszechniasz swoją praktykę. Wygląda na to, że pracujesz w wielu różnych językach. Ma to wiele zalet, ale ma tę wadę, że osłabia twoje doświadczenie. Jeśli spędzasz czas pracując w pięciu różnych językach, zapamiętasz mniej niż jeśli spędzasz ten sam czas w jednym języku. Co gorsza, istnieje wiele niezupełnie podobnych koniunkturalnych między różnymi językami (czy to inaczej, jeśli, elsif lub elif?), Aby cię potknąć. Aby temu przeciwdziałać, wyostrz ostrość. Wybierz jedną rzecz do nauczenia się i naucz się na zimno. Następnie przejdź do następnej rzeczy.

Myślę, że jeśli skupisz się na wymyślaniu umiarkowanego kodu, zwiększysz swoją wydajność i produktywność. Prawdopodobnie więcej czasu zajmuje wyszukiwanie kodu, czytanie / rozumienie go, kopiowanie go do źródła, odpowiednie modyfikowanie itp.

Jeśli sam to wymyślisz, najprawdopodobniej lepiej dostosuje się do konkretnej sytuacji, a po pewnym czasie te rozwiązania przyjdą Ci szybciej niż ich wyszukiwanie.

Spoglądam na to tak, jakbyś chciał mieć drugą opinię na temat określonego rozwiązania, więc możesz sprawdzić, jak robią to inni (w Internecie). Jeśli okaże się, że za bardzo to robisz / chcesz, pomyśl o tym, pytając kolegę o to, co myśli o rozwiązaniu. Jeśli zadajesz swojemu koledze pytanie co 15 minut, prawdopodobnie będzie zirytowany. Dlatego zadajesz mniej pytań i sam próbujesz je wymyślić.

Wyobraź to sobie, gdy chcesz szukać rzeczy w Internecie.

Najlepszy sposób, aby dowiedzieć się, czego nie wiesz: google! Uważam, że masz rację na równi z większością programistów. Umieść kompleks niższości w plecaku i wejdź z otwartym umysłem.

Nie bój się zadawać pytań, przeprowadzać badań w Google, próbować i zawieść. To wszystko jest częścią tego.

Tworzenie oprogramowania w ustawieniach korporacyjnych wymaga ponownego użycia kodu. Po co przepisywać funkcję / metodę, jeśli interfejs API już istnieje i jest powszechnie używany? Najprawdopodobniej będzie tak samo wydajny jak wszystko, co napiszesz, i zajmie mniej czasu.

Oczywiście sukces w tworzeniu oprogramowania wymaga również przerwy w pracy z klawiaturą, abyś mógł przeczytać i zrozumieć, co się naprawdę dzieje. Weź dowolny framework internetowy. Powinieneś wiedzieć, co się dzieje pod spodem, więc rozumiesz kod, który piszesz, ale prawdopodobnie nigdy nie będziesz musiał samodzielnie pisać frameworka.

Musisz tylko napisać kod, który korzysta z tego rodzaju frameworka (powiedzmy, że frameworka oparta na komponentach wymaga określonego stylu) i wynika to ze zrozumienia szerszego obrazu. Dowiedz się większy obraz i wszystko będzie dobrze.

Z udzielonych odpowiedzi jasno wynika, że ​​nie ma nic złego w badaniu twojego problemu, zamiast ślepego kodowania. Ale pytanie, na które nie udzielono odpowiedzi, ponieważ nie zadałeś tego bezpośrednio, brzmi: dlaczego czujesz się niepewnie - i co możesz z tym zrobić? W końcu wiele osób wyszukuje w Google swoje problemy i ma dużo pewności siebie (nawet ci, którzy nie powinni ...)

Co więc robić? Może po prostu potrzebowałeś kilkuset klepnięć w plecy, które właśnie dostałeś, i teraz możesz kodować z pewnością. Ale jeśli to nie zadziała, proponuję przyjrzeć się automatycznym testom i rozwojowi opartemu na testach. Nic nie mówi „dobrze zrobione” jak „Wszystkie testy zdane” z zestawu testów: kiedy tam dotrzesz, wiesz , że zrobiłeś to dobrze.

Powinieneś także spróbować rzucić sobie wyzwanie: mówisz, że zawsze szukasz składni, którą już znasz; więc zmuś się do napisania kodu bez sprawdzania składni, a dowiesz się (wkrótce, jeśli nie natychmiast), że wszystko idzie dobrze.

Programiści nie rodzą się „wspaniali”, ale wielkość nie przychodzi automatycznie z doświadczeniem. I odwrotnie, brak doświadczenia nie czyni dewelopera „złym”. Różnica między wielkim i złym programistą nie leży w ich wiedzy domenowej, ale w ich metodyce. Znakiem rozpoznawczym wielkiego programisty jest to, że koduje on świadomie. Innymi słowy, dobry programista zawsze wie, dlaczego coś robi. Z punktu widzenia etyki osobistej wymaga to odwagi intelektualnej i uczciwości.

Bardzo ważne jest, aby poświęcić trochę czasu i zrozumieć podstawy, bardziej złożone rzeczy, które w zasadzie składają się na to. Jeśli nie ma podstaw do zrozumienia języka i tego, co dzieje się za kulisami, kodowanie będzie po prostu hakowaniem…

Więc czytanie książek z przykładami i odwoływanie się do nich jest złym programowaniem jest kontekstem twojego pytania. Cóż, ponieważ niewiele osób dokumentuje swój interfejs API, pozostało nam tylko książka.

Nie wiem, jakie są powody, dla których warto zadać to pytanie, być może możesz sam na nie odpowiedzieć po przeczytaniu mojej sytuacji, ponieważ odsyłam do wielu przykładów kodu.

Nigdy nie miałem szansy pójść na uniwersytet, ponieważ byłem na ulicy w wieku 16 lat. W jakiś sposób w wieku 24 lat byłem w stanie uczyć się przez kolegium korespondencyjne i robić certyfikaty sprzedawcy jako SCJP, SCJD, SCBCD i SCWCD. Muszę przyznać, że czasami walczyłem i musiałem szukać przykładów online. Jednak nieświadomie miałem w tym czasie guza mózgu rosnącego w głowie (do 2010 r. Był wielkości pomarańczy). Po moich 5 operacjach mózgu, 6 tygodniach łączących chemioterapię / radioterapię i 10 miesięcy chemio, nadal programuję z ręcznie napisanymi kodowanymi stronami, które są widoczne z mojego profilu.

Tak, potrzebuję teraz wielu przykładów kodu z uszkodzeniem mózgu, więc czy to czyni mnie złym programistą?

Widzę więc, że wspomniałeś, że idziesz na hackaton. W ubiegłym roku byłem w kilku (ponad 15) i zauważyłem, że są świetne do nauki. Przez świetną naukę rozumiem naukę, jak nigdy więcej tak nie kodować. Przeważnie staram się robić coś nowego na każdym hackathonie, do którego chodzę, aby móc uczyć się nowych rzeczy. Ponieważ istnieje ogromne ograniczenie czasowe, polegasz tylko na skopiowaniu wklejenia całego kodu, który możesz znaleźć, a to cię gryzie w tyłek podczas testowania.

Jednak z tego wynikają dobre rzeczy: A) DOWIEDZ SIĘ tak dużo podczas testowania błędów (również mocno płacz) B) Wiedz, że nigdy więcej tak nie koduj i ucz się lepszych praktyk kodowania. Ponadto podczas hackathonów spotkasz ludzi, którzy mogą nauczyć cię tak wielu nowych rzeczy, o których nigdy nie wiedziałeś, i będziesz robić rzeczy, których nigdy nie będziesz robić w szkole.

Więc mówię, że wklejanie kopii jest złe i nie nauczysz się niczego, a czas zaoszczędzony na wklejaniu kopii ugryzie cię później podczas testowania błędów i nie masz pojęcia, co nawet napisałeś, jest 8 rano, i są nasycone całą kofeiną. Ale myślę, że dopóki będziesz testować swój kod, będziesz musiał nauczyć się wszystkiego, co wcześniej skopiowałeś.

Nie nazywam siebie dobrym programistą. Ale to, co robię, jest proste. Jeśli nie wiem, jak coś zrobić, faktycznie patrzę na jakiś kod / przykład w Internecie. Następnie po przeczytaniu staram się go przepisać, zoptymalizować i użyć rzeczy, które najlepiej pasują do kodu, który chcę.

Uwaga: czytanie kodu z Internetu nie czyni cię złym programistą. Zawsze dobrze jest patrzeć, jak robią to inni ludzie, i zawsze się czegoś nauczysz. Ale kopiowanie go na ślepo nie jest dobre.

Jeśli programista / uczeń powie .. Wikipedia .., aby skopiować / wkleić kod do swojego projektu, to po prostu próbuje go „uruchomić”, wtedy jedyne umiejętności, które rozwija ta osoba, to „Jak google”. Może tam być pewien proces osmozy, ale nie cała grupa. (Nie uwierzyłbyś, ile osób to robi na studiach)

JEDNAK, jeśli przeanalizujesz kod innych ludzi i naprawdę pomyślisz o tym, co dzieje się w samym kodzie, nie oznacza to, że osoba jest złym programistą. To czyni ich zdeterminowanym programistą i prawdopodobnie wskazuje styl uczenia się, który jest bardziej dotykowy lub wizualny. Uczę się bardzo dobrze na przykładach. Jeśli ktoś mi coś mówi lub próbuje mi to wytłumaczyć, zwykle proszę, aby pokazał mi, o czym mówi.

Przeglądanie, analizowanie i uczenie się na podstawie kodu sprawia , że z czasem są dobrym programistą , ponieważ czytają i uczą się w języku, którego używają.

Często żartuję, że znam tajniki języków komputerowych niż mój rodzimy język angielski. Co nasuwa pytanie; „Wyjaśnisz mi to w Java PLZ?”

Myślę, że to trochę jak gra w szachy. Sprawdzamy elementy indywidualnie i sprawdzamy, gdzie mogą się poruszać zgodnie z zasadami, i musimy przejść przez to świadome sprawdzanie przez pewien czas, aż podświadomość się włączy, odsłaniając wzory i natchnione sekwencje.

Przy programowaniu może być więcej kawałków i reguł, często potykam się ze składnią i utknąłem na błędach, które można znaleźć na zawsze, przechodząc przez „reguły”, ale w końcu podświadomość zacznie działać. Kiedy pozostanie wystarczająco długo, mogę przeczytać czasem wracać i zastanawiać się, co potrafi.