[Reevo]

Kocham jak przychodzi nowy programista do projektu i zaczyna wszystko robić po swojemu. Wszystko jest źle. "To wstrzykiwanie zależności jest bee, lepiej tak, to generowanie kodu jest stare, lepiej nowszą paczkę, tu źle, tam jeszcze gorzej" itd..

Klasyczne 'Kto to Panu tak #!$%@?ł?", tylko ubrane w techniczny bełkot i robienie po swojemu.

Albo kogoś naprostujesz i 'psujesz atmosferę i kulturę pracy', albo machniesz ręką i po roku każdy problem ma już 6 konkurujących rozwiązań (╯°□°）╯︵ ┻━┻.

#programowanie #programista15k

[Saly]

@Reevo: prawda jak zwykle jest po środku, bez szczegółów ciężko powiedzieć, czy wy jesteście zasiedzianymi januszami czy młody uprawia hype driven development

[Reevo]

@Saly: To jest typowe robienie 'po swojemu' i nie odnosi się do konkretnej osoby, bo praktycznie każdy kolejny programista robi to samo, a mamy sporą rotację ludzi.

Przez niektóre rozwiązania przechodzimy już trzeci raz...

[tomek_dev]

@Reevo: aż mi się przypomniała nowa UI designerka w projekcie, która po przyjściu chciała zmienić WSZYSTKO. Czemu nie włączacie kamerek? Czemu to jest tak? Zmieńmy to (nie mówię o jej działce, ale funkcjonowaniu całego zespołu). W efekcie po krótkim czasie większość zespołu miała jej dość. ( ͡° ͜ʖ ͡°)

[ECMAlover]

@Reevo: dla tego dobry zespół, to stały zespół a wdrażanie innych pomysłów/technologii ze świeżym podejściem jest super. Ale od tego są spotkania, pomysł trzeba sprzedać a grupa ocenić ile czasu ewentualnie może na to spalić :P A jak się nie podoba, to won :P

[dzejro]

@Reevo: ustalcie sobie guideline projektu i się go trzymajcie, wtedy bedziesz mógł podlinkowac na code reviewu, że to jest niezgodne z guidelinem i zarequestujesz zmiany. Kazda zmiana guidelinuje wymaga szerszej dyskusji i refaktoringu starego kodu - tym samym utrzymujecie spokójność.

[patrolez]

@Reevo: to sobie spiszcie na jakimś wewnętrznym Wiki/dokumencie FAQ od każdego przypadku dla nowoprzybyłych :P

Najgorzej jest się powtarzać z powodu braku notatek.

[E.....r]

@Reevo: dokumentacja wymagań + tacy od wszystko inaczej to z reguły juniorzy

[dziadmankowy]

@Reevo: nie kumam skąd ludzie mają w sobie to przekonanie że zrobiliby coś lepiej niż zespoły które były przed nimi. Zero pokory i jakiegoś takiego pomyślenia że ci poprzedni to najczęściej nie byli debile i że kod psuje się z czasem bo wszyscy musimy iść na kompromisy czasowe, bo wymagania się zmieniają setki razy, bo trzeba robić "szczególne przypadki" na jakieś egzotyczne usecase, bo trzeba zachować jakąś dziwną kompatybilność wsteczną, bo

[fiolkins]

@Reevo: Zawsze tak jest, ale to ze to zauważasz to tez kwestia Twojego doświadczenia. Następny krok to unikać takiego zachowania przy zmianie pracy.

[imdejv1]

@Reevo: Musicie nowym ludziom tłumaczyć, że nie ma się co podpalać i że zrobi się wszytko "na jutro" i zmieni cały świat, bo są pewne wypracowane elementy w firmie, jest plan działania na xx czasu do przodu i nie jesteście w tej chwili gotowi na zmianę kierunku oraz inne pomysły i zmiany. To może uspokoi pełną wigoru osobę, która chce wszystko zmieniać i zrozumie ona, że tu już jest pomysł na

[p.....k]

@Reevo: śliska sprawa - z jednej strony wszystko ma swoje powody i największa #!$%@? powstała z powodu innych problemów. Z drugiej strony gość pewnie ma rację więc taka opinia musi cię boleć

@dziadmankowy: bo prawdopodobnie tak właśnie jest. Niestety na końcowy kształt gówna wpływa wiele czynników poza niskimi umiejętnościami programistów - jak nacisk managementu, zmieniające się wymagania, zastany kod itp

Trzeba też brać poprawkę na to do czego ten człowiek

[wpiot]

@Reevo: ale jak, tak po prostu se zmienia? u mnie by to nie przeszło, razem całym zespołem tworzymy taski, wyceniamy i product owner decyduje co ma priorytet a co nie. Jak nie ma pewności to taki człowiek dostaje np. 1 dzień na proof of concept.

[Saly]

@wpiot: to trochę patologia. Product owner może decydować o części biznesowej ale nie o technicznej, bo najpewniej nie ma o tym pojęcia. Jak product owner może nadać priorytet, jedyne co mi przychodzi do głowy to wybranie taska w taki sposób, żeby suma punktów była w normie. Wszystko inne musi być podejmowane przez cały team tj. jest dialog pomiędzy product ownerem na temat planów i na tej podstawie ustalane są priorytety. Czym

[wpiot]

@Saly: nie do końca. U nas po prostu PO po dyskusji wstępnej (technicznej) zadaje odpowiednie pytania, np: jakie jest ryzyko zmiany? czy trzeba to zmienić bo biblioteka nie ma wsparcia, albo ma dziurę? ile to potrwa? czy będzie szybciej/taniej/lepsze czasy odpowiedzi? czy dzięki temu kolejna praca pójdzie szybciej? czy trzeba będzie coś innego zmienić (np testy, logi, monitoring)
I wtedy się okazuje czy to jest zmiana dla zmiany, czy będzie jakaś

[szmichal]

@dziadmankowy: znajdziesz link do tego artykułu?

[dziadmankowy]

@szmichal: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

[Krolik]

nie kumam skąd ludzie mają w sobie to przekonanie że zrobiliby coś lepiej niż zespoły które były przed nimi.

@dziadmankowy: może stąd, że wcześniej już 10x poprawiali po "zespołach przed nimi" i faktycznie było lepiej?

Zero pokory i jakiegoś takiego pomyślenia że ci poprzedni to najczęściej nie byli debile

Z tym to różnie bywa. Jak założysz, że jednak debile, to masz mniejsze prawdopodobieństwo się pomylić.

Niestety praktycznie każdy realnie dojrzały i

[Krolik]

@dziadmankowy: Joel ma dużo racji, ale mam pewne obawy, że ten jego wpis na blogu jest niezrozumiany podobnie jak programiści nie zrozumieli słynnego "premature optimization is the root of all evil" Knutha i teraz ślepo stosują to jako "nigdy nie przepisuj, nie optymalizuj".

Fakty są takie, że w historii było wiele *udanych* rewrite'ów oprogramowania. Przykładowo Discord przepisał swój system backendowy z Go na Rust, Twitter przepisał swój system z Ruby na

[MlodyDziadzio]

@dziadmankowy:

nie kumam skąd ludzie mają w sobie to przekonanie że zrobiliby coś lepiej niż zespoły które były przed nimi

Jak przychodzisz z korpo gdzie wszystko jest ładnie udokumentowane i są testy automatyczne do rozpędzonego startupa gdzie się kodzi na yolo, gdzie prostsza część kodu pisana przez dwóch juniorów to nieoptymalne sito, a część wymagająca czegoś bardziej zaawansowanego to jest pisana przez seniora żyjącego is dwóch dekad w swoim świecie, to