Koniczność ogarniania całości projektu

W zespole powinni być techniczni goście którzy ogarniają więcej niż aktualny task. Nie muszą zagłębiać się w kody wszystkiego, ale mieć ogólne pojęcie. Przejrzeć dokumentacje, przejrzeć schematy UML i bazy danych, oblookać interfejs publiczny klas, pogadać z ludźmi na tematy techniczne.
Od dawna tak uważam, a teraz mi się to nasunęło gdy w dwóch wątkach jest:
propozycja rozszerzenia edytora postów o informacje że ktoś aktualnie pisze, jak jest w wiadomościach
Czy kategorie forum nie są zbyt przestarzałe?
Zasugerowanie że właśnie taka informacja może powodować trudności z pisaniem wiadomości na smartfonie
Wiadomości nie można edytować wpisując na smartfonie
Ogarnianie całości byłoby oczywiście łatwiejsze gdyby dokumentacja była zwięzła, aktualna i zawierała wszystko co jest istotne.
Takie były kiedyś Rzeczypospolite, takie było kiedyś młodzieży chowanie.
Ale z pisania dokumentacji został w wielu wypadkach tylko cult cargo, z automatycznym tworzenie sterty papierów (wirtualnych) bo dokumentacja musi być, bez zrozumienia po co mysi być

To chyba nie ulega żadnej wątpliwości. W dobrych organizacjach tak jest, choć trudno mi powiedzieć jaka część tak ma. Niestety często nieumiejętne zarządzanie/presja finansowa/whatever sprawia, że pracownicy, którzy mogliby to robić, szybko odchodzą, a do góry idą osoby zainteresowane wygodną posadką, robieniem problemów i przeciąganiem wszystkiego. Może AI jest jakąś nadzieją, trudno mi powiedzieć.

Miang napisał(a):

W zespole powinni być techniczni goście którzy ogarniają więcej niż aktualny task. Nie muszą zagłębiać się w kody wszystkiego, ale mieć ogólne pojęcie. Przejrzeć dokumentacje, przejrzeć schematy UML i bazy danych, oblookać interfejs publiczny klas, pogadać z ludźmi na tematy techniczne.
Od dawna tak uważam, a teraz mi się to nasunęło gdy w dwóch wątkach jest:

Na tym opiera się praca w IT. Niestety zdobycie tej wiedzy jest trudne a ogarnięcie danego projektu daje wielokrotnie większą wydajność klepania i jakość. Do tego bardzo ciężko się tego nauczyć bez praktyki i dlatego architekt mówiący jak ma być ze swojej wieży z kości słoniowej to tak wielki problem. O tym, że wiele firm przez zwalnianie, słabe warunki albo ciągłę zmiany organizacjyne psuje to co jest najważniejsze do dobrej pracy

IMO to też największa wada LLMów. Ciężko się wgryźć temat jak AI rozwiązuje wszystkie problemy. Może jestem i 5x wydajniejszy, ale pisząc tradycyjnie pewnie byłbym po roku 10x wydajniejszy. Dobrze zauważam to w pracy, gdzie dołączyłem do nowego projektu, gdzie już wszystko opiera się o LLMy i naprawdę ciężko ogarnąć projekt

One-men-army człowiek od wszystkiego umiejący naprawić i zrobić wszystko w projekcie.
Z takimi osobami współpracuję się lepiej, gdyż nie mają czasu na narzekanie tylko douczają się w trakcie bardzo szybko

Dodatkowo polecam osoby z mentalnością "dajcie mi problem i czas a dostarczę rozwiązanie"

Mnie od innych osób odróżnia tylko liczba popełnionych błędów,

Miang napisał(a):

Od dawna tak uważam, a teraz mi się to nasunęło gdy w dwóch wątkach jest:
propozycja rozszerzenia edytora postów o informacje że ktoś aktualnie pisze, jak jest w wiadomościach
Czy kategorie forum nie są zbyt przestarzałe?
Zasugerowanie że właśnie taka informacja może powodować trudności z pisaniem wiadomości na smartfonie
Wiadomości nie można edytować wpisując na smartfonie
Ogarnianie całości byłoby oczywiście łatwiejsze gdyby dokumentacja była zwięzła, aktualna i zawierała wszystko co jest istotne.

Co do edytora Markdown na 4programmers.net, wystarczy przeczytać testy automatyczne, one specyfikują jego zachowanie w całości, dlatego że cały edytor był sterowany testami.

A co do buga o którym mówisz, z dziwnym zachowaniem treści na telefonie, to taki bug zwyczajnie należy poprawić i tyle.

Z piętnastu lat pilnowania produkcji mam jedno spostrzeżenie: ten, który ogarnia całość, prawie nigdy nie jest tym, który najwięcej pisze. To jest gość od logów, od wdrożeń i od pytania „a co się stanie, jak to padnie o trzeciej w nocy". I dokładnie ta rola jako pierwsza leci przy cięciach, bo w ticketach jej nie widać. Z LLM-ami jest jeszcze gorzej, niż pisze slsy: nie tylko trudniej się wgryźć, ale nikt już nie ma w głowie mapy, bo nikt tego nie przepisywał ręcznie. Dokumentacja tego nie zastąpi, bo dokumentacja opisuje stan, a ogarnianie całości to znajomość tego, co się psuje.

Nigdy nie mieściło mi się w głowie, jak można robić karierę jako człowiek od jednej rzeczy.

Całe życie klepiesz klasy w Javie, a jak przyjdzie rozwiązywać jakieś problemy na pograniczu to już oj nie nie, bo to nie moja działka, ja jestem od klas w Javie, a tu proszę państwa jest kawałek Basha to trzeba do sysadmina. Ojojoj, a tu jakieś indeksy spowalniają bazę, to ja nie będę tego ruszał, niech przyjdzie DBA bo to sprawa dla DBA. Czemu taka implementacja? No jak to czemu, pan architekt narysował to tak naklepałem.

Zdumiewają mnie ludzie mentalnie tkwiący w fabryce, w której są od tej jednej operacji przy taśmie i nawet nie widzą produktu końcowego. Wkręcają śrubkę numer 2137 i gdyby przyszło im zamiast tego zastąpić kolegę i zakładać zderzak, to chyba by musieli zgłosić mobbing.
Choć na marginesie, jak w stanie wojennym w FSM w Tychach robotnicy dostawali cyrografy i byli kierowani do produkcji dla wojska, to doskonale zdawali sobie sprawę, że części do Malucha to nie są

Nie musisz znać każdego szczegółu, bo w większych projektach to zwyczajnie niewykonalne, ale trochę wstyd nie wiedzieć nic poza swoją małą bańką.

superdurszlak napisał(a):

Nigdy nie mieściło mi się w głowie, jak można robić karierę jako człowiek od jednej rzeczy.

Całe życie klepiesz klasy w Javie, a jak przyjdzie rozwiązywać jakieś problemy na pograniczu to już oj nie nie, bo to nie moja działka, ja jestem od klas w Javie, a tu proszę państwa jest kawałek Basha to trzeba do sysadmina. Ojojoj, a tu jakieś indeksy spowalniają bazę, to ja nie będę tego ruszał, niech przyjdzie DBA bo to sprawa dla DBA. Czemu taka implementacja? No jak to czemu, pan architekt narysował to tak naklepałem.

Zdumiewają mnie ludzie mentalnie tkwiący w fabryce, w której są od tej jednej operacji przy taśmie i nawet nie widzą produktu końcowego. Wkręcają śrubkę numer 2137 i gdyby przyszło im zamiast tego zastąpić kolegę i zakładać zderzak, to chyba by musieli zgłosić mobbing.
Choć na marginesie, jak w stanie wojennym w FSM w Tychach robotnicy dostawali cyrografy i byli kierowani do produkcji dla wojska, to doskonale zdawali sobie sprawę, że części do Malucha to nie są

Nie musisz znać każdego szczegółu, bo w większych projektach to zwyczajnie niewykonalne, ale trochę wstyd nie wiedzieć nic poza swoją małą bańką.

Tylko pamiętaj, że to nie pochodzi tylko o osobowości tych ludzi. Często dochodzi do sytuacji w których są oni warunkowani do takiego sposobu pracy przez firmy w których pracują. Niektóre cross-funkcjonalne zespoły są czasami zmuszane do podziału na backend i front przez niemądrych managerów.

Riddle napisał(a):

Tylko pamiętaj, że to nie pochodzi tylko od osobowości tych ludzi. Często dochodzi do sytuacji w których są warunkowani do takiego sposobu pracy przez firmy w których pracują. Niektóre cross-funkcjonalne zespoły są czasami zmuszane do podziału na backend i front przez niemądrych managerów.

Może i tak, ale gdyby to tak bardzo przeszkadzało, to by dążyli do tego by to zmienić, jakoś. No bo to jednak dosyć wygodne, jeśli nie musisz się niczym interesować, nie musisz o nic się martwić poza wąziutką działeczką, a wypłata wpływa na konto i to niekoniecznie taka zła.

Co do frontu to tu akurat muszę się przyznać, że mam do niego dwie lewe ręce i unikam go jak ognia, UI/UX ogółem też, zresztą większość zespołów po 1-2 próbach odpuszczały, bo nie wiadomo było, kto był bardziej zażenowany efektami. Ale cała reszta - jak to mówią "żadnej pracy się nie boję".

superdurszlak napisał(a):

Riddle napisał(a):

Tylko pamiętaj, że to nie pochodzi tylko od osobowości tych ludzi. Często dochodzi do sytuacji w których są warunkowani do takiego sposobu pracy przez firmy w których pracują. Niektóre cross-funkcjonalne zespoły są czasami zmuszane do podziału na backend i front przez niemądrych managerów.

Może i tak, ale gdyby to tak bardzo przeszkadzało, to by dążyli do tego by to zmienić, jakoś. No bo to jednak dosyć wygodne, jeśli nie musisz się niczym interesować, nie musisz o nic się martwić poza wąziutką działeczką, a wypłata wpływa na konto i to niekoniecznie taka zła.

Chciałem zmienić sposób w jaki się pracuje w wielu korporacjach, i każdy kto również próbował powiedziałby Ci jak trudne to zadanie

superdurszlak napisał(a):

Co do frontu to tu akurat muszę się przyznać, że mam do niego dwie lewe ręce i unikam go jak ognia, UI/UX ogółem też, zresztą większość zespołów po 1-2 próbach odpuszczały, bo nie wiadomo było, kto był bardziej zażenowany efektami. Ale cała reszta - jak to mówią "żadnej pracy się nie boję".

No to z całym szacunkiem jaki mam do Ciebie, ale czy właśnie przez to nie jesteś trochę częścią problemu? Aplikacje potrzebują UI (chyba że tworzysz CLI), więc to jest tak samo ważny element delivery jak każdy inny.

Zgodzę się, że największym faktorem motywującym do zrobienia czegoś więcej, mimo, że boli to współpracowników jak o coś pytają i się odbijają, to jednak pieniądze.
Ja zostałem zatrudniony jako ogarniacz motywany przyszłością podwyżki - wiadomo jak to się skończyło. Dziś, robię tylko to co mam do zrobienia i tyle, nie obchodzą mnie cudze problemy.
Dobrze jest czuć się potrzebnym, ale mi te braki wynagradza rodzina, a nie kołchoz.