Temat: Cała prawda o programistach

Rafał Ziółkowski:
To zalezy. Sa ludzie ktorzy sa swietnymi specjalistami ale maja problem sie sprzedac - czyli stresuja sie w przypadku jak przychodza na rozmowe.

To prawda, wielu ludzi po prostu nie umie zareklamowac swojej wiedzy. Dodatkowo sa bardzo krytyczni w zakresie tego co potrafia i czesto nie umiejac odpowiedziec w 100% poprawnie mowia, ze tego nie wiedza.

Ale to tez cos pokazuje. Taki specjalista nigdy nie bedzie client-facing, poniewaz nie ma odpowiednich zdolnosci komunikacyjnych. To tez trzeba wziac pod uwage.

Sam test Fizz-Buzz - nie dziwi mnie, ze niektorzy oblewaja, niezlych kandydatow widzialem.

Temat: Cała prawda o programistach

Właśnie zaliczyłem 21 rok w zawodzie programisty i niejedno już widziałem.
Osobiście uważam ,że zdolność „sprzedania się” czyli zdobycia pracy w czasie rekrutacji to osobna nie związana z wiedzą programistyczną umiejętność.
Po prostu jedni umieją czarować a inni nie.
Prawdą jest ,że można się tego nauczyć ale jedynie przez branie udziału w rekrutacjach tylko dla nauki a nie by zostać przyjętym do pracy.
Wychodzi z tego paradoks. Nie wiedza i doświadczenie decydują o ocenie przyszłego pracownika a jego zdolności nie związane z zawodem.(:
Stres na rozmowie kwalifikacyjnej zależy od człowieka. Jeden za drugim razem daje sobie radę a inny za 20 nadal duka jak przedszkolak. Szczególnie ,że za każdym razem jest się sprowadzanym do podstaw. Tak jakby wieloletnia praca w zawodzie i udział w wielu projektach nie mówiły same za siebie.
Czasami patrze na przebiegi kariery tu na GoldenLine i dziwie się ,że ludzie przyznają się ,że po 6 latach pracy zaliczyli 10.. firm. Po 1m – 6m. Wygląda na to ,że dla rekrutujących nie jest dziwne,że ktoś nie potrafi utrzymać się w pracy. A ktoś kto w jednej firmie pracował 16lat w innej 4lata i wykonywał projekty na własną rękę jest wsadzany do tego samego worka.
Dochodzi do tego jeszcze problem pewności siebie. Generalnie naj bardziej pewni siebie są programiści ze średnim doświadczeniem. Już nie początkujący ale jeszcze nie mają pełnej perspektywy swojej dziedziny. Zwykle to wychodzi po 3-4 latach. Potem pewność siebie wraz z wiedzą maleje. Po prostu zaczyna się wiedzieć ile jeszcze się nie umie i ile pracy należy poświęcić dla zdobycia tej wiedzy.

Temat: Cała prawda o programistach

Adrian Olszewski:

Sebastian Pienio:
Hmm, a da sie? IMHO nie (o ile nie zalozysz jakiego typu sa to zmienne i nie przygotujesz gimnastyki pod tym katem).

Da się, ale tylko dla zmiennych całkowitych, poprzez wielokrotne "xorowanie" ich ze sobą.

Zartujesz?

Sprawdź, co będzie w A i B po sekwencji takich instrukcji:

A = A + B;
B = A - B;
A = A - B;
Oczywiście to działa nie tylko dla numeryków, ale i dla innych typów, w których implementacja operatorów '+' i '-' ma identyczne
niektóre z własności, a konkretniej poniższe warunki muszą dawać prawdę:

x+y == y+x (przemienność dodawania)
x-x == 0 (element zerowy)
x+0 == x (neutralność elementu zerowego względem dodawania)
x-0 == x (neutralność elementu zerowego względem odejmowania)
A tak naprawdę to wcale nie jestem pewien, czy koniecznie wszystkie z nich, ale nie chce mi się o tym teraz myśleć ;)Piotr G. edytował(a) ten post dnia 10.01.10 o godzinie 22:48

Temat: Cała prawda o programistach

Maurycy Mikulski:
Wychodzi z tego paradoks. Nie wiedza i doświadczenie decydują o ocenie przyszłego pracownika a jego zdolności nie związane z zawodem.(:

Nie zgadzam sie, zdolnosc "sprzedania sie" jest jedna z najwazniejszych umiejetnosci w zawodzie programisty. Powiem wiecej - programista, ktory nie umie sprzedac swojej wiedzy nie moze byc dobrym programista.

Jaki ma sens wiedza, jezeli sprawnie nie potrafisz jej przekazac zespolowi? Co z tego, ze doskonale potrafisz przewidziec problemy jezeli nie przekonasz do zmiany taktyki swojej druzyny?

Jezeli myslisz o powaznej karierze musisz liczyc sie z tym, ze bedziesz pracowal w zespole. Poprawna praca w stresie (deadline, nowa technologia, nieprzewidziane problemy) odroznia "programiste" od "klepacza", rozmowa kwalifikacyjna (ze wszystkimi dodatkami w postaci stresu) jest swietnym detektorem tego, z kim mamy do czynienia.

IMHO taka "chowana" wiedza jest warta zero. Sorry, life is brutal.

Temat: Cała prawda o programistach

A wg. mnie nijak się ma przekazywanie wiedzy na rozmowie do przekazywanie jej zespołowi. A 'chowaną' wiedzę i tak wykorzystujesz, co sprawia że jednak ktoś kto więcej umie jest więcej wart od tego który się potrafi tylko lepiej sprzedać.

No i dosyć istotna sprawa, stres podczas rozmowy to jedno, podczas pracy nad projektem drugie - tutaj już wiemy że pracujemy, wiemy z kim pracujemy i mam nadzieje, że ufamy i lubimy osoby z którymi pracujemy ;-)Jerzy Mieczyński edytował(a) ten post dnia 11.01.10 o godzinie 00:31

Temat: Cała prawda o programistach

Piotr G.:

Adrian Olszewski:

Sebastian Pienio:
Hmm, a da sie? IMHO nie (o ile nie zalozysz jakiego typu sa to zmienne i nie przygotujesz gimnastyki pod tym katem).

Da się, ale tylko dla zmiennych całkowitych, poprzez wielokrotne "xorowanie" ich ze sobą.

Zartujesz?

Czy żartuję... niestety, nie jestem algebraikiem, któremu pierwsza myśl, jaka wpadła do głowy przy okazji "swapa zmiennych", to "grupa abelowa" (sądząc z zapisu własności)... To jednak nadal są tylko liczby. Trudno mi sobie wyobrazić przeciążanie operatora XOR dla klas, przekazywania referencji...

Ad meritum, popieram Jerzego.

Mój mózg pracuje inaczej w sytuacji, gdy jest świadom, żę testuje się go "na stres", a zupełnie inaczej, gdy skupiam się na rozwiązaniu problemu (nawet bardzo pilnego i niewdzięcznego), izolując się od wszystkich, za przeproszeniem, pierdół. Są konstruktywne uwagi, jest zaangażowanie wszystkich stron, jest burza mózgów albo też mój własny popis. Zadanie-Metoda-Rozwiązanie.

Rozwiązywanie problemów na egzaminie to nie jest TAKI SAM stres, jaki będzie towarzyszył rozwiązaniu problemu w rzeczywistości. Rzadko kiedy w życiu programista musi w 15 minut znaleźć rozwiązanie. Może iść z tym do domu, posiedzieć w toalecie :) poradzić się kolegi, poczytać książki. Wymienianie się wiedzą też wygląda inaczej w zgranym (jakoś) środowisku, niż na egzaminie. Tu zaś kandydat nie wie, czy sprawdza się go w "czysto technicznie", czy chodzi o redukcję żądań, czy o sprawdzenie "frontowej przydatności bojowej", czy o negatywny stosunek rekrutującego. Czy o wszystko na raz. Praca to kwestia bytowa, a te są wysoce stresogenne.

Mam swoje dwa tryby pracy: minimalistyczny i eksperta.
Tryb minimalistyczny - gdy jest mało czasu, terminy gonią, trzeba wymyślić minimalistyczne, lecz wystarczające na daną chwilę rozwiązanie. Tryb eksperta - siadam z kartą i długopisem, włączam muzykę i otwieram głowę. Biorę także na siebie odpowiedzialność za to, co spłodziłem. Wcześniej jednak wymagam dokładnego poinformowania o zadanym wejściu i wyjściu czarnej skrzynki mojego zagadnienia oraz terminach oraz dostępnym zespole oraz środkach i negocjuję czas oraz funkcjonalność, mając za brata "zasadę potrójnego ograniczenia".

To pomaga realnie zredukować stres (chociaż podnosi ciśnienie handlowcom, którzy już obiecali coś klientowi :) ).

Trzeciego trybu: ekspert na 60 sekund przed wybuchem reaktora jądrowego - nie przewiduję na co dzień. Był mi potrzebny tylko kilka razy w życiu, ale współpracowałem z ludźmi, którzy byli również zaangażowani, a sytuacja była nietypowa, a zyski dla mnie - wymierne. To jest w porządku, ale i - powiedzmy sobie wprost - do tego zagadnienia nie byli angażowani wszyscy, a tylko kilka osób, które na to się zdecydowały. I nie była to codzienność, która wymagała podczas rozmowy kwalifikacyjnej testowania mojej odporności, jak bym miał co najmniej walczyć w Afganistanie.

Weryfikacja umiejętności - jak najbardziej. W końcu nikt nie chce kupować kota w worku, a kandydat ma wypracowywać nasz zysk. Ale wyważyć - czy chodzi o dyrektora d/s zarządzania ryzykiem, czy o szeregowego programistę, czy kierownika zespołu - i owszem, tego warto przemaglować pod kątem odporności na stres :)

Wspomniane "codility" jest bardzo przydatne, jak każdy AC. Bada umiejętności rozwiązania problemu, gdzie można sobie usiąść spokojnie (ale nie za spokojnie - przecież płynie czas, a moje rozwiązanie będzie ocenione pod różnymi kątami) i pomyśleć.

I jeszcze jedno - ludzie się zmieniają. Zahukany programista z wielkiej korporacji może się odnaleźć w małej firmie, gdy trafi na rozsądnych ludzi i może być z niego pożytek. Piszę, co widziałem.Adrian Olszewski edytował(a) ten post dnia 11.01.10 o godzinie 06:31

Temat: Cała prawda o programistach

Adrian Olszewski:
Rozwiązywanie problemów na egzaminie to nie jest TAKI SAM stres, jaki będzie towarzyszył rozwiązaniu problemu w rzeczywistości. Rzadko kiedy w życiu programista musi w 15 minut znaleźć rozwiązanie. Może iść z tym do domu, posiedzieć w toalecie :) poradzić się kolegi, poczytać książki. Wymienianie się wiedzą też wygląda inaczej w zgranym (jakoś) środowisku, niż na egzaminie. Tu zaś kandydat nie wie, czy sprawdza się go w "czysto technicznie", czy chodzi o redukcję żądań, czy o sprawdzenie "frontowej przydatności bojowej", czy o negatywny stosunek rekrutującego. Czy o wszystko na raz. Praca to kwestia bytowa, a te są wysoce stresogenne.

Wyobraz sobie, ze przychodzisz na "bytowa" rozmowe kwalifikacyjna, a tam zastajesz dwoch ludziskow w dzinsach, daja ci herbatke, opowiadaja troche o sobie, pytaja co u Ciebie, atmosfera robi sie bardziej luzna. Zaczynasz rozumiec, dlaczego prosili, zebys nie przychodzil w garniturze. Pytaja co Cie pasjonuje, czym lubisz sie zajmowac w programowaniu, czy widziales ostatnio jakies ciekawe rzeczy na blogach. Pozniej prosza Cie, zebys wypelnil prosty test na ktorym jest interpretacja "skomplikowanego" kodu takiego jak deklaracja klasy (pierwsza linijka), proste rzutowanie, pytanie co to jest IList. Nie ma "masz test i rob", tylko luzno rozmawiamy o tym co jest napisane na kartkach. Caly czas powtarzamy, ze test jest kwestia drugorzedna, bo chodzi nam o to, zeby sie poznac.

Jezeli ktos w takiej sytuacji nie jest w stanie sobie poradzic to nie poradzi sobie w pracy. Predzej czy pozniej musi kontaktowac sie z osobami z zewnatrz, stanie przed niekompetencja konsultantow czy manipulacjami ze strony kierownikow z innych firm.

Ale to mniej istotne.

Juz po tygodniu czy dwoch bedzie regularnie bral udzial w meetingach. Tam poddawane pod dyskusje beda rozne kwestie i osoba, ktora siedzi na nich cicho (bo sie boi albo nie ma nic do dodania) znaczy w firmie coraz mniej, mniej, az w koncu sama jak nie zdecyduje sie odejsc (wszystkie znany mi przypadki odeszly same) to sie jej pewnie dziekuje za "brak wkladu". Pisanie pod wlasnym nosem swietnego kodu jest ok dla "klepacza" (pensja/2 i pierwszy do odstrzalu w razie czego).

Spotkalem w zyciu ponad setke programistow, zrekrutowalem kilkudziesieciu, doradzalem wielu firmom i tak to wyglada w praktyce. Teoretyzowac, ze "genialny" programista bedzie szara myszka mozemy, tylko po co? ;)

Temat: Cała prawda o programistach

Sebastian ma rację.
Ale to dotyczy nie tylko zawodu programisty.
Wszelkie zawody, wymagające jednocześnie kreatywności i pracy grupowej, wymagają ciągłego balansowania pomiędzy soft- i hardskills, czyli pomiędzy umiejętnością istnienia w grupie i merytoryką. Dotyczy to także np. muzyków.
Potrafi dochodzić do sytuacji, kiedy to grupa odrzuca nadprzeciętnie dobrego członka (bo "zawyża" poziom, skraca normy czasowe itd), ale z drugiej strony daje się pokroić na plasterki za najsłabszego z nich (bo ma poczucie humoru, jest lubiany itp).

Nie prawdą jest myślenie, że skoro jestem dobrym (merytorycznie) programistą, to tak będę widziany. Wiem, że na studiach tego nie uczą, ale postrzeganie fachowca przez innych jest sumą merytoryki i umiejętności "miękkich". I dopóki nie płacimy sobie sami, doputy musimy walczyć o dobrą ocenę w oczach innych.

Oczywiście w dużych korporacjach bywa nieco "lżej": tam często programista dostaje zadania z dość dużym marginesem czasowym, wykonuje je sam, może poczytać, pomyśleć... Taka niby praca w grupie, ale z tą grupą ma się doczynienia tylko z okazji spotkania noworocznego. Super sprawa, jeśli ktoś lubi pracować 08:00...16:00 i po wyjściu z pracy chce mieć wszystko w d... Ale spróbujcie być choć trochę kreatywni w takich środowiskach, a zaraz się zacznie: zazdrosni koledzy, bojący się wykopania szef, inne wizje firmy... IMHO to jest dobre dla koderów.

Sorry, jeśli kogoś uraziłem - ale takie jest moje zdanie.

Kiedyś prowadziłem rekrutację i po pierwszych rozmowach (zwykle były 2 lub 3 etapy - zależnie od ilości kandydatów) świadomie odrzuciłem bardzo dobrego merytorycznie, ale bardzo pewnego siebie i chyba zbyt ambitnego kandydata. Dość szybko okazało się, że zrobiłem dobrze: gość, kiedy usłyszał, że odpadł na pierwszym etapie, zrobił mi przez telefon straszną awanturę, że przecież on wszystko wie i to on POWINIEN dostać tą pracę. Dzwonił potem do mnie jeszcze kilka razy mówiąc, że da mi jeszcze jedną szansę, żebym go zatrudnił, a w końcu nawet groził, że mnie zniszczy.
To oczywiście ekstremalny przypadek - być może własną firmę mógłby mieć, ale do pracy w grupie gość się absolutnie nie nadawał - pewnie w ciągu tygodnia by wszystkich pozabijał, bo stosują nieprawidłowe nawiasowanie czy złe nazewnictwo klas.

Tak więc umiejętności to nie wszystko: sądzę, że to góra 60% sukcesu.

Temat: Cała prawda o programistach

Herbatka? Dżinsy? Ależ to byłby raj! Nigdy takiej nie miałem i prawdę mówiąc, nie patrzyłbym na takich ludzi dobrze - ja nawykłem do garnituru i frontalnej obrony.

Ja piszę o ostrym wałkowaniu, jakiemu "gdzieś/kiedyś" podlegałem, 3 godzinnej rozmowie, jak by mnie mieli przyjąć na co najmniej viceprezesa, a pytania nie dotyczyły chyba tylko rozmiaru ......., w atmosferze "było tu już programistów wielu, a za drzwiami stoi jeszcze ośmiu, młody przyjacielu", a nie gaworzeniu przy herbatce (której zresztą nigdy mi nie zaproponowano) i prośbie o napisanie deklaracji klasy... I znam takich, którzy przechodzili taki sprawdzian i byli do de... (i miałem wątpliwą przyjemność pracować z nimi).

Nie będę się tutaj kreował na znawcę - macie dużo większe doświadczenie rekrutacyjne ode mnie i tworzyliście więcej zespołów - chociażby z racji wieku i ilości bagażu zawodowego. Wiem jedynie, że coraz bardziej drażni mnie zaprzęganie psychologii i wymyślnych socjotechnik dla potrzeb rekrutacji programisty. Na wszelkie takie rzeczy jestem cięty jak osa.

Co zaś do teoretyzowania - nie teoretyzuję :) Wiem sam, jaki byłem, wiem, jacy byli niektórzy moi koledzy ze studiów, a także ludzie, których poznawałem w czasie prac i wielu fuch. wiem kim jestem obecnie i kim oni są. I sporo byśmy podpasowali pod tę rozmowę w kontekście "sorry, guys". No i tych mitingów też za wiele nie pamiętam z firm, bo chyba nie piszemy o spotkaniach XP... No ale każdy ma swoje wspomnienia.

Po to je tu wymieniamy, żeby każdy wyciągnął dla siebie jakąś średnią :)Adrian Olszewski edytował(a) ten post dnia 11.01.10 o godzinie 19:47

Temat: Cała prawda o programistach

Adrian Olszewski:

Piotr G.:

Adrian Olszewski:

Sebastian Pienio:
Hmm, a da sie? IMHO nie (o ile nie zalozysz jakiego typu sa to zmienne i nie przygotujesz gimnastyki pod tym katem).

Da się, ale tylko dla zmiennych całkowitych, poprzez wielokrotne "xorowanie" ich ze sobą.

Dijkstra, "Umiejętnośc programowania".
Klasyka.
W zasadzie należy chyba przyjąć, że kto tego nie czytał, to, hmmm... może wszystkiego nie wiedzieć ;)
Wiem, wiem - mam kolegów, którzy doskonale programują w C# wykorzystując .NET Framework, ale nie potrafią zrobić "na piechotę" list, czy sortowania bąbelkowego - bo po co, skoro jest już gotowe?

Temat: Cała prawda o programistach

Trochę to zabrzmiało impertynencko... Nie, nie czytałem Dijkstry, tylko Wirtha. I to dawno. Nie pamiętam Codda, ani II algorytmu Bootha mnożenia liczb binarnych, choć był na studiach. Nie pamiętam nawet metody wyszukiwania danych algorytmem Ghosha opartym o geometrię rzutową rozpiętą na ciałach Galois <jakichśtam>, choć miałem z tego egzamin i byłem w niej niezły - klasyka na mojej uczelni. Umiem zaprogramować listę (dwukierunkową), Quicksorta (za bąbelki nie dostawało się nawet
"dosta", chyba, że prowadzący miał dobry humor i przemaglował nieco z algorytmiki). Umiem nawet zaprogramować niejedną metodę statystyczną w TSQLu (co tam w zwykłym C) czy policzyć medianę z przedziałem ufności w "groupbaju" bez użycia CLR. Zapewne nie wiem bardzo wielu rzeczy, które mi na co dzień nie są absolutnie potrzebne w moim profilu zawodowym (tak, wiem, regres, regres...), nie znam nawet układu ramki datagramu IP. Wiem, że są koledzy, którzy wiedzą bardzo wiele, są wręcz da Vinci swoich czasów, szczerze ubolewam nad swoimi brakami, ale dla mnie to nadal jest mało już przydatny trick, którym można zaszpanować na rozmowie kwalifikacyjnej i mocno ubolewać, że kandydat nie umie "zamienić zawartości dwóch zmiennych bez użycia trzeciej", a może nawet zapytać go, czym się różni pierścień od ciała. Wszak algebra jest podstawą informatyki.

I niestety (tu podzielę się moim doświadczeniem z rekrutacji i współpracy w ramach tworzenia zespołów ludzkich) dość często spotykam osoby, które są podobnym przypadkiem do owego "wściekłego geniusza", który nie został przyjęty. Tylko tu, zamiast złości, jest profesjonalnie chłodny cynizm i spoglądanie z góry. W końcu "TRVE
programista" koduje na poziomie sprzętu, liczy cykle maszynowe, operuje strumieniami video w telekomunikacji i zastanawia się, po co te wszystkie kolekcje typowane, jak by nie można było listy sobie zaprogramować...

Piszę to jako jeden z tych .netowców "frejmłorkciarzy-od-składania-klocków", który nie czytał klasyki informatyki i hmmm "nie wie wszystkiego"... świadom tego, że brak wiedzy o w/w zagadnieniu operatora xor i jego algebraicznych podstawach, mógłby zaważyć na wyniku jego
rozmowy kwalifikacyjnej na stanowisko codera, a może nawet inżyniera systemowego... Podobnie, jak pewnie niejednego dobrego analityka danych wysłał do /dev/null na rozmowie brak znajomości twierdzenia Rao-Cramera...Adrian Olszewski edytował(a) ten post dnia 11.01.10 o godzinie 20:30

Temat: Cała prawda o programistach

Ok, masz rację, schodzimy w stronę dyskusji o wyższości Swiąt Bożego Narodzenia nad Swiętami Wielkiej Nocy ;)

Tak naprawdę to chyba zgubiliśmy tutaj pewną, dość istotną, rzecz: programista C != programista SQL != programista C# != programista ASM uC.
W zależności od tego, jaką klasę zagadnień mamy okodować i w czym (język, środowisko) kodujemy, wymagane są inne umiejętności. To nie znaczy wcale, że jedni są lepsi od drugich (choć co poniektórzy tak twierdzą ;) ).
Z drugiej strony jednak patrząc: jasne, że w .NET są rozmaite, gotowe kolekcje - ale ktoś, kto wie, jak to działa będzie umiał sobie wyobrazić, jak to zostało zaimplementowane i napewno lepiej sobie poradzi w przypadku np. konieczności optymalizacji czasowej kodu. Wiem, wiem - teraz optymalizację czasową załatwia się mocniejszą maszyną, bo maszyna jest tańsza od pracy człowieka.
I w ten sposób dochodzimy do modnego obecnie pojęcia produkcji oprogramowania, dającego się określić w dużym uproszczeniu w następujący sposób: pisać kod, nie myśleć, bo szkoda czasu i się nie opłaca. Po prostu fabryka, linia produkcyjna. Wychodzi więc na to, że programiści stają się po prostu robotnikami - oczywiście wykwalifikowanymi.
Tyle, że trochę łza się w oku kręci, bo chyba z kąpielą wylane zostało i dziecko - a gdzie przyjemność z tworzenia?Piotr G. edytował(a) ten post dnia 11.01.10 o godzinie 21:01

Temat: Cała prawda o programistach

Ależ przyjemność nadal jest! I to w różnych sytuacjach. Tak dla przykładu pokażę, jakie to dla mnie są "źródła radości z tworzenia". Przecież właśnie dlatego zostałem programistą - aby mieć z tego nie tylko pieniądze, ale ponieważ to lubię :)

- skomplikowana kontrolka, która po tygodniach mozolnej pracy wyświetla i pozwala edytować złożone dane nie tylko schludnie i czytelnie, ale jest w pełni obsługiwana z klawiatury, realnie przyspiesza wprowadzanie danych. W moim przypadku to wprowadzanie wszelkiego rodzaju wyników badań klinicznych i laboratoryjnych (jedna kontrolka, wiele typów wyników i zachowań edytora). Piękny przykład wykorzystania wzorca model-widok-kontroler.

- system analityczny, który przez COM rozmawia z silnikiem obliczeniowym i udostępnia jego funkcjonalność lekarzowi, który za pomocą webowego GUI zadaje kryteria analizy, pozwala tworzyć ich scenariusze. Może mało odkrywcze i algorytmiczne, ale cieszy oko :) Znów MVC, do tego wdzięczny przykład do nauki modelowania obiektowego - hierarchia testów i procedur, renderery ich wyjścia, providery i selektory danych. Gdy straciłem większą część tego kodu wskutek błędu, kilka dni nie umiałem dojść do siebie. Wziąłem nawet na tę okoliczność urlop w pracy (na szczęście był to projekt "na boku" i już sprzedany).

- wspomniana przeze mnie wcześniej procedura (jedna z wielu różnych), wyliczająca dłuuugi szereg statystyk opisowych w podgrupach w SQLu. Można się tutaj wyżyć, że hoho! Trzeba np. liczyć momenty zwykłe i centralne i wykorzystywać je później, by nie liczyć iks razy tego samego. Trzeba zaimplementować test normalności rozkładu + tablice wartości krytycznych do niego, a także wartości statystyk dla przedziałów ufności, można nawet wyliczać pradopodobieństwa... Niby tak banalnie brzmi, ale gdy pierwszy raz odpaliłem tę procedurę na danych, mogłem natychmiast zdefiniować selectem-z-groupbajem próby i czysty (bez żadnych DLLek) "dynamic SQL" wyrzucał mi listę pokaźnych statystyk z badaniem normalności rozkładu, przedziałami ufności, średnimi (windsorską, uciętą), błędami, odchyleniami (dla średniej i mediany), kurtozą, etc. plus kontrola poprawności wprowadzonego selecta, miałem łzy w oczach :) Mam w profilu zrzut ekranu z jej działania, jestem z niej prawdziwie dumny - a o to przecież chodzi :)

- bogaty w funkcje klient Centrum Kształcena Dystansowego przy "moim" zakładzie na uczelni, pisany w... uwaga! Macromedia Authorware (graficzny "język programowania" dla celów prezentacyjnych i symulacyjnych) oraz MFC. Własny parser własnej gramatyki (scenariusze kursu i powtórek), komunikacja międzyprocesowe (Boże, ileż nocy nad książką Petzolda i innymi cegłami... tłumaczenie z rosyjskiego tutoriali o DDE, nauka TCP/IP i COM). 3 bite lata pisania w skrajnie różnych środowiskach. Opis do tego (instrukcja obsługi + draft licencjatu) mam także w profilu. Myślę, że jak na studenta, nie była to mała robota.

- frontend do konsolowego frameworka do komunikacji z telefonami Nokia. Ktoś by rzekł - a cóż to za problem napisać GUI? Parę kontrolek... tak, ale trzeba było aplikację konsolową napisaną w C++ przerobić tak, by pracowała z GUI w .NET ("marszaling", alokacja zasobów i zarządzanie nimi), drążenie w kodach źródłowych... wcześniej przed tym czytałem wyjście konsoli i parsowałem je, bo nie mogłem sobie poradzić z DLLką :)Screeny do tego - także w profilu. Sporo kadry z zakładu się tym bawiło :) Działa do dzisiaj - jak ktoś ma stara Nokię, kabel FBUS (łatwo zmajstrować), to można sobie zrobić alarm z powiadomieniem na SMS albo sterowanie urządzeniami za pomocą SMSa. Pewnie, że są gotowe moduły i to nie wymagające komputera (z Windows) do pracy, ale w 2004r. było to ciekawe rozwiązanie :)

- napisany podczas stażu system ewidencji pojazdami i kierowcami... Już kilka lat minęło, nabyłem wielu umiejętności, a nadal mi się podoba :) Spora aplikacja, wydruki na formularzach klienta, złożone parametryzowanie, pełny instalator, który wyszukiwał po sieci serwery SQL, pełna administracja, nowoczesne GUI (jak na tamte czasy). Wszystko to w 2 miesiące per jedna osoba... do tego dokumentacja użytkownika. Miałem gdzieś, ile za to dostanę - dopieszczałem ten system nie śpiąc po nocach, bo to było "moje dzieło" :) Pasja.

- obecna aplikacja, flagowy produkt firmy, w której pracuję, system generowania dokumentacji elektronicznej, jej synchronizacji między jednostkami ZOZu oraz backupu. Chociaż nie ja to programuję, tylko duże centrum produkcyjne ze świetnym specjalistą na czele, to jednak jestem jednym z jej "głównych ojców" pod względem analitycznym - przynajmniej w zakresie EHRa i wydruków. Zanim przekażę centrum produkcji analizę z jakąś nową kontrolką - sam ją najpierw piszę, aby oni nie musieli przeczesywać netu i tracić czasu na "kombinowanie". Długo walczyłem o to, aby wolno mi było to robić (programować analitykowi), szef z bólem serca poszedł mi na rękę i nadal mam swój świat :) I tak to potem biorą na tapetę specjaliście lepsi ode mnie, ale mają chociaż punkt wyjścia - i nie narzekają :) A jakie cuda można robić za pomocą microsoftowej kontrolki raportów (RDLC) - takie wydruki, że ha! Siadam do tego nie poczuciem wykonania "jakiejś pracy", tylko, kurde, z radością :)

Właśnie to wszystko, co mam w profilu, to chęć podzielenia się własną radością z tego, czemu poświęciłem tyle czasu, ile jeszcze żadnemu projektowi zawodowemu (szefie, nie czytaj tego!). To są czasy nauki wielu technologii: z jednej strony Turbo Pascal (i moja biblioteka procedur, którą wykorzystywano jeszcze kilka lat na uczelni - oczywiście bez mojej zgody i wiedzy :]), assembler, MFC, z drugiej początki .NET (1.0, kto pamięta?)...

... to tylko kilka przykładów z niemałej ich liczby. Nie ma tu co prawda wyższej matematyki i algorytmiki, ale nie ma też bezmyślnego wstukiwania kodu: utwórz dataset, wyklikaj kolumny, nazwij je, zbinduj z listą, zrób refresza, liście ustaw dokowanie na fill, nacisnij F5, ciesz się...

Aby jednak nie poruszać się tylko w zakresie nowości - pisałem na studiach w assemblerze na zaliczenie programik - nic wielkiego - przesyłanie pliku przez RS232. Postawiłem sobie wyzwanie (opłaciło się potem!), że nadajnik i odbiornik będą TSRami, że będą odporne na błędy transmisji, że będą sumy kontrolne, wyświetlanie czasu do zakończenia operacji... że będą definiowalne skróty klawiszowe... urosła z tego spora aplikacja, a mnie cieszyła każda dołożona funkcjonalność. No i był to początek kariery na zakładzie, z którym związałem się na 3 kolejne lata :) W każdym razie zaliczenie już miałem w kieszeni, stukałem kod - jak w każdym przypadku - just for fun.

A przecież o to chodzi :)

Dziś jestem bardziej analitykiem danych, analitykiem funkcjonalnym i inżynierem systemowym, niż programistą (pod względem % wykorzystania czasu), ale nadal czasem siadam do kompilatora w pracy, chociaż mnie od tego szef odciąga(ł) prośbą i groźbą - ale to jest moja pasja. Jak przestanę programować, to za pół roku wypadnę totalnie z obiegu. Już widzę, że wypadłem, gdy czytam o nowych technologiach na tej grupie, o programowaniu aspektowym... już jestem daleko w tyle... Ale ciągle w maratonie!

Chociaż nie czytałem Dijkstry :)Adrian Olszewski edytował(a) ten post dnia 12.01.10 o godzinie 10:39

Temat: Cała prawda o programistach

No cóż - nie ukrywam że to, co napisałeś o swoich dokonaniach, robi wrażenie. Na całe szczęście wygląda na to, że jesteś jednak w grupie fachowców którzy chcą i lubią robić porządnie (choć to gatunek prawie już wymarły) - a ja bardzo szanuję takich ludzi.
Widzę, że nie róznimy się wcale tak bardzo, jak na pierwszy rzut oka się zdawało - doskonale rozumiem motywy, które kazały Ci siedzieć po nocach i dopieszczać soft, za który nie miałeś dostać góry $$$.
Nie będę tutaj przedstawiał własnych dokonań, bo primo: nie o licyctację chodzi, secundo: nie wiem, czy bym Cię przelicytował ;)
Nie napisałeś jednak o drugiej stronie medalu.
Ja, po prawie 19 latach pracy jako programista (no, z przerwami), mam też pewne złe doświadczenia:
- kilkanaście razy projekty, które tworzyłem lub byłem ich "ojcem" (sorry za podkradnięcie), zostały mi odebrane bez prawa głosu, bo "teraz zajmował się będzie tym ktoś inny";
- kilka razy projekty "pudełkowe", które tworzyłem i którymi się opiekowałem po wdrożeniach (np. 50 lokalizacji po 30 urządzeń mobilnych) były uznawane przez kolejnego szefa handlowców (powinienem napisać: sprzedawców) jako niesprzedawalne i zbyt drogie w utrzymaniu (w rzeczywistości utrzymanie kosztowało góra kilka godzin miesięcznie - ale nikt tego nie chciał sprawdzić) i "uziemiane". W niektórych przypadkach, po kilku miesiącach, jednak handlarze dochodzili do wniosku, że było to błędne posunięcie, kilka razy projekty były nawet przywracane - ale wq... pozostawało;
- wiele razy zabrakło mi "softskillsów" i wytrwałości w walce (tak, w walce) z handlowcem czy nieprofesjonalnym projectmanagerem, żeby nie pozwolić projektom, w których uczestniczyłem, zdryfować w stronę mało profesjonalnych i bardzo bylejakich rozwiązań.

Z moich doświadczeń wynika jedno: jeśli nie uprawiasz "wewnętrznego marketingu" (wewnętrznego = wewnątrz organizacji), prędzej czy później zaczną wypychać Cię ze stołka (funkcji, odpowiedzialności, itp, itd) różni "wszystkowiedzący" śmieszni pseudofachowcy. I wracając do meritum, od którego te wszystkie dyskusje się zaczęły, czyli do sensowności "egzaminów" rekrutacyjnych: uważam, że WARTO sprawdzić kandydata w warunkach stresu i presji, żeby móc ocenić, jak on sobie poradzi w sytuacjach takich, których np. ja doświadczyłem. I wcale nie chodzi o to, czy on to "zadanie" podczas rekrutacji rozwiąże poprawnie, czy też nie - nikt nie jest nieomylny, szczególnie w stresie. Tak naprawdę chodzi o to, na ile stres blokuje mu myślenie, jak reaguje na wytknięcie błędu, czy umie go poprawnie zdiagnozować i poprawić, czy potrafi cofnąć się w rozumowaniu wstecz, jeśli okazuje się, że brnie w ślepą uliczkę itd. No i, co dosyć ważne, wychodzi zwykle czarno na białym, ile gość nazmyślał w CV. Bo co innego, jak pomyli się przy tworzeniu klasy statycznej i zapomni dopisać atrybutu 'static' przy jednej z metod, a co innego, jeśli gość zaczyna się zastanawiać, dlaczego nie może utworzyć instancji takiej klasy i po kilku naprowadzeniach widać, że nie rozumie różnicy między klasą statyczną i "zwykłą"...

Co nie zmienia faktu, że mnie to cholernie wq... że trzeba stosować takie wybiegi. Ale każdy kij ma dwa końce: skoro wymaga się softskills od już zatrudnionego pracownika, trzeba być przygotowanym także na to, że CV będzie "podbarwione".

Temat: Cała prawda o programistach

Adrian Olszewski:
Herbatka? Dżinsy? Ależ to byłby raj! Nigdy takiej nie miałem i prawdę mówiąc, nie patrzyłbym na takich ludzi dobrze - ja nawykłem do garnituru i frontalnej obrony.

Tak wyglada u nas rozmowa kwalifikacyjna :)

Mala firma, duze projekty, wysoki prog wejscia (min. 9 miesiecy nauki). Na pomylki w rekrutacji nie ma miejsca, a wiadomo jakie glupoty ludzie pisza w CV...

Temat: Cała prawda o programistach

W temacie rozmów kwalifikacyjnych...
Najlepsza w jakiej miałem przyjemność uczestniczyć składała się z bardzo prostych elementów, a kluczowym było napisanie banalnej aplikacji. Siadam przed VisualStudio z potencjalnym przyszłym przełożonym i... koduję. W ten sposób widzi jak obchodzę się z VS, jak organizuję pracę, jak rozumuję pisząc kod, jak posługuję się skrótami klawiszowymi itd. Zadanie było naprawdę proste: kalkulator w WinForms. A okazało się, że jako jedyny z aplikantów nie wrzuciłem całej "pseudologiki" w obsługę OnClicków, że o zahaczeniu o unit testy nie wspomnę.
Wystarczy dosłownie kilka minut żeby w ten sposób ocenić potencjał kandydata.
Z kolei kodowanie na papierze i czepianie się do błędów syntaktycznych uważam za bezsensowne - do tego Bozia wymyśliła kompilator.
Kiedy indziej dostałem polecenie "Proszę narysować diagram uml dla aplikacji typu Paint. Wracam za 5 minut"... Co prawda można podobne zagadnienie sformułować w bardziej sensowny sposób, ale czy tak naprawdę stworzenie diagramu w kilka minut bez precyzyjnych wymagań sprawdzi cokolwiek oprócz umiejętności rysowania prostokątów?
Generalnie uważam, nie należy od kandydata oczekiwać na rozmowie pełnej "zdolności bojowej", ponieważ i bez tego da się odfiltrować "potencjalnie dobrych" od "z pewnością beznadziejnych".

Temat: Cała prawda o programistach

Maciej Aniserowicz:
Siadam przed VisualStudio z potencjalnym przyszłym przełożonym i... koduję.

Bardzo fajne zadanie :) Esencja, Zazdroszczę.

Większość pytań na typowych rozmowach, to albo zakoduj 5 zadań na kartce... co wg mnie nie jest najlepszym pomysłem, albo też pamięciówka w stylu ta klasa to jakiego namespacu pochodzi?.

Generalnie z tego co sam zobaczyłem oraz to co znajomi mi przekazali jak byli na swoich rozmowach, rekrutacje możemy podzielić na następujące typy:

1. Typ. Sztuczki czyli Test z samymi pytaniami o rzeczy z których nikt nie korzysta na co dzień, albo też się nad tym nie zastanawia, często wie ale w stresie ciężko o takie detale. Te testy mają na celu pokazać jak dobry jest ten kto to pisał ;)

Przykłady:

Jeśli do zmiennej bit w SQL przypiszemy coś z poza zakresu to co się stanie.

Jeśli zrobimy funkcje anonimową zwracającą delegat anonimowy za parametrami x,y,z to co nam kompilator wygeneruje.

2. Typ. Testy pamięciowe albo "co to jest?", "co robi?" Czyli generalnie testy teoretyczne. Jeśli testują to co faktycznie będziemy robić w pracy to na 95% znamy odpowiedź, ale w tej kategorii zdarzają się też pytania z serii trudne, jako że można się zapytać o detale. Ale na pewno jest to bardziej preferowana forma niż 1.

3. Typ. Programy na kartce, jeśli ktoś je pisał to wie jaki to ból nie mieć kompilatora, jeśli są to testy w stylu zaprojektuj kolekcje np. albo zrób coś biznesowo to jeszcze ok, gorzej jeśli dostaniemy skomplikowane algorytmy, wtedy zanim zrozumiemy zadanie trochę minie a przecież trzeba to na kartkę przenieść i nie ma możliwości sprawdzenia tego co napisaliśmy.

Dobry Przykład: Zaprojektuj kolekcje spełniające wymagania x,y,z.

Zły Przykład: Napisać program do znajdowania liczb pierwszych metodą statystyczną, pierwsza myśl jaka może się nam nasunąć to jak znajdowało się liczby pierwsze, a kolejna to jak wyznaczać je metodą statystyczną.

4. Typ. UML, DFD etc, czyli rysowanie. Nie jest to złe zadanie do zrobienia na teście, jeśli dostaniemy wymagania co do systemu i mamy to przedstawić w postaci diagramu.

Natomiast metoda:

"Niech pan teraz tu narysuje wzorzec np: Chain of Resp", jest zupełnie nie trafiona ponieważ mogę się tego na pamięć nauczyć tzn nie muszę wiedzieć jak on działa ani mieć pojęcia do czego się go stosuje.

5. Typ. Pisanie przy komputerze prostych programów, oraz sprawdzenie kandydata pod kątem tego jak koduje. Niestety nigdy nie miałem przyjemności :( ale pomysł wydaje się najbardziej trafiony.

6. Typ. Rozmowa oraz zadawanie pytań problemowych. Preferowany typ, najmniej stresujący, poza tym prowadzimy dyskusję na znane nam tematy.

7. Typ. Kombinacje powyższych punktów, osobiście spotkałem się z kombinacjami (1,2) oraz (3,4,5) jak też (2,5) z tych trzech kombinacji z którymi się spotkałem osobiście najlepsza wydaje się (2,5). Prosty test + rozmowa z programistami, co tam robiłem jak kodowałem jak rozwiązywałem problemy itp.

Czy ktoś jeszcze może coś dodać do tej kolekcji?Bartosz Adamczewski edytował(a) ten post dnia 13.01.10 o godzinie 12:55