DEFILA: Taky jsem o tom přemýšlel, ale vidím tam rizika :
1) prgoši tě mezi sebe už nepřijmou, už myslíš jinak
2) budeš na tu pozici drahý
3) nemysli ti to už tak jako čerstvým absolventům
4) stejně časem ti to nedá a začneš ty věci organizovat
5) začne ti vadit ten bullshit co padá seshora a budeš mít míň možností to nějak ovlivnit
6) zjistíš že na učení dalšího hype frameworku se už můžeš vlastně vysrat
7) budeš "divný" a "podezřelý" pro HR a podobná individua
...

No prostě ačkoliv mě to taky láká, zase zpátky dělat víc technické věci, tak si to nějak neumím představit...

Lepší je asi jít jako kontraktor a pást si pár firem. Ale to je zase jiná story...

DEFILA:
DAVIDOWITCH: taky si myslím, že management má je spíš přechod na jinou linii než směrem k vyšší senioritě - všichni ti projekťáci, produkťáci, department leadeři a já nevím, kolik mgmnt vůbec mi rozkazuje, nejsou ani omylem technický lidi, nikdy nedělali programátora, ani jinýho IT dělníka a přesto úkolují programátory, analytiky, testery atp.

DEFILA: Takova mozna trochu derailing otazka, ale nemate moznost karierniho kroku stranou spis nez kroku dolu? My mame Individual Contributor track kterej jde se senioritou az nekam do nebes. Senior Distinguished Researcher je max co sem zatim potkal, typek co u firmy zacal cca v dobe kdy sem sel na stredni. A presto neni manazer, formalne ma nad sebou asi tri lidi, ale v realu si dela co chce s kym chce a rozhodne lidi nevede (kdyz se mu nekdo nelibi, tak si ho priste na projekt neprizve, mozna se nekde zmini, ale nemusi ho managovat)

ALMAD: Presne proto mam radsi prototypovani nez stravit dlouhej cas whiteboard designem. Vetsina veci co sem po sobe nechal v predchozim zamestnani byla ve verzi 2 az 3

MLEKAR_STEIN: Tak záleží jak moc máš smůlu a kdy narazíš na nějaký tvrdý limit toho frameworku. Ted dělám na produktu, kterej byl tři čtvrtě roku psanej na Faust framework (Kafka/python), aby se pak ukázalo, že to hlavní (horizontální škálování) v tom frameworku v podstatě nefunguje a pak se většina appky přepisovala, abychom se toho zbavili.

MLEKAR_STEIN: Moje zkusenost je, ze prepisy jsou kosmicky jednodussi, pokud ma ta vec dobre navrzeny a srozumitelny interfacy (at uz APIs knihoven, nebo nejaky sitovy service APIs).

Bohuzel teda typicky clovek zjisti jak je spravne navrhnout az po tom co to napise, a aby to udelal dobre tak by to vlastne musel prepsat do v2 a…ohwell.

MLEKAR_STEIN: bez frameworku se to dneska IMO neda. Ale snazime se vybirat neco, co neni prilis specificke a nepouzivame ho uplne na dren (konkretne ted jedeme Kotlin + Micronaut a dovedu si predstavit, ze migrace na Spring nebo Quarkus by nebyla zas tak tezka, snazime se pouzivat spis primocare DI a nezabredavat do nejakych prilis chytrych vychytavek).

me prijde, ze se s technickym dluhem neda nic moc delat. i kdyz to na zacatku je dobry, a ani se to moc nezprasi, tak to stejne bude za par let nic moc.
treba jednoduche zalohovaci scripty. Kdysi jsem si napsal zalohovaci scripty. Byly blbe napsany, protoze jsem shell neumel a nedaly se konfigurovat a nemel jsem na to cas atd. Casem jsem si uskubl cas z jinejch veci a postupne je prepsal. daly se nejak konfigurovat, byly i o neco lepe naspane. ale stejne, kdyz jsem se do nich po par letech podival, tak nebyly proste dobre. musely se trochu prepsat. tentokrat uz jsem na tom netravil moc casu. proste jsem tam pridal nejakoou blbost, co jsem poterboval a hotovo.
co mi prislo jako zasadni, ze jsem si pri prepisu pomerne dobre definoval, co to teda ma delat. melo to nejak smysluplnou konfiguraci a nejak definovany vystupy, jako ze co ma logovat a kam, jak ma v konfiguraci vypadat popis odkud se zalohuje a kam se zalohuje. a dokud tohle je vice mene stejne, tak to docela jde.
no a protoze to porad stejne neni, tak mam takovejch zalohovacich veci napsanejch vicero. vice mene si jsou podobny :)
ale nejsem schopnej udelat neco, co by se dalo nazvat obecne produktem a nejak obecne pouzivat. :)

KOJA: k tomuhle pocinu me dohnaly jiz zmineny faktory + vyuzil sem tak trochu toho, ze sem byl jedinej core programator kterej si moh tak trochu dupnout... Spis sem tohle rozhdnuti uvadel proto, ze se do takovyhle souhry asi uz nedostanu... Dalsi vec je to, ze puvodni kod byl jinak docela pruhlednej, plno veci bylo tak trochu copy/paste, takze sem uz dopredu vedel ze me necekaj naky extra pasti.
v nasledujicim zamestnani uz sem podobnej zamer viditelne brzdil jako clen tymu (prestoze sem patril spis k "diverzantsky" casti), protoze sem si byl vedomej komplexity celyho projektu, bylo to vseobecne velky sousto a nebyl si jistej zda bysme byli schopni se dohodnout na finalni forme.
A kdyz sem pak podobny veci resil ze zodpovednejsiho postu kde sem musel resit vicemene i zdroje, bylo mi jasny ze je to dost nakladna zalezitost. Ono kdyz se pro neco takovyho tym rozhodne, je treba si bejt jistej ze nekdo stezejni v pulce neodejde nebo ze ho neprelozej nekam jinam, stejne tak si clovek musi bejt jistej s jeho kompetencema - to ze dotycnej dovede najit chybu a commitnout fix kterej zachrani v danym momentu situaci neni zaruka toho, ze je dobrej i na to aby napsal komplet nakej novej modul kvalitne a i z hlediska udrzitelnosti.
Momentalne treba resim komplet refaktoring jednoho z projektu taky (puvodni kod napsal kolega toho casu cerstvej absolvent, cca pred 3 rokama), nicmene pokud se k tomu opravdu rozhodnem, bude to jenom pro novou verzi nasazenou do uplne rozdilnyho prostredi, kde by portovani stavajiciho reseni bylo pracnejsi nez to napsat znovu ... a ano, porad sem v ty euforii ze se to musi komplet prepsat protoze z hlediska maintenance to bude cimdal vetsi horror (vlasy si rvu denne kdyz se v tom hrabu), ale zustavam porad pragmatictejsi, protoze pro klienta to bude mit porad mizivou pridanou hodnotu v dohlednym horizontu (tj. par let).

ABAP: My nebyli velký korporát, ale naši zákazníci byli čistě interní. Takže šlo argumentovat že to buď bude náš čas na přepsání, nebo pak artist time před deadline když něco nepůjde doprogramovat dost rychle a budou to muset řešit manuálně. Ale to jsme měli velmi osvícené a technické vedení až po majitele včetně.