TheTarPit

rekrutacja

Taka sobie refleksja po krótkiej inspekcji stanu/postępu prac w zespole — warto się upierać przy „głupich” zadaniach podczas przesłuchania kandydatów na programistów. Warto kazać im rozpisywać na kartce problemy, z którymi nigdy się nie spotkają w prawdziwym życiu. Warto pytać i dociekać dlaczego takie a nie inne rozwiązania stosują. Warto sprawdzić czy rozumieją sugestie, czy „chwytają” podpowiedzi i kojarzą.

Patrząc na dokonania (wciąż) młodego stażem kolegi W jestem pewien, że zespół został zasilony w najlepszy wtedy możliwy sposób i że nie wymaga to już ode mnie żadnej interwencji i ani odrobiny nadzoru. Patrząc na postępy całkiem nowej koleżanki T jestem spokojny o to, że każda zainwestowana chwila prowadzi w dobrym kierunku, ustawia na właściwe tory i nie zostanie zmarnowana. Patrząc na stos odrzuconych CV i kartek zapisanych idiotycznymi wypocinami jestem pewien, że nie czai(ł) się tam żaden niesamowity talent programistyczny.

Klucz do sukcesu rekrutacji — nie bój się odrzucać 95% kandydatów. Jeżeli wydaje Ci się, że oni nie są warci zachodu, to naprawdę nie są. Większość tych, którzy szukają pracy programisty, zwyczajnie nie zasługuje na to, żeby poświęcać im czas przesłuchania.

A poza tym — jaki jest sens przyjmować do zespołu kogoś, kto nie jest (lub nie rokuje, że już niedługo będzie) lepszym programistą ode mnie. Gorszych od siebie mogę znaleźć na pęczki; jednak znaleźć i utrzymać odpowiednią liczbę lepszych — to sztuka i jedyny sens tej zabawy.

My i oni

Pracuję w ten branży lat kilka (no... -naście powiedzmy szczerze) i miałem okazję (współ)pracować z różnymi zespołami i szeroką gamą „typów ludzkich”. Parę rzeczy (za dużo) widziałem i wyrobiłem sobie kilka niezmiennych opinii i zapewne niesprawiedliwych uogólnień. Wiele z nich wynika z mojego trudnego sposobu bycia. Jednak nie udało się uniknąć wyraźnego poczucia, że oni są inni. Nigdy nas nie zrozumieją i zazwyczaj mają zupełnie inny pogląd na sytuację i inne cele. Oczywiście pogląd gorszy, a cele sprzeczne. A jednak z jakiegoś zupełnie niezrozumiałego powodu uparcie się ich trzymają...

kryptonim: polmos

Produkcja oprogramowania kategorii środkowej pociąga za sobą jeszcze jedną komplikację, której wcześniej nie byłem świadom — wersjonowanie programu okazuje się nie całkiem banalne.

...ponieważ jesteś kretynem, który łatwo daje się zagadać

Są takie książki, których warto się uczyć na pamięć. I są takie cytaty, które po prostu trzeba zapisać...

Jak przeżyć pod naporem zadań i nie zwariować do końca

Disclaimer: znowu będzie marudzenie o sprawach, które nikogo nie obchodzą. Za to będzie długo. Ale co mi tam. Czasem trzeba po prostu napisać coś dla przekonania samego siebie, że pewne działania wbrew pozorom mają sens... ;-) Charakter mojej pracy uległ w czasie ostatniego pół roku tak znacznej zmianie, że właściwie nie spodziewałem się, że to kiedykolwiek nastąpi. Słowem wpadłem po uszy w środowisko rzeczywiście sterowane zadaniami. Nie dziwne zatem, że starając się przeżyć (efektywnie) w pracy i równocześnie wyspać (również efektywnie) nie myśląc o pracy po nocy, opracowałem sobie pewien zestaw zachowań i zebrałem pewien zbiór maksymalnie prostych narzędzi umożliwiających funkcjonowanie w środowisku sterowanym zadaniami. Garść przemyśleń poniżej. Wszelkie komentarze i propozycje jak zwykle mile widziane...

Ja nic nie wiem, ja tu tylko programuję...

Po ponad 8 latach pracy zawodowej z systemami o zbliżonym i względnie ograniczonym zakresie biznesowym, dokonałem ostatnio całkowitej zmiany branży... Stąd narasta we mnie od jakiegoś czasu pytanie, którego nie miałem potrzeby zadawać właściwie nigdy wcześniej: na ile ważne jest zrozumienie procesu biznesowego klienta i sposobu w jaki używa on naszego oprogramowania?

Starszych wpisów szukaj w archiwum tematu lub ogólnym.