W dniu niedziela, 20 stycznia 2019 21:54:04 UTC+1 użytkownik Queequeg napisał:
> Sebastian Biały <h...@p...onet.pl> wrote:
>
> > Nigdzie nie pracujesz. Nikt by z tobą nie wytrzymał nawet minuty w
> > jednym zespole.
>
> Gorzej jeśli takie osoby, jak ten przygłup, są narzucane z góry poprzez
> znajomości...
>
> W dwóch firmach, w których pracowałem, właśnie takie wciskanie na siłę
> osobników, które zdecydowanie nie powinny nigdy mieć nic wspólnego z
> pracą, do której zostały przydzielone, skończyło się odejściem najbardziej
> wartościowych jednostek (które bez problemu znalazły inną pracę).
>
> Jeszcze osobna sprawa to to, że gdy rekrutowałem programistów do swojego
> zespołu to poziom ludzi, którzy przychodzili na rozmowy, autentycznie mnie
> przerażał. Nie chodzi o to, że nie znali niuansów języka -- tego zawsze
> można się nauczyć -- ale większość z nich autentycznie nie potrafiła
> myśleć.
>
urocza historyjka ze swiata chorych na łeb prymitywow (klasyka w swoim oblesnym
gatunku)

do góry

On 20/01/2019 21:49, Queequeg wrote:
>> Moja obserwacja jest odwrotna. Czasem trzeba poprawiać po domorosłych
>> hackerach.
> Tzn. kod, z którego nie wynika jasno, co autor miał na myśli, bo autor
> myśli, że jest zdolniejszy, niż faktycznie jest i stosuje sztuczki, które
> zaciemniają kod?

Domorośli hackerzy mają tendencję nie do pisania wydajnie, sprytnie itd.
Mają tendencję do pręzenia mięśni intelektualnych *specjalnie* generując
kod który jest upierdliwy albo przy czytaniu albo refaktorowaniu tak aby
każdy widział że ma do czynienia z hackerem. Skutki są oczywiście
odwrotne, każdy widzi że ma do czynienia z pierdołą. To troche jak
wychodzenie na spacer z amstaffem, od razu widać coś zupełnie odwrotnego
niż się imaginuje właścicielowi. Hackerzy nie nadają się do pisania
niczego poza duperelowatym kodem. Ich rozumienie pojęc projektowania,
testowania, abstrakcji itp jest znikome i wręcz alergiczne. Hacker
będzie miał tendencję do wciskania wszędzie zoptymalizowanych wersji i
unikania abstrakcji ignorując fakt że kompilatory zrobią tą
optymalizację za niego a abstrakcji już nie.

Prosty przykład z szarej rzeczywistości programisty: jest sobie pewna
klasa specjalizowana może pięcioma typami. Jeden z nich nie zadziałał
poprawnie (samoczynnie zdejmuje się const w wyniku buga w VS). Domorosły
hacker napisał cztery ekrany elaboratu dlaczego ma rację powołując się
na detaliczne punkty standardu i kilkanaście klas które obchodzą problem
bokiem aby wyszło na jego. Prawidłowe rozwiązanie wymagało pozbycia się
szablonu i dodaniu dwóch linijek dodatkowego kodu którego nie ma i tak w
release bo to był tylko do debugu.

Problem z hackerami polega na tym że mają za duże ego i za wielkie
pojęcie o swoich umiejętnościach oraz nie potrafią pracować w grupie.
Kod z gatunku foo( (*it++) || ++it==end, *it) leci od razu do śmieci jak
tylko go napotkam, śmierdzi na kilometr i jest bez znaczenia czy działa.

> jakości, który działa w sumie tylko przez przypadek (a często nie działa
> wcale i trzeba łatać i obchodzić coś, co nie my zepsuliśmy).

Od tego sa testy.

> Problem jest taki, że dostarczają nam to inne działy, nad którymi nie mamy
> żadnej kontroli.

Nie ma testów, nie ma kodu. Kwestia wyjaśnienia to kierownictwu.

do góry

Sebastian Biały <h...@p...onet.pl> wrote:

> Domorośli hackerzy mają tendencję nie do pisania wydajnie, sprytnie itd.
> Mają tendencję do pręzenia mięśni intelektualnych *specjalnie* generując
> kod który jest upierdliwy albo przy czytaniu albo refaktorowaniu tak aby
> każdy widział że ma do czynienia z hackerem.

Tak, to prawda. U nas na szczęście takich nie ma.

> Hacker będzie miał tendencję do wciskania wszędzie zoptymalizowanych
> wersji i unikania abstrakcji ignorując fakt że kompilatory zrobią tą
> optymalizację za niego a abstrakcji już nie.

To też prawda.

Tzn. nie ma nic złego w zabawie językiem -- dopóki jest to tylko zabawa,
poza pracą.

> Kod z gatunku foo( (*it++) || ++it==end, *it) leci od razu do śmieci jak
> tylko go napotkam, śmierdzi na kilometr i jest bez znaczenia czy działa.

Słusznie. Kod jest przede wszystkim dla człowieka, więc ma być czytelny.
Kompilator zoptymalizuje sobie go po swojemu.

>> jakości, który działa w sumie tylko przez przypadek (a często nie działa
>> wcale i trzeba łatać i obchodzić coś, co nie my zepsuliśmy).
>
> Od tego sa testy.

Teoretycznie tak. Praktyka mija się z teorią. Pomijając, że testerów u nas
ostatnio zwalniają (cięcie kosztów, czyt. małpa z brzytwą).

>> Problem jest taki, że dostarczają nam to inne działy, nad którymi nie mamy
>> żadnej kontroli.
>
> Nie ma testów, nie ma kodu. Kwestia wyjaśnienia to kierownictwu.

Bezpośrednie kierownictwo wie, zgadza się i robi wszystko, żebyśmy jednak
cokolwiek byli w stanie dowieźć. Kierownictwo nad nim niestety żyje w
swojej własnej bańce. Im wyżej, tym większy poziom oderwania od
rzeczywistości.

Takie korporealia...

--
https://www.youtube.com/watch?v=9lSzL1DqQn0

do góry