Zawsze powtarzałem, że profesjonalny twórca oprogramowania nie przestaje się uczyć nigdy.
Pragmatyczny programista mówi:
- Naucz się jednego języka na rok
- Przeczytaj branżową książkę raz na kwartał
- Czytaj także niebranżowe książki
- Korzystaj z kursów
- Uczestnicz w spotkaniach lokalnych społeczności
- Eksperymentuj z różnymi środowiskami
- Bądź na bieżąco
- Interesuj się (blogi, wykop, HackerNews, itp.)
Generalnie to fajne pomysły, ale jak to koreluje się z tym, co napisałem ostatnio we wpisie: Bicie piany gdzie twierdzę, że można niewiele zyskać z nauki nowego języka czy frameworku, ponieważ nasza branża zbliża się do pewnego rodzaju asymptoty technologii i frameworków. To znaczy, czy powinniśmy się uczyć nowego języka każdego roku, skoro niewiele można na tym zyskać?
Tak, oczywiście. Powinieneś uczyć się jednego nowego języka każdego roku. Kiedy to robisz, okazuje się, że pewne aspekty języków programowania stają się powtarzalne.
Kiedy uczysz się Lua okazuje się, że to po prostu JavaScript (i odwrotnie). Kiedy uczysz się Ruby, okazuje się, że to tak naprawdę Python, tylko w innych ciuszkach. Kiedy uczysz się Swifta odkrywasz, że to odgrzewana Java, która przeszła zapachem Pascala. Uczysz się języka GO i dochodzisz do wniosku, że to mieszanina C, Javy i Erlanga.
Zaczynasz widzieć pewne wzorce, które stoją za tymi językami i uświadamiasz sobie, że jest ich niewiele. Powoli dochodzisz do wniosku, że istnieją lepsze rzeczy do robienia w życiu niż odkrywanie niekończonych się kombinacji tych wzorców.
A więc, tak. Naucz się jednego nowego języka każdego roku, aby dojść do wniosku, że całkiem dobrze wyeksplorowaliśmy domenę języków programowania.
To samo odnosi się do frameworków. Naucz się jednego nowego frameworku rocznie, a zaczniesz uświadamiać sobie, że żaden z nich nie jest tak naprawdę nowy. Zaczniesz uświadamiać sobie, że, tak jak w przypadku języków, pod spodem jest lista powtarzalnych patternów, i jest to liczba ograniczona, i jak bezsensowne jest miksowanie tych patternów we wszystkich możliwych kombinacjach.
Czy ten punkt widzenia napawa Cię pesymizmem? Nie powinien. Fakt, że przeszliśmy wzdłuż i wszerz jakiś kawałek naszej profesji nie oznacza, że inne części są poznane. O kurka! Okazuje się, że lista, rzeczy do nauczenia się i poprawienia biegłości jest dosyć duża. Co więcej, podczas naszej niekończącej się krucjaty poznawania nowych języków i frameworków zaniedbaliśmy te rzeczy.
A więc, dla przykładu, porozmawiajmy o współbieżności. Jest to dziedzina, w której naprawdę leżymy i kwiczymy. Czy nie nadszedł już najwyższy czas, aby to zmienić? Czy nie byłoby dobrym pomysłem poznanie domeny współbieżności w stopniu, w jakim poznaliśmy domenę języków. Czy nie jest to szczególnie prawdziwe w czasach, gdy nasze aplikacje są coraz bardziej uzależnione od wieloprocesorowych środowisk? Czy gwałtowny wzrost liczby aplikacji hostowanych w chmurze oznacza, że możemy poszczycić się coraz lepszym zrozumieniem współbieżności?
No dobra, pozwól mi przetestować trochę Twoją wiedzę:
Kiedy uczysz się Lua okazuje się, że to po prostu JavaScript (i odwrotnie). Kiedy uczysz się Ruby, okazuje się, że to tak naprawdę Python, tylko w innych ciuszkach. Kiedy uczysz się Swifta odkrywasz, że to odgrzewana Java, która przeszła zapachem Pascala. Uczysz się języka GO i dochodzisz do wniosku, że to mieszanina C, Javy i Erlanga.
Zaczynasz widzieć pewne wzorce, które stoją za tymi językami i uświadamiasz sobie, że jest ich niewiele. Powoli dochodzisz do wniosku, że istnieją lepsze rzeczy do robienia w życiu niż odkrywanie niekończonych się kombinacji tych wzorców.
A więc, tak. Naucz się jednego nowego języka każdego roku, aby dojść do wniosku, że całkiem dobrze wyeksplorowaliśmy domenę języków programowania.
To samo odnosi się do frameworków. Naucz się jednego nowego frameworku rocznie, a zaczniesz uświadamiać sobie, że żaden z nich nie jest tak naprawdę nowy. Zaczniesz uświadamiać sobie, że, tak jak w przypadku języków, pod spodem jest lista powtarzalnych patternów, i jest to liczba ograniczona, i jak bezsensowne jest miksowanie tych patternów we wszystkich możliwych kombinacjach.
Czy ten punkt widzenia napawa Cię pesymizmem? Nie powinien. Fakt, że przeszliśmy wzdłuż i wszerz jakiś kawałek naszej profesji nie oznacza, że inne części są poznane. O kurka! Okazuje się, że lista, rzeczy do nauczenia się i poprawienia biegłości jest dosyć duża. Co więcej, podczas naszej niekończącej się krucjaty poznawania nowych języków i frameworków zaniedbaliśmy te rzeczy.
A więc, dla przykładu, porozmawiajmy o współbieżności. Jest to dziedzina, w której naprawdę leżymy i kwiczymy. Czy nie nadszedł już najwyższy czas, aby to zmienić? Czy nie byłoby dobrym pomysłem poznanie domeny współbieżności w stopniu, w jakim poznaliśmy domenę języków. Czy nie jest to szczególnie prawdziwe w czasach, gdy nasze aplikacje są coraz bardziej uzależnione od wieloprocesorowych środowisk? Czy gwałtowny wzrost liczby aplikacji hostowanych w chmurze oznacza, że możemy poszczycić się coraz lepszym zrozumieniem współbieżności?
No dobra, pozwól mi przetestować trochę Twoją wiedzę:
- Czy znasz problem ucztująch filozofów i czego uczy?
- Czy potrafisz zdefiniować problem zakleszczenia i opisać, jak go uniknąć?
- Czy wiesz co to jest model aktorów?
- Czy jesteś zaznajomiony z run-to-completion threads?
- Czy kiedykolwiek napisałeś bufor cykliczny do obsługi przerwań w aplikacji głównej i działającej w tle?
- Czy wiesz co to jest semafor, kiedy go wymyślili i po co?
- Czy jesteś zaznajomiony z racjami stojącymi za blokadą z podwójnym zatwierdzeniem?
- Co to jest inwersja priorytetów?
A jak tam protokoły komunikacyjne? Czy odkryliśmy wystarczająco to królestwo? Czy znasz tę domenę?
- Czy wiesz, w jaki sposób połączenia, na których nie można polegać używane są do komunikacji, na której można polegać?
- Czy wiesz, co to jest mechanizm okna przesuwnego?
- A co z CRC?
- Dlaczego wykrywanie kolizji jest tak ważne w Ethernecie.
- Czy znasz algorytm Exponential backoff?
- Jakie jest 7 warstw modelu OSI i dlaczego one są tak ważne?
- Jaka jest różnica pomiędzy BPS i BAUD?
Jak daleko jesteś wyedukowany w klasykach naszej branży? Czy przeczytałeś i zrozumiałeś (wspominam tylko kilka):
- Sztuka programowania : Knuth
- Sieci komputerowe : Tanenbaum
- Struktura i interpretacja programów komputerowych : Abelson and Sussman and Sussman
- Structured Analysis and System Specification: DeMarco
- Wzorce projektowe : Gamma, Helm, Johnson, Vlissides
- Analysis Patterns: Reusable Object Models : Fowler
- Structured Programming: Dijkstra, Dahl, Hoare
- Object Oriented Software Construction : Meyer
Czy rozumiesz różnicę pomiędzy dyskretną symulacją zdarzeń a symulacją ciągłą? Kiedy byś użył każdej z nich?
Jak u Ciebie z teorią kolejek?
Czy rozumiesz jak zorganizować zestaw bramek i kolejek, aby zmaksymalizować przepływ w różnych środowiskach?
Czy rozumiesz jak zorganizować zestaw bramek i kolejek, aby zmaksymalizować przepływ w różnych środowiskach?
Czy jesteś zaznajomiony z algorytmami grafów?
Jak byś podszedł do znalezienia najkrótszej drogi pomiędzy dwoma miastami? A jak do znalezienia najszybszej?
Jak byś podszedł do znalezienia najkrótszej drogi pomiędzy dwoma miastami? A jak do znalezienia najszybszej?
Czy potrafisz napisać algorytm quicksort na żądanie, bez szukania w książkach / Googlach?
Czym są prawa De Morgana i do czego mogą Ci się przydać?
Jak tam z Twoją geometrią obliczeniową? Jak obliczyłbyś pole dowolnego wielokąta?
Czy kiedykolwiek napisałeś algorytm genetyczny? Czy pracowałeś z siecią neuronową? Co wiesz o Big Data? Jak byś napisał bibliotekę do liczb zmiennoprzecionkowych? Czy kiedykolwiek napisałeś sterownik wejścia - wyjścia? Czy napisałeś system plików? Czy napisałeś wielozadaniowe jądro? Czy napisałeś kompilator?
Są jeszcze języki. Czy nauczyłeś się naprawdę ważnych - tych które naprawdę były innowacyjne, które były stopniami w drabinie, dzięki którym jesteśmy tu, gdzie jesteśmy? Czy nauczyłeś się Fortrana? Czy nauczyłeś się Cobola? Czy znasz Snobol i Forth i Lisp i Prolog i C?
Czy kiedykolwiek pisałeś w języku maszynowym, ręcznie łącząc swój kod w kod binarny?
Czy czytałeś oryginalny artykuł Alana Turinga : On computable numbers ...?
Są jeszcze języki. Czy nauczyłeś się naprawdę ważnych - tych które naprawdę były innowacyjne, które były stopniami w drabinie, dzięki którym jesteśmy tu, gdzie jesteśmy? Czy nauczyłeś się Fortrana? Czy nauczyłeś się Cobola? Czy znasz Snobol i Forth i Lisp i Prolog i C?
Czy kiedykolwiek pisałeś w języku maszynowym, ręcznie łącząc swój kod w kod binarny?
Czy czytałeś oryginalny artykuł Alana Turinga : On computable numbers ...?
*~~~*
No więc, tak. Naucz się jednego języka na rok. Być może, że ten język będzie nowy -- dla Ciebie; ewentualnie będzie stary i znaczący dla naszej branży. Być może podczas nauki tego języka, nauczysz się czegoś z listy, którą tutaj przedstawiłem.
Pole uprawne naszej branży jest ogromne. Ledwo zadrapaliśmy powierzchnię. Jest wiele ważkich rzeczy do nauki o obliczeniach komputerowych i o oprogramowaniu. Byłoby szkoda, gdybyśmy nigdy nie odkryli tych głębi, ponieważ byliśmy rozproszeni błyskotkami.
No więc, tak. Naucz się jednego języka na rok. Być może, że ten język będzie nowy -- dla Ciebie; ewentualnie będzie stary i znaczący dla naszej branży. Być może podczas nauki tego języka, nauczysz się czegoś z listy, którą tutaj przedstawiłem.
Pole uprawne naszej branży jest ogromne. Ledwo zadrapaliśmy powierzchnię. Jest wiele ważkich rzeczy do nauki o obliczeniach komputerowych i o oprogramowaniu. Byłoby szkoda, gdybyśmy nigdy nie odkryli tych głębi, ponieważ byliśmy rozproszeni błyskotkami.
Wujek Bob
Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :
hahaha czyli w skrócie : zamiast uczyć się języka rocznie, idź na studia i poznasz podstawy informatyki przez co zrozumiesz czemu nowe języki to tylko nowe ubranka dla algorytmów i struktur danych (no i kilka rzeczy "do okoła") :D
OdpowiedzUsuńHej, No właśnie Wujek Bob przekonuje, że warto uczyć się jednego języka rocznie. Było coś w tym artykule o studiach?
Usuń