Walka o swoje podwórko w projekcie

Walka o swoje podwórko w projekcie
DE
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 599
0

Czy u Was też się zdaża, że członkowie zespołu są samozwańczymi panami części systemu nad którym pracujecie i próba dotknięcia kodu przez kogoś innego powoduje kwas? Znowu jestem w firmie produktowej i znowu tak to wygląda że trzeba sobie trochę wymyślać zadania no i zmiana czegoś w UI powoduje że pan frątaś (tylko sam się tak nazywa, każdy jest fullstackiem, ale on nie umie w backend) czuje się jakby mu sikali na drzewo. Kiedyś miałem podobne odczucia też z frontendowcem.
Takie mamy teraz czasy czy o co chodzi?

AD
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 342
0

Widać ci nie ufaja albo robisz im syf i nie chcą po tobie poprawiać.

obscurity
  • Rejestracja: dni
  • Ostatnio: dni
10

No ja strasznie nie lubię jak mi się sika na drzewo. Projektuję szkielet aplikacji miesiącami a tu nagle przychodzi taki, robi wszystko od zera po swojemu, nie wgłębiając się w istniejący kod, na prostą 5 minutową zmianę tworzy 10 klas, 3 workaroundy, zabiera mu to kilka dni, podpiera na patykach, skleja taśmą i plasteliną, nasra na środek i mówi że zadanie zrobione szefie. Taki problem zapytać kogoś siedzącego w tym kodzie dłużej w jaki sposób to zrobić? Najgorzej jest właśnie jak backendowiec się tyka frontu

Tgc
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 192
2

Nie ma opcji, zeby MR zrobil Ci autor kodu ktory modyfikujesz? Jak jest spor to w MR moze wlaczyc sie reszta zespolu.

PI
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 2786
1

Jako backendowiec, FE w ogóle nie tykam - nawet jak to prosta zmiana labelki, to robię subtaska dla FE engineera.

DE
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 599
0

Nie chodzi o modyfikowanie, rozbudowę ani kopiowanie czyjegoś kodu. Jestem w projekcie gdzie dużo kodu już istniało i wszyscy są tak samo świezi, mało tu jest programowania w ogóle. Ale jak już jest to ludzie się do takich zadań pchają.

Na mój kod też nikt nie narzekał, a wręcz przeciwnie.

Pyxis
  • Rejestracja: dni
  • Ostatnio: dni
0

Czyli robisz zmianę czegoś, co istnieje, tylko po to by się wykazać robotą? To nie ma trochę sensu. Jak już chcesz poprawić coś po kimś, to wypadałoby uzasadnić, np. poprawą wydajności, skróceniem kodu. A jak już na siłę coś potrzebujesz dopisać, to spróbuj napisać testy. I się pewnie okaże, że cała architektura to kupa, której refaktor zająłby kilka miesięcy.

KL
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 643
1

Projektuję szkielet aplikacji miesiącami a tu nagle przychodzi taki, robi wszystko od zera po swojemu, nie wgłębiając się w istniejący kod, na prostą 5 minutową zmianę tworzy 10 klas, 3 workaroundy, zabiera mu to kilka dni, podpiera na patykach, skleja taśmą i plasteliną, nasra na środek i mówi że zadanie zrobione szefie. Taki problem zapytać kogoś siedzącego w tym kodzie dłużej w jaki sposób to zrobić?

Tak, to jest problemem, tylko tak jakby... sprowadziłeś do absurdu pytanie z wątku i sobie dopowiedziałeś że jak ktoś inny dotknie danego fragmentu kodu to będzie zrobione chu*owo.

A to co opisałeś jest tak samo złe jak to co opisał autor wątku, czyli że jedna osoba chce zawsze odpowiadać za dany fragment kodu.

DE
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 599
0
Pyxis napisał(a):

Czyli robisz zmianę czegoś, co istnieje, tylko po to by się wykazać robotą? To nie ma trochę sensu (...)

Nie zmiana tylko rozbudowa i zostało nam powiedziane na początku że oczekiwana jest od nas inicjatywa w tworzeniu produktu, że nie zawsze jakiś leader czy PO będzie nam mówił co mamy robić.

TB
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 32
0

Eskalowac do managera/team leadera/biznesu. Produkt i kod za nim jest po to zeby realizowac potrzebe biznesowa a nie byc jakims totemem Pana developera.

RJ
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 496
4

Bawią mnie ludzie traktujący swój kod personalnie, jakby byl ich dzieckiem 😉

LukeJL
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 8536
3
debugariusz napisał(a):

Czy u Was też się zdaża, że członkowie zespołu są samozwańczymi panami części systemu nad którym pracujecie i próba dotknięcia kodu przez kogoś innego powoduje kwas? Znowu jestem w firmie produktowej i znowu tak to wygląda że trzeba sobie trochę wymyślać zadania no i zmiana czegoś w UI powoduje że pan frątaś (tylko sam się tak nazywa, każdy jest fullstackiem, ale on nie umie w backend) czuje się jakby mu sikali na drzewo. Kiedyś miałem podobne odczucia też z frontendowcem.

Jak backendowcy wchodzą na frontend, to efekt jest czasem podobny do tego, jakby frontaś wszedł w backend i zamienił piękny SQL z joinami, na select całej bazy i ręczne filtrowanie za pomocą array.filter w JS 🤡

Nie mówię, że tak jest w tym przypadku, jednak wskazuję na pewien problem z tym, że jak ktoś jest "fullstackiem", to czasem nagle zaczyna myśleć, że zna się na totalnie wszystkim.

Pinek napisał(a):

Jako backendowiec, FE w ogóle nie tykam - nawet jak to prosta zmiana labelki, to robię subtaska dla FE engineera.

Prosta zmiana labelki też może wymagać konsultacji. Np. ktoś może zmienić labelkę bezpośrednio w pliku z widokiem, olewając to, że copy do labelek są trzymane w osobnych plikach. Albo ktoś może narzucić customowe style, które będą się kłócić z resztą styli. To często nawet nie tyle psucie, co dokładanie pracy frontendowcom, którzy będą musieli to poprawiać.

To już nawet nie chodzi o frontend, tylko że ktoś rusza jakiś kod, którego przeznaczenia nie rozumie i ora ileś tygodni czyjejś pracy, żeby tylko zamknąć pojedynczego taska.

Z drugiej strony zdarzyło mi się, że byłem po drugiej stronie barykady i to ja byłem tym, kto się miesza komuś i dostawałem ojebki. O ile tamten programista mógł mieć zbyt duże poczucie terytorialności oraz zbyt małe skille miękkie, żeby komunikować się w bardziej kulturalny sposób, to również:

  • był zły podział ról w projekcie (za co odpowiadała góra). I nasze role się dublowały.
  • byłem nowy w projekcie i nie znałem dobrze architektury i faktycznie robiłem coś, co było niezgodnego z jego zamysłem. I faktycznie potem po mnie poprawiał.
  • brak odpowiedniej komunikacji (pewne rzeczy powinno się dokumentować, żeby ułatwić potem pracę innym programistom. W twoim przypadku też pewnie frontendowiec mógłby jaśniej się komunikować/dokumentować, jeśli ma jakieś rzeczy, które muszą być tak, a nie inaczej. Ale i ty też powinieneś mocniej to konsultować, a nie po prostu zmieniać coś na chama).
  • PM był niedoświadczony i dostrzegał konflikt (to trwało trochę dłużej), ale nie umiał odpowiednio zmoderować pracy własnego zespołu (aż to musiało zostać eskalowane jeszcze wyżej)
LitwinWileński
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 812
1
debugariusz napisał(a):

Czy u Was też się zdaża, że członkowie zespołu są samozwańczymi panami części systemu nad którym pracujecie i próba dotknięcia kodu przez kogoś innego powoduje kwas?

Tak, spotkałem się z tym kiedyś u 1 osoby. Refactor zrobiłem dobrze, wszyscy powiedzieli, że dobrze ALE jedna osoba, która tez powiedziała, że dobrze się wkurzyła i zablokowała zmiany.

Róznica między inżynierem a artystą jest taka, że artysta swój wytwór traktuje osobiście. Powiesz mu, że zrypał to się obrazi. Inzynierowi powiesz, że zrypał to powie Ci wiem.

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.