Zmieniacie pracę co kilka lat - a co z wiedzą domenową?

1

Zależy o jakiej domenie mówimy. W Polsce ogromna większość projektów IT funkcjonuje wokół szeroko pojętych finansów (głównie 2 domeny - ubezpieczenia i bankowość). Jeżeli pracujesz w jednej z nich to faktycznie znajomość produktów i niuansów z nimi związanych zapłaci więcej niż wiedza czysto techniczna. Tak jak ktoś już napisał, jak jesteś klepaczem to takich problemów nie masz. Robisz projekt praktycznie tylko według dokumentacji, ewentualnie po małych konsultacjach. Domenowa wiedza ekspercka nie jest wtedy potrzebna. Jeżeli pracujesz bardziej jako konsultant-programista to wtedy warto się zastanowić nad zmianą domeny. Technicznie będziesz zapewne rozwijał się szybciej, ale trzeba liczyć się wtedy ze spadkiem pensji (często znaczącym). Projekty tak czy tak warto zmieniać, przecież mogą być z tej samej domeny produktowej - nawet w innej firmie.
Tak w skrócie - nie patrz na to czy to system ERP czy nie. Ważne, żeby rozumieć problemy, które występują w danej branży i uświadamiać klientów o tym, że mogą się pojawić oraz jakie mamy możliwości poradzenia sobie z nimi. Programowanie to tylko rzemiosło. Znajomość narzędzi wiadomo, że pomaga, ale w pewnym momencie stanowi to dla Ciebie coraz to mniejszy problem. W dużych firmach IT i biznes bardzo się ze sobą obecnie zazębiają i jeżeli chcesz faktycznie dużo zarabiać (mówię tu cały czas o polskich realiach) to warto to brać pod uwagę.. Mi to odpowiada, siedzenie tylko brzy biurku bywa nudne :)

1

wychodzę z założenia że jak szefowi będzie zależało na zatrzymaniu mojej wiedzy domenowej w firmie to podejmie odpowiednie działania żeby mnie w tej firmie zatrzymać.

4

Widocznie w większości firm nie jest na tyle istotna, ja też mam to w gdzieś. To pracodawcy powinno zależeć, żeby pracownika z taką wiedzą zatrzymać, jeżeli jest dla niego ważna. Jednak z tego co się słyszy to tak nie jest.

5

Co z tego, że koduję niczym mid-level jak w temacie wiedzy domenowej jestem juniorem i potrzebuję zapewne paru lat, żeby powiedzieć, że dobrze czuję temat/działanie systemu jako całości.

To trochę przesada, nie wiem w co chciałbyś wdrażać sie kilka lat. Zwykle to kwestia kilku miesięcy, a cokolwiek więcej jest niemożliwe do utrzymania w głowie ;) Zresztą czy w ogóle jest sens? Na przykład od roku nie było żadnych zmian w jakimś module/serwisie i raczej nie zapowiada się żeby były potrzebne, a już na pewno nie na poziomie architektury, może co najwyżej jakiś prosty bugfix w jednej czy dwóch klasach. Więc czy jest sens siedzieć i się w niego "wdrażać"? YAGNI. Jak będzie trzeba to się wdrożysz.

Tak, żeby projektując jakiś element, mieć jakiś obraz całości, żeby wiedzieć co może mieć jaki wpływ na inne elementy systemu.

Tak to chyba nigdy sie nie da, no chyba że jesteś twórcą i jedynym architektem i głównym developerem tego kodu. W prawdziwym życiu jak kilka miesięcy nie zaglądałeś do jakiegoś serwisu to:

  • już nie pamiętasz dokładnie jak to było zrobione i musisz sobie przypomnieć
  • doszło tyle zmian od innych developerów że i tak to działa inaczej niż pamiętasz

Przecież gdybym teraz zmienił projekt i poszedł rozwijać - powiedzmy - system do zarządzania rezerwacji lotniczych - to znowu jestem kompletna zielonka.

To nie do końca tak jest. Jasne, na rezerwacjach sie nie znasz, ale czym się niby różni stuknięcie do webserwisu getReservationDetails od stukniecia do jakiegoś zupełnie innego serwisu w zupełnie innej domenie? Niczym! Jak dam ci jakiegoś klienta z jasnym interfejsem to jaką ci zrobi różnicę co dokładnie ten klient robi "biznesowo"? To jest trochę jak z wzorcami projektowymi -> pewne mechanizmy pasują wszędzie i nie ma znaczenia że raz masz Factory które tworzy warzywa, a drugi raz masz Factory które robi parsery brainfucka.

Wyobraź sobie że masz poprawić skalowalność robienia tych twoich rezerwacji lotniczych. Przychodzą requesty ale czasem jest spike i serwis nie wyrabia i się dławi. Załóżmy że serws po prostu dostaje jakiegoś POSTa a potem woła sobie jakiegoś klienta który przekazuje tą rezerwacje dalej, ale ta operacja trwa długi. No to nic trudnego, stawiasz jakąś kolejkę, kontroler wrzuca eventy do kolejki a potem N nodów czyta z tej kolejki i wykonuje te "długie" operacje asynchronicznie.
A co jeśli zamiast zrobienia rezerwacji lotniczej te requesty to zupełnie co innego? Czy ma to jakieś specjalnie znaczenie? Bardzo mozliwe że nie ma ;)

Generalnie twoje obserwacje są dobre -> na poziomie mida czy seniora nie ma w zasadzie czegoś takiego jak "wdrożenie technologiczne", bo niby jakie nowinki ktoś tam może mieć? ;) Wszystko już pewnie widziałeś, a nawet jak mają bibliotekę X a ty znasz Y, to idea jest pewnie taka sama a interfejsy i tak są opakowane "firmowymi wrapperami", więc w zasadzie to bez znaczenia. Główny problem stanowi ogarnięcie domeny. Ale tak jak pisałem wyżej, robi sie to na zasadzie "co potrzebujesz" i zdobywasz tą wiedzę w trakcie pracy.
Zmiana dziedziny to oczywiście konieczność nauki nowej, ale czy to taki problem? To jest przecież właśnie ciekawe! Wielu ludzi właśnie dlatego zmienia pracę, bo są znudzeni tym co robią.

Są domeny gdzie jest masa procedur i standardów i faktycznie znajomość dziedziny to spory plus (np. systemy krytyczne, space, defence, czasem też finanse i banki) ale nie jest to reguła i nie jest to raczej "must have" tylko "nice to have". Zresztą co zrobisz jeśli zwyczajnie nie ma na rynku takiego unicorna którego szukasz? :)

1

Problemem jest wiedza domenowa, żeby ogarnąć co system robi, jak to robi, dlaczego to robi i czego user chce.

Ja myślę, że w tym przypadku nabycie wiedzy dziedzinowej to często efekt końcowy całego procesu, a nie coś co się "ma" i rozporządza.

żeby ogarnąć co system robi, jak to robi,

Może mam takie a nie inne doświadczenia, ale zwykle trudność z ogarnięciem "co system robi" polegała na tym, że systemy były słabo napisane pod kątem kodu/architektury kodu, a nie na skomplikowanej dziedzinie. Może nie programowałem jeszcze w super skomplikowanych dziedzinach, ale przypuszczam, że projekty pisane w skomplikowanych działkach biznesu mogą być napisane jeszcze gorzej pod kątem kodu (bo trudną dziedzinę ciężej jest ogarnąć rozumem, więc można przypuszczać, że jeszcze więcej byłoby spaghetti i haków. Jak coś jest łatwe pod kątem dziedziny czy wymagań biznesowych jako takich, np. kolejny CRUD bez udziwnień, to się kod pisze łatwo, korzystając ze wcześniejszych doświadczeń).

dlaczego to robi i czego user chce.

Ale, żeby się tego dowiedzieć są potrzebne: wyczucie biznesowe, empatia, umiejętność komunikacji z innymi, a także krytyczne, refleksyjne i empiryczne podejście... Czyli skille miękkie i świadome dążenie do tego, żeby zrozumieć temat. To nie jest tak przecież, że wchodzisz do projektu, kodzisz sobie coś i z samego kodu i dokumentacji wyczytujesz wiedzę dziedzinową i po kilku miesiącach zagrzebania się w kodzie jesteś jakimś ekspertem dziedziny. No chyba nie.

1

Tu chyba jest rozjazd między tym co kto uważa za wiedzę domenową.
"Problemem jest wiedza domenowa, żeby ogarnąć co system robi, jak to robi, dlaczego to robi i czego user chce." - to chyba jest bardzo uboga część wiedzy domenowej, pozostaje jeszcze masa pytań typu "co jeśli zmieni się w systemie x na y, z, a, b, c, d, w prawie zmieni się g, h lub c, a jeszcze w grupie, do której należy firma ktoś wprowadzi standard prawa międzynarodowego l, a tak w ogóle to wprowadzenie y i h powinno skutkować poprawką q, ale bez wiedzy o p nie można o tym wiedzieć. Te kilka pytań z cytatu wyglądają mi trochę jak pytania kierowane przez osobę typowo przepisującą dokumentację na kod zrozumiały dla komputera, ale ja nie mam komercyjnego doświadczenia w stricte programowaniu tylko siedzę z boku, więc ciężko mi powiedzieć jak to jest i trochę strzelam na oślep. Fajnie by było zobaczyć więcej wiadomości od osób, które bywały mocno i w biznesie w korpo, i w dziale technicznym.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0