Odcinek możesz przesłuchać w swojej ulubionej aplikacji do podcastów:

• Google Podcasts
• Spotify
• Anchor

---

Cześć! Dzisiaj mam dla Ciebie kolejny odcinek podcastu z serii dotyczącej poszukiwania wymarzonej pracy w świecie IT.

Dopiero ostatnio opublikowałem tu na blogu wpisy z nagraniami dwóch pierwszych odcinków, gdzie opowiadałem o tym, od czego zacząć poszukiwania wymarzonej pracy w IT oraz gdzie szukać dobrych ofert dla programistów. Jeśli nie znasz jeszcze treści tych odcinków to gorąco Cię zachęcam do ich przesłuchania 😉

Ich jakość nie jest najlepsza (w aktualnym, trzecim odcinku jest dużo lepiej!), ale mimo tego wiedza tam zawarta może Ci się bardzo przydać w trakcie kolejnej rekrutacji.

W tym odcinku przedstawiam różne rodzaje firm, w jakich można pracować jako programista. Bazując na moich własnych doświadczeniach i moich znajomych pokazuję, czym charakteryzuje się praca w każdej z nich.

Odcinka możesz przesłuchać na tej stronie, za pomocą zagnieżdżonego odtwarzacza Anchor powyżej, albo na Spotify. Pracuję nad tym, żeby podcast był dostępny również na pozostałych platformach, takich jak Google czy Apple Podcasts, także „stay tuned”.

Poniżej znajdziesz również treść odcinka w podstaci blogposta, jeśli wolisz raczej czytać niż słuchać.

Życzę miłego słuchania (lub czytania) 😀🎙

Treść odcinka

Dzisiaj chciałbym opowiedzieć o tym, jakiego rodzaju firmy są w ogóle dostępne na rynku pracy dla programistów. Czyli innymi słowy, w jakiego typu firmach można pracować jako programista i czym się one różnią między sobą.

O tym się tak często nie mówi wprost, a może ja po prostu wchodząc do branży nie miałem takiej wiedzy. W każdym razie ja sam kilka lat temu, na początku mojej zawodowej drogi, bardzo chętnie bym się z takim zestawieniem zapoznał.

Bo kiedy szukałem pierwszej pracy to chciałem, żeby wzięli mnie po prostu „gdziekolwiek”, gdzie byłaby niezła atmosfera i dobra kasa. Natomiast w ogóle nie zastanawiałem się nad tym, jakiego rodzaju działalność będzie prowadziła moja firma i jak wpłynie to na projekty, w których będę uczestniczył, a co za tym idzie – jak wpłynie to na mój rozwój zawodowy.

Dlatego za chwilę postaram się to wszystko podsumować i usystematyzować tak, żeby dla Ciebie ten temat był chociaż odrobinę jaśniejszy.

Na ten moment dla mnie podział firm zatrudniających programistów wygląda z grubsza tak:

• Dojrzała firma produktowa
• Start-up
• Korporacja
• Software house
  • Projekty długofalowe
  • Projekty krótkotrwałe
• Outsourcing

Oczywiście można by ten podział jeszcze bardziej dzielić, ale myślę, że są to takie główne rodzaje firm dla programistów.

Są też pewnego rodzaju hybrydy, np. software house, który tworzy również jakiś swój produkt, albo firma produktowa, gdzie można pracować tylko przy wewnętrznych systemach. Wtedy charakter naszej pracy i rozwoju będzie najczęściej zależał od tego, jaki charakter pracy ma zespół czy cały dział, którego jesteśmy członkiem.

Omówię teraz każdą z nich pokrótce i powiem czym się między sobą różnią i jak to wpływa na to, jakiego rodzaju pracowników potrzebują oraz czym programiści się tam zajmują i jak wygląda ich rozwój.

Dojrzała firma produktowa

Firma produktowa to taka, która posiada jakiś swój produkt. Może go sprzedawać, albo udostępniać za darmo i czerpać zyski na przykład z reklam. Przykładami są tutaj tacy giganci jak Facebook, Google czy nasze rodzime Allegro.

Wyróżniłem słowo „dojrzała” firma, dlatego że start-up, o którym powiem za chwilę, też jest firmą produktową, ale na dużo wcześniejszym etapie rozwoju i praca tam wygląda zupełnie inaczej.

W dużej firmie produktowej jako programiści najczęściej współtworzymy jakiś kawałek tego tytułowego produktu. Jeśli jest to usługa online to mamy dostęp do logów, możemy monitorować zachowanie użytkowników a tym samym widzimy, w jaki sposób kod, który tworzymy, wpływa na użytkowników końcowych.

To bardzo satysfakcjonujące, kiedy nasza praca jest wykorzystywana przez tysiące czy miliony osób. Ale jednocześnie wiąże się z tym spora odpowiedzialność. W nowoczesnych podejściach każdy zespół jest odpowiedzialny za swój kod na produkcji. Czyli może być tak, że coś przestanie działać i będziemy musieli interweniować, czasem nawet w środku nocy. Jest to jednocześnie zachęta dla zespołów, żeby już od najwcześniejszych etapów tworzenia oprogramowania dbali o jakość i o testowanie – dzięki temu takich sytuacji będzie jak najmniej.

To co jest jeszcze bardzo ciekawe w firmie produktowej to fakt, że często dosyć wprost można policzyć, jakie przełożenie na przychody firmy miała nasza zmiana. Jeśli np. zoptymalizowaliśmy czas ładowania stron o 0.5s i w kolejnym miesiącu sprzedaż w naszym systemie wzrosła o 10%, to bardzo prawdopodobne, że to właśnie wzrost wydajności miał na to wpływ.

W takiej dojrzałej firmie najczęściej jest wiele zespołów programistycznych, z których każdy odpowiada za jakiś wycinek produktu, albo np. za jeden mikroserwis. To powoduje, że zespoły zaczynają się dość mocno specjalizować. Nie ma wobec tego takich sytuacji, że jakiś programista dotyka praktycznie każdego obszaru aplikacji. Dodatkowo, ugruntowana pozycja firmy na rynku nie wymaga bardzo szybkich zmian w produkcie, a ważniejsze jest raczej bezpieczeństwo i stabilność działania. Dlatego w takiej dojrzałej produktowej firmie często mocno stawia się na jakość kodu, testowanie, przemyślaną architekturę, stabilność wdrożeń i bezpieczeństwo.

W związku z powyższym takie firmy szukają zazwyczaj doświadczonych programistów, midów oraz seniorów, którzy dobrze odnajdą się w takim skomplikowanym środowisku pracy. Co za tym idzie, pensje są zazwyczaj bardzo dobre, a bonusy mogą być uzależnione od tego, jak praca konkretnego zespołu przyczyniła się do wyników finansowych firmy.

Start up

Przejdźmy teraz do „niedojrzałej” firmy produktowej, jak można by nazwać start up. Start up, czyli firmę oferującą jakiś produkt, działającą w warunkach dużego ryzyka i niepewności i dążącą do szybkiego wzrostu.

Start upy dopiero szukają swojego miejsca na rynku, nie mają ugruntowanej pozycji i często mogą zmieniać swój model biznesowy (czyli robić tzw. pivot). Jasne więc jest, że charakter pracy programisty będzie tutaj zupełnie inny.

Przede wszystkim start up ma najczęściej dużo mniej pracowników niż dojrzała firma, a co za tym idzie jest również mniej programistów. Zazwyczaj nie specjalizują się oni aż tak bardzo jak Ci w dojrzałej firmie produktowej, tylko są raczej „generalistami”. Czyli programista w startupie może jednego dnia robić backend i bazę danych, drugiego frontend webowy a trzeciego aplikację mobilną. A czwartego będzie pomagał w sprzedaży i marketingu.

Jasne jest, że żadnej z tych rzeczy nie będzie robił tak dobrze, jak specjalista od jednej z tych dziedzin. Ale w startupie nie ma znaczenia, że coś nie będzie zrobione perfekcyjnie. Ma być zrobione „jakoś”, pomóc firmie jechać do przodu, a po ugruntowaniu swojej pozycji, zdobyciu klientów i inwestorów przyjdzie czas na usprawnianie i dopieszczanie jakości. Przynajmniej w teorii.

Dlatego w startupie nie jest aż tak ważne tworzenie jakościowych rozwiązań, a raczej sprawne i szybkie robienie czegoś, co działa „well enough”. Potrzeba tu takiego trochę „hackerskiego” nastawienia. Osoby, które lubią sobie długo dłubać w kodziku i go dopieszczać, raczej się nie sprawdzą w takim środowisku.

Start upy we wczesnej fazie nie mają dużo pieniędzy. Liczą na to, że szybko urosną, zajmą odpowiednią pozycję na rynku, wykoszą konkurencję dzięki swoim innowacyjnym rozwiązaniom a wtedy poleci do nich niewspółmiernie duży strumień pieniędzy. Dlatego regularne, comiesięczne wynagrodzenie w startupie może być dla programisty poniżej rynkowej średniej. Ale ponad to najczęściej dostajemy wtedy opcje na akcje firmy, czy coś w tym stylu… nie jestem najlepszy w te klocki. W każdym razie w przyszłości, jeśli firma odniesie sukces, to mamy szansę na bardzo dużo forsy. Natomiast póki co być może będzie trzeba żreć gruz.

Podsumowując, tworzymy produkt i mamy wpływ na życie użytkowników podobny jak w dojrzałej firmie produktowej, ale w mniejszej firmie o niepewnej pozycji rynkowej. Jesteśmy raczej generalistami niż specjalistami w jednej działce technologii, pensję mamy poniżej rynkowej ale robimy bardzo ciekawe rzeczy i w przyszłości mamy teoretyczną szansę stać się milionerami.

Korporacja

Idąc dalej trafiamy na korporacje. Mam tu na myśli wszelkiego rodzaju firmy, takie jak banki, ubezpieczalnie, firmy energetyczne itp., których produkty czy usługi nie są ściśle związane z jakimś oprogramowaniem. Oczywiście, w dzisiejszych czasach każdy bank czy ubezpieczalnia ma swój portal online, ale „core” ich działalności leży gdzie indziej. Poza tym firmy takie mają bardzo dużo wewnętrznych systemów, które „spinają” różne aspekty ich działalności i często są tworzone i utrzymywane przez wewnętrzne zespoły.

Taki rodzaj pracy programistycznej mam tu na myśli – siedzimy wewnątrz dużej organizacji i tworzymy lub utrzymujemy jeden z systemów, który pomaga tej firmie sprawnie funkcjonować.

Tutaj często nie mamy takiego wpływu na użytkowników końcowych jak w przypadku dwóch pierwszych rodzajów działalności. Nasza praca często pozostaje w cieniu i jej beneficjentami są np. wewnętrzni pracownicy firmy, czyli kilkadziesiąt, kilkaset, max. kilka tysięcy osób. O milionach tu nie ma mowy.

Dodatkowo takie korporacje posiadają systemy, które dobrze pamiętają jeszcze czasy poprzedniego ustroju. I nawet jeśli nie dłubiemy przy nich bezpośrednio, to często musimy się z nimi integrować, co kończy się koniecznością odreagowania w weekend.

Tutaj nasza specjalizacja może być jeszcze głębsza niż w firmie produktowej i nasza wiedza może być nieprzenaszalna do innych firm, bo opiera się np. na znajomości konkretnego systemu i umiejętności integracji z nim.

Fakt, że jesteśmy w korporacji, powoduje też nierzadko masę papierologii i biurokracji oraz formalizmów. Załatwienie pozwolenia na skorzystanie z nowego narzędzia programistycznego w naszym zespole może trwać tygodniami i przejść przez wszystkie szczeble managerów. Po czym zostanie odrzucone.

Praca w takich warunkach i obcowanie z przestarzałymi technologiami jest często rekompensowana ponadprzeciętnymi stawkami. Powszechnie wiadomo, że fucha programisty w banku jest jedną z najlepiej płatnych na rynku.

Z tego co słyszałem, to w takich miejscach dosyć łatwo można się „okopać” i robić niewiele, a hajs się wciąż zgadza. Ciekawe jak wtedy z rozwojem zawodowym i co w przypadku, gdy kiedyś będziemy już zmuszeni zmienić pracę. Moja odpowiedź brzmi: nie wiem, choć się domyślam.

Osobiście miałem tylko kilkumiesięczną przygodę z tego rodzaju firmą i powiedziałem sobie, że nigdy więcej. Ale co kto lubi. Może po prostu miałem dużego pecha i w innych miejscach jest lepiej.

Software house

I tak dochodzimy do przedostatniego punktu, którym są software house’y. Czyli firmy, które mają w swoich szeregach programistów i szukają firm-klientów, które mają potrzebę stworzenia jakiegoś oprogramowania.

Ci klienci z różnych powodów nie mogą albo nie chcą mieć swoich programistów i dlatego zlecają tworzenie software’u zewnętrznej firmie.

Taki software house najczęściej specjalizuje się w jakichś konkretnych technologiach, np. w Javie albo w Pythonie, w konkretnych obszarach typu web czy mobile, a czasem nawet w konkretnych segmentach rynku, np. oprogramowanie dla instytucji finansowych.

Charakter pracy programisty w takiej firmie mocno zależy od tego, czy mamy do czynienia z klientami krótko- czy długofalowymi. Pracowałem w obu typach software house’ów dlatego mogę powiedzieć, jakie są różnice.

Krótkofalowe projekty

Jeśli mamy krótkofalowych klientów to z punktu widzenia programisty oznacza to, że często zmieniają się klienci i projekty, w których pracujemy. A w związku z tym mogą również zmieniać się technologie. Klientami są często omawiane wcześniej start upy, które chciałyby zacząć już budować projekt, ale np. nie mają jeszcze skompletowanego zespołu albo chcą wyoutsource’ować część pracy, np. stworzenie aplikacji mobilnej.

Mogą to być też duże firmy, które potrzebują pomocy w jakimś specyficznym obszarze, w którym nie mają kompetencji po swojej stronie a nie chcą ich u siebie budować, bo projekt trwa jakiś określony czas i nie mieliby co potem z tymi ludźmi zrobić. Może być też tak, że firma nie nadąża z rekrutacją a potrzeby projektowe są „na już”, wtedy od ręki ma np. 10 osób z software house’u i praca może iść do przodu.

Tego typu praca jest dobra dla osób, które nie lubią zbyt długo zajmować się jedną rzeczą. Tutaj projekty mogą trwać od miesiąca do roku, półtora maksymalnie. Z mojego osobistego doświadczenia taka średnia to było około 4-5 miesięcy. Z każdym projektem zmienia się trochę stos technologiczny (a czasem nawet bardzo, bo może to być np. zupełnie inny język programowania), zmienia się domena, w jakiej się poruszamy oraz klient, a co za tym idzie specyfika współpracy, bo z każdym klientem pracuje się trochę inaczej.

Tutaj często jest również tak, że w każdym projekcie zespół, w którym pracujemy, wygląda trochę inaczej. Dlatego z jednej strony mamy okazję pracować z bardzo różnymi osobami, ale z drugiej strony ciężko będzie zbudować taki naprawdę zgrany zespół, gdzie wszyscy będą dobrze znali swoje słabe i mocne strony, będą się dobrze dogadywać i uzupełniać – bo to po prostu wymaga czasu, którego w krótkich projektach nie ma. Coś za coś.

Długofalowe projekty

Drugi rodzaj software house’ów to takie, które tworzą projekty dla swoich klientów oraz je następnie utrzymują i ulepszają na przestrzeni wielu lat. Takie długofalowe współprace potrafią trwać nawet po 10 lat, a klientami są najczęściej duże korporacje, które z jakichś powodów nie chcą budować po swojej stronie zespołu programistów – wolą całkowicie wyoutsource’ować proces tworzenia oprogramowania do zewnętrznego dostawcy.

Po stronie software house’u wygląda to wtedy tak, że są tam zespoły, których skład na przestrzeni lat niewiele się zmienia. Dąży się raczej do tego, że tworzony jest zgrany zespół, który pracuje nad projektem dla jednego klienta. Jeśli w tej współpracy zdarzą się jakieś przestoje, to zespół może wziąć na klatę jakiś mniejszy projekt w międzyczasie, ale skład zespołu pozostaje raczej stały.

Minusem tej sytuacji jest to, że może wkraść się monotonia, bo wciąż pracujemy z tymi samymi ludźmi nad tymi samymi projektami. Natomiast z drugiej strony takie warunki stwarzają okazję do zbudowania naprawdę zgranego zespołu, który jest w stanie bardzo wydajnie dowozić nowe funkcje w projekcie.

Ten rodzaj pracy, jeśli chodzi o typ projektów, jest w gruncie rzeczy dosyć podobny do pracy w dojrzałej firmie produktowej lub w korporacji. Różnica jest jednak taka, że programiści w software house są jednak dużo bardziej oddaleni od użytkowników. Wdrażaniem, utrzymywaniem, analizą logów itp. najczęściej zajmuje się jednak jakiś dedykowany dział IT po stronie klienta.

Ciekawy plus może być taki, że taki mały software house może mieć siedzibę w jakiejś fajnej willi z ogródkiem na Bielanach (true story), podczas gdy praca w korpo zazwyczaj jednak wiąże się z dojazdem do biurowca.

To tyle jeśli chodzi o różnice między tymi dwoma typami software house’ów, a teraz przejdźmy do podobieństw. Największym wyróżnikiem pracy w software house jest na pewno dodatkowa warstwa izolacji od tzw. „biznesu”, czyli osób, na zlecenie których oprogramowanie w ogóle powstaje i którzy decydują, w jaki sposób ma ono na siebie zarabiać.

W firmie produktowej Ci ludzie mogą siedzieć kilka biurek obok nas. W software house są oni w zupełnie innej firmie. Dodatkowo, deweloperzy w software house najczęściej nie komunikują się z biznesem klienta bezpośrednio, tylko robi to Project Manager, który jest łącznikiem między zespołem technicznym a klientem.

Oczywiście nie wszędzie tak to wygląda i są firmy, gdzie kontakt programistów jest bardziej bezpośredni, ale to raczej mniejszość. Są też firmy produktowe, gdzie również mamy PMów i mocny rozdział programistów od biznesu.

Niemniej jednak z moich obserwacji w software house ten rozdział jest szczególnie wyraźny. Z jednej strony to powoduje, że programiści mają pozorny „spokój” i mogą skupić się na kodziku. Ale z drugiej często okazuje się, że ta dodatkowa „warstwa” komunikacji wprowadza sporo szumu i nieporozumień.

Osobiście im dłużej w tym siedzę, tym bardziej jestem zdania, że programiści powinni jak najściślej współpracować z biznesem. Uważam, że to prowadzi do lepszego transferu wiedzy, wzajemnego zrozumienia, wzrostu zaufania i efektywniejszej pracy.

Podsumowując, praca w software house jest dobra, jeśli chcemy robić różne rzeczy, a jednocześnie nie zależy nam tak bardzo na byciu blisko biznesu oraz użytkowników tworzonego przez nas systemu.

Bo jednak nawet przy tych długofalowych współpracach te projekty co jakiś czas się zmieniają, lub też nasz zespół może pracować na przykład przy dwóch projektach w tym samym czasie. To pozwala na chwilowe „przeskoczenie” do drugiego projektu, jeśli znudzimy się w tym pierwszym.

Outsourcing

Ostatnim punktem jest outsourcing, moje osobiste nemesis. Mam bardzo złe wspomnienia z tą formą pracy, dlatego pewnie będę mocno nieobiektywny.

Generalnie outsourcing polega na tym, że jesteśmy formalnie zatrudnieni przez firmę X, ale tak naprawdę nigdy dla niej nie pracujemy bezpośrednio. Zamiast tego jesteśmy wysyłani do klienta naszej firmy, na przykład firmy Y. Często jest to zsyłka fizyczna, bo trafiamy do biura firmy Y i możliwe, że sprzęt również dostarczy nam firma Y. I tak sobie pracujemy aż do momentu, kiedy firma Y stwierdzi, że już nas nie potrzebuje i wtedy firma X szuka nam kolejnego klienta.

W skrócie jesteśmy wypożyczani z naszej macierzystej firmy do jej klientów. Różni się to od pracy w software house tym, że tutaj mamy do czynienia z tzw. „body leasingiem”, podczas gdy software house robi często „team leasing” – czyli nie udostępnia klientowi pojedynczej osoby, tylko cały zespół (który z resztą najczęściej fizycznie zostaje tam gdzie był). Dla mnie jest to kolosalna różnica.

Plusy: tacy „konsultanci” mogą mieć bardzo dobre stawki, o ile większości nie zjada po drodze nasza macierzysta firma (z tym bywa różnie).

Minusy: konsultanci często dostają najmniej pożądane zadania – te, których nie chcą robić zwykli pracownicy. Jest też dobrze opłacany, więc sporo się od niego wymaga. Dodatkowo ciężko o takie poczucie bycia członkiem zespołu, skoro jesteśmy człowiekiem z zewnątrz. Często nie dotyczą nas również benefity dla pracowników firmy Y, różnie to bywa z wyjazdami integracyjnymi itd.

Nie ukrywam, że mam dosyć negatywny stosunek do praktyk outsourcingowych. Najwyraźniej jest na nie zapotrzebowanie, skoro istnieje tyle firm, które się tym zajmują. Ale dla mnie jest to często po prostu „odcinanie kuponów” od pracy programisty przez firmę outsourcingową. To prawda, że jeśli projekt się nagle skończy to nie musimy się martwić szukaniem kolejnego – zrobi to za nas nasza firma. A w międzyczasie otrzymujemy pensję. Ale jakim kosztem…

Podsumowanie

To tyle jeśli chodzi o najpopularniejsze moim zdaniem typy firm, w których mogą pracować programiści. Jak widzicie charakter pracy w każdej z nich jest nieco inny. Dlatego szukając pracy warto sobie zadać pytanie, nie tylko ile chcę zarabiać i z jakimi technologiami chcę pracować, ale również czy chcę często zmieniać projekty, czy jednak wolę wgryźć się porządnie w jeden temat i siedzieć w nim kilka lat? Czy chcę pracować cały czas w jednym zespole z tą samą grupą ludzi, czy wolę co kilka miesięcy zmieniać współpracowników? Czy chcę być blisko biznesu i użytkowników współtworzonego przeze mnie systemu, czy jednak wolę mieć warstwę pośrednią w postaci Project Managera i klienta jako osobnej firmy?

To są pytania, na które każdy musi sobie odpowiedzieć sam. Oczywiście nawet jeśli mamy w tych tematach jakieś swoje idealne preferencje, to wcale nie znaczy, że to nam się zawsze sprawdzi. Po pierwsze, często nie da się tego dowiedzieć dopóki nie zaczniemy w danej firmie pracować. Niemniej jednak warto o te tematy pytać na rozmowach kwalifikacyjnych. Po drugie, to że nie uda nam się osiągnąć 100% naszych założeń nie znaczy, że mamy w ogóle się nad tym nie zastanawiać i do tego nie dążyć. Jeśli na przykład 80% naszych preferencji będzie spełnionych, to i tak będzie nam się lepiej pracowało niż gdyby miało to być 20% i charakter pracy w ogóle by nam nie odpowiadał.

To tyle na dzisiaj 😀 Zachęcam Cię do napisania w komentarzu, który rodzaj pracy najbardziej się Tobie podoba i dlaczego!

Jeśli chcesz otrzymać darmowego ebooka z 10. powodami, dlaczego warto nauczyć się Pythona w 2020 roku, to gorąco Cię zachęcam do wejścia na https://ebook.pythonowiec.pl.

Oprócz ebooka dołączysz w ten sposób do mojej listy mailowej, której co tydzień wysyłam 1 mail z najciekawszymi linkami znalezionymi przeze mnie w danym tygodniu. Oczywiście z mailingu możesz w każdej chwili zrezygnować. Choć pewnie będziesz żałować.

To tyle na dzisiaj, pozdrawiam Cię serdecznie i do zobaczenia w kolejnym wpisie. Cześć!