Temat: Test kwalifikacyjny w Comarch
Kazimierz Kuta:
Po lekturze wątku dochodzę do wniosku, że dzisiejszemu programiście wystarczy tylko umiejętność korzystania z wyszukiwarki ;)
Dostrzegam emotkę, niemniej muszę zaprotestować - przynajmniej w kontekście mojej osoby (w końcu ja to napisałem).
Jestem zarówno analitykiem jak i programistą - "reserczrem" (ja po prostu lubię rozwiązywać problemy techniczne :) ). Łączyłem wiele technologii, testowałem i uczyłem się wielu rozwiązań i poznawałem wiele "dirty solutions" (które jednak skutecznie działają) jak również "best practices" (do których jak najczęstszego stosowania powinno się dążyć). Tak się składa, że znam spory kawałek MSDN'a (bo to wynika z wieloletniej praktyki), ale któregoś dnia zapytałem sam siebie - "Na Boga, po co ci to? ZAPOMNIJ. C#, ASM, Pascl, C++, MFC, RDLC, XSD, XHTML, Java, JS, IDL - o Chryste Panie, i co jeszcze!?".
I tutaj pojawia się nawiązanie do wypowiedzi Przemka: język programowania jest nieistotny (w teorii, w praktyce są przecież specyficzne aspekty konkretnego języka i platformy). Ważna jest umiejętność patrzenia na wyższym poziomie abstrakcji, myślenia nie kodem, a rozwiązaniami.
Dobry programista ma w sobie żyłkę i umiejętności inżyniera aplikacji. "Zwykły koder" po prostu pisze kod - lepiej lub gorzej. Polega na analizach technicznych inżynierów oprogramowania. Dostaje wejście i wyjście "czarnego pudełka" i analizę funkcjonalno-techniczną. I jedzie. A czego nie wie, poszuka i przepisze "egzampla" z MSDNa.
"Programista co się zowie" jest "prawdziwym informatykiem", który traktuje bycie informatykiem nie tylko jako "kodowanie w C++". On zna szereg zagadnień związanych z informatyką - szeroką bądź co bądź nauką. Zna wzorce projektowe, zna dobre praktyki (i to różne, by móc wybierać - nie stara się być zaślepionym "fanboyem" jednej, za którą odda życie, "bo tak").
Ale przychodzi w końcu moment, gdy - i teraz powrót ładnym kółeczkiem do wypowiedzi Kazimierza - wiedza inżynierska staje się większa i ważniejsza, niż lista metod jakiejś tam klasy. Lista klas, wybrane (i wykorzystywane w codziennej pracy najczęściej) metody, może nawet tytuły wartościowych artykułów i adresy portali branżowych - już tak. Patrzy na problem i "generuje mu się" w głowie lista potencjalnych rozwiązań.
I właśnie wtedy programista staje się inżynierem / analitykiem, a od szczegółów technicznych JEST Google (i MSDN, CodeProject, StackOverflow i dziesiątki innych). Może nie być tak dobry w szczegółach, jak koder, który stuka w te klawisze dzień i noc i zna na wylot 80% klas, metod i propertów, ale umie rozwiązywać problemy.
Przytoczę przykład statystyki, którą się zajmuję, a w której padają podobne "zarzuty". Czy każdy statystyk zna szczegółowe wzory rotacji w analizie czynnikowej albo wzory na sumy kwadratów różnych typów (a jest ich trochę)? A może postać macierzy kowariancji w uogólnionym modelu liniowym dla różnych typów autokorelacji? Nie, oni znają WADY I ZALETY poszczególnych metod statystycznych oraz warunki ich użycia, założenia i - dodatkowo, wynikające z praktyki "kruczki i sztuczki". Od obliczeń mają Statistikę, od wzorów - kilka liczących 2 tysiące stron "handbooków". Tak, kiedyś musieli się przegryźć przez te wzory, by ZROZUMIEĆ jak działają (albo, dlaczego w danej sytuacji działają źle), ale dziś już nie jest im to potrzebne do codziennej pracy. Student, który zna wszystkie wzory, ale nie wie, jak je zastosować, wart jest jednak mniej, niż analityk, który może nie znać praktycznie żadnych szczegółowych wzorów (no dobra, przekoloryzowałem nieco, bo te wzory się po prostu pamięta, jak twierdzenie Pitagorasa :) - ale wszystkie ma w książkach i wie, gdzie co jest), ale ma szerokie rozeznanie w kontekście zastosowania różnych metod.
W mojej opini jednak wiedza jest ważna. Nie musi być to wiedza ekspercka, ale ktoś, kto uważa się za programistę technologii powinien tę technologię znać i sprawnie się w niej poruszać.
Jak najbardziej. Aczkolwiek - taki .NET - przecież to jest OCEAN, a nie rzeka. WCF, WPF, Domeny aplikacji, ADO, atrybuty, COM/Interop, LINQ, XML, webserwisy, serwisy systemowe, ASP, multimedia, wątki - część MSDNa dotycząca .NETa jest GRUBA.
Sam ASP.NET to cegła grubości Encyklopedii Britannica.
Przyklad: nie musi znać na pamięć wszystkich atrybutów konfiguracji sesji ASP.NET, ale powinien wiedzieć że się da, wymienić możliwe sposoby wraz z ich scenariuszami użycia.
W porządku. Ale wystarczy, że wie, że "jest taki atrybut i wiem, jak go znaleźć, wraz z przykładem składni". Albo wiem, że podpowie mi to "kod-intelidżens", a mnie się nazwa od razu skojarzy ze znanym rozwiązaniem.
Niestety ludzie rozwiazujący problemy przy pomocy google żadko zwracają uwagę na ograniczenia pewnych rozwiązań.
Czy rzadko... subiektywne spojrzenie, w mojej praktyce (gdy kierowałem pracami programistów) nie było to aż tak rzadko. Ale zgodzę sie, że nie ma szału :]
Co do wyszukiwarki http://www.searchdotnet.com/ jest chyba lepsza ;)
Dzięki :)
----
Co zaś do "odsiewu" rzeczywiście wartościowych informatyków, którzy oblali szczegółowy test -
Do firmy dostają się tacy ludzie, jakich ta firma potrzebuje i na jakich zasługuje :)
Adrian Olszewski edytował(a) ten post dnia 13.08.09 o godzinie 11:56