5 rzeczy, które chciałbym wiedzieć, jako początkujący dev

Pracuj z lepszymi

Najprostsza zasada, ale jakże trudna do osiągnięcia szczególnie, gdy mamy cieplutką posadę w projekcie, który jest swoistym greenfield’em.

Współtworzymy aplikację od samego początku, każdy liczy się z naszym zdaniem. Jesteśmy osobą decyzyjną do tego stopnia, że każdy ufa nam na słowo, że jakiejkolwiek zmiany nie wprowadzimy, to będzie dobrze. Same plusy – robimy to, co lubimy i jesteśmy w tym dobrzy, więc po co coś zmieniać?

Przede wszystkim warto się zastanowić, jakie pułapki to z sobą niesie. Tak jak wspominałem, gdy mamy wyrobioną tak silną pozycję w projekcie, to większość osób ufa nam za bardzo – prowadzi to do kuriozalnych sytuacji, zwłaszcza gdy czujność pozostałych developerów z zespołu może być uśpiona choćby podczas code review: „bo przecież on wymiata zawsze, więc tylko przescrolluje czy mi się nie rzuci coś w oczy”. Zapominamy o tym, że przecież nikt nie jest nieomylny.

Łatwo również o to, aby do pracy wkradła się monotonia, z którą godzimy się żyć, mimo, iż może nas ona powoli wypalać zawodowo. Z autopsji wiem, że najlepsze pomysły – tudzież odkrycia genialnych rozwiązań – wynikały właśnie podczas dyskusji (które czasem niejednokrotnie przeradzały się w kłótnie) z innymi developerami, bo każdy miał swój punkt widzenia i zderzenie ich wszystkich rodziło wiele pomysłów.

Uwielbiam to uczucie, gdy po zażartej rozmowie każdy odczuwa spełnienie, że udało się dojść do porozumienia i znaleźć soczyste rozwiązanie, które satysfakcjonuje wszystkich.

Przychodzi mi do głowy jeszcze jeden oczywisty argument: praca z lepszymi zmusza nas do gonitwy za poziomem innych – przecież nikt nie chce odstawać w zespole. Co więcej, podziw w oczach bardziej doświadczonych devów względem Twojej osoby działa szalenie motywująco i pcha nas nieustannie w stronę pogłębiania swoich umiejętności.

„Dobry programista to leniwy programista”

Przyznam, że do niedawna nie znałem tego powiedzenia. Słyszałem jednak o tym, że Bill Gates zwykł mawiać: „Zawsze wybiorę osobę leniwą do trudnego zadania, ponieważ ona szybko znajdzie najprostsze rozwiązanie”. I powiem wam szczerze – wygodnie było mi się utożsamiać z tymi słowami.

Mimo iż zawód programisty raczej nie polega na leżeniu brzuchem do góry, a raczej wymaga od nas determinacji w poszerzaniu wiedzy i logicznego myślenia, to odrobina lenistwa pozwala sprawić, by nasze życie było łatwiejsze. Zdradzę Wam, że właśnie od lenistwa zaczęła się moja przygoda z programowaniem, gdy jeszcze jako serwisant w pewnej firmie musiałem często testować aplikację dla klientów. Zawierała ona sporo formularzy i wypełnianie ich potrafiło być po paru godzinach bardzo monotonne. Dodam, że wtedy jeszcze nie wiedziałem o istnieniu testów automatycznych (np. tych tworzonych z użyciem Selenium), ale za to potrafiłem pisać proste skrypty w AutoHotKey’u.

Jeszcze jako nastolatek zacząłem ich używać. Jedyne co robiły, to pisały uprzednio zdefiniowane zadania – używałem tego do spamowania na czatach w grach MMORPG (sorry za Piotra z przeszłości!). Tak czy inaczej, ta bardzo uboga wiedza z zakresu tworzenia skryptów AHK połączona z kilkoma godzinami spotkań z wujkiem Google, pozwoliła mi stworzyć w pełni zautomatyzowane skrypty do wypełniania formularzy. Później zacząłem tworzyć bardziej zaawansowane rzeczy jak aktualizatory do aplikacji (zamiast ręcznie puszczać skrypty, kopiować pliki). Wszystko sprowadzało się do przesłania klientowi EXE’ka i uruchomieniu go, a cała magia działa się w tle, podczas gdy ja oddawałem się innym rzeczom. Był to pierwszy krok, który skierował mnie do bycia developerem. Po dziś dzień używam AHK do automatyzacji codziennych, powtarzalnych czynności. Także pracuj z głową i rób tak, aby zrobić i się nie narobić!

Nie ograniczaj się tylko do obecnego projektu

Osobiście lubię długofalowe projekty. Pozwalają na to, by bardziej dopieścić produkt niż na prędko sklejona mała aplikacja w miesiąc, a ja czerpię ogromną satysfakcję z czystego, dobrze napisanego kodu. Jedynym minusem jest to, że w takich dużych projektach nie ma szans, abyśmy wszędzie mieli swój udział. Często przechodzimy do już trwającego projektu i tak naprawdę nigdy nie mieliśmy okazji skonfigurować swojego projektu od zera, stworzyć fundamenty aplikacji, mieć wpływ na architekturę. Dodatkowo często jesteśmy zmuszeni działać w określonych ramach, co skutecznie może przyćmić naszą wenę.

Nie zgodzę się też z tym, że dobry programista musi drugie tyle poświęcać na samorozwój – co wtedy mielibyśmy z życia? Uważam jednak, że warto na boku tworzyć własne, mniejsze projekty, gdzie mamy całkowity wpływ na kierunek rozwoju aplikacji, np. jaki wybierzemy język, technologie czy framework. „Kiedy trzymasz w ręku młotek, każdy problem będzie wyglądał jak gwóźdź” – i tak o to, nie eksperymentując na własną rękę, może się szybko okazać, że jesteśmy dobrzy tylko w tym, co aktualnie robimy, a każde odstępstwa od utartego flow może się okazać dla nas dużym gwoździem, ale nie takim, który szybko wbijemy.

Część rozwiązań, które stworzyłem w celu zgłębienia jakiegoś problemu, który sobie sam wymyśliłem, faktycznie przydały się nawet w głównym projekcie, nad którym pracowałem i zaoszczędziły nie tylko mi, ale całemu zespołowi mnóstwo czasu i nerwów. Mało tego – na niektórych stworzonych programach udało mi się nawet zarobić, bo okazały się dla kogoś atrakcyjne! Dlatego twórz, twórz cokolwiek, bo nie da się przewidzieć, co akurat „chwyci”, a o efekt kuli śnieżnej nie jest aż tak trudno.

Nie musisz wiedzieć wszystkiego

Jedna z najbardziej kontrowersyjnych reguł, jakimi się kieruję. Wiem, że spora część programistów uważa, że aby programować w danym języku musisz absolutnie ogarnąć jego podstawy, zanim zaczniesz tworzyć coś poważniejszego. Dzieje się tak głównie dlatego, że większość rozmów kwalifikacyjnych jest oparta właśnie o znajomość głównie teoretycznych zagadnień, bo tak najłatwiej odsiać ludzi. Często prowadzi to do zabawnych sytuacji, gdzie osoba rekrutująca się jest w stanie wyklepać z pamięci, czym jest „kowariancja”, ale nie zdaje sobie sprawy, że na co dzień tego używa.

Wolałbym zadać pytanie: „Czy mając zmienną typu X mogę przypisać do niego obiekt typu Y, zakładając, że X jest klasą bazową klasy Y? Jeśli tak, to kiedy to ma sens?” Dzięki temu poznałbym sposób myślenia danej osoby, a nie czy ma tylko dobrą pamięć. Nie zrozumcie mnie źle – zasady działania danego języka są bardzo ważne, ale upierałbym się, że raczej jest to wiedza, którą powinni dysponować przede wszystkim zaawansowani Medium Developerzy czy Seniorzy. Myślę, że przyjemniej pracowałoby mi się z osobą, która potrafi napisać poprawną dyrektywę strukturalną w Angularze, aniżeli jest mi w stanie opowiedzieć dokładnie, na czym polega prototypowanie w języku JavaScript czy też jak działa Garbage Collector.

Uważam, że taka „precyzyjna” wiedza, jeśli już będzie potrzebna, to jest ona bardzo łatwa do pozyskania – Google pomoże. Framework AngularJS uczyłem się po obejrzeniu 2-godzinnego kursu online z JavaScriptu i wiecie co? Wystarczyło mi to w zupełności, a całą pozyskaną wiedzę na temat podstaw działania mechanizmów JS nabywałem przez lata, czytając różne blogi – po prostu z czystej ciekawości. Powiem więcej – będąc bardziej doświadczonym, uczenie się tych „podstaw języka” okazywało się przyjemne i łatwiejsze w zrozumieniu, bo miałem szersze spojrzenie, niż osoba początkująca, która jest zalewana ogromem nowych rzeczy.

Nie ważne jak coś zrobisz, ale jak przedstawisz, że to działa

Osoby, które ze mną pracują, pewnie kojarzą te słowa, bo czasem na głos je przypominam. Zdarzyło Wam się spędzić dziesiątki minut na rozmowie z klientem o tym, gdzie w projekcie powinien być button i jak powinien działać? Ja uczestniczyłem w stanowczo za dużej liczbie tego typu spotkań.

Załóżmy sobie prosty przypadek, że mamy formularz, który nie może zostać wysłany, bo pewne dane są nieprawidłowe (dla uproszczenia jest to pierwszy przypadek w nowej aplikacji). Co więcej, klient nie opisał dokładnie w kryteriach, co powinno się stać.

Co teraz?

• obgadujemy to z całym zespołem,
• dzwonimy do klienta,
• tłumaczymy mu jaki jest problem,
• sugerujemy mu rozwiązania, rzucone przez wszystkich np. wyświetlanie modala, blokowanie przycisku z tooltipem lub bez,
• tłumaczymy mu, co to w ogóle jest tooltip,
• robimy przerwę na kawę,
• pokazujemy mu na jakimś przykładzie z internetów, jak to działa,
• ocieramy łzy, bo jest piątek godzina 16:15,
• wreszcie wymyślamy jakąś dziką notyfikacje z ostrzeżeniem, wyjeżdzającą z którejś części ekranu w zależności od aktualnej pozycji księżyca na niebie,
• …

Ile pieniędzy klienta i naszych nerwów kosztowała decyzja dotycząca prostej rzeczy, nie mówiąc o dodatkowym czasie potrzebnym na implementacje? Czasem takie sytuacje mogą wydawać się dla nas oczywiste, a dla klienta niekoniecznie – przez to będzie próbował się dostosować, na prędko szyć jakieś rozwiązanie, wybierze coś losowego bądź się wycofa. Czasem nie warto obarczać go takimi problemami i po prostu przejąć inicjatywę.

Owszem, może trochę przejaskrawiony przykład, ale wiecie, co mam na myśli. Często widzę sens w zrobieniu jednego rozwiązania, które wydaje mi się słuszne i łatwe, a następnie w pokazaniu go klientowi z pytaniem czy mu odpowiada, opowiadając jakie to jest proste i przyjemne dla użytkownika. Nie zawsze się tak da, ale często klient darzy nas wystarczającym zaufanie – w końcu jesteśmy fachowcami, więc korzystajmy z tego ?

To byłoby na tyle ode mnie. Nie umiem w zakończenia, więc poproszę Was tylko, abyście podzielili się w komentarzach tym, co Wam pomaga (poza kawą) zachować równowagę każdego dnia w środowisku IT ?