Samotność programisty

Jak w temacie. Czy programować (z naciskiem na PROGRAMOWAĆ) można w ogóle zespołowo? Czy jest to czynność wymagająca bezwzględnego wyizolowania się z otoczenia i skupienia na problemie?

Zobaczmy jak to wygląda z zewnątrz. Są ogólne cele (roczne, kwartalne, whatever) i mamy zespoły. Zespół spotyka się co jakiś czas by podzielić pomiędzy siebie pracę, rozbić większe problemy na mniejsze - do ogarnięcia przez jedną osobę. Jeśli wszystkie osoby reprezentują tą samą prędkość pracy to problemu nie ma.

Ale rzadko tak bywa. Zazwyczaj idzie to mocno nierówno i lider zespołu bliżej terminu zaczyna mieszać przydzielając szybszych do maruderów (albo ich zastępując). I mimo tego praca dalej zwalnia, liderzy nie potrafią ogarnąć pracy maruderów i często grzęzną w zadaniu dłużej niż gdyby miał je dokończyć oryginalny autor. A jeśli pracują w parach to zaczynają się pojawiać problemy i tarcia interpersonalne.

Czy nie jest tak że w zespołach ignoruje się indywidualne cechy każdego programisty na rzecz podejścia zrównującego (wszyscy jesteście programistami więc możecie zaprogramować rozwiązanie dla każdego problemu)? Każdemu wciskają wzorce, dobre praktyki, nawet paradygmaty - lider lubi podejście funkcyjne, język X wspiera to podejście więc będziemy kodować w tym stylu. Nieważne że reszta zespołu dalej robi proceduralne OOP.

Powiemy sobie - zły lider. I ok. Ale co z sytuacją gdy decyzja jest koncyliacyjna, podział przebiega fifty-fifty i ostatecznie wszystko zależy od głosu wypalonego gościa który już podjął decyzję o ucieczce ale że lubi poeksperymentować to czemu nie?

I tak dochodzimy do kolejnego problemu - wypalenie. Które może wynikać z powyższego. Z pracy nad problemami których nie ogarniamy, z wymuszenia stylu w którym nie czujemy się naturalnie i ciągłego powtarzania za plecami że tak robią najlepsi więc i my tak musimy a jak nie potrafimy to się nadajemy. Ale w zasadzie dlaczego?

Kod który piszemy jest obrazem naszego podejścia do zadanego problemu (nawet powiem że wyobrażenia jakie o nim posiadamy). Większość problemów może być zaatakowana z wielu stron. I jeśli maszyna go wykonuje i dostarcza akceptowalne rezultaty to co złego wynika jeśli np. całość została napisana w C/C++ z wstawkami assemblerowymi?

Jeśli ktoś podniesie zarzut o utrzymanie czegoś takiego przez innych - ok. Ale szczerze, ile w karierze widzieliście nowych projektów gdzie pierwszym odruchem nie było napalmem to!? Albo założymy że wszyscy piszą ch*jowy kod a my jesteśmy wyjątkiem albo po prostu - styl projektu jest obcy naszym zwyczajom i przyzwyczajeniom. Mamy decyzję, możemy zostać i przekształcać to co zastaliśmy w naszym stylu albo poszukać czegoś co nam bardziej odpowiada.

Może zamiast zaklinać rzeczywistość naszej branży IT - przyznajmy po prostu: praca zespołowa w IT to mit. Programista jest samotny z problemami które rozwiązuje a styl w którym pisze implementację jest kompletnie indywidualny. Komunikacja (efektywna) pomiędzy ludźmi pracującymi nad cząstkowymi problemami czegoś większego jest niewielka i w zasadzie sprowadza się do uzgodnienia interfejsów komunikacji pomiędzy ich implementacjami.

Programista jest sam na sam z problemami które przed nim stoją. Żadne SCRUMy ani Agile tego nie zmieniają, co najwyżej ładnie zamaskują rzeczywistość.

loza_wykletych napisał(a):

Komunikacja (efektywna) pomiędzy ludźmi pracującymi nad cząstkowymi problemami czegoś większego jest niewielka

Osobiście nie zgadzam się z tym. Obecnie w moim zespole (a są sami doświadczeni programiści) najwięcej jest pytań co chcemy osiągnąć, aniżeli jak to zrobić (Wojtek Seliga kiedyś to fajnie opowiedział: ). Pracujemy w javie i co prawda nie wyobrażam sobie, że nagle ktoś będzie chciał jakąś funkcjonalność napisać w c++, ale tak szczerze, to nie bardzo razi mnie, czy coś tam jest zrobione builderem, fabryką czy konstruktorem. Oczywiście code review to ważna rzecz i warto trzymać się konwencji projektowych, żeby potem np szybko i sprawnie nawigować po całym projekcie. Ale szczerze przyznaję, że napisanie faktycznego kodu to jedynie mała część czasu - o wiele więcej schodzi na ustalanie wymagań i dyskusje. Okej, być może nasila to fakt, że projekt jest we wczesnej fazie.

Co do tytułu wątku oraz komunikacji - osobiście pracuję 100% zdalnie, więc w moim przypadku jest wskazane, aby na komunikację kłaść jeszcze większy nacisk (wszak tracę komunikację niewerbalną, która stanowi większość przekazu). I np rozmowy na Slacku z ludźmi z podobnej strefy czasowej są wręcz dla mnie obowiązkowe - współpraca z ludźmi ze stref czasowych oddalonych o około 10h jest fatalna - okej, ktoś powie komunikacja asynchroniczna - no super, zadam jedno pytanie, on mi odpowie na drugi dzień, i kolejne pytanie do tego co on odpowiedział, muszę zadać dopiero w kolejnym dniu. Wtedy się widzi, jak ważna jest komunikacja wewnątrzzespołowa.

Programista jest sam na sam z problemami które przed nim stoją. Żadne SCRUMy ani Agile tego nie zmieniają

SCRUM nie ma zabierać problemu od programisty. SCRUM ma właśnie zapobiec braku komunikacji - załóżmy, że dogadujesz się z "biznesem" co ma aplikacja robić, po pół roku oddajesz gotowy projekt a tu się okazuje, że jednak "biznesowi" co innego chodziło po głowie. I lipa.

co z sytuacją gdy decyzja jest koncyliacyjna, podział przebiega fifty-fifty i ostatecznie wszystko zależy od głosu wypalonego gościa który już podjął decyzję o ucieczce ale że lubi poeksperymentować to czemu nie?

Jak już wspomniałem, najważniejsza w projekcie (według mnie przynajmniej) jest konwencja - wolę średnie rozwiązanie które jest w całym projekcie, niż najlepsze praktyki programowania, jeśli w każdym module byłyby inne. A kto ma ostateczny głos? No cóż, zawsze będzie jakaś jedna osoba decyzyjna. Nawet jeśli oficjalnie nie, to w każdej grupie społecznej ktoś dowodzi - jeśli nie ma lidera, to albo ktoś automatycznie sam poczuwa się do bycia osobą decydującą, albo grupa społeczna się rozpada. Taka osoba decyzyjna ma odpowiedzialność za projekt - jeśli się nie powiedzie, to w najlepszym wypadku zostanie owiany złą sławą.

Trochę się rozpisałem :) ale musiałem z siebie do wydusić

Firmy nie mogą sobie na to pozwolić, bo ich na to nie stać:

1. Projekt może być tworzony wolniej, i tempo jego powstawania będzie w pełni zależne od tego w czym najsłabiej czuje się wybrany programista. Czyli z jednej strony potrzebujesz kogoś wszechstronnego, z drugiej żeby był rzeczywiście dobry w tym co robi i żeby potrafił w miarę szybko uzupełniać braki i uczyć sie nowych rzeczy.

2. Czyli szukamy kogoś pro, ale mamy też dodatkowe wymagania, zobacz: rzadko się zdarza, aby ktoś był zdolny albo bardzo pracowity, a jeszcze rzadziej by był zdolny i pracowity. By ciągnąć projekty do przodu trzeba wtedy robić jak wół inaczej projekt będzie miał ślimaczne tempo, z drugiej strony potrzebne jest doświadczenie, by umieć patrzeć na kod z wielu płaszczyzn. Poza tym czy ktoś normalny pozwoliłby wyciskać się jak cytrynę, czy ktoś normalny ot tak poświęciłby zdrowie dla pensji? Myślę, że tak - ale to zależy o jakich kwotach mówimy. Ja mogę zasuwać, ale po drugiej stronie mam nieziemskie oczekiwania wobec tego co chcę tą pracą osiągnąć. Wątpie, by inne firmy byłoby stać na takie układy.

PS, tylko pomyśl jak gigantyczna przepaść dzieli firmy, a możliwy do wykorzystania przez programistę potencjał :-D

najważniejsza w projekcie (według mnie przynajmniej) jest konwencja - wolę średnie rozwiązanie które jest w całym projekcie, niż najlepsze praktyki programowania, jeśli w każdym module byłyby inne

Nie mogę się z tym zgodzić. Konwencja to najczęściej jedynie poziom estetyki. Programiści uwielbiają się kłócić o takie pierdoły jak wcięcia czy kolejność importów, ale to w sumie nie ma tak dużego znaczenia. Nawet jeżeli na tym poziomie jest nieco niespójnie, to tragedii nie ma.

Duże znaczenie ma struktura projektu i sensowne abstrakcje. Jeżeli coś ma dobrą strukturę, tzn. nie trzeba czytać całości aby zrozumieć jak coś dziala, to styl jest kwestią drugorzędną. Wolę mieć w połowie projektu dobry kod funkcyjny a w drugiej dobry kod imperatywy niż wszędzie równo spartolone spaghetti obiektowe utrzymane w jednej konwencji.

Krolik napisał(a):

Jeżeli coś ma dobrą strukturę, tzn. nie trzeba czytać całości aby zrozumieć jak coś dziala, to styl jest kwestią drugorzędną. Wolę mieć w połowie projektu dobry kod funkcyjny a w drugiej dobry kod imperatywy niż wszędzie równo spartolone spaghetti obiektowe utrzymane w jednej konwencji.

Właśnie o dobrą strukturę mi chodziło. A właściwie o konwencję w strukturze - bo nawet jeśli wszędzie jest "spartolone spaghetti obiektowe", to jeśli jest w jakiejś tam wspólnej konwencji, to sorry, ale brutalna prawda jest taka, że wtedy nawet można wiedzieć od razu co autor miał na myśli - nawet, jeśli bez żadnego kontekstu projektowego, ktoś oceniłby ten kod na kupę g##na. Więc jeśli jest zgrany zespół piszący średniawy kod, to łatwo się w nim odnaleźć. Okej - nowy członek zespołu nie będzie wiedział o co chodzi w kodzie. Ale prawda też jest taka, że niezależnie od tego jak pisany jest projekt, to na początku wszystko wydaje się być czarną magią. Wystarczy zobaczyć mechanizmy działania klas i jeżeli z grubsza projekt jest napisany spójnie, to nawet jeśli byłaby to spójność g##na, to będzie dobrze :D

Dodam jeszcze jedną uwagę, której za bardzo nie widać między firmami a solo programistą.

Gdy programista w firmie wykonuje zadania to on jest zorientowany na taski. Często jest tak, że sobie dziubie, coś robi, przyjmuje kolejny task i robi i robi i robi. I ten programista ostatecznie tworzy, ale jego efekt uboczny jest taki, że działa źle na system (nie wiedząc o tym), ponieważ pisze kod na wielu warstwach nie wiedząc o żadnej szczególnie wiele, a nawet gdyby mógł myśleć to zmiany jakie chciałby wnieść byłby trudniejsze do wdrożenia, bo inni programiści też tak samo jak on obłędnie skaczą po warstwach realizując swoje taski.

Inaczej jest gdy piszesz projekt w mniejszym gronie. Wtedy nie ma ciśnienia, by wszystkich programistów eksploatować po 100% możliwości czasowych. Wtedy możesz budować soft warstwami i możesz wiele rzeczy uspójnić, a nawet uprościć, dzięki czemu końcowe rozwiązanie uzyska prostszy stan i mniej złożony przepływ.

O każdym sporcie drużynowym możesz powiedzieć, że tak naprawdę jest indywidualny bo na koniec dnia każdy musi indywidualnie odbyć swój trening i jeżeli doznasz kontuzji to nikt za ciebie nie przejdzie operacji i rehabilitacji, jesteś z tym sam.

W piłce nożnej mówi się, że drużyna jest tak silna jak jej najsłabszy gracz. Czy w IT jest podobnie? Raczej nie, najbardziej wartościowy programista w zespole pierwszy widzi pewne problemy i pierwszy wychodzi z inicjatywą jak je rozwiązać. Liderem możesz zostać na wiele sposobów, niekoniecznie musisz być najlepszym programistą w zespole. Co z tego, że jesteś lepszy niż lider w jednej dziedzinie, lub nawet wielu skoro lider jest dużo bardziej zasłużony? Jeżeli chcesz, żeby zespół wyglądał tak jak ty tego chcesz to musisz założyć nowy team. Z drugiej strony, tak samo jak na boisku może być wielu liderów w różnych formacjach, tak samo może być lider od frontendu, backendu, QA, devops i wielu innych dziedzin. Możesz znaleźć swoją niszę i ją kreować według swoich wartości dzielenia się wiedzą wśród małej grupy twoich współpracowników.

Ja spotkałem wielu ludzi, którzy dzielili się swoją wiedzą, spotkałem też takich, którzy wiedzą nie dzielili się z premedytacją oraz takich którzy oczekiwali, że inni będą się dzielili z nimi, a sami się wiedzą nie dzielili. Pamiętaj, że sam kreujesz kulturę pracy swojego zespołu.

Krolik napisał(a):

Duże znaczenie ma struktura projektu i sensowne abstrakcje. Jeżeli coś ma dobrą strukturę, tzn. nie trzeba czytać całości aby zrozumieć jak coś dziala, to styl jest kwestią drugorzędną. Wolę mieć w połowie projektu dobry kod funkcyjny a w drugiej dobry kod imperatywy niż wszędzie równo spartolone spaghetti obiektowe utrzymane w jednej konwencji.

Dokładnie - czy spartolone spaghetti obiektowe w różnych modułach propaguje się na inne? Weźmy np. podejście unixowe - jeden problem, jeden program (w ideale). Programy można łączyć pipelinem i wyczyniać cuda. Nikt nie dba (poza autorami) w czym i jak jest napisany program - o ile zwraca poprawne wyniki dla zadanych parametrów.

W czym się różni to od sensownej abstrakcji? W czym się to różni od hype'owanych mikroserwisów? To że powodów wydajnościowych wygrało kiedyś podejście one binary to rule them all to nie znaczy że dziś w w wielordzeniowej architekturze, stare podejście uniksowe nie ma więcej sensu.

twoj_stary_pijany napisał(a):

W piłce nożnej mówi się, że drużyna jest tak silna jak jej najsłabszy gracz. Czy w IT jest podobnie? Raczej nie, najbardziej wartościowy programista w zespole pierwszy widzi pewne problemy i pierwszy wychodzi z inicjatywą jak je rozwiązać.

To chyba zadanie analityka (z głębokim backgroundem programistycznym). Ale nawet jeśli kto widzi problem i jego rozwiązanie to nie implikuje że przy delegowaniu tego innej osobie ten problem zostanie rozwiązany tak jak sobie życzył. Bo wyobrażenie rozwiązania a implementacja w kodzie to dwie osobne rzeczy które są trywialne dla jednej osoby ale dla dwóch osób już nie bardzo.