Patrząc wstecz na moją karierę i życie jako programista, było wiele różnych sposobów doskonalenia umiejętności programistycznych - czytanie kodu, pisanie kodu, czytanie książek, słuchanie podcastów, oglądanie screencastów i wiele innych.

Moje pytanie brzmi: jaka jest najbardziej efektywna rzecz, którą zrobiłeś, która poprawiła twoje umiejętności programowania? Co poleciłbyś innym, którzy chcą poprawić?

Spodziewam się tutaj różnych odpowiedzi i nie ma jednej odpowiedzi „jeden rozmiar dla wszystkich” - chciałbym wiedzieć, co zadziałało dla różnych osób.

Bez określonej kolejności ...

• Praca z ludźmi o wiele mądrzejszymi ode mnie

• Zawsze słuchając tego, co mają do powiedzenia inni, niezależnie od tego, czy są młodsi, średniozaawansowani, starsi czy guru. stanowisko nie ma znaczenia.

• Uczenie się innych frameworków / języków i sprawdzanie, jak oni to robią, i porównywanie tego do rzeczy, które już znam

• Czytanie o wzorcach, najlepszych praktykach, a następnie badanie moich starych rzeczy i stosowanie tych wzorców w razie potrzeby

• Programowanie w parach

• Nie zgadzam się ze wszystkim, co mówi Joel. ;)

Decydując DO być „Jack-o-all-handlu”

Dość wcześnie w swojej karierze byłem ekspertem w zakresie konkretnej bazy danych i języka programowania. Niestety, ta konkretna baza danych straciła „wojny baz danych” i odkryłam, że moje opcje kariery były… ograniczone. Po tym świadomie zdecydowałem, że nigdy więcej nie pozwolę się tak zamknąć. Studiowałem więc wszystko, co mogłem zdobyć: Windows, Unix, C, C ++, Java, C #, Perl, Python, Access, SQL Server, Oracle, Informix, MySQL itp. Bez względu na to, jakie narzędzia i technologie są nowe lub nietypowe, ja został „idącym do faceta” - „Zapytaj Craiga, jeśli tego nie wie, nauczy się”. W rezultacie pracowałem nad wszelkiego rodzaju projektami, od systemów wbudowanych do telemetrii środowiskowej po systemy dowodzenia i kontroli obrony przeciwrakietowej.

Jedyny problem, jaki kiedykolwiek miałem, to firmy, które nalegają, aby zrobić dziurę w specjalności, kiedy moją specjalnością jest generalizacja. [EDYCJA: Znany również jako Polymath lub Renaissance Man lub multi-specjalista. ]

O czym należy pamiętać ... jaki jest okres półtrwania wiedzy w zaawansowanych technologiach? Śledzi to według prawa Moore'a: połowa wszystkiego, co wiesz, stanie się nieaktualna za 18-24 miesiące. Ekspert, który wybierze niewłaściwą dyscyplinę, może łatwo zostać podważony przez technologię; generalista musi tylko dodać trochę więcej umiejętności i pamiętać o lekcjach z przeszłości w stosowaniu tych umiejętności.

Zawsze myślałem o sobie jako o programatorze pracującym na gorąco. Potem do naszego zespołu zatrudniono nowego faceta, nazywającego go Aaron. Aaron był oczywiście znacznie lepszy ode mnie w większości dziedzin. On też był młodszy ode mnie. Uświadomił mi, że tak naprawdę niewiele się poprawiłem w ciągu ostatnich lat. Byłem hakerem ad hoc i przeciętnym.

Zaalarmowało mnie to, że świadomie próbuję poprawić siebie, a zwłaszcza jakość kodu, który piszę.

Aaron poprowadził mnie do nauki wielu rzeczy. Nauczył mnie, w jaki sposób większość kodu, który piszę, będzie musiała być utrzymywana i rozszerzana przez co najmniej kilka lat, więc powinienem o tym pisać. Powinienem napisać automatyczne testy dla mojego kodu. Aaron zawsze mówił o tym, jak nigdy nie powinienem zatrzymywać się przy pierwszej działającej wersji, ale ulepszaj i dopracowuj, dopóki kod nie będzie elegancki. Odkryłem, że języki i narzędzia, których używałem, miały wiele miejsca na ulepszenia.

Najważniejszą rzeczą, której nauczyłem się od Aarona, było to, aby nigdy nie przestawać się uczyć.

Po kilku latach Aaron opuścił firmę. Czułem się pusty. Ostatnie lata spędzone z nim podniosły mnie na zupełnie nowy poziom umiejętności i zdałem sobie sprawę, że jestem teraz znacznie lepszy niż reszta zespołu. Wciąż pisali zły kod i popełniali te same błędy, co wcześniej. Próbowałem ich uczyć, ale oni nie byli zainteresowani nauką. W rzeczywistości denerwowało ich, że ktoś byłby tak arogancki, aby powiedzieć im, jakie popełniają błędy.

Kilka miesięcy później opuściłem firmę. Przeprowadziłem się do mniejszej firmy z bardzo utalentowanym zespołem. Wszyscy tam chcieli dowiedzieć się więcej i bardzo mi się podobało.

Cieszę się, że poznałem Aarona. Bez niego pewnie nadal pracowałbym w starym towarzystwie ze starym gangiem, nigdzie się nie wybieram i zbyt dużo o sobie myślę.

Dwie rzeczy:

1. Przeczytaj kod napisany przez różne osoby.
2. Napisz dokumentację do kodu napisanego przez inne osoby.

Pisanie kodu jest niezwykle łatwe; każda inna osoba, którą znam, może to zrobić. Ale odczytanie kodu innej osoby i ustalenie, co ona robi, było dla mnie zupełnie nowym światem.

Regularnie chodź na siłownię.

Poważnie, mój mózg działa o wiele lepiej, gdy jestem w formie. Problemy stają się łatwiejsze i mniej przytłaczające, wygłupianie jest znacznie mniejszą pokusą, a praca nad krokami krok po kroku nie wydaje się tak trudnym zadaniem.

Programowanie. Praca nad ciekawymi projektami. Nie ma NIC takiego jak wejście i praca nad rzeczami. Zwłaszcza pod presją. Zawsze mówię każdemu, kto pyta mnie, jak programować - po prostu znajdź fajny projekt (nawet jeśli musisz go wymyślić) i popracuj nad nim.

Podjąłem pracę w niepełnym wymiarze godzin, ucząc studentów CS na moim uniwersytecie. Naprawdę zmusza cię do zrozumienia czegoś na zupełnie innym poziomie, kiedy musisz wyjaśnić to komuś innemu.

1. Jestem wielkim fanem systemu „ucz się jednego języka programowania każdego roku”. Jeden rok daje ci wystarczająco dużo czasu, aby przejść przez „okej, znam składnię, więc teraz znam język” i zmusza cię do pójścia trochę dalej i zrozumienia, co jest korzystne w tym języku, i programowania w stylu natywnym dla ten język (Rozumiem przez to, że nie kończysz pisać aplikacji Java przy użyciu składni Ruby). Każdy język zmieni sposób myślenia o programowaniu - wiedziałem, jak korzystać z rekurencji, ale myślenie w rekurencji nie miało miejsca, dopóki nie wziąłem lekcji prologu (wyobrażam sobie, że funkcjonalny język, taki jak ML, miałby taki sam efekt).

2. Rozpocznij projekt zwierzaka. Moje osobiste równanie dla dobrego projektu zwierzaka to coś, z czym masz doświadczenie + coś, czego nie = aplikacja, która byłaby dla Ciebie przydatna. Na przykład Migratr (mój własny projekt z kofeinowym weekendem, który zakończył się w toku) zaczął jako „Wiem c #, ale nigdy nie kodowałem w sieci Web API. Chcę przenieść wszystkie moje zdjęcia do Zooomr”. Równie łatwo mogłoby to brzmieć „Kodowałem wcześniej w interfejsie API internetowych, ale nie znam C #”

Publikowanie projektu twojego zwierzaka jest samo w sobie niesamowitym doświadczeniem edukacyjnym. Nagle wszystkie rzeczy praktycznie nikt nie uczy, ale wszyscy powinni wiedzieć (dla mnie było to konfigurowanie własnego systemu testowego, jak najlepsze wykorzystanie systemów kontroli wersji, jak zadbać o siebie, gdy nikt inny nie określa twoich terminów, jak wchodzić w interakcje z twoim użytkownicy i jak wiedzieć, kiedy powiedzieć „nie”, aby polecać funkcje), to wszystko powoduje wypychanie bąbelków na powierzchnię i zmusza do samokształcenia na poziomie, w którym nie byłeś wcześniej - przynajmniej przez bezczynne czytanie flamewars na dzone o zalety / wady sposobu robienia rzeczy „foo” vs „bar”.

Wykonanie tych dwóch czynności obejmuje oba końce spektrum. Nauka nowego języka sprawi, że będziesz lepszym programistą. Projekt zwierzaka sprawi, że będziesz lepszym programistą: P

Nauczyłem się montażu. Czy to na starym układzie 6502, gdy miałem 13 lat? 14? Za dawno. Ale nie mogę wymyślić niczego, co poprawiłoby twój rozwój bardziej niż zejście do poziomu bitowego.

Uczenie się w assemblerze daje wgląd w sposób, w jaki komputery „myślą” na zasadniczo niższym poziomie, a elegancja na tym poziomie jest zaskakująca ... nie ma zmarnowanych ruchów, nie „pozbywa się” danych. Rozwój na tym poziomie nauczy Cię wydajności i doskonali umiejętności krytycznego myślenia i logiki. To również wyleczy cię z wszelkich niedbałych nawyków, które masz dość szybko!

Układ 65xx miał trzy rejestry (akumulator, X i Y) i brak instrukcji poziomu maszyny do mnożenia lub dzielenia. Pamiętam, jak kodowałem procedurę obliczania zniszczeń w bitwie, przeglądałem książkę i nagle uświadomiłem sobie, że będę musiał napisać własną bibliotekę matematyki. Spędziłem kilka tygodni, zapisując cyfry 1 i 0 w całym moim notesie, próbując dowiedzieć się, co tak naprawdę oznaczają „dzielenie” i „miejsca dziesiętne”.

Od tego czasu studiowałem C ++, pascal, .NET, wiele innych ... ale żaden z nich mnie tak nie nauczył, nie zaintrygował ani nie pozostawił poczucia „wow”, które zrobiło moje stare komodore .

Patrząc wstecz na stare rzeczy, które napisałem, i zdając sobie sprawę, jak złe były.

Czytać

• książki, nie tylko strony internetowe
• do samodoskonalenia, nie tylko w przypadku najnowszego projektu
• o poprawie handlu, nie tylko o najnowszą technologię
• czytaj kod, nie tylko nad czym pracujesz.

Po prostu rozwijaj apetyt na czytanie.

Programowanie.

Poważnie, są książki, są kata kodujące, są takie strony, ale uważam, że najlepszym sposobem na ulepszenie jako programisty jest praca nad prawdziwym projektem, z prawdziwymi zmiennymi klientami o rzeczywistych, ciągle zmieniających się wymaganiach z prawdziwą inżynierią problemy. Nic nie zastąpi doświadczenia.

Myślę, że najważniejszą rzeczą, jaką możesz zrobić, jest świadomy wysiłek na rzecz poprawy. Nie ma jednej srebrnej kuli, musisz ciągle szukać nowych źródeł informacji, nowych doświadczeń i więcej praktyki.

I drugą najważniejszą rzeczą, zastanów się, co robisz, dlaczego to robisz i jak możesz to zrobić lepiej. To samo z poprzednimi projektami. Spójrz wstecz na to, co zrobiłeś i jak teraz możesz to zrobić inaczej. Pomyśl o tym, co można było zrobić lepiej lub gdzie można to jeszcze poprawić.

Codziennie widzę dwa świetne tego przykłady. Mam jednego współpracownika, który uwielbia się uczyć i chce być najlepszym programistą, jakiego potrafi. Wykorzystuje wszelkie przestoje, aby czytać blogi, czytać książki, omawiać techniki programowania i zadawać mnóstwo pytań. Poprawił się także w ciągu ostatniego roku. Inny współpracownik wykonuje swoją pracę i robi to całkiem dobrze. Ale to wszystko, co robi. Trzyma się tego, co wie, nie stara się wiele ulepszać, nie pracuje nad żadnymi projektami poza swoimi istniejącymi, a po 4 latach ma dokładnie taki sam zestaw umiejętności i umiejętności programowania, jakie miał, kiedy się poznałem mu.

Wiele osób sugerowało pisanie kodu. Muszę powiedzieć, że czytanie kodu innych osób jest znacznie bardziej korzystne.

Programowane parami z bardzo różnorodnymi i opiniotwórczymi ludźmi

Podstawowe rzeczy, które pomogły mi jako programistom:

• Nauczyłem się pisać na klawiaturze.
• Nauczył się pokonywać nieśmiałość i zadawać pytania.

Wpisanie dla programisty jest niezbędne. Każdy miał współpracownika „programisty”, który pisał na klawiaturze dokładnie dwoma palcami i musiał wszystko sprawdzić na klawiaturze. Nie śmieszne. Nauka obsługi dotyku znacznie zwiększa produktywność programisty.

A jeśli nie zapytasz, nikt ci nie powie.

Udział w projektach typu open source był dla mnie zdecydowanie najważniejszy.

Możesz przeczytać wszystkie książki, kod i projekty open source, które ci się podobają, ale musisz zrozumieć aspekt rozwoju oprogramowania dla użytkownika końcowego. Musisz wyjść z komory echa. Zajmę się więc kilkoma nietechnicznymi kwestiami, które pomogą twojej karierze technicznej.

1. Odsuń się od klawiatury i wejdź w interakcję z użytkownikiem końcowym i zobacz, jak widzą, jak korzystają z oprogramowania. Użytkownicy końcowi zazwyczaj nie są techniczni, więc widzą oprogramowanie jako magiczną pracę, a oprogramowanie jako logiczny zestaw kroków. Dwa światy są zupełnie inne. Więc to, co wydaje się łatwe i logiczne, może wydawać się tajemnicze i zastraszające dla innych.

2. Test, test, test. Wiele programów, które widziałem w dużych korporacjach, wykorzystuje przypadki testowe. Do diabła, używają JUnit, xUnit i wszystkich innych dostępnych języków testowania jednostek. Problem, który widziałem, polega na tym, że większość programistów nigdy nie widzi, jak wygląda ich oprogramowanie w środowisku produkcyjnym. Dowiedz się, w jaki sposób użytkownicy (lub systemy, jeśli są to zadania wsadowe) wchodzą w interakcję z aplikacją, biblioteką lub interfejsem, aby dowiedzieć się, jakiego rodzaju odrażające informacje na nich rzucają. Pomoże Ci to wygenerować dobre przypadki testowe i przestaniesz zakładać, że Twój program zawsze będzie otrzymywać poprawny zestaw danych.

Nauczył się programu.

Pisanie kodu i dużo.

Nauka wyrażeń regularnych.

Rywalizacja w konkursach TopCoder Algorytm .

Idź na całość: stwórz własny projekt, kamienie milowe, zasoby, zależności, wymagania i plan testów. Zmusi cię to nie tylko do poprawienia umiejętności programowania w zakresie określonych parametrów, ale również do podkreślenia, gdzie najbardziej potrzebujesz poprawy. Regularnie aktualizuj swoje postępy, czy to za pośrednictwem bloga, czy też bardziej formalnych aktualizacji projektu, abyś mógł dokładnie zobaczyć, gdzie byłeś i dokąd chcesz się udać.

Rzuć moją ostatnią pracę.

Myślę, że ciągłe kwestionowanie tego, co robisz, jest najważniejsze. Nigdy nie myśl, że Twój kod jest doskonały, zawsze staraj się go ulepszać.

Wygląda na to, że miałem 2 lub 3 razy, kiedy myślałem, że mój kod jest idealny, a potem zdałem sobie sprawę, że mam przed sobą długą drogę.

Wydaje mi się, że największą rzeczą było to, że zacząłem postrzegać mój kod jako pochłaniany przez innych programistów, a nie maszynę. Łatwo jest napisać kod, który urządzenie może przetworzyć, ale trudne jest pisanie SUCHEGO, zrozumiałego kodu.

I nie chodzi mi tylko o zrozumienie „Co robi ta linia”, mam na myśli uczynienie trywialnym zrozumienie „Jak ta klasa pasuje do wszystkich innych klas”, jednocześnie czyniąc interfejs klas tak dobrze uformowanym, że jest to praktycznie niemożliwe niewłaściwie go używać.

Mówią, że 70% dobrego kodu to sprawdzanie błędów i obsługa. Kiedy zacząłem programować w ten sposób, mój kod stał się znacznie lepszy. Myślenie o tym, co może pójść źle, a następnie natychmiastowe radzenie sobie z nim, zrobiło ogromną różnicę. To czuje się jak robi wszystko, sprawdziany dopiero się w sposób dotarcia kodu w górę i działa, ale skraca czas od początku do końca przez współczynnik 2 do 4.

Kim są ci ludzie „oni” i gdzie „oni” żyją?

Moje umiejętności kodowania znacznie się poprawiły, kiedy zacząłem się zastanawiać, zanim zacznę coś wdrażać, jak mam to udokumentować .

„Rzecz” tutaj powinna mieć możliwie największą ziarnistość. Od metody do całego produktu. Na przykład na poziomie metody zapobiega dodaniu metody w interfejsie API, która nie pasuje lub jest niejasna, przed jej faktycznym napisaniem. A jeśli naprawdę muszę wdrożyć metodę, której nie mogę (łatwo) udokumentować, to znak, że gdzieś jest problem projektowy ...

Automatycznie postawa „ jeśli nie potrafię tego wyjaśnić, nie piszę ” odfiltrowuje zły kod i odwrotnie, gdy wiem, jak poprawnie udokumentować rzecz, staje się prostsza i czystsza w implementacji.

Ciągle ucz się i ćwicz to, czego się uczysz.

Za pomocą:

1. Projekty osobiste: Odkąd zacząłem programować, realizuję projekty osobiste. Począwszy od małych gier, przetwarzania obrazu, steganografii, wdrażania specyfikacji typów plików, wdrażania różnych protokołów od zera lub wdrażania różnych programów w czasie.

2. Czytanie książek: W wolnym czasie postanowiłem czytać i przeglądać różne książki. Istnieje wiele dobrze napisanych książek ekspertów, którzy siedzą i czekają na przeczytanie. Głębokość, jaką można uzyskać z książki, nie ma sobie równych, na przykład czytając różne posty na forum.

Zwykle jest to mój chronologiczny porządek uczenia się każdej nowej technologii:

1. Regularnie czytaj dobre blogi (Atwood, Martin Fowler itp.), Bądź na bieżąco z nowościami technologicznymi, Śledź rzeczy o ciekawych nowych technologiach. Te kroki pozwolą mi zdecydować, czy znajdę coś interesującego do dalszego zbadania.

2. Przeczytaj odpowiednią książkę lub inny materiał do nauki na swoim poziomie (np. Dla początkujących, jeśli chcesz nauczyć się wzorców projektowych, sugerowałbym „Wzory wzornictwa na pierwszym planie”). Mam również określone preferencje dotyczące książek .

3. Za pomocą tego, czego się nauczyłem, zrealizuj projekt zabawkowy lub dwa. Nie martwię się o przydatność projektu. Moim zamiarem jest wykorzystanie mojej wiedzy. (np. projekt kalkulatora dla OOP byłby w porządku)

4. Zobaczę, czy będę mógł użyć tego w pracy . (np. chociaż nie używamy subversion w pracy, używam go jako mojego lokalnego repozytorium, użyłem Ruby do zadania, które w innym przypadku byłoby zbyt monotonne i czasochłonne)

5. To najlepsza część, którą, jak sądzę, większość ludzi tęskni. Sesje dzielenia się wiedzą. Daj sesję lub dwie innym członkom zespołu, na przykład. Wierzę, że nauczanie jest jednym z najlepszych sposobów, aby naprawdę nauczyć się technologii. Gwarantuję, że Twój poziom zrozumienia technologii stanie się wielorakie, niezależnie od tego, czy odbiorcy ją dostaną, czy nie. :-)

Włam się na jakiś projekt open source przez kilka miesięcy; im większy tym lepszy. Kiedy wchodzisz w interakcję z niektórymi wysoce opiniotwórczymi, zróżnicowanymi geograficznie ludźmi, którzy cię nie znają, nie możesz pomóc, ale uczyć się na własnych błędach znacznie szybciej - myślę, że to pewien czynnik zawstydzający. Ponadto, jeśli zidentyfikujesz jednego lub dwóch naprawdę inteligentnych ludzi, możesz uzyskać od nich cenny wgląd, jeśli nie czystą wiedzę.