Pierwszy dzień w pracy developera

Tworzenie własnych projektów z myślą o pracy, wbrew temu co się mówi, tylko w niewielkim stopniu przygotowuje nas do przyszłego stanowiska. Tworząc stronę, znamy każdy plik, a projekt zwykle nie rozrasta się bardziej, niż do kilku podstron, arkusza stylów i podfolderów na zdjęcia, pliki JS i pliki wektorowe.

Twój pierwszy dzień w pracy, zmieni Twoje podejście do deweloperki o 180 stopni. W przypadku mojej znajomej, Ani, wyglądało to tak:

Pierwszym zadaniem, było skonfigurowanie sobie komputera, począwszy od "znalezienia" jakiejś klawiatury i myszki, zainstalowanie systemu i zainstalowanie IDE. Okazało się, że Ania będzie pracowała na PHPStormie, którego nie widziała nigdy wcześniej. Błąd - mogła zapytać o edytor tekstu stosowany w firmie w czasie rozmowy kwalifikacyjnej lub nawet po uzyskaniu prawidłowej odpowiedzi. Nic to, że była power userem Sublime Text.

Po drugie - w jej firmie w części projektów używano SVN zamiast Gita, a wszyscy pracownicy, korzystali z systemu kontroli wersji w PHPStormie, a nie w konsoli. Inne rzeczy, takie, jak kompilacja Sass czy Less, także były robione przez IDE.

Dzień zaczął się od daily scrum, na którym poznała kilkunastoosoobowy zespół. Zapamiętała podczas niego tylko imię full stacka, od którego miała otrzymywać zadania i w razie trudności, prosić go o pomoc.

Pierwszym zadaniem Ani w pracy, było zrobienie animacji pasku postępu. Tutaj przerażenie, bo nie robiła nigdy ani animacji, a przez dłuższy czas, nie mogła zrozumieć, jak działa projekt. Wordpress był ściągany z Gita i następnie trafiał na dysk sieciowy, który służył za podręczny serwer. Trochę różniło się to w stosunku do pracy w XAMPP. Na szczęście, od frontend developera na początku nie wymaga się znajomości takich konfiguracji i kolega siedzący obok, pomógł ściągnąć i odpalić projekt. Konfiguracją Sass zajęła się sama.

Gdy Ania już dopytała, jak znaleźć potrzebny plik i mogła go stylować w CSS, pojawił się kolejny problem - komputer, mimo tego, że potężny, dawał bardzo duże opóźnienie od zapisania do zobaczenia efektów w przeglądarce. Sprawdzenie czasu kompilacji przez Compass watch --time pokazało, że plik najpierw jest automatycznie wysyłany na serwer, a dopiero po 2 sekundach się kompiluje. Nie było to zbyt dziwne, ponieważ gotowy CSS liczył ponad 15 000 wierszy kodu. Nie mniej, kosztowało to trochę nerwów i pytań w stylu "dlaczego to nie działa". Czasem trudno też było się jej połapać, który fragment kodu HTML jest generowany przez PHP, a który można zmienić w szablonie. Bardzo przydało się tutaj wyszukiwanie stringów w całym projekcie.

Problemem był też rozwój szablonu na WP, ponieważ część plików Ania musiała edytować w CSS, a część w Visual Composer. Nie miała też pewności, czy te zmiany są widziane przez innych pracowników, którzy pracowali przy tym samym szablonie. Na szczęście znała Gita i zatwierdzanie zmian nie stanowiło problemu. Zaskoczyła nawet kolegów z pracy tym, że korzysta z konsoli.

Pierwszego dnia w pracy okazało się także, że liczą się umiejętności komunikacji. Ania dostała na przykład zadanie, które wymagało dodania do menu WP custom data-attributes. Musiała to przeanalizować, porozmawiać o tym z backendowcem i dokładnie wyjaśnić mu, o jaki efekt chodzi.

Co więcej, duża część zadań polegała na wdrażaniu gotowych rozwiązań, takich, jak slidery w JS.

Podsumowując - praca w zespole, w niczym nie przypomina spokojnego rozwijania swoich projektów. Największą różnicą, jest skala i skomplikowanie projektu - te czynniki sprawiają, że przez pierwsze dni, musimy się wdrażać i tracimy sporo czasu na szukanie różnych rzeczy. W komentarzu opisz, jaki był Twój pierwszy dzień w pracy dewa.