RUDOLF: jak kde a jak v cem. U nas se treba naklady dost hlidaj, je to rozpoctovany per service, coz muze byt klidne tym nebo pultym. A produktaci maj KPI ve stylu "chci aby se feature X pouzivala o Y% vic", u cehoz je samozrejme to, ze za featuru se plati nebo, v pripade nasi divize, se tim zvysuje bezpecnost klientu, coz minimalne dobre vypada :)
My jsme teda korporat nejkorporatovejsi, takze jsem rad i za malo ;)

Mě v korporátu překvapilo, že se jede spíš projekt management (kterému se říká produkt management) a úplně chybí product ownership. Ale člověk si časem uvědomí, že místní produkťáci začali na univerzitě, nikdy si neprošli realitou, kdy museli vymyslet capabilitu, který se skutečně někomu hodí natolik, že je za ní ochotný platit. Místo toho vyrůstali v tom, že musí udělat prezentaci další management vrstvě, hodit na engineering nějakou capability, jejíž užitečné jádro se ztratilo v tiché poště, když se to sbíralo od uživatelů, který si některý management snažší udržovat daleko o týmu, který by jim mohl dodat něco užitečného. Celý je to skutečně pracovně organizační problém. Za zdroj považuji nejasný KPI. Ve firmě, pokud je dobrý datový insight, je možný pozorovat změn na příjem peněz, používají aplikací. V korporátu chybí jak měřit úspech. Počet uživatelů/projektů neříká jaká hodnota je tam pro korporát. Nedej bože, že máš platformu, kde si uživatel vytvoří compute za tisíce dolarů a nikdo netuší, jestli je to úžitečný nebo ne. Protože vlastnictví nákladů třeba u nás, nejde za projektem ale za platformou. Takže my musíme hlídat, jestli děcka nedělají blbosti. A z druhý strany, jejich rodiče, nám nechtějí říct, jestli se děcka se vůbec snaží o něco užitečného. Já osobně vidím celkem schopný lidi, který se to snaží proměnit, dokonce mají podporu ze zhora. Ale korporát je tanker, který mění trajektorii ale oproti small-business jachtě je to úplně jiný feeling.

KOJA: Jo. Stinna stranka je, ze kdyby nabirali lidi, co jim nevadi se s nekym bavit, byl bych bez prace.

KOJA: Prece bys pri naboru nechtel u lidi testovat schopnosti, ktere pak budou realne pouzivat, to by se zhroutilo nekolik oboru :)

KOJA: to bych řekl že je nepochopení problémů. Ten organizační problém je často o tom že necháš dělat lidi věci ke kterým nejsou kompetentní. Pak autisti navrhují UI místo aby zůstali u těch grafových algoritmů.

ALMAD: A presne proto je idealni kdyz firma nabira autisty co z rukavu vysypou na whiteboard libovolnej grafovej algoritmus ale maj nocni mury z toho, ze by se s nekym museli bavit

QWWERTY: Prace v korporatu mi dala poznani, ze kazdy technicky problem je ve skutecnosti lidsky a organizacni problem…a nihilismus.

FARIN: je to takovy "down the rabbit hole", kdy cim vic do toho zapadnes, tim vic misto technickych problemu skoncis ve vnitrofiremni politice
amici nasrany ze samotneho outsourcingu
lidi snazici se doklepat tech par let do duchodu
lidi snazici si udrzet vlastni praci ve vlnach layoffu, kdy firma vyhodila 100k+ lidi
manazeri snazici se udrzet status quo, at uz z vlastni lenosti, nebo ze strachu z nadrizenych
lidi predstirajici ochotu a pomoc, jenom aby meli interni info a pak ti hazeli klacky pod nohy

oproti tomu je nejaka pomala webovka easy problem, ktery se eventualne opatchoval
kdyz jsme se po letech dozvedeli, jak vlastne ten tool vznikl, za jakych podminek, etc... tak se ani tomu vyvojari nedivim, ze to bral jako prilezitost, jak se toho zbavit a hodit to na nekoho jinyho

QWWERTY: :-)
Kamarad a kolega je jeden z "founding commiters" Eclipse. Jeho oblibena historka je, ze po zverejneni Eclipse (pry docela hekticke obdobi) prisel prvni patch od cloveka zvenku, Hned bezeli za Steve "this-code-is-crap" Northover ktery, aniz by se na patch podival, prohlasil: "If this patch is any good, I'll jump, revolve three times, fart and drop down dead."

QWWERTY: to musi být radost dělat s takovyma lidma

TOOMIX: nas interni system ma jednoduchy ukol - na zaklade parametru udelat query do databaze a zobrazit nam jako uzivatelum formatovanou tabulku (a z nekterych sloupcu slepit odkazy, etc..)
spooooustu let v kodu byl while loop a z te databaze tahal vysledek query po jednom radku. query, dopln html table radek na frontend, query....
jak se tahalo vic jak 1000 zaznamu tak mohl jit clovek na kafe, ktere jsi pil zatim co jsi se koukal, jak se HTML tabulka vykresluje radek po radku, rychlosti jako kdyby jsi ji tahal pres 9600baud RS232

a nas "hlavni a jediny vyvojar" nam tehdy rekl, ze s nama bude rad spolupracovat, ale jestli doplnime do toho webu jediny radek naseho kodu, tak nas tym prebira za ten jeho mrdnik celou zodpovednost a veskera budouci udrzba pada na nasi hlavu

TOOMIX: Pan je boomer a pouziva databaze s transakcema, takhle se to AI webscale neudela /s

Stary, ale furt platny: https://www.youtube.com/watch?v=b2F-DItXtZs

Uplne libova byla springboot aplikace, ktera mela konfiguraci ulozenou v databazi a kazdej parametr tahala pri startu zvlast. Kdyby to nebylo smutny, bylo by to smesny.

AI je v tomhle alespon normalni a zakladni navrh dela v poradku

SUCHRE: normálně otevřu transakci a začnu to tam hrnout najednou. Když to někde padne na hubu, tak rollback, jinak commit. Co záznam to transakce udělá leda tak nějaký junior ne?

AI umi navrhnout REST API, kde se s pri insertu 10 polozek do databaze nedela 10 transakci. To doted polovina vyvojaru nepochopila a absolutne ani netusi, kde a proc je to problem. Pokrocilejsi delaji tu hruzu aspon na strane serveru, vykonnostne prijatelny mass insert/merge/update/delete zvlada jeden ze sta.