On 05/02/2013 10:12, Maciej Sobczak wrote:
> W dniu wtorek, 5 lutego 2013 00:12:12 UTC+1 użytkownik Andrzej
> Jarzabek napisał:
>
>> Pytanie nie jaki zbiór można ogarnąć, tylko jakim kosztem. Każdy
>> dodatkowy język wiąże się z dodatkowymi kosztami.
>
> Jest też komplementarne pytanie, jakie są koszty nie-ogarnięcia.

Oczywiście, przecież to jest punkt wyjścia do dyskusji.

>> Co jednak, jeśli z refleksji wychodzi co innego niż z liczenia
>> checkboksów?
>
> Z refleksji wynika lista checkboksów a z tej listy konkretne
> rozwiązanie problemu.

Więc liczenie wydaje mi się zbędnym etapem, bo jeśli z refleksji i z
liczenia wynikają sprzeczne wnioski, to słusznym wnioskiem będzie ten z
refleksji.

>> W praktyce w skali zespołu zawsze będziesz miał ograniczenie
>> polegające na tym, że rekrutowani byli ludzie z określonymi
>> umiejętnościami.
>
> "Oczekujemy gotowości do zdobywania nowych umiejętności i poszerzania
> swoich kwalifikacji."
>
> Jeżeli masz ludzi, którzy nie chcą się rozwijać, to nie będą. Pomyśl
> o tym już w czasie ich zatrudniania.

Ale też rozwijać można się w bardzo różnych kierunkach. Jako javowiec
możesz spokojnie rozwijać się w kierunkach, w których zalety Scali nigdy
nie wypłyną: TDD, refaktoryzacja, design patterns, Spring, CI, cotamjeszcze.

>>> Konflikt wygląda tak:
>>> "Panowie, no weźcie zróbcie coś, żeby tych bugów tyle nie było."
>> U was w firmie programiści chcą, żeby bugi były?
>
> Nie chcą.

No to nie w tym jest konflikt.

Konflikt przejawia się np. tym, że w twojej metodzie checkboksowej
pracodawca wpisałby checkboska "trudniej będzie wymieniać programistów"
po stronie wad, natomiast programista mógłby go wpisać po stronie zalet.

>>> "Oferujemy możliwość pracy z najnowszymi technologiami."
>> Być może, ale to przecież nie znaczy, że każdy dobór najnowszej
>> czy dobrej technologii ma sens w każdym projekcie.
>
> Niczego takiego nie pisałem.

Dyskutujesz z moją dygresją, że może nie należy pozwolić programiście
wybierać technologii, bo programista może wybrać to, co go osobiście
interesuje (jest cool, modne), a nie to, co jest dobre dla projektu.

>> Tak więc teoretycznie może zaistnieć sytuacja, kiedy programista,
>> któremu pozostawiono w tej kwestii wolną rękę,
>
> To kto ma mieć wolną rękę? Sprzątaczka?

Nie wiem, kto ma mieć, raczej jest to złożony problem, na który trudno
dać odpowiedź abstrahując od konkretnego projektu i firmy. Natomiast
zauważę, że w wielu instytucjach takie decyzje podejmuje się na
jakichśtam stanowiskach kierowniczych typu "head of development" czy CTO.

>>> Tak. Dobry wybór technologii nie stoi w sprzeczności z tym
>>> celem.
>> Zależy jak rozumie się "dobry".
>
> Tak, żeby było "lepiej". Celem refleksji jest określenie, co to
> oznacza. Dla różnych branż, firm i projektów to mogą być różne
> rzeczy.

Cały czas jednak problem w konflikcie interesów - po refleksji dla
pracownika dobre może być co innego niż dla pracodawcy.

>> * Kandydaci owszem, chętnie się nauczą Scali, ale póki co jej nie
>> znają. Zanim się zapoznają minie ileś tam czasu, w którym to czasie
>> będą mniej produktywni.
>
> Kandydaci i tak nie są produktywni przez początkowy okres czasu.

Ale im dłużej nie są praduktywni, tym gorzej. Koniczeność nauki nowych
języków, czy co gorsza całych paradygmatów programowania, sprawę tylko
pogarsza.

>> * Jeśli zdecydujesz się zatrudnić ludzi, którzy nie znają ani
>> Scali, ani odpowiednich technik, to ryzykujesz, że się ich nie będą
>> w stanie nauczyć.
>
> Tak. Wtedy będą robić mniej ciekawe rzeczy w mniej wartościowym
> projekcie. Nie widzę problemu.

Ale rekrutujesz, bo potrzebujesz programistów do tego akurat projektu.

>> Możesz powiedzieć, że tak czy inaczej starasz się zatrudnić tych
>> kumatych, ale wszystko jest kwestią skali (no pun intended).
>
> Tak. Ale zależnie od skali inaczej będę też podchodził do rekrutacji.
> Masowy projekt zwykle prowadzi do masowej rekrutacji - i masowych
> efektów.

Nie chodziło o wielkość projektu, tylko o skalę kumatości, której
wymagasz. To, że lepiej zatrudniać kumatych nie znaczy, że nie możesz
strzelić sobie w stopę stawiając poprzeczkę zbyt wysoko (bo np. nikogo
aż tak kumatego nie uda ci się znaleźć).