[karolwojciszko]

@karolwojciszko: Jak poprawić wydajność programisty? https://wojciszko.com/2017/11/13/jak-poprawic-wydajnosc-programisty/

Często mówi się o tym, że dany programista jest “niewydajny”. Pojęcie to jest nieostre – można je różnie zinterpretować, ktoś w organizacji A może być uważany za niewydajnego, natomiast w organizacji B może być najbardziej produktywnym programistą z całego zespołu. Często chodzi jedynie o relatywizm i percepcje. Tak jak wspominałem w poprzednich wpisach – uważam, że ludzie z natury nie są “źli”. Nikt nie przychodzi do pracy z myślą, co by tu dziś opóźnić/zepsuć – starają się pracować najlepiej jak potrafią. Zdarza się jednak, że środowisko projektowe temu nie sprzyja – dzisiaj właśnie będzie o tym.

#wojciszko #programowanie #programista15k #zarzadzanieprojektami #webdev #php #java #javascript

[Vetinari]

@karolwojciszko: Przeczytałem cały artykuł i nigdzie nie ma odpowiedzi na pytanie postawione w tytule. Na dodatek jest sporo pytań bez odpowiedzi, nie ma zdefiniowanej wydajności jako miary i informacji jak konkretne rzeczy wpływają na jej poprawę.

Za to tagów jest milion i totalnie niezwiązanych.

[karolwojciszko]

@Vetinari: Na samym początku wspominam o tym, że wydajność jest pojęciem nieostrym - chodzi o relatywizm. Jeśli chodzi o odpowiedź na tytułowe pytanie to oczywiście, że się znajduje - słowem klucz jest higiena projektowa

[Vetinari]

@karolwojciszko: Czyli nie da się liczyć wydajności według Ciebie?

[karolwojciszko]

@Vetinari: da się :)

[Kaczus2B]

@Vetinari: zależy od dziedziny... Jak masz do wykopania dół o odpowiednich rozmiarach, to da się policzyć w jakim czasie wykopie ten dół ktos pracowity, ktos leniwy i koparka i takie coś można porównywać. Gorzej jest przy pracach których trudno zmierzyć,, bo jak, ilość kodu? Czy może ilość poprawianych błędów?, No właśnie jak to określić, tu możemy co najwyżej czuć, że coś idzie odpowiednio szybko, albo niekoniecznie i to też może być

[karolwojciszko]

@Kaczus2B: true. Da się określić wydajność programistów jeśli wykonują bardzo podobne zadania. W praktyce rzadko się takie zdarzają, niektórzy błędnie mierzą wydajność przez liczbę zamkniętych zadań (lub sumę story points zamkniętych zadań). Co dąży do tego, że ludzie mnożą zadania (by zamknąć więcej) lub przeceniają ich trudność

[Kaczus2B]

Ale prawdą jest to co jest przedstawione w artykule, bardzo demotywuje, że coś jest niedookreślone, ale to jeszcze pół biedy, udajesz sie do osoby akceptującej, by dopytać się szczegółów, dostajesz odpowiedz "zrób tak by było dobrze, ufam ci, że będzie dobrze", ok, robisz pierwszą przybliżoną wersję, podsyłasz, brak jakiejkolwiek reakcji, więc ja realizujesz, kończysz projekt i dowiadujesz się, że no nie do końca o to chodziło, że wyobrażał sobie to inaczej, no

[Vetinari]

@Kaczus2B: Można to określić na przykład tak: ilość funkcjonalności na sprint (można im dać wagi). Wtedy poprawianie bugów nie jest "produktywne", bo nie dostarcza nic do produktu. Taki podział trochę ułatwia finansowe liczenie, bo z punktu widzenia klienta błędy są niepożądane.

[karolwojciszko]

@Kaczus2B: Bo żeby to dokładnie zaplanować to wymagany jest duży wysiłek - trzeba zrobić analizę przedwykonawczą. Ludzie nie wiedzą CZEGO CHCĄ, natomiast wiedzą CZEGO NIE CHCĄ. Czyli muszą zobaczyć twoją wersję, żeby wytknąć błędy - ogólnie temat rzeka - tutaj go opisałem gdybyś chciał: https://wojciszko.com/2017/05/15/zlecenie-na-prosta-stronke-10-minut-roboty/

[karolwojciszko]

@Vetinari: Pewnie zgodzisz się ze mną, że nadawanie "wagi" to bardzo subiektywna rzecz. Zależy od dnia i osoby - więc może być krzywdzące ( ͡° ͜ʖ ͡°)

[Kaczus2B]

@Vetinari: błedy dzielimy na bugi i błedy projektowe, to nie jest jednoznaczne, bo poprawiając bład projektowy często dajesz mu nową funkcjonalność. Przykład, spotkałem się z czymś takim, że listy słownikowe na każdy rok ktoś zrobił w kodzie, ja miałem wprowadzić poprawki dość znaczne w liście na aktualny rok. Co ciekawe, do tego otrzymywali zarówno ppoprzednicy jak i ja xml-a ze słownikiem i opisem jak i zakresem działania odpowiednich danych w każdym

[karolwojciszko]

@Kaczus2B: @Vetinari ja bym w ogóle nie łączył wydajności z błędami. Może zdarzyć się, że ktoś poprawia czyjeś błędy (nie jest to jego wina). Istnieją też sytuacje gdy ktoś pisze kod szybciej ale z błędami - pomimo to jest w stanie szybciej poprawić te błędy niż osoba pisząca wolniej ale z mniejszą ilością błędów - więc w tym przypadku ta pierwsza osoba powinna być uznana za "wydajniejszą"

[LiczbaPi]

@karolwojciszko: Miałem ten pech, że moja pierwsza firma miła niemal perfekcyjną higienę projektową. Milestone dla projektów rozpisane na 3-4 kwartały z góry, epic stories na min. kwartał z góry, same zadania z obszernymi kryteriami akceptacyjnymi na min. 1 sprint do przodu, do tego liczone i w miarę stabilne velocity. Regularne spotkania scrumowe na poziomie zespołów i projektów. Każdy wiedział co ma robić i co robią inni, gdzie się pojawiają problemy i

[karolwojciszko]

@LiczbaPi: Dzięki za twój komentarz. To pokazuje, że DA SIĘ planować. Jest to trudne, ale wykonalne. Poruszyłeś ważną kwestię - że ludzie byli zaangażowani w projekty i pomimo atrakcyjniejszych ofert nie zmieniali pracy

[Wyrewolwerowanyrewolwer]

Jak poprawić wydajność programisty?

@karolwojciszko: Zrezygnować z open-space i zrobić programistom normalne, ograniczone pokoje w których będą mogli przynajmniej minimalną prywatność.
Wpoić im do głów, że za pytanie nie grozi szubienica.
Tylko i aż tyle.

[karolwojciszko]

@Wyrewolwerowanyrewolwer: heh, u każdego coś innego jest problemem :)

[Wyrewolwerowanyrewolwer]

@karolwojciszko: Tak jeszcze sobie myślę, że kolejnym rakiem branży jest "Clean desk policy" które powoli wchodzi.

[karolwojciszko]

@Wyrewolwerowanyrewolwer: szczerze mówiąc nie słyszałem o tym, ale domyślam się czym to jest :)

[Wyrewolwerowanyrewolwer]

@vanquin: Mam na myśli to, że idealnie z założenia masz na biurku tylko monitory, klawiaturę i mysz. Opcjonalnie kubek z kawą, ale nic więcej. Przynajmniej z takim najczęściej się spotykam.
I ogólnie spoko bo niby poprawia produktywność i obniża liczbę zalanych klawiatur, ale wtedy to biurko jest tak w pełni bezosobowe, że aż słabo się przy nim pracuje.