Jak wygląda praca w dziale Developers

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ę. Zobacz, jak wygląda przykładowy dzień pracy programisty w CodeTwo:

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:

8:00 – odpala swój komputer i zabiera kubek z niedopitą kawą, aby zrobić świeżą. Jako, że komputery programistów są bardzo szybie (mają procesor 300 MHz), więc jak wraca 8:03, ze świeżą kawą, to maszyna jest prawie gotowa do działania.

8:03 – idzie na Standup. Standup to czas, w którym programiści opowiadają o postępach w swoich zadaniach i wspólnie rozwiązują napotkane problemy. Zatem każdy opowiada o tym, co niesamowitego zrobił wczoraj, co nadzwyczajnego chce zrobić dzisiaj i czy napotkał przy tym jakieś problemy.

8:03 -11:00 – jest to okres, w którym oprócz realizacji swoich zadań, może omawiać rozwiązania i napotkane problemy. Od godziny 11:00 następuje tzw. ‘cisza programistyczna’, podczas której skupia się wyłącznie na swoich zadaniach i jeśli ktoś mu przeszkodzi, to może zostać wtrącony do firmowego lochu na czas nieokreślony. W lochu nie ma Wi-Fi.

11:00 – 13:00 – projektuje i implementuje zadania, czyli ”nadusza”.

13:00 – 13:15 – je obiad (jeśli zamówił i nie zapomniał przyjść do jadalni).

13:18 – 16:00 – ”nadusza” do spodu. Choć zdarzają się sytuację, że koledzy z 2nd Level Support proszą o pomoc przy sesji naprawczej u klienta np. z Wielkiej Brytanii (ostatnio był Premier League), ponieważ klient ma tak specyficzne środowisko, że nasz program nie chce działać w domyślnej konfiguracji.

16:00-17:00 – je pizzę i chipsy.

17:00 – 08:00 – gra w GTA.

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:

Zrzut ekranu zadań w TFS dotyczących jednego z produktów CodeTwo.