Praca w CodeTwo
Jak wygląda praca w dziale Developers w CodeTwo
Praca programisty może wyglądać różnie, ale jedno jest pewne – odbywa się przy komputerze. W CodeTwo nie jest inaczej, choć są pewne wyjątki. Ważne jest to, że każdy ma swoje biurko z komputerem i dwoma monitorami. Co prawda monitory mają tylko 14 cali, ale za to są kolorowe i mają kineskop. Po okresie próbnym dostaje się też myszkę i klawiaturę, a niektórzy dostają również taboret. Może ktoś myśleć, że to nic nadzwyczajnego, ale w porównaniu do dużych korporacji, gdzie na 105 osób przypada 100 biurek, to fajnie przyjść rano do swojego biurka i widzieć swój kubek z niedopitą kawą zamiast rozkładać swój super fancy tablet na jakiejś pufie.
Pewnie Was ciekawi, co robi programista w CodeTwo, skoro nie musi szukać biurka do pracy. Może w tym czasie napisać sporo linijek dobrego kodu, ale nie tylko. W CodeTwo piszemy swoje autorskie programy i sami wymyślamy, jak mają działać i wyglądać. Dzięki temu każdy z programistów ma duży wpływ na to, jak ostatecznie będzie wyglądał program. Praca w CodeTwo zatem nie ogranicza się tylko do implementacji, ale także do analizy i projektowania. Dodatkowo, możliwość implementacji własnych pomysłów daje dużo frajdy i wpływa pozytywnie na ogólną motywację.
Realizacja projektów odbywa się w metodyce ‘zwinnej’ Scrum z wykorzystaniem jej głównych praktyk, w tym gry w pokera, aby oszacować pracochłonności zadań. Raz gramy na pieniądze (z Eurobiznesu), innym razem na zapałki, a czasem na własne ubrania, ale najważniejsze jest to, że po takiej sesji kierownik projektu (czy ogolony z kasy, czy nie) wie, kiedy będziemy mogli wydać kolejną wersję produktu.
Jeśli chodzi o technologie w jakich pracujemy, to są to głównie rozwiązania Microsoft. Jest to wybór oczywisty skoro tworzymy oprogramowanie na platformy Exchange i Office 365 i jesteśmy Partnerem Microsoft. W związku z tym, że programiści lubią rzucać nazwami i akronimami, których nikt inny nie rozumie, to oto kilka z nich: C#, C++, ASP.NET, WCF, WPF, MVVM, JS, JQuery, Angular, MSSQL, ETL, WC, ZUS, PiS i Polsat.
Nasze produkty na pierwszy rzut oka nie wydają się być bardzo skomplikowane: dodają stopki, przekierowują maile, przerzucają elementy z jednego serwera na drugi. Pozory jednak mylą. Programy często nie mają dużej liczby funkcjonalności, ale algorytmy i rozwiązania, które wykorzystują, są bardzo złożone, a do tego muszą być optymalne, gdyż sporo zdań, które realizuje program musi się dziać w czasie rzeczywistym i wspierać scenariusze klientów ze wszystkich krajów świata. W związku z tym kładziemy bardzo duży nacisk na planowanie, optymalizację i zastosowanie najinteligentniejszych rozwiązań, niekiedy przecierając szlaki, którymi nikt nigdy nie szedł. Można powiedzieć, że jesteśmy ekspertami w technologiach związanych z Microsoft Exchange i Office 365. Zdarzyło się nawet, że do naszego głównego architekta, Jarka, dzwonili prosto z Microsoftu z Redmond, aby spytać o działanie jednego (z ich własnych) protokołów obsługi poczty.
Mimo, że kładziemy duży nacisk na jakość kodu i rozwiązań programistycznych, to przy tak złożonych algorytmach zdarzają się błędy. Łatwe błędy poprawiamy przez ponowną kompilację na Atari, trudne błędy poprawiamy od ręki, a na te nie-reprodukowalne trzeba chwilę zaczekać, aż architekt Jarek będzie miał chwilę i na czerwonym świetle napisze nam maila jak to poprawić. Dzięki automatycznym testom wszystkich funkcjonalności (tak, program sprawdza program) jesteśmy w stanie szybko wydawać nowe wersje i zabierać się za pracę nad kolejnymi. Dla każdego produktu lista życzeń na nowe funkcjonalności jest tak długa, że niektóre funkcjonalności muszą czekać na implementację dłużej niż czeka się na wizytę u ortopedy „na kasę chorych”.
W nocy programiści grają w GTA V lub w GTA San Andreas. Pytanie, które się zatem nasuwa, to jak wygląda dzień programisty skoro w nocy gra on w GTA?
Otóż do pracy można przyjść między godziną 8:00 a 10:00 – zależy, o której skończy się grać w GTA. Dzień programisty, który przyjdzie do pracy o 7:59, może wyglądać tak:
Zakres i podział prac dla każdej wersji każdego programu trzymamy w TFS. Dzięki temu kody źródłowe, User Stories, bugi i listy zapotrzebowań na nowe funkcjonalności mamy w jednym miejscu.
A tak wygląda przykładowy wycinek zadań zaplanowanych na wydanie kolejnej wersji jednego z naszych produktów:
