Od czeladnika do mistrza
Przeczytałem "Pragmatycznego Programistę". Większość rzeczy tam zawartych była mi w większym lub mniejszym stopniu znana, więc część podrozdziałów albo tylko przeskanowałem, albo w ogóle zignorowałem [1]. Tak czy siak książka zdecydowanie dobra i polecałbym wszystkim początkującym (i nie tylko) programistom. Zwłaszcza żałuję, że nie przeczytałem jej jakieś dwa-trzy lata temu (co najmniej; preferowalnie znacznie wcześniej), zanim zabrałem się za pisanie pldzianej automatyki ftpowej. Wtedy zacząłem po raz pierwszy bawić się na serio obiektami w pythonie i tak sobie klepiąc przyszło mi do głowy, że ok, samo tworzenie obiektów jest proste, tyle, że nie mam zielonego pojęcia w jaki sposób dzielić różne rzeczy na obiekty. Szkoda, że wtedy nie postanowiłem coś bardziej doczytać na ten temat.
[1] Jak byłem mały, to potrafiłem przeczytać od deski do deski praktycznie dowolną knigę. Teraz niestety już nie potrafię -- znacznie spadła mi tolerancja na książki techniczne -- za dużo tam słów, za mało przydatnej treści. Nawiasem mówiąc będę musiał pomyśleć w jaki sposób dałoby się napisać książkę tak, żeby zaawansowani nie mieli wrażenia, że tracą czas, a jednocześnie ci nie do końca zaawansowani byli w stanie z niej coś wynieść. Bo zdecydowanie powinno się dać.
Jedna rzecz jest w tym wszystkim mocno przerażająca -- ogrom materiału. Wszyscy znają przypowieść o archetypicznym 'informatyku', który kiedyś nauczył się jakiegoś visual basica i do tej pory wszystko robi przy jego pomocy. No i prawdę mówiąc ja się nie dziwię. Takie rozwiązanie jest bardzo kuszące.
Naczelną zasadą tej książki jest, że programista powinien wiedzieć wszystko o swoim fachu, bo tylko dzięki temu może dobierać właściwe narzędzia do zastanych problemów i używać ich w prawidłowy sposób.
Tylko ile tego wszystkiego jest! Ekosystem uniksiany (shelle, skrypty, szybkie przetwarzanie tekstu), ekosystem javowy (eclipse, javadoc, jUnit, jBoss, jAdziękuję), ekosystem .netowy, języki dynamiczne (trza by przynajmniej z dwa teraz znać, tj. pythona i ruby'ego), a to tylko same narzędzia. Do tego dochodzi jeszcze masakryczna ilość wiedzy, żeby z tego sensownie korzystać. Już te lata wymagane na zdobycie doświadczenia w tym wszystkim pominę -- poznęcam się trochę nad samą suchą wiedzą odnośnie programowania (obiektowego). Na niskim poziomie trza znać jakiś język (maluteńki język zwany javą na przykład). Do tego dochodzą te wszystkie narzędzia i frameworki. Do tego na najwyższym poziomie jakieś typowe architektury, MVC, klient-serwer, etc. A żeby nie było zbyt różowo, to taki UML (z którego olewamy 99%, bierzemy tylko podstawy) i jeszcze jakieś wymysły typu design patterns.
Brrr. W przypadku tych ostatnich zdecydowanie zgadzam się z krytykami -- jeśli przy rozwiązywaniu określonych typów problemów koduje się w sposób, który "zasługuje" na stworzenie wzorca, to znaczy, że nie powinno się robić wzorców, tylko (a) rozszerzyć język o nowe abstrakcje i (b) zrobić jakiś framework/zestaw modułów do niego. To co już jest, jest i tak cholernie skomplikowane, więc zupełnie nie podnieca mnie przedzieranie się przez formalne opisy wzorców projektowych, żeby znaleźć ten, przypominający akurat to, co mam zamiar robić. W takich przypadkach zdecydowanie powinienem mieć gotowy framework, który prowadzi mnie za rączkę krok po kroku, minimalizując przy okazji szansę, że sobie odstrzelę nogę.
Ja jestem leniem. Ja się nie lubię uczyć nowych rzeczy zbyt często. Ilość wiedzy jaka w tym wszystkim jest zawarta mnie przeraża.
(A jak ktoś już jest kompletnie pokręcony, to może spróbować się nauczyć htmla, cssa i jsa w stopniu zaawansowanym, tzn. takim, który wystarczy do stworzenia jakiejś bardziej zaawansowanej strony działającej we wszystkich popularniejszych przeglądarkach. Good luck.)
12 III 2007 o 01:11
Właśnie ostatnio myślałem w podobny sposób. O tym co umiem, a co powinienem jeszcze się nauczyć jeśli chcę być dobrym programistą/informatykiem. To co wymieniłeś to tylko niewielka część. Od siebie dodam:
-bazy danych (ze 2 pasuje znać, np mysql i coś komercyjnego, np oracle) - i nie mówię tu o czymś tak prostym jak "select * from...", trzeba wiedzieć co się dzieje niżej, by np optymalizować zapytania etc.
-przy większych aplikacjach - skalowanie, keszowanie
-wszelakie protokoły (http to podstawa)
-programowanie rozproszone - rmi, rpc, corba, soap, xml-rpc itp
-metodologie: tdd, xtreme, testy unitowe itd
-wszystko co dotyczy xmla - xml, scheme, xslt itd
-edytory, środowiska programistyczne
-ogromna liczba bilbiotek
-znajomość algorytmów?
-umiejętność jako tako myślenia analitycznego (żeby pisany system miał ręce i nogi)
W sumie można wymieniać w nieskończoność. Ogrom tego wszystkiego daje mi tylko dowód na to, dlaczego wszelakie firmy mają problem ze znalezieniem dobrych programistów.
12 III 2007 o 01:13
Ja u siebie zaobserwowałem ostatnio ciekawą "właściwość", mianowicie gdy tylko mam czas to poznaję coraz to nowsze rzeczy: nowe języki: Ruby,Python, Java, C++, CSS, JavaScript ; różne jak to nazywasz wzorce: mvc itp. ; a także trochę sprzętu i spraw *niksowych ale też graficzne działanie w GIMPIE, Flashu, Inkscape'ie czy też teorię barw albo rzeczy mało-poligraficzno-komputerowe (tzw. DTP) i inne badziewia. No i tak jak na to patrzę, to _kolekcjonuję_ tę wiedzę i wkładam do coraz to nowszych szufladek w główce i kolekcjonuję, poznaję, czytam o protokołach, programach, interesując się wszystkim po trochu. W międzyczasie pisząc z wykorzystaniem tych nowo poznanych regułek i całej tej wiedzy skromniutkie aplikacje, czy inne wytwory mojej wyobraźni jak ciekawe retusze zdjęć, animacje i inne "rzeczy", bo tego naprawdę jest DUŻO.
I często się łapię za głowę, po co to wszystko. Jestem młody, studia jeszcze przede mną a i większość moich kolegów ze szkoły czy kąd inąd to o tym wszystkim nie ma nawet zielonego pojęcia. Dla nich instnieją tylko jakieś stronki w HTML3.01 (SERIO!), czy inne gierki oparte na if/cout/cin/return w C++. A ja?
Czyżbym dążył do "pragmatycznego programisty"?
Prawdopodobne. Bo jak się nad tym wszystkim zastanawiam, to już teraz często jak ktoś przychodzi z jakimś problemem do mnie, to często nie widzę rozwiązania w tym czym on prosi (zazwyczaj C++, co ciekawe :P) a np. w czymś w czym pisanie sprawia mi przyjemność i radość (Ruby, PHP czy inne cuś jak inkscape/Gimp/wpiszCokolwiek - mimo wymaganego Corela Draw/Photoshopa/Flasha itepe.)
A co Wy sądzicie o takim czymś?
12 III 2007 o 10:28
Sądzę że powinieneś szukać rozwiązań problemu w obrębie możliwości jakie są Ci dane.
Pracując dla firmy nikogo nie będzie obchodziło że ty potrafisz rozwiązać zadanie A w języku X skoro tak naprawdę firma tworzy konkretny projekt w języku W (chyba że przebijesz się przez project managera dobrze argumentując dlaczego tak i tak - ale to "wyrozumiały przypadek").
Oczywiście im więcej umiesz/znasz tym milej jesteś widziany ale :) o ile nie pracujesz sam czasami bedzie Ci się trudno przebić (choć - Ruby coraz bardziej popularny) z własnymi pomysłami.
12 III 2007 o 11:18
@ravbaker:
Lepiej uważaj. Wiedzieć wszystko (zwłaszcza w młodym wieku) równoznaczne jest z 'nic nie wiedzieć'. Zrobić sobie tour de technologiae jest dobre, tyle, że jeśli chociaż na jednej z tych rzeczy się nie skupisz (tzn. na serio, preferowalnie uczestnicząc w jakimś większym projekcie z daną technologią związanym), to później w CV i tak nie będziesz miał czego wpisać. Bo jak wpiszesz 50 słów kluczowych (bo nad każdym z nich spędziłeś kiedyś kilka minut), to większość ludzi się tylko pod nosem uśmiechnie na takie CV.
@jar
To by była prawda, gdybym miał zamiar pracować jako wyrobnik w większej firmie.
A nie mam zamiaru.
12 III 2007 o 11:43
@mmazur:
poprzedni komentarz dotyczył RaVbaker ;) (przepraszam ze nie zaznaczylem)
Co do dużej listy wpisów w CV -> prawda. Lepiej mieć ich kilka(naście) ale potwierdzone realnym doświadczeniem (np. jakis projekt open-source) niż ... nie odpowiedzieć na pytania podczas rekrutacji ;).
12 III 2007 o 15:31
Akurat design patterns się przydają, co prawda gdy się o nich tylko czyta to może wyglądają dziwnie, ale implementując je co chwilę trafia się na jakiś pomysł jak to wykorzystać (a czasem po prostu na "jezu, ale to fajne")
12 III 2007 o 18:26
http://norvig.com/21-days.html
17 III 2007 o 16:44
jest cos takiego jak krzywa poziomu kompetencji ktora obrazuje
zjawisko ciaglego uczenia sie i dosc jasno mowi ona, ze by
utrzymac staly poziom kompetencji trzeba sie ciagle uczyc.
w przypadku gdy sie nie uczymy poziom kompetencji NIE zostaje
utrzymany a MALEJE. zatem by utrzymac wlasne kompetencje
na stalym poziomie trzeba sie uczyc; by go zwiekszyc trzeba sie
naprawde porzadnie uczyc nowych rzeczy.
wazne jest to zwlaszcza w branzy IT ..
o 23:00 przed snem czytamy cos w internecie i jestesmy
calkowicie na biezaco
nastepnego dnia wstajemy o 7 rano, czytamy cos w internecie
i wlasnie powstala nowa technologia ktorej nie znamy.
jestesmy zacofani
w przyszlosci nikt nie bedzie sie pytal czy pracownicy
IT potrafia zrobic A, B, C tylko czy spelniaja wymagania
jakie zostaly podane i okreslone. lenistwo nigdy nie bylo
i nie bedzie usprawiedliwieniem
21 III 2007 o 20:58
człowiek jako programista ma rozwiązywać problemy (które z resztą sam sobie tworzy), a to całe gówno o którym mówicie to tylko narzędzia którymi sie posługuje. Ja też jestem pół-profesjonalnym programistą i jakoś mnie nie interesuje WSZYSTKO co dotyczy programowania, skupiam się na mojej działce, czyli webdevelopingu. Czegoś nie mogę zrobić, wyszła jakaś nowa super-technologia, douczam się i tyle. Bo wiedząc wszystko wie się NIC. BTW: co to za germańskie napisy na tej stronie?? :P )
05 X 2007 o 09:49
@mmazur:
Wzorce = dobry słownik (albo elementarz). Zawsze warto skorzystać z (wieloletniego) doświadczenia innych. Zawsze można je rozbudować do własnych potrzeb. Nie zawsze jest czas na wytworzenie/sprawdzenie poprawności własnej koncepcji.
@ravbaker:
Zainwestuj w… teorię. To co robisz jest bardzo dobre, ale czy kogoś dzisiaj obchodzi, że grafikę programowało się przez przerwanie 21h (jak teraz o tym myślę to muszę się zastanowić chwilę czy to rzeczywiście było 21h)? Nie zaniedbaj więc matmy, fizyki, algorytmiki na pewno nie będziesz żałował za kilka lat.