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ę.

Praca - developers - Photo 1

Praca - developers - Photo 2

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 szybkie (mają procesor 300 MHz), więc jak wraca o 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ę sytuacje, ż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.

 

Praca - developers - Photo 3

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:

Praca - developers - Screen 3