[wargi-sromowe-mniejsze]

Jako #programista30k z 16-letnim stażem, głównie w projektach związanych z szerokim web-devem ale też integracją produktu z urządzeniami mobilnymi, zewnętrznymi serwisami, internet of things pragnę podzielić się listą największych wg mnie błędów jakie popełniają firmy technologiczne na którymś z etapów swojego istnienia.

1. Migracja monolitu do SOA.
W większości przypadków przynosi więcej szkody i niepotrzebnych kosztów niż utrzymanie solidnie zaimplementowanego monolitu. Zazwyczaj inicjowana na pewnym etapie życia produktu przez grupę doświadczonych inżynierów znudzonych codzienną pracą z monolitem i szukających wyzwań pozwalających im zdobyć nowe doświadczenie. Potrzeba tej zmiany jest argumentowana zazwyczaj lepszą w teorii skalowalnością systemu, łatwiejszym deploymentem i utrzymaniem wszystkich serwisów. W praktyce podobną skalowalność dużo łatwiej osiągalną przez dołożenie zasobów można uzyskać zostając przy monolicie. Zazwyczaj taka migracja dokłada tylko problemów z architekturą sieciową i integracją wszystkiego w jedną całość, dochodzi konieczność utrzymania brokera eventów i asynchronicznej komunikacji, etc. Przy braku odpowiednich nakładów świetnych inżynierów: zarówno programistów i devopsów firmy dokładają sobie tylko niepotrzebnego skomplikowania całości, nie wspominając o kosztach przepisania całości z monolitu na SOA co samo nie przekłada się na zysk firmy.

Z mojego doświadczenia w 99% przypadków dobrze napisany monolit, najlepiej napisany w podejściu: Loosely Coupled Monolith będzie o wiele korzystniejszym, prostszym i tańszym zarówno w implementacji jak i utrzymaniu rozwiązaniem.

Pokuszę się nawet o stwierdzenie, że przepisywanie monolitu na SOA w zasadzie nigdy nie może wyjść dobrze a pozwolić sobie na używanie tej architektury mogą sobie tylko wielcy gracze, dysponujący nieograniczonymi zasobami zarówno finansowymi jak i ludzkimi, pozwalającymi na napisanie a nie przepisanie wszystkiego od nowa przez wiele niezależnych teamów, każdy odpowiedzialnych tylko i wyłącznie za jeden serwis. Firma powinna również posaiadać dedykowany, doświadczony team devopsów to stworzenia i utrzymania architektury sieciowej dla SOA (niezależnie czy w cloudzie czy na serwerach dedykowanych)

2. Wdrażanie modnych rozwiązań na siłę - szlagierowy przykład to używanie GQL zamiast REST do API
Wdrażane z pobudek podobnych do migracji do SOA - chęć użycia i nauczenia się nowej technologii.
Problemy w zasadzie te same. W przypadku GQL jest to komplikowanie prostych rzeczy, problemy z optymalizacją zapytań i eliminacją problemu N+1, które w GQL rozwiązuje się w sposób nietrywialny jak ma to miejsce w api REST.
Często śmieję się z firm, które na siłę wrzucają GQL mając tylko jednego i to swojego klienta tego API, API które do tego nie zmienia się często. GQL ma w zasadzie sens tylko w projektach, które udostępniają różnorakie podzbiory API różnym klientom, co nie przeszkadza programistom wdrażać tego rozwiązania w prostych projektach tym samym robiąc klasyczny "strzał z potężnej armaty jaką jest GQL do muchy, jaką jest ich prosty w założeniach projekt"

3. Naiwne myślenie, że wytwarzanie oprogramowania skaluje się liniowo względem ilości inżynierów.
W przybliżeniu jest tak faktycznie do pewnego rozmiaru firmy. Słowem 2 programistów wykona pracę 2x szybciej niż 1, czy nawet 6 wykona ją 2x szybciej niż 3, ale od powiedzmy 5 programistów przestaje się to tak prosto skalować ponieważ dochodzi znacząca praca polegająca na po pierwsze podziale pracy między zespoły a po drugie komunikacji między nimi czy wreszcie po 3 scaleniu tej pracy. Najgorsze, że nawet doświadczeni managerowie czy tech-leadzi często zakładają że mając zespół 50 osób, dobiorą kolejne 50 osób i zrobią pracę 2x szybciej. Otóż często zrobią tę pracę nawet trochę wolniej.

#programowanie #pracbaza #pracait #it

[wykopowy_brukselek]

@Ogniste_Jezyki_Sprawiedliwosci: naprawde nie wiem. zajrzyj na FB na grupy testowanie op[rogramowania i tam zobaczysz co odpisuja innym juniorom
ja mam juz prawoie 44 lata wiec naprawde nie wiem jak wyglada rynek juniorow oprocxz tego ze nie jest latwo

[Ogniste_Jezyki_Sprawiedliwosci]

@wykopowy_brukselek a jak oceniasz te prace i zawód? Czy zmienił byś ją na coś innego gdybyś mógł wcześniej?

[wykopowy_brukselek]

@Ogniste_Jezyki_Sprawiedliwosci: mi sie podobalo przez te wszstkie lata, ale biorac pod uwage ze pracuje pond 18 lat to juz nam dosc
tzn sama praca jest ok, ale fajnie jakby byla bardzoej zaangazowana spolecznie, dawala wiecej satysfakcji ze robisz rzeczy ktore sa przydatne
ale ja naprawde trafilem na dobre lata, jako junior dostalem w krakowie w 2006 roku prawie 7000 brutto. chyba teraz tyle juniorzy nie maja a wtedy to byly prawie

[damianooo8]

Ja to się dziwię że ten wpis ma tyle plusów. Wpis typowo specjalistyczny. A plusuje go 1/3 mirko. Mam wrażenie że to działa na tej samej zasadzie że ludzie chcą się dowartościować że rozumieją. Coś jak plusowanie pseudo zagadek logicznych, lub memów po angielsku.

[kryshak]

@wargi-sromowe-mniejsze: Super wpis i proszę o więcej! Pracuję jako analityk systemowy, więc nie jestem w IT na jakimś głębokim poziomie, ale takie wpisy byłyby dla mnie bardzo interesujące. Z rzeczy, które wymieniłeś, widzę podobny problem u nas z GQL :)

[markier]

Tak wiem, to ja dzwonię, ale chętnie poznam motywacje i stosunek do pracy ludzi z większym stażem ;)

@Pit1337: 12 lat w branży. Pisać kodu tak codziennie to mi się nie chce. W pewnym momencie tak pokierowałem kariera by to inni pisali ten kod na moje zlecenie. Jednocześnie nie jestem managerem i nie chce nim być. Chcę być blisko kwestii technicznych ale na odpowiednim poziomie abstrakcji. Rozkminiam w firmie jak połączyć

[Pit1337]

@markier czyli architekt :D

[Drmscape2]

No i generalnie na dzisiaj to wolę rozwijać się w innych hobby a z programowania zbierać tylko łatwą kasę

@Pit1337: i zajebiście gościu, wszystkim życzę, żeby osiągnęli taki etap kariery, pozdrowienia.

[fuuYeah]

@wargi-sromowe-mniejsze: bardzo mądrze. Mam podobne doświadczenie i zgadzam się całkowicie. Sam doświadczyłem w poprzedniej firmie „migracji” na GQL podczas gdy jednocześnie postępowała migracja po stronie backendu na bardzo szybkie i wydajne mikroserwisy. Potem się okazało ze wygodniej jest używać ich bezpośrednio niż przez „proxy” jakim jest GQL. Dodatkowo, ludzie odpowiedzialnymi za to, odeszli z firmy :)

Ciężko jest o dobrego CTO albo Eng. Managera, który wie kiedy kogoś powstrzymać przed „robieniem

[fuuYeah]

@wargi-sromowe-mniejsze: #!$%@? spojrzałem na nicka… xD Poważny człowiek hehe

[P.....c]

@wargi-sromowe-mniejsze: pytanie z innej beczki - po 16 latach chce Ci się robić? Mi po 9 już nie bardzo, znalazłem takie korpo w którym działam sobie w ulubionym stacku (Golang, Kubernetes, etc.) mam tu dobre pieniądze, za wiele się nie narobię, spokojnie gdybym chciał to drugi etacik równolegle mógłby wlecieć, ale... nie chce mi się. Robiłem już w korpo, małych SW house gdzie zawsze był zapie#$ol, obrobiłem w życiu kilka języków

[pragma_once]

@ly000 modularny monolit rozwiązuje takie problemy.

[Pit1337]

@Pozytywny_gosc Sam kiedyś byłem takim gościem z pasją, ale robiłem to bo kochałem programować a nie dla dobra firmy czy aby piąć się po drabince w korpo czy w ogóle w branży aby co chwilę zmieniać robotę po lepszą kasę. Myślę że nadgorliwy pasjonat i tak jest dużo lepszy niż nadgorliwy karierowicz ;)

[boryspo]

@fuuYeah: ewidentnie ktoś miał dobry pomysł, ale położył wdrożenie, jak to często bywa z GraphQL-em. Jako centralne API sprawdza się doskonale, o ile jest dobrze zrobione i rozwiązuje część problemów, które się pojawiają w takim bezpośrednim dostępie do serwisów (uwierzytelnianie / autoryzacja w jednym miejscu, jeden synchroniczny protokół komunikacyjny, ujednolicenie interfejsu, cała dokumentacja razem z API). Można nawet pójść o krok dalej i podzielić schemę pomiędzy te serwisy. Czego u was

[Dobrytyp]

@seanconnery Taaaa, bo za granicą to ludzie nie są zazdrośni, tylko w tej Polsce. ( ͡º ͜ʖ͡º)

[mcdzizas]

@Pit1337: 7 rok here. Sama inżynieria nie jest już czymś co turbo wkręca, zaczynam szykować się pod następny krok czyli architektura lub liderowanie -> Management. Wydaje mi się, ze przy 10 latach łatwo o wypalenie jak zajmujesz się tylko i wyłącznie developerka

[Pit1337]

@mcdzizas Nie boisz się wypaść z obiegu zostając jakimś rodzajem managera? Jednak nawet klepiąc kod bez większej pasji utrzymujesz się w nurcie a widziałem wielu managerów którzy już po roku czy dwóch, odlecieli

[XpedobearX]

pytanie z innej beczki - po 16 latach chce Ci się robić? Mi po 9 już nie bardzo

@Pit1337: Sam powoli odczuwam podobny problem z 11 lat expa. Zaczynam coraz bardziej traktować pracę jako środek do zarabiania pieniędzy oraz możliwości realizacji swoich pasji. Jesli ktos lubi po pracy pracowac (czyli sie uczyc w IT) to jego sprawa. Wole uczyc sie w czasie pracy, bo to tez praca i wartosc dodana pracodawcy.

[mcdzizas]

@Pit1337: Wciąż chce się trzymać kodu, natomiast plan długoterminowy zakłada wybąbelkowanie w góre w kierunku stanowiskach na C level. Zawsze interesował mnie aspekt "miękki" biznesu oraz rozwój umiejętności liderskich. Mając dobry background techniczny można być jeszcze lepszym liderem, natomiast trzeba pamiętać żeby nie odlecieć. Natomiast sytuacja "odlotu", o której wspomniałeś jest często zauważalna właśnie w przypadku osób, które idą na stanowiska zarządzające czy liderskie, nie mając ani podstaw technicznych, ani wiedzy