On 14/03/2012 16:26, Wojciech Jaczewski wrote:
>>
>>> gdyby wszyscy się zwolnili, bo management nie
>>> pozwala robić bezpiecznych produktów,
>>
>> I gdzie by poszli? Do innej firmy, która *też* nie pozwala? To jest
>> właśnie powód, dla którego nie odejdą.
>
> Nie odejdą, bo boją się zmian. Albo nie odejdą, bo za bardzo cenią sobie
> pieniądze, których po odejściu prawdopodobnie zarobią mniej.

Niekoniecznie przecież. Ja bym się raczej spodziewał, że wielu ludzi nie
odchodzi, bo nie mają odpowiednich umiejętności lub po prostu nie zdają
sobie sprawy na czym polega inne podejście.

Na dzień dobry przecież nie ma w tym nic nieracjonalnego: jeśli
popełniasz błędy, przez te błędy produkt, który wytwarzasz ma defekty,
ale pracodawca jest "wyrozumiały" i nie szykanuje cię na ogół żadnymi
konsekwencjami z tego powodu, to dlaczego chciałbyś zmienić pracę na
taką, gdzie wiesz, że kładą duży nacisk na to, żeby defektów nie było?

No i oczywiście przy decyzji o wyborze czy zmiany pracy mają znaczenie
też czynniki powiedzmy pozamerytoryczne: lokalizacja, godziny, względy
towarzyskie i tak dalej.

Oczywiście można też podejść do sprawy pryncypialnie, zgodnie z radą
Martina Fowlera "if you can't change your organisation, change your
organisation". Możliwości, wydaje się, istnieją, i też wydaje mi się, że
ludzie, którzy tak działają, często wychodzą na tym dobrze - kwestia czy
się jest ewentualnie skłonnym do pewnych poświęceń żeby to osiągnąć.

>>> Usprawiedliwia się ludzi: "nie ma na to wpływu",
>>
>> A ma wpływ?
>
> To jest obojętne, czy ma wpływ czy go nie ma. Skoro wie jak firma
> funkcjonuje, nie próbuje tego zmienić, a po ewentualnym ocenieniu że nie ma
> wpływu - nie zwalnia się - to znaczy, że akceptuje ten model funkcjonowania.
> I to, że nie miał wpływu, nie jest żadnym usprawiedliwieniem.

W takim modelu, gdzie za jakość produktu odpowiada wyłącznie
przedsiębiorca, nie ma się nawet z czego usprawiedliwiać.

Oczywiście z drugiej strony prawda jest taka, że programista ma zawsze
jakiśtam wpływ na jakość prroduktu - nawet jeśli ten wpływ jest
niewielki, to z punktu widzenia powiedzmy etyki zawodowej jest OK jeśli
produkujesz dobry kod i poprawiasz błędy w napotkanym złym kodzie, jeśli
tylko tyle możesz zrobić. Nawet jeśli twój wpływ na ostateczną jakość
produktu jest niewielki, to ostatecznie lepiej zrobić tyle, ile można
zrobić, niż nie zrobić nic.

Dodatkowo łatwo nie docenić swojego faktycznego wpływu na organizację:
nawet jeśli się nie ma możliwości zarządzania zmian, to nie znaczy, że
inni nie widzą co robisz i nie ma to na nich wpływu - czasem przecież
będzie tak, że wielu osobom faktycznie przeszkadza to, że odwalają
kaszanę, ale wpadają w groupthink "nie ma czasu zrobić porządnie, bo
termin" - w takim przypadku nawet jedna osoba, która się wyłamie, może
dać przykład innym.

> W sumie może niepotrzebnie w ogóle na ten temat napisałem, bo jest to poza
> tematyką tej grupy... Kwestia priorytetów, którymi kierujemy się w życiu.
> Dla jednego zasady będą ważniejsze niż własne życie, dla drugiego nie ma
> żadnych zasad, byle tylko żyło się jak najprzyjemniej, dla większości -
> różne punkty pomiędzy tymi dwoma skrajnościami.

Według mnie jak najbardziej w tematyce grupy.
Filmik do obejrzenia i przemyślenia w tym temacie:
http://www.infoq.com/presentations/Robert-C.-Martin-
Bad-Code