U mnie działa, czyli jak wyjść na amatora w pracy

Jakiś czas temu pisałem o tym, co odróżnia seniora od juniora  w pracy. Dzisiejszy wpis, będzie kontynuacją moich obserwacji zachowań “narybku”. W zasadzie jest to lista grzechów głównych, które powodują niezadowolenie każdej ze stron. Wpis ten ma charakter mocno sarkastyczny i zdecydowanie z perspektywy “pracodawcy” więc jeśli pracujesz na etacie – możesz się poczuć urażony.

1. “U mnie działa”

To moja ulubiona wymówka, kiedy okazuje się, że wyprodukowany kod wysypuje się na serwerach testowych lub produkcyjnych. Słyszałem, już to wiele razy i zwykle są to ostatnie słowa, jakie wymawia programista przed zwolnieniem.

Smutna prawda jest taka, że nikogo nie interesuje to, że coś działa na Twoim komputerze. Twoim celem jest uruchomienie oprogramowania gdzieś indziej. Łańcuszek szczęścia jest prosty – programujesz dla pracodawcy lub klienta końcowego. Jeden z tych dwóch miłych Panów (lub Pań) zostawia pieniądze, które po części idą na Twoje wynagrodzenie, ogrzewanie biura, w którym siedzisz i dobre samopoczucie zainteresowanych stron. Jeśli łańcuszek szczęścia zostanie przerwany – pozostajesz z radością posiadania oprogramowania działającego na Twoim własnym komputerze.

Bardziej krnąbrnym programistom można ewentualnie zaproponować przekazanie swojego komputera klientowi (w końcu na nim działa) lub też dostarczenie wybranej maszyny do data center.

2. Nie miałem czasu przetestować

To też jest całkiem sprytny sposób na wytłumaczenie się z lenistwa. Nie mamy czasu na testowanie, zawsze znajdziemy czas na poprawki. W większości przypadków dużo łatwiej jest zakomunikować “opóźnienie” niż wytłumaczyć się z kiepskiego rozwiązania.  A na pewno powoduje to mniejszą frustrację chlebodawcy. Wymówka i grzech ten jest powiązany z pierwszym. W końcu na moim komputerze działa, sprawdziłem. Zabrakło czasu na napisanie testów, lub kliknięcie na produkcji. Oczywiście też przetestowanie dwóch różnych skrajnych możliwości jest poza zakresem moich obowiązków. Wszyscy wiedzą, że w pierwsze pole można wpisać tylko cyfry w przedziale 1-5, a w drugim 3 literki oddzielone przecinkami.

3. To jest najlepsza metoda

Programista myśli inaczej. Nie chodzi o to jak działa, tylko że działa. Można wyświetlić 1000 pozycji na jednej stronie, przecież można ją przewinąć. Po co sortować coś alfabetycznie, przecież jest w kolejności dodawania. To co z tego, że mamy dwóch J. Kowalskich na liście – musisz się domyśleć który to Jan, a który Janusz. Chcesz usunąć na raz 10 pozycji ? Kliknij 20 razy. Przecież  ja na raz usuwam rekordy pojedynczo i klikam potwierdzenie. Nie wiesz jak znaleźć edycję ? Musisz kliknąć dwa razy, po lewej stronie w 3 kolumnie.  Użyteczność (usability) to nie jest coś za co mi płacą. Płacą mi, że to działa – nie za to żeby było komuś łatwiej.

4. Nie wiem jak to zrobić, ale wstydzę się zapytać

Siedzę już nad tym 3 dni, mógłbym się zapytać kogoś kto to już robił, ale wyjdę na amatora. Poczekam jeszcze trochę, sprawdzę google bo jest łatwiej niż zapytać kolegi zza biurka. Ewentualnie napiszę to inaczej. Dodam 300 linii kodu, bo używanie czyjegoś kodu jest oznaką słabości. Moja biblioteka będzie lepsza, szybsza i na pewno użyję ją więcej niż raz. Na wszelki wypadek nie dam komentarzy, bo szkoda na to czasu. Przecież wiem dlaczego tutaj jest 3.123533 a metoda XYZ ma samo opisującą się nazwę.

5. No przecież to musi być takie wolne – dajmy więcej RAMu

Wydajność mojej aplikacji jest odwrotnie proporcjonalna do mojego doświadczenia. Chodzi za wolno ? Za wolny procesor, za mało RAMu. To co, że mam 10 zagnieżdzonych pętli, albo wykonuję w niej zapytania zamiast wyciągnąć je raz. Przecież tak działa – klikam i widzę wyniki. Czy moją aplikację będzie używało 100 osób na raz ? Na pewno będę miał tutaj mniej niż 100 rekordów. Chociaż moją ulubioną wymówką jest “memory leak” – od czasu do czasu restartujemy aplikację i działa. Rozwiązanie problemu nie wchodzi w grę – wymaga zbyt dużo wysiłku. Tak musi być i koniec.

6. To zawsze się uda

Nie musimy obsługiwać błędów, ponieważ dana operacja zawsze się powiedzie. E-mail zawsze się wyśle, plik zawsze się doda a ryzyku przerwania połączenia z serwerem nie występuje. Dlatego nie musimy ubezpieczyć się na wypadek tego, że się nie uda. Po prostu coś zniknie, coś się nie wyśle i nikt się nie zorientuje.

Obsługa błędów jest czasem straconym jak i testowanie. Przecież musi działać, u mnie działa i zawsze będzie działać. Masz starą przeglądarkę ? Za wolny komputer… cóż. Moje 27″ z i7 daje radę. Zrób sobie upgrade.

7. Nie będę tego zmieniał znowu

Ten grzech jest dosyć dyskusyjny – nikt tego nie lubi, nikt tego nie chce. Prawda jest taka, że czasami trzeba. Trzeba zmienić, trzeba poprawić, trzeba skasować tydzień pracy. Tym razem zamiast szydzić – dam Ci radę. Jeśli nie chcesz zmieniać – raportuj postęp prac, albo koncepcję z przełożonym. Jest duża szansa, że jeśli coś idzie źle – wyłapiesz to zanim spędzisz tydzień swojego życia na pisaniu czegoś zupełnie niepotrzebnego.

8. Będę pracował zdalnie

Na koniec marzenie każdego programisty – praca zdalna. Będę klikał z domu, nie stracę czasu na dojazdy. Przecież robię to samo – tak ? Nie do końca. O ile Twoja umowa z pracodawcą nie wskazuje na taką możliwość, to… jest to raczej przywilej oparty na mocnym zaufaniu pracodawcy, że w domu nie będziesz siedział “mniej” na  Facebooku jak to robisz w pracy, czy też postanowić obejrzeć sobie wszystkie dostępne filmy na YouTube. Dlatego, jak już wychodzisz z taką propozycją – upewnij się, że nie zostałeś złapany na opierdzielaniu się w pracy w ostatnim tygodniu.