czwartek, 25 grudnia 2014

Świeżak w korpo - czyli różnice między tym co na studiach, a w pracy

Pierwsze kroki...


Od pół roku pracuję w pewnej firmie, którą chyba można nazwać korporacją. W dziale, w którym jestem zajmujemy się głównie rozwijaniem, dostosowywaniem i sprzedażą sporej aplikacji dla różnych, znanych marek takich jak Airbus, Volkswagen, Audi, Renault, Adidas, Simens, Apple itp. itd.
Jest to moja pierwsza praca na etat. Wcześniej wprawdzie miałem jakieś praktyki, ale odbywałem je w małej ok. ośmio-osobowej firmie, gdzie połowicznie robiłem strony webowe, a połowicznie grafikę, więc to się nie liczy :P
Powoli dochodząc do tematu, który zamierzałem zawrzeć w tym poście, chciałbym przedstawić Wam moje subiektywne porównanie, tego z czym mamy do czynienia na studiach, a tym z czym trzeba się mierzyć podczas rozwijania oprogramowania w pracy. Oczywiście, tak jak sugeruje temat wpisu, jestem jeszcze absolutnym nowicjuszem w kwestii pracy programisty w większej firmie, ale mimo to, przez te pół roku parę rzeczy od razu rzuciło mi się w oczy.

"Jak będziesz po riwiu, to zobacz czy się bilduje, zmerdżuj zmiany z repo i zaczekinuj" - czyli programistyczno-korporacyjny slang.



Być może nie ma to za dużego związku z samym kodowaniem, ale specyficzny, 'zangielszczony' język używany w pracy na pewno jest jednym z pierwszych i ciekawszych zjawisk, które odnotowałem. Zabawne jest to, że zawsze trochę denerwowali mnie ludzie, których zdania np. po miesiącu pobytu w UK czy USA zawierają połowę angielskich lub 'zangielszczonych' słów. Tymczasem, teraz, podczas rozmów z kolegami z firmy, leci taki programistyczny ponglish, że dla przeciętnego słuchacza, nie związanego z branżą, równie dobrze moglibyśmy używać języka simów.
Wydaje mi się, że przyczyną tych leksykalnych nawyków jest to, że składnia języków programowania jest po angielsku, dokumentację pisze się po angielsku, wszystkie programy jakich używamy w pracy są po angielsku, materiały do nauki po angielsku, angielski po angielsku itd.
Do tego na niektórych projektach (ja na taki trafiłem) są codzienne meetingi z 'zagranicą', podpowiem, nie po polsku :). Dzięki temu, cały czas ten język jakoś rozwijam, choć czasem nie jest łatwo. Kiedy przychodzi porozmawiać z Amerykaninem... indyjskiego czy chińskiego pochodzenia, ich oryginalny akcent czasem jest po prostu zbyt egzotyczny by cokolwiek zrozumieć :P.
Czy w takim razie, aby pracować w IT trzeba władać płynnym angielskim? To zależy oczywiście od wymagań pracodawcy, ale jeżeli umiecie przeczytać dokumentację i jakoś sensownie się skomunikować to zazwyczaj może on być nieco kwadratowy i drewniany.

Zasady dobrego programowania


Na studiach różnie z tym bywa. Wiele zależy po prostu od prowadzącego. Niektórzy z nich zwracają uwagę na czystość kodu, starają się przybliżyć studentom zasady SOLID, GRASP itp. inni natomiast tylko coś o tym wspomną. Generalnie jednak, da się bez problemu pozaliczać różne laborki z programowania pisząc kod, który przyprawia o ból głowy, oczopląs, śmiech przez łzy i odruch wymiotny w jednym.
W poważnej firmie coś takiego nie przejdzie przez review. Kod musi być czytelny. Klasy i metody powinny być krótkie, a ich nazwy i nazwy zmiennych, stałych i wszystkiego innego powinny być adekwatne do funkcjonalności, tudzież zawartości. No i oczywiście powinny być po angielsku.
Jeżeli piszemy program na studia, który składa się powiedzmy z dziecięciu klas, to łatwo nam się w nim połapać. Aplikacja, z którą mam do czynienia w pracy liczy sobie kilkadziesiąt tysięcy klas (!). Jest rozwijana od kilkudziesięciu lat, przez setki osób i korzysta z wielu przeplatających się technologii. Do tego dochodzi jeszcze mnóstwo propertiesów, plików konfiguracyjnych czy baza danych. Projekt jest na tyle duży i rozwijany przez tylu różnych ludzi z kilku stron świata, że niestety nie mógł ustrzec się od błędów. Przemierząjąc więc jego zakamarki, czasem zdarza mi się trafić na kod, który wygląda jakby był napisany przez kodera - sadystę lub osobę, której gdyby pokazać wspomniane zasady dobrego programowania, przyglądałaby się im jak egzotycznym zwierzakom z Animal Planet. Zdarzało mi się kląć na brak dokumentacji, która czasem naprawdę staje wybawieniem, byłem wkurzony przez nic nie mówiące nazwy zmiennych i metod typu "a_object", "b_object", czy (hicior) "maybeCompile()". Rozbawiały mnie również nazwy niemieckie i martwiły umlauty, które w nich występowały. Co jakiś czas odczuwam więc na własnej skórze, co znaczy brudny kod i tym bardziej motywuje mnie, aby nie stać się autorem podobnego.
Dlatego, nawet jeśli piszecie małe projekty na studia, czy dla samych siebie w domowym zaciszu, piszcie prosto i elegancko, zgodnie z zasadami SOLID i czystego kodu, żeby wyrobić sobie dobre nawyki :)

Superman !


Kolejną ciekawą rzeczą, którą zaobserwowałem w firmie jest rzucanie nowicjusza od razu na głęboką wodę. Często, od razu po 1-3 miesięcznym szkoleniu trafiasz na poważny projekt, dla wielkiej korporacji i to nie jako jakiś pomagier kogoś tam, tylko pełnoprawny programista, traktowany na równi z innymi. Dołączasz do pracującego już teamu, albo czasem sam prowadzisz projekt. W związku z tym, dla klienta jesteś ekspertem, od którego można wymagać tyle samo, co od innych pracowników. Bierzesz udział w meetingach, czasem trzeba jechać w delegację, za granicę i popracować na miejscu u klienta. Ogólnie wszystkie ewentualne braki trzeba uzupełniać w tak zwanym międzyczasie. Nikt nie przyjdzie i nie powie "Ojej nie umiesz tej technologii, no dobrze, to tu masz książkę, tu tutoriale i postaraj się to ogarnąć w parę dni." Sytuacja wygląda raczej tak (na własnym przykładzie):
Ktoś: No, dobrze, a miałeś kiedyś do czynienia z GWT? Bo na naszym projekcie dosyć gęsto jest używany.
Ja: Nie, niestety nie znam.
Ktoś: ... Ok, nie szkodzi. Nauczysz się, my na początku też nie znaliśmy.
Nie wiem czy tak to wygląda w każdej firmie z IT, ale ma bardzo pozytywny wpływ na ilość i szybkość przyswajanej przeze mnie wiedzy, oraz podnosi samoocenę. Miło widzieć jak koledzy i koleżanki z pracy wierzą w moje umiejętności. Starając się ich i siebie nie zawieść, poprzez praktykę i czytanie różnych turoriali, douczam się "w biegu" nowych technologii i rozwiązań i muszę powiedzieć, że jestem zadowolony z efektów. Jeszcze ze 2 lata temu jakby mnie ktoś zapytał: "...a mógłbyś do tej apki javovej dać połączenie z bazą w MySQL i dorobić na szybko jakiś webowy interfejs np. w ExtJS?" To bym pomyślał: Jak się robi połączenie z bazą danych? ...W ogóle jak to było z tymi zapytaniami? ExtJS??? Pierwsze słyszę, niby jak mam to połączyć... nope nope nope. Teraz, byłoby to raczej: Nowa technologia? Dawać ją! Zaraz to ogarnę :) Spostrzeżenie: wrzucenie w wir wyzwań często może skutkować dynamicznym rozwojem umiejętności i poszerzaniem horyzontów.
Oczywiście wiara współpracowników, że sobie poradzę w nieznanym obszarze wiąże się też z dużą odpowiedzialnością. Na studiach, zawsze są jakieś dodatkowe terminy, coś można ugadać, albo zaliczyć na tróję. W pracy, nie można wykonać pracy na tróję, albo olać terminu, więc jeśli okazuje się, że wymagania były zbyt duże, trzeba to jak najszybciej zgłosić i poprosić o pomoc, a nie zgrywać bohatera.
Reasumując uważam, że nie ma się co bać nieznanych technologii. Jeżeli planujecie jakiś projekt, po prostu wybierzcie najlepsze rozwiązania, nie zważając na to czy znacie jakiś język, czy technologię. Jeżeli wiecie, że sprawdza się w jakimś obszarze i chcielibyście jej użyć ale jej nie znacie... Po prostu zacznijcie jej używać, a nauczycie się dużo więcej niż korzystając tylko z tego co już umiecie :)

'Expienie' :)


Nie wypisałem wszystkich ciekawych aspektów życia firmowego, z którymi mam do czynienia, ponieważ przypuszczam, że wiele z nich jest charakterystycznych tylko dla tej konkretnej korporacji, w której pracuję. Raczej wybrałem te, bardziej uniwersalne, które (jak mi się wydaje) mają szansę się powtarzać w wielu innych przedsiębiorstwach.
Jeszcze jedna uwaga na koniec: Ten wpis może, zostać przez niektórych odebrany jako admiracja pracy w korporacjach, ale tak nie jest. Po prostu myślę, że warto spróbować pracy w takim miejscu, chociażby ze względu na zbieranie nowych, ciekawych doświadczeń. Później z bagażem zdobytego 'expa' można śmiało ruszać dalej :)

3 komentarze:

  1. jeszcze bardziej przesra... jeszcze ciężej jest jak się trafi do firmy w której 90% rozwiązań jest oparta o jakieś wewnętrzne technologię, i wychodzi że wcześniej korzystałeś tylko z ... javy :D

    OdpowiedzUsuń
  2. Jeśli w korporacji pracują inni młodzi ludzie to studentowi jest łatwo znaleźć nic porozumienia.

    OdpowiedzUsuń
  3. "głównie rozwijaniem, dostosowywaniem i sprzedażą"
    Ciekawy zestaw, szczególnie sprzedaż mi tu nie pasuje, chyba że jest to sprzedaż idei wewnątrz zespołu programistów Java, ale chyba nie.
    Poza tym fajny wpis. Co do korpo, jak to w korporacjach zawsze człowiek się czegoś uczy, choć zawsze na początku jest to nowomowa...

    OdpowiedzUsuń