W ubiegłym roku na moim blogu w serwisie MyApple pisałem o pewnym moim noworocznym postanowieniu i jego następstwach. Chodziło oczywiście o naukę programowania w Swift i chęć zostania programistą. Tamten tekst był podsumowaniem swego rodzaju pierwszego etapu mojej deweloperskiej kariery - od powzięcia wspomnianego postanowienia i rozpoczęcia nauki po napisanie pierwszych aplikacji i znalezienie pierwszej pracy na tym stanowisku. Od tego czasu zdarzyło się jednak wiele i zebrałem też bardzo dużo doświadczeń, o które jestem stale pytany przez osoby nie tylko w moim wieku (po czterdziestce). Okazuje się bowiem, że takich osób jak ja jest więcej. Wielu zastanawia się, czy rozpocząć swoją przygodę z programowaniem.

Jak pisałem, po niemal dwóch latach samodzielnej nauki, przede wszystkim z książek autorstwa jednego chyba z najlepszych nauczycieli - Paula Hudsona, rozpocząłem pracę na stanowisku młodszego dewelopera w jednym z łódzkich software house'ów, w którym wcześniej przez dwa miesiące, w ramach stażu, po godzinach pisałem aplikację pogodową. Było to zadanie, które miało sprawdzić moją wiedzę i którego realizacja ostatecznie otworzyła mi drzwi do pracy w tym zawodzie.

Jak dostać się na taki staż? Trzeba przede wszystkim obserwować to, co dzieje się na różnych grupach na Facebooku poświęconych programowaniu, obserwować profile software house'ów w mediach społecznościowych i brać czynny udział w różnego rodzaju lokalnych spotkaniach poświęconych programowaniu na daną platformę lub w wybranym języku. To tam, przy pizzy i piwie, można nawiązywać znajomości i dowiadywać się o możliwościach podjęcia pracy czy sprawdzenia się choćby właśnie w ramach stażu. Niekiedy same firmy organizują staże, dlatego warto śledzić informacje pojawiające się w branży. Wiele z software house'ów tak naprawdę stale przyjmuje nowych pracowników, choć wiem, i to nie tylko z własnego doświadczenia, że dwa lata nauki to może być za mało. Znaleźć pracę na stanowisku juniora wcale nie jest łatwo. Firmy szukają bowiem doświadczonych, a przynajmniej średniozaawansowanych programistów. I nawet wtedy, kiedy w ogłoszeniu pada to słowo „junior”, często okazuje się, że ocena tego, co taki junior powinien potrafić, jest bardzo subiektywna. Nie wynika to bynajmniej ze złej woli prowadzących domy programistyczne, a raczej z tego, jak bardzo są one obłożone pracą. Tej jest tak dużo, że nie ma czasu na edukowanie świeżo upieczonego juniora.

Przekonałem się o tym sam, kiedy właściwie z początkiem pracy zostałem rzucony na głęboką wodę bez koła ratunkowego. Moje pierwsze osiem miesięcy na stanowisku junior dewelopera to jeden z najbardziej stresujących okresów. Szybko zdałem sobie sprawę, jak niewiele wiem, jak bardzo brakuje mi doświadczenia i pewnych nawyków. Te ostatnie musiałem w sobie szybko wyrobić (stałe wysyłanie na serwer zmian we wprowadzanym kodzie w ramach systemu kontroli wersji GIT). Przez te osiem miesięcy najczęściej odwiedzanym przeze mnie serwisem internetowym był Stack Overflow, czyli takie ogromne forum programistów piszących na różne platformy i w różnych językach. Można tam znaleźć odpowiedzi na niemal każde pytanie. Pamiętać jednak trzeba, że nie zawsze odpowiedzi te są najlepszymi rozwiązaniami, a czasem są przykładami wręcz złych nawyków programistycznych. Nie powinno się więc bazować tylko na tym, co można tam znaleźć. Z moich obserwacji wiem, że na Stack Overflow zaglądają jednak także doświadczeni programiści z kilkunastoletnim stażem. Także oni nie wiedzą wszystkiego i nie mają w głowie odpowiedzi (kodu) na każdy problem. Wydaje mi się jednak, że lepiej wiedzą, gdzie szukać, a zbieranie informacji zaczynają przede wszystkim od dokumentacji technicznej dostarczonej przez Apple. Dopiero w kolejnym etapie zaglądają na „Stacka”.

Zadania przede mną postawione nie były łatwe, ale - jak to bywa w tego typu firmach - nic więcej o nich nie mogę napisać, podpisałem wszak umowę o zachowaniu poufności. Wspomnę jedynie, że udało mi się je zrealizować, choć kiedy przypominam sobie kod stworzony przeze mnie rok temu, to wiem, że było się czego wstydzić. To także podobno typowe, że w miarę zdobywania doświadczenia deweloper zaczyna coraz bardziej krytycznie patrzeć na kod, który napisał jakiś czas wcześniej. Z drugiej strony ograniczenia związane z umową poufności w pewnym stopniu podcinają skrzydła. W software house'ach jest się bowiem mniej lub bardziej jedynie trybikiem większej maszyny i to do tego - będąc juniorem - trybikiem nie do końca jeszcze dobrze naoliwionym.

Dla mnie nowa praca była także wyzwaniem innego typu. Po niemal dziesięciu latach pracy w domu, gdzie sam sobie byłem kapitanem, sterem i okrętem, musiałem odnaleźć się w biurze. Z tym bywało różnie. Najgorzej chyba radziłem sobie z punktualnością, która przegrywała z zadaniami domowymi. Miałem też o wiele mniej czasu na naukę w dotychczasowym trybie, w którym poświęcałem od jednej do kilku godzin na studiowanie podręczników czy oglądanie samouczków wideo. Musiałem dostosować się do ogólnie przyjętych zasad działania biura i firmy oraz wyrobić sobie nawyki pracy z ludźmi. Nie uważam się za antyspołecznego dziwaka, ale okazało się, że przy pracy w domu nie zwraca się uwagi na wiele drobnych szczegółów, choćby takich jak natężenie dźwięku wydobywającego się ze słuchawek. Brakowało mi także pewnej wolności w organizacji czasu. Pracując w domu, czasem mierzę się z blokadami, brakiem kreatywności, niemożnością rozwiązania napotkanych problemów. Wtedy zwykle wychodzę do lasu na godzinę lub dwie, gdzie podczas marszu staram się zresetować, co w efekcie pozwala mi znaleźć rozwiązanie. Gdy pracuje się w biurze, to raczej nie jest możliwe.

Ostatecznie więc okazało się, że w mojej pierwszej pracy byłem swego rodzaju nieudanym eksperymentem i po ośmiu miesiącach musieliśmy się rozstać. To było pouczające osiem miesięcy.

Oczywistym krokiem było rozesłanie wici w serwisach społecznościowych i wśród znajomych o tym, że junior deweloper z ośmiomiesięcznym doświadczeniem szuka pracy. To właśnie tutaj przekonałem się, jak ważne są kontakty branżowe, znajomości zawarte często wiele lat temu, kiedy jeszcze w ogóle nie myślałem o tym, by zostać programistą.

To bowiem w styczniu 2011 roku, w San Francisco, na dzień przed otwarciem targów i konferencji Macworld, na jednej z towarzyszących imprez poznałem Jacoba Gorbana z Apparent Software. Niewielkiego, ale prężnego studia programistycznego, wydającego swoje autorskie aplikacje dla Maca. Część z czytelników na pewno kojarzy ImageFramer, Cashculator i Trickster. Od tego czasu utrzymywaliśmy ze sobą kontakt w mediach społecznościowych, a czasem rozmawialiśmy również za pośrednictwem Skype'a. Dzieliliśmy bowiem także wspólną pasję do rocka progresywnego i gitar. Okazało się, że w czasie, kiedy ja rozpocząłem poszukiwania kolejnej pracy w mojej karierze dewelopera, Jacob rozpoczął poszukiwania juniora, który pomógłby mu w opracowaniu aplikacji na platformę iOS - dotąd Apparent Software miało bowiem w swojej kolekcji tylko programy dla Maca - i którego mógłby także uczyć. I w ten sposób kolejnej pracy programisty szukałem dwa dni.

Wróciłem także do środowiska pracy, w którym czuję się najbardziej komfortowo - do biurka we własnym mieszkaniu. Znowu mogłem wykorzystać mój czas najbardziej efektywnie, nie marnując go np. na bezmyślne ślęczenie nad komputerem wtedy, kiedy zatrzymałem się nad problemem wydawać by się mogło niemożliwym do rozwiązania. Co więcej, w każdej chwili mogłem teraz pytać się mojego bardziej doświadczonego kolegi o radę i po prostu czegoś nie umieć, nie znać się. Dzięki czemu praca stała się mniej stresująca i znowu była wyzwaniem, które stawiałem sobie sam. W przeciwieństwie też do pracy w domu programistycznym, w którym po prostu realizuje się zlecenia klientów w sposób mocno anonimowy, mogę pokazywać efekty naszej wspólnej pracy.

Różnica pomiędzy pracą w firmie realizującej zlecenia klientów, a tej niewielkiej, tworzącej własne, autorskie aplikacje, to jak różnica pomiędzy pracą w orkiestrze, w której jest się po prostu anonimowym muzykiem, zmuszonym grać narzucony z góry repertuar, a graniem w zespole rockowym złożonym z przyjaciół, gdzie dzieła są wypadkową umiejętności i pomysłów wszystkich członków, którzy czerpią dużą przyjemność ze wspólnego tworzenia.

W Apparent Software tworzę od podstaw aplikację Socialite: naklejki i ramki, pozwalającą na dodawanie do zdjęć naklejek i ramek tworzonych przez naszego grafika Bradena oraz tekstu w jednym z wybranych krojów. Upiększone w ten sposób obrazki można następnie zapisać lub wysłać do innych programów czy serwisów społecznościowych. Program posiada też rozszerzenie dla iMessage, pozwalające na wysyłanie naklejek. Wszystko wydaje się proste, ale wyzwań stojących przed juniorem było i jest tutaj sporo. Począwszy od odpowiedniego skalowania obrazów, naklejek, ramek czy tekstu do pełnej rozdzielczości zdjęcia przy jego eksporcie, poprzez zastosowanie niestandardowych sposobów skalowania, obracania i przesuwania samych naklejek (standardowymi są gesty obsługiwane przez odpowiednie klasy dostępne w bibliotece UIKit), odpowiednie przekształcenia geometryczne (musiałem przypomnieć sobie zagadnienia, z którymi ostatni raz miałem do czynienia w liceum), obsługę zakupów wewnątrz aplikacji, zapisywanie i przenoszenie obrazków naklejek i ramek w ramach pakietu, jakim jest aplikacja dla iOS, po tworzenie rozszerzenia dla iMessage i własnej biblioteki.

Cały czas się uczę i cały czas staram się wykorzystywać właśnie zdobytą wiedzę do ulepszania tej aplikacji, przebudowy struktury jej kodu, by był prostszy, a co za tym idzie bardziej czytelny.

Oczywiście wciąż wiele przede mną, pracuję też nad innymi aplikacjami, m.in. ulepszeniem Negative, mojego czytnika PDF z trybem nocnym, czy klientem sieci społecznościowej Mastodon. Cały czas też uczę dzieci programowania. W tym roku były to już dwie klasy - pierwsza i czwarta. Uczniowie stawiają przede mną nowe wyzwania (chcą, bym w przyszłym roku szkolnym uczył ich podstaw programowania na platformę Android), ale to już temat na drugą część cyklu „od blogera do nauczyciela”.

Artykuł ukazał się pierwotnie w MyApple Magazynie nr 3/2019

Pobierz MyApple Magazyn nr 3/2019