Quant developer

Krzysztof Kempiński
Aug 17 · 19 min read
Image for post
Image for post

W ramach podcastu “Porozmawiajmy o IT” miałem okazję porozmawiać z Piotrem Jareckim, Pawłem Kołtuniukiem i Andrzejem Sokolnickim o pracy quant developera.

Posłuchaj naszej rozmowy w wersji audio 🎧 👇

Cześć, dzisiejszy odcinek będzie pod wieloma względami nieco wyjątkowy, ponieważ będę miał przyjemność rozmawiać aż z trzema gośćmi jednocześnie.

A dzisiaj będą to Piotr Jarecki, programista F#, software development lead w Credit Suisse, zarządzający zespołem odpowiedzialnym za aplikacje frontendowe dla traderów. Jego hobby to gry planszowe i narciarstwo.

Paweł Kołtuniuk, programista z dziesięcioletnim doświadczeniem, lead software development engineer w Credit Suisse, zarządzający zespołami i projektujący wewnętrzne systemy dla banku. Wcześniej pracował w Microsoft, gdzie zajmował się tworzeniem frameworków testujących dla aplikacji webowych.

Andrzej Sokolicki, absolwent Elektroniki i Telekomunikacji, wcześniej pracował jako software testing engineer w Intelu i UTC, a także programista C++ w Nokii. Obecnie pracuje jako quantitative developer w Credit Suisse, w codziennej pracy łączy technologię zarządzania zespołem i styk z biznesem. W wolnym czasie uwielbia podróże, wspinaczkę oraz dobre filmy i jazdę na snowboardzie.

Dzisiaj z tymi trzema panami porozmawiam sobie o temacie jak dla mnie totalnie nowym, z tym po raz pierwszy będę miał okazję się zetknąć, także traktuję też tę rozmowę jako formę nauczenia i dowiedzenia się czegoś nowego. Mianowicie będzie to temat quant developera. Witam was serdecznie w podcaście! Niezmiernie mi miło, że tak liczne grono będę tutaj gościł!

Na początku zapytam was o to, o co zawsze pytam moich gości — czyli czy słuchacie podcastów, jeśli tak to, jakich najczęściej?

[Piotr] Cześć, Krzyśku! To może ja sobie pozwolę zacząć. Też bardzo mi miło trafić do ciebie. Jeżeli chodzi o pytanie, zdecydowanie podcasty to jest coś co lubię, coś, co słucham, jeżeli chodzi o naszą stronę, czyli software inżynierską, to słucham oczywiście ciebie, słucham też twojego konkurenta, czyli Maćka Aniserowicza z Devstyle’em oraz ostatnio taki nowy podcast, który powstał od strony ludzi z Bottega IT Better software design, który bardziej jest skonkretyzowanym na programowanie, a pisanie kodu na podstawie domain driven design i to, co oni promują. Jeżeli chodzi o poza to dość szeroko od bardziej politycznych, światowych, na przykład Dział Zagraniczny, Raport o stanie Świata, poprzez biznesowe jak na przykład Mała, wielka firma albo APP Jacka Santorskiego.

I tak poza tym, to co ktoś poleci dobrego.

[Andrzej] Cześć, Krzyśku! Mnie również bardzo miło być u ciebie. Ze swojej strony powiem szczerze, że głównie w związku z tym, że brakuje w polskich mediach informacji o tym, co się dzieje na świecie, to właśnie Dział Zagraniczny i Raport o stanie Świata to są takie dwa podcasty, na które poświęcam w każdym tygodniu jakiś czas, żeby odsłuchać.

Super, dziękuję!

[Paweł] Cześć, z tej strony Paweł! Osobiście preferuję blogi i czytanie na temat większości nowych technologii lub tym, czym zajmuję się w pracy lub w domu. Ale zdarza mi się słuchać podcasty i to w większości dzięki mojemu managerowi, Michałowi Małeckiemu, którego teraz tutaj pozdrawiam. Michał bardzo namiętnie słucha podcastów i kiedykolwiek znajdzie coś ciekawego, to podsyła mi i w tym momencie mam okazję zapoznać się z bardzo ciekawymi tematami.

Pewnie! Dobrze jest mieć takie źródło, bo faktycznie scena podcastowa rośnie i nie raz nie da się wyśledzić wszystkich nowości, które się pojawiają, także taki filtr, który nam wstępnie przeselkcjonuje te podcasty jest na wagę złota. Super.

Dzięki wielkie za wasze rekomendacje. Myślę, że dla wielu słuchaczy to pojęcie quand developera jest czymś zupełnie nowym, z czym stykają się, z resztą podobnie jak ja, po raz pierwszy. Dlatego wyjdźmy może od jakiejś definicji — spytam was, kim jest taka osoba, czym się zajmuje na co dzień?

[Paweł] Jeżeli chodzi o quant developera, to tak naprawdę to jest spektrum osób, które się tym zajmują, gdzie z jednej strony moglibyśmy powiedzieć — osoby, które my wewnętrznie nazywamy quanci. To są z reguły matematycy, fizycy, którzy zajmują się modelowaniem instrumentów finansowych, też muszą potrafić programować i przenieść te modele na kod, aż po ludzi, którzy rozumieją jak działa bankowość inwestycyjna, w jaki sposób budowane są instrumenty, ale niekoniecznie rozumieją matematykę, która jest pod spodem i są bardziej skoncentrowani na technologii, której się używa do wyceny czy obliczenia w chmurze, w jaki sposób przedstawić użytkownikowi bardziej skomplikowane aspekty związane właśnie z handlem instrumentami finansowymi, aż po ludzi, którzy tak naprawdę zajmują się na przykład infrastrukturą. Oni też muszą mieć jakąś wiedzę domenową związaną z bankowością inwestycyjną, ale tutaj oni są bardzo mocno technologiczni, to jest dla nich najważniejsze — technologia, niż wiedza domenowa. W skrócie takim quant developerem to jest programista software engineer, który ma wiedzę domenową z zakresu bankowości inwestycyjnej, a rozległość tej wiedzy jest tak naprawdę różni się od tego, w którym miejscu banku jesteśmy. Czy jesteśmy tymi typowymi quantami, którzy tworzą modele czy jesteśmy bardziej programistami, którzy używają tych modeli i tworzą na przykład aplikacje webowe czy desktopowe dla końcowych użytkowników.

Okej. W nazwie tego stanowiska jest developer, dlatego zastanawiam się, jakie są różnice czy też podobieństwa w stosunku do takiego standardowego software developera?

[Paweł] Myślę, że tak jak przed chwilą powiedziałem. To jest software developer, tylko tak samo, jak masz back end developera, front end developera, który ma swoją specjalność w tym ogólnie pojętym software developement, to tak samo quant developer to jest programista, który w takim bardzo dużym uproszczeniu ma znajomość rynków finansowych.

[Piotr] Pozwoliłbym sobie dodać do tego, co powiedział Paweł — dużym wyznacznikiem jest ta ilość wiedzy biznesowej, której quant developer musi posiadać. Tak jak sobie mówiliśmy tutaj o pewnym spektrum stanowisk, które byśmy nazywali quant developerem, to im bardziej się przybliżamy do tych konkretnych modeli finansowych, konkretnych wyliczeń, które się opierają o czystą matmę, czyste modelowanie zachowań rynków finansowych, tym więcej tej wiedzy biznesowej przychodzi i tym mniej można się oprzeć na takich czystych wymaganiach funkcjonalnych, które byśmy dostali czy jakieś VRD, tym więcej trzeba mieć pełne zrozumienie, żeby móc to zakodować, odpowiednio zaprogramować, zaimplementować.

[Paweł] To jest troszeczkę jak w przypadku analityków biznesowych, którzy są między programistami a klientem końcowym — tutaj raczej to się troszeczkę spłaszcza, w sensie, że ty musisz być też analitykiem, żeby zrozumieć jak do danego problemu podejść.

Dobrze, to porozmawiajmy chwilę o progu wejścia, bo tu faktycznie tak jak powiedzieliście, to jest połączenie trochę różnych kompetencji. Z jednej strony takiego klasycznego software engineera, z drugiej osoby, która potrafi posługiwać się takimi narzędziami, potrafi posługiwać się matematyką, tworzyć modele, wreszcie ma jakąś wiedzę domenową. Połączenie różnych pól, konieczność rozwijania się w tych licznych polach, dlatego zastanawiam się jak trudno jest się nauczyć tych kwestii quantowych, związanych bardziej ze specyfiką tej branży i czy ten próg wejścia leży wysoko czy bardzo wysoko?

[Paweł] Myślę, że tutaj każdy z nas ma swoją historię, ponieważ żaden z nas nie jest z wykształcenia quant developerem, jeśli można tak powiedzieć, tylko przychodził do Credit Suisse jako programista, który musiał nauczyć się kwestii quantowych. Co jest warte zaznaczenia, jeżeli chodzi o zachód, kiedy przychodzi programista na stanowisko quant developera, naprawdę musi mieć bardzo mocną wiedzę finansową, ponieważ jest to coś, czego ludzie uczą się na uczelniach, na stażach.

W Polsce jeszcze, chociaż powoli to się zmienia, nie mamy za bardzo ludzi, którzy są świeżo po uczelni albo z innych miejsc pracy, mają wiedzę quantową. Taka firma jak Credit Suisse otwarta jest na programistów, którzy są gotowi na to, żeby nauczyć się kwestii quantowych. U mnie wyglądało to tak: ja przyszedłem co Credit Suisse z Microsoftu, gdzie byłem programistą i nie do końca nawet wiedziałem jak te rynki finansowe działają poza takim zainteresowaniem jak wybuchł kryzys, co to jest akcja, opcja, ale niewiele więcej. Tutaj była bardzo duża pomoc, ponieważ najpierw miałem miesięczne szkolenie w Londynie, w którym ludzie uczyli mnie podstaw matematyki, gdzie tak naprawdę próg wejścia to jest matematyka, którą mamy w liceum, trochę na studiach. Po prostu nie można się bać takich podstaw.

W Polsce jeszcze, chociaż powoli to się zmienia, nie mamy za bardzo ludzi, którzy są świeżo po uczelni albo z innych miejsc pracy, mają wiedzę quantową. Taka firma jak Credit Suisse otwarta jest na programistów, którzy są gotowi na to, żeby nauczyć się kwestii quantowych.

Reszty można się nauczyć. Ciężko jest to zrobić samemu, dużo łatwiej, jak ktoś ci to wytłumaczy no i mieliśmy takie szkolenia, z drugiej strony w trakcie pracy też mamy już w Polsce wielu ludzi, którzy są ekspertami w swoich dziedzinach. Nawet skomplikowane tematy, gdybym się miał tego nauczyć, powiedziałbym, że próg wejścia jest kosmiczny, ciężko. Ale kiedy masz osobę, do której możesz podejść, ma na to czas i jest w stanie ci to wytłumaczyć krok po kroku i często ukryć te szczegóły matematyczne, ponieważ sam jako programista, który ma użyć modelu niekoniecznie musi rozumieć, jak działa całka stochastyczna albo w ogóle jak ją obliczono, to zmniejsza ten próg wejścia.

Dla kogoś, kto chciałby nauczyć się tego w domu wydaje mi się to bardzo duże, ale jeżeli ktoś nie boi się matematyki i chciałby jej używać w pracy, to jest do zrobienia. Kwestia chęci.

[Andrzej] Jeżeli mógłbym coś dodać od siebie, to właśnie — jak powiedziałeś na wstępie. Też nie wyszedłem z żadnego backgroundu finansowego, bankowego albo innego, ekonomicznego, tak byśmy to nazwali. Tak jak Pawła, zawsze mnie interesowały te kwestie, dlaczego wybuchł kryzys w 2008, 2009, dlaczego upadło Lehman Brothers i tak dalej, i tym podobne, ale nie miałem mocnego backgroundu. I to, co ja zauważyłem, to jeżeli chodzi o uczenie się samodzielnie kwestii quantowych, czyli po prostu tłumacząc jak działają rynki finansowe, na czym polegają dane instrumenty finansowe, dlaczego one są w pewien sposób unikalne, czy one się między sobą różnią, to na rynku ogólnie jest bardzo dużo darmowych lub płatnych, ale pomocy bardzo podstawowych. Na przykład investopedia, która ci potrafi powiedzieć bardzo dużo o tym właśnie czym jest obligacja, czym jest akcja, jaka jest różnica pomiędzy akcją i obligacją.

Jest też bardzo dużo materiałów zaawansowanych, które wchodzą w szczegóły jak dany instrument finansowy wygląda, jak on się zachowuje, jak on jest handlowany na rynkach światowych i tak dalej, i tym podobne. Ale to są bardzo eksperckie materiały. A brakuje tej części pośredniej. Czyli czegoś, co by pozwoliło przeskoczyć od tej wiedzy takiej bardzo podstawowej, takiej — był taki film, Big Short, który właśnie podstawową pokazywał, jak to wygląda, ale żeby przejść do bardziej zaawansowanych kwestii. I tutaj jak Paweł powiedział, mi się też wydaje, że bez wsparcia ludzi, którzy już się na tym, znają, którzy już pracują w banku byłoby ciężko się samemu tego nauczyć. Szczególnie tutaj ja jestem ciekawym przykładem, ponieważ przychodząc do Credit Suisse przyszedłem do tych zespołów bardzo mało quantowych, które zajmowały się wsparciem infrastruktury, zbudowaniem continuous integration, odpowiednich tuli testowych i tak dalej, i tym podobne, a potem przeskoczyłem do zespołu, który jest już bardzo quantowy i de facto chyba z naszej trójki ja jestem najbliższej tych modeli finansowych i dopiero jak weszła taka mocna pomoc ludzi z wiedzą ekspercką, czy to od nas z polskiego oddziału Credit Suisse wrocławskiego czy może z zagranicy, z londyńskiego oddziału, nowojorskiego, z Zurychu, to dopiero pozwoliło mi tak w pełni zrozumieć i w pełni być w stanie zaimplementować ze wszystkimi szczegółami te modele, które są w mojej odpowiedzialności, żeby je dostarczyć.

Ponownie powiem, że naszym niesamowitym, cennym assetem jest to, że mamy tych ludzi, których możemy się zapytać i fajne jest to, że chyba — myślę, że mogę to powiedzieć — w całym banku jest taka atmosfera, że nie ma głupich pytań, zawsze można się zapytać, zawsze można poprosić o wytłumaczenie i jest na to pełna otwartość wszystkich.

[Piotr] To jest też trochę tak jak w firmach informatycznych często jest jakiś tam mind board, gdzie dyskutuje się jakąś architekturę czy graf, jak użytkownik będzie używał jakiejś aplikacji no to tutaj często się widzi, jak siedzi informatyk z matematykiem i rozmawiają o co chodzi w tej transformacji macierzy czy jak tutaj będą wypłacone kupony dla jakiegoś instrumentu finansowego no i tak naprawdę no to na tym chyba wszyscy bazujemy.

Też studiowałem automatykę i robotykę, więc na starcie może miałem trochę łatwiej z matematyką w porównaniu do innych, ale też pamiętam, że jak musiałem coś zmienić w modelu i z macierzą korelacji, to nie spodziewałem się, że będzie tak na starcie z dość wysokiego C, natomiast to to też oczywiście jest wiedza, którą się zdobywa przez lata. Jak ktoś idzie do Nokii no to też pewnie musi się bardzo dużo wiedzy wewnętrznej nauczyć czy w jakiejś innej branży.

[Paweł] Pozwolę sobie jeszcze na koniec oddać, że bardzo ważna jest chęć, żeby się tego nauczyć. Trzeba się przygotować na to, że jeżeli chcę pracować w quantach, muszę chcieć się tego nauczyć, a dzięki pomocy ludzi, których mamy już na pokładzie, będzie to możliwe.

Wiele razy tutaj padły różne zagadnienia związane z matematyką: macierze i tak dalej. Zastanawiam się, na ile znajomość matematyki jest kluczowa w tym co robicie na co dzień i czy podczas rozmowy kwalifikacyjnej trzeba rozwiązać równanie różniczkowe czy też może wychodzi to później, że te kompetencje poszerzacie w trakcie pracy, natomiast niekoniecznie trzeba być na wejściu super matematykiem?

[Paweł] Jeżeli chodzi o rozwiązanie równania różniczkowego, jeżeli ktoś idzie typowo na rolę quantową, to będzie musiał to rozwiązać, ale myślę, że raczej Piotr zaczynając jako quant musiał coś takiego robić, ale ja na przykład nie musiałem rozwiązywać żadnych zadań matematycznych na rozmowie. To, co w moim zespole jest oczekiwane, to że ktoś nie będzie się bał. Jeżeli powiem mu, że musisz napisać funkcję, która przybliża pochodną, to nawet nie musi znać tych metod. Po prostu będzie umieć porozmawiać z tym matematykiem, który mu to wyjaśni, w jaki sposób to ma być zakodowane i tak jak mówiłem wcześniej. Wydaje mi się, że ta wiedza to jest takie naprawdę liceum i podstawy ze studiów. To jest wystarczające, żeby zrozumieć, ale daje to też trochę satysfakcji. Bo większość ludzi miała te różne rodzaje matematyki na studiach i zastanawiałem się, po co mi to jest. Osobiście, kiedy nagle się okazuje, że cała ta analiza numeryczna, odejmowanie bliskich liczb albo błędy numeryczne, po co ja się tego uczyłem i okazuje się, że mogę to zastosować w praktyce i zdarzyło mi się raz, że nawet wyciągnąłem skrypt ze studiów, żeby sobie zrozumieć jakiś problem, dzięki temu mogłem rozwiązać coś w pracy, to dało mi dużo satysfakcji. Szczerze muszę się przyznać, że czeka, aż będę mógł zastosować mnoży skróconego mnożenia.

Może kiedyś nadejdzie ten piękny dzień.

[Paweł] Kiedyś nadejdzie. Ale nawet w pracy bardzo quantowej jeszcze mi się to nie zdarzyło.

[Andrzej] Z mojej strony, z tego, co robimy, dodam taki mały szczegół, że bardziej niż typowa analiza matematyczna albo algebra to po naszej stronie ważne jest zrozumienie probabilistyki i statystyki. I ponownie, jak mówiliśmy przedtem. To nie jest tak, że my od razu na wejściu będziemy męczyć ludzi z rozkładów prawdopodobieństwa albo dystrybuanty i czym ona się różni od gęstości, ale jeżeli te modele, zwłaszcza takie duże, portfelowe, które biorą wszystkie trade’y, które bank zrobił i wyciągają z nich jakieś statystyczne wartości typu, chociażby wartość średnia oczekiwana strat lub zysków i trzeba, chociażby dostarczyć parametrów do tych modeli, no to warto jest to rozumieć jak te parametry wiążą się z teorią statystyki, żeby prawidłowo to zakodować. Ponownie wracamy do tego, że im więcej mamy wiedzy domenowej, tym lepiej jesteśmy w stanie to zaimplementować. Ponownie do tego wrócę, żeby nie przestraszyć naszych słuchaczy — to nie jest tak, że to jest must have na wejściu. To jest coś, na co trzeba się mentalnie przygotować, znaczy być może trzeba będzie wejść w temat.

bardziej niż typowa analiza matematyczna albo algebra to po naszej stronie ważne jest zrozumienie probabilistyki i statystyki.

To, co Andrzej powiedziałeś, że coraz bardziej cenieni są programiści z wiedzą domenową dodatkowo, to myślę, że jest trendem, który też coraz bardziej obserwuję. Inny taki trend, który już dosyć mocno się zakorzenił, to jest przesuwanie rozumienia IT nie jako kosztu, ale trzonu całego biznesu.

W Credit Suisse — to nie jest firma, która pozycjonuje się jako firma technologiczna jako taka. Pomimo swojego zaawansowania technologicznego. Zastanawiam się, jak wam się pracuje w takiej firmie, wam jako programistom, w firmie, która zajmuje się domenowo czymś innym — nie opiera wszystkiego na technologii.

[Piotr] Credit Suisse składa się z kilku dywizji, części. Ciężko wrzucić 50 000 osób na całym świecie pod ten sam mianownik. W tej części bankowości inwestycyjnej, no to my jesteśmy zaraz za traderami czy osobami, które bezpośrednio zajmują się kupnem, sprzedażą instrumentów finansowych, tworzeniem portfela dla banku i strategii inwestycyjnej, no to quanci, quant deweloperzy razem z nimi są pierwszą linią frontu. Oni rozumieją, że bez tych modeli matematycznych i całej otoczki IT, która idzie razem z nią — bank inwestycyjny nie jest w stanie funkcjonować w żadnym stopniu.

Bankowość inwestycyjna jest dużo bardziej technologiczna niż bankowość prywatna czy bankowość komercyjna, którą również Credit Suisse oferuje. Tutaj jest dużo mniej kontaktu z klientem, a dużo więcej na technologię i na poprawną wycenę instrumentów, bo tutaj są ogromne transakcje między firmami, gdzie koszt złych obliczeń jest wielokrotnie większy niż w innych częściach.

[Paweł] Myślę, że tutaj, jeżeli chodzi o to, że firma się nie pozycjonuje jako technologiczna, to ma takie swoje plusy i minusy. Jeżeli jest firma technologiczna, tak naprawdę byś oczekiwał, że jest jakaś konkretna metodologia czy na przykład scrum. Od samej góry do samego dołu.

U nas z tego względu, że na pewnym poziomie są ludzie, którzy nie są technologiczni, są bardzo mocno biznesowi, później są też ludzie, którzy mają mocną wiedzę technologiczną. Mamy naprawdę dużą dowolność, jeżeli chodzi o proces wytwarzania oprogramowania. Czyli mamy zespoły, które pracują w scrumie, w kanbanie, inne decydują się na jakieś inne modele pracy, co na przykład dla mnie jest super. Dla moich zespołów mogę wybrać to, co jest najlepsze, ale też ma to swoje minusy, bo jednak spójność, kiedy wszystkie zespoły pracują w dokładnie tej samej metodologii, jak to się dzieje z reguły w firmach technologicznych, ułatwia coraz wyższemu managementowi zarządzanie projektami.

Powtórzę się, że jako dla mnie, że zarządzam zespołem jest bardzo fajne to, że mogę sobie dowolnie wybierać, przez to, że to nie jest firma technologiczna, to nikt by nam nie narzucił metodologii programowania, ale z drugiej strony boli mnie, to kiedy współpracuję z wieloma, innymi zespołami, że jest trochę tego tarcia, żeby dopracować pracę, kiedy każdy pracuje w innej metodologii, ma inne release cycle, używa innych narzędzi do zarządzania projektem.

[Andrzej] Powiedziałbym tutaj o takich dwóch przykładach, które by wynikały z tego, co Paweł powiedział. Na przykład, jeżeli ja współpracuję z moim managerem, który jest bardziej matematykiem, fizykiem, który też jest programistą i ja mogę z nim porozmawiać o pointerach w C++, to jednak do takich rzeczy, które są powszechnie przyjęte w świecie software developmentu, ja nie mogę do niego podejść, że on to naturalnie wie. Jeśli na przykład rozmawiamy o tym, że dostarczamy pewną funkcjonalność, to tutaj akurat to jest ciekawe, że ja muszę się bardzo trzymać mocno scrumowego podejścia, że jak dostarczamy, to dostarczamy w wersji gold, a nie takie, że dostarczamy cokolwiek, a potem to zrefaktorujemy jak już dostaniemy błogosławieństwo, bo mój manager sam z siebie nie rozumie, dlaczego my mamy zmieniać coś, co już działa. Przecież dostarczyliśmy, działa? No to idziemy dalej z funkcjonalnościami. To jest taka pierwsza rzecz.

Z drugiej strony mój manager absolutnie nie ma problemu, że ja zarezerwuję ten czas, żebyśmy dostarczyli w wersji gold. Trzeba się troszkę samemu pilnować, żeby nie pójść czasem na łatwiznę, tylko wykonać tę robotę dobrze od A do Z. A druga rzecz, którą zauważyłem, to jest to, że — trochę pochodna tego, co powiedziałem — że pewne rzeczy musimy dużo mocniej uzasadnić. Na przykład, jeżeli chcemy przejść z .Neta w wersji 4.6 do .Net core’a, to my naprawdę musimy pokazać, gdzie jest ta wartość biznesowa, jak to będzie wyglądało w ilości błędów, które się zmniejszą dzięki temu. Jak będzie to dużo bardziej skalowalne, dużo prostsze do obsługi i jak to koniec końców przełoży się na naszą wyższą produktywność, niż to byłoby naturalne w firmach technologicznych, gdzie każdy praktycznie do samego CEO wie, że takie rzeczy trzeba zrobić.

Kontynuując ten temat chciałem też zapytać o wpływ na wybór technologii. Do banku czy w ogólności jakiejś instytucji powiedzmy finansowych taka trochę przylgnęła łatka, że korzystając z przestarzałych technologii rzadko próbują takich nowinek czy też wszystko musi być bardzo mocno uzasadnione i zabezpieczone od tron technologicznych, żeby takich zmian czy takich właśnie prób dokonać. Chciałem się zapytać, czy to jest prawda — czy z waszej pracy też wynika raczej przeświadczenie, że stare, ale sprawdzone technologie i raczej nie tykamy czegoś, co jeszcze jest bardzo świeże? Czy też może jest to po prostu mit, który możecie od razu obalić?

[Piotr] Jestem na co dzień programistą F#, który nie jest — co prawda już jest teraz ugruntowany, ale jeszcze jak zaczynałem parę lat temu, no to był to powiedzmy język, który dopiero się tworzył. Jeszcze mieliśmy kod w wersji 1.9, jak jeszcze był w wersji beta i nawet z Microsoftu trzeba było ściągać developerów, żeby tutaj pomogli w tych pierwszych latach pracy. Akurat tutaj mogę się posłużyć przykładem, że nie do końca. Też eksperymentujemy z F Starem, w którym robiliśmy ostatnio pull requesta do kompilatora tego języka, więc to nie jest do końca prawda. Na pewno czasem jest problem domeny. Jeżeli Credit Suisse podpisuje z kimś kontrakt na 20 lat, to my jako Credit Suisse musimy przez 20 lat być w stanie taki instrument finansowy wyceniać. Policzyć jego ryzyka, być w stanie klientowi powiedzieć, dlaczego te kupony będą wypłacone w taki, a nie inny sposób. To nie jest taki zawsze green field development, że teraz od początku zaczynamy z nowym projektem i zapominamy o tym, co było, więc jednak trzeba mieć zawsze z tyłu głowy, że to musi działać. Na tyle jest to główny asset banku, że za 10 lat będzie działać bez problemu.

Natomiast akurat wydaje mi się, że quanci w takiej części bankowości, są troszeczkę takim działem R&D, w sensie, że tutaj są tworzone nowe modele, których później reszta używa. Tutaj są rozwiązywane najtrudniejsze problemy biznesowe, które też często wymagają nowego podejścia. Wydaje mi się, że oczywiście jest tutaj zawsze taki trade off, ale nie czuje się tak, że jesteśmy w jakichś bardzo starych technologiach.

Natomiast akurat wydaje mi się, że quanci w takiej części bankowości, są troszeczkę takim działem R&D, w sensie, że tutaj są tworzone nowe modele, których później reszta używa. Tutaj są rozwiązywane najtrudniejsze problemy biznesowe, które też często wymagają nowego podejścia.

[Andrzej] Pozwolę sobie skomentować do tego co Piotr powiedział o tym, że mamy instrumenty dwudziestoletnie albo trzydziestoletnie, też jak najbardziej. Ostatnio jak grzebałem po danych do mojego modelu to zauważyłem, że mamy referencje do jeszcze Wschodnich Niemiec I Czechosłowacji. Najprawdopodobniej chodzi o to, że wtedy obligacje były też wydawane i wtedy też trzeba było je obsłużyć.

Nie mniej to nie jest tak, że ten kod został napisany w ’89 i teraz musimy utrzymywać jakiegoś starego Haskella, nie. My to ciągle update’ujemy, ciągle release’ujemy, ciągle podwyższamy nasze frameworki. Te modele wyceny są też przepisywane. Kiedyś praktycznie wszystko było w C++.

[Piotr] W Excelu jeszcze było!

[Andrzej] Nawet w Excelu!

[Piotr] A w polskich bankach dalej Excel jest królem.

[Andrzej] A teraz my głównie stoimy na .Necie. Pozwolę sobie jeszcze tak hasłowo rzucić, żeby nikt nie myślał, że my tu jesteśmy starzy Excelowcy i Haskellowcy, bo jeżeli przyjdzie się do nas, mikroserwisy są. Sam jestem w trakcie migracji na GIT. To nie jest tak, że mamy stare repozytorium, jeszcze clear case’a IBM-a sprzed lat.

Mamy właśnie też — może nie jesteśmy totalnie bleeding edge, ale z wersjami .Neta ciągle migrujemy, tak samo z wersjami C++. To jest. To nie jest tak, że ktoś przyjdzie do nas to utknie w najstarszych technologiach, ale też jedno, co trzeba pamiętać, że bank musi bazować na sprawdzonych technologiach, bo to jest bezpieczeństwo finansowe.

Okej. To teraz chwilkę może w innym kierunku pytanie — w kierunku kompetencji, które są potrzebne w ogólnie rozumianym quant developmencie. W waszym przypadku to jest taka rola łącząca wiedzę techniczną, domenową, biznesową i jeszcze związaną z zarządzaniem ludźmi. Jak wygląda przykładowa ścieżka quant developera? W jaki sposób on może swoją karierę rozwijać?

[Piotr] Na pewno są dwie podstawowe ścieżki, też jak w firmach technologicznych, czyli jedna to jest bardziej taki people manager, project manager, czyli zarządza się grupą programistów, albo jakimś projektem. Bardziej migruje się w stronę bardziej taką miękką, gdzie te kompetencje miękkie są kluczowe natomiast druga część jest taka bardziej jak osoba, która ma taką specjalność technologiczną, jakby jego głównym narzędziem jest to, że jest bardzo dobry technologicznie.

Natomiast to, co jest pewnie szczególnie w tej ścieżce takiej technologicznej, ta działka quantowa jest na tyle duża, zbudowana, że można przez kilkanaście, czy dwadzieścia-parę lat tę wiedzę quantową poszerzać i budować na tym całą swoją karierę.

[Paweł] Tak samo, jeśli chodzi o wiedzę technologiczną, czyli jakby tak obrazowo opisać — nie skupiajmy się na tej managerskiej, tylko bardziej, co jest warte podkreślenia — jest wielu ludzi na bardzo wysokich stanowiskach w Credit Suisse, którzy nie są managerami. Są osobami, które są techniczne i są doceniane w firmie. To nie jest regułą w wielu firmach technologicznych. Czyli nie ma konieczności stania się managerem, aby coraz wyżej wspiąć się na ścieżce kariery. Zaczyna się od osoby, która przychodzi i jest świeżo po studiach albo gdzieś już pracowała, zaczyna zdobywać te umiejętności quantowe, wiedzę techniczną. Często ludzie w tym momencie, czasami niektórzy — mamy kilka przypadków, że osoby bardziej się kierowały — pomimo że przyszły jako programiści, to tak im się spodobała ta kwestia modelowania, że bardziej szły w stronę modelowania, a osoby, które przyszły jako ludzie, którzy modelują, ale te kwestie technologiczne tego, w jaki sposób masz zrównoleglić kilkadziesiąt tysięcy godzin obliczeń tak, żeby one się wykonały w ciągu jednego dnia. W jaki sposób zarządzać taką dużą ilością kodu szły bardziej w stronę technologiczną i można powiedzieć, że na początku jesteś soft engineerem, później zdobywasz coraz więcej wiedzy quantowej, ważna jest też ta miękka umiejętność rozmowy z klientem.

Dużo naszej pracy to albo ja rozmawiam z quantem, albo rozmawiam z tym maklerem, traderem, albo z kimś, kto potrzebuje jakiś raport i muszę mieć umiejętność tego, żeby dowiedzieć się, jaki jest problem tego kogoś i jak ja go mogę rozwiązać albo pisząc kog, albo dając już to, co było napisane. Im wyżej jest się w hierarchii, tym bardziej trzeba umieć rozmawiać z klientem.

Nasz idealny pracownik to taki, który będzie umieć pójść, zdiagnozować problem, zaproponować rozwiązanie albo samemu zaimplementować. Często ne jest możliwe, żeby jedna osoba zaimplementowała albo zaproponować jak cały zespół jest w stanie to rozwiązać.

Dojście do tego momentu to są lata. Tak bym w skrócie opisał ścieżkę kariery, jeżeli chodzi o quant developera. Od programisty czy matematyka do osoby, która ogarnia naprawdę duży aspekt biznesowej części, jest w stanie nie tylko to zrozumieć, ale także w razie potrzeby zakodować.

[Andrzej] Z kolei bym trochę rozwinął to co Paweł powiedział. Dodał tę kwestię zrozumienia banku. Ponieważ zróbmy takie dwa kroki w tył. Credit Suisse to jest jeden z czołowych banków inwestycyjnych na świecie, będących w pierwszej dziesiątce. To się tam trochę zmienia, ale jak powiemy pierwsza dziesiątka to jak najbardziej. On działa na wszystkich rynkach finansowych na świecie, od Azji przez Europę, skończywszy na USA czy Brazylii. To jest dla bardzo różnych regulatorów, czyli nadzorów finansowych i to może być właśnie chiński nadzór finansowy, japoński — bo też mamy działy w Tokio. Europejski, też z Europy wychodzi Wielka Brytania, wiec też brytyjski, który zawsze był w pewien sposób niezależny, teraz będzie jeszcze bardziej niezależny.

Wszystkie praktycznie instrumenty finansowe też podchodzą w ten trading. I teraz mnogość tego wymusza, że mamy też mnogość systemów, które zostały stworzone, żeby to ogarnąć, żeby utrzymać, żeby wycenić i żeby dać możliwość też wyliczenia ryzyka z tym związanego.

Dochodzi do tego ten moment, o którym mówiliśmy wcześniej. Takiego business analityka, który musi rozumieć nie tylko ten kawałek kodu, który pisze, ale jak on się wkomponuje w ten cały ekosystem systemów do przetrzymywania trade’ów, do wyceny trade’ów, do wyliczenia ryzyka związanego z danym tradem i tak dalej, i tym podobne. Dla mnie, personalnie, to jest naprawdę bardzo satysfakcjonująca rzecz, że ja potrafię w głowie poukładać sobie klocki tych systemów. Jak jedne na siebie wpływa, jak ten trade, który jest zrobiony przez maklera w Nowym Jorku jest zapisany u nas w systemie, jak on jest potem wyceniany. Jak ryzyko z nim związane jest wyliczane, jak on jest potem zaciągany do mojego modelu, który jest następnie przedstawiany do zarządu banku, żeby pokazać, jakie jest takie całościowe ryzyko. Jeżeli ktoś lubi takie naprawdę wyzwania technologiczne względem działania całego systemu, uważam, że my jako bank jesteśmy jedną z czołowych firm, które mogą dać takie wyzwania właśnie programistom, ludziom technicznym.

👉 Czytaj dalej na:

kkempin’s dev blog

Dev and life blog.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface.

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox.

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store