• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    KOJAProgramovani 40+
    Diskuze o obzive programovanim pro starsi a pokrocile.
    rozbalit záhlaví
    CERMI_FOX
    CERMI_FOX --- ---
    KOLCON:
    DEFILA: asi v tom je rozdil, krom startupu jsem nezazil, ze by vedouci vyvojovyho oddeleni byl technik. Projektak jasny, byznysak jasny, dokonce reditelka materske skolky, ale technik nikdy, programovani leda tak na skole (mba, vse nebo tak neco). Vzdycky jsem si to zduvodnoval tim, ze dobryho vyvojare je skoda, aby cely dny jen sedel na meetingach, politikaril a delal reporty a takovy ty plany (promakany excel, kde je, ze tym z projektu X bude delat na projektu X a kolik lidi ma dovcu).
    V soucasny firme je to vubec extrem, ale tak nejak jsem si zvykl, ze centralne se moc neridi a veci funguju jako p2p management - proste se jako team leadri dohodnem, jak to bude a management to jen pasivne sleduje :)
    DEFILA
    DEFILA --- ---
    KOLCON:
    CERMI_FOX:

    ciste ze zvedavosti, odkuh prameni tyhle informace o platech? Zazil jsem dobre managery (coz je ekvivalent dobreho inzenyra), kteri meli nadprumerny plat a zazil jsem i spatne manazery i inzenry
    Lidi si vseobecne stezuji na mzdu, ale pokud je clovek dostatecne seniorni, tak zna svou cenu a trh mu ji zaplati : )

    v obou pripadech:
    - to, ze ma clovek manazerskou pozici neznamena, ze ma vyssi plat nez kvalitni vyvojar
    - a zaroven plati to, ze pokud je clovek vyvojar, tak to neznamena, ze je hned rich bitch :)
    KOLCON
    KOLCON --- ---
    CERMI_FOX: Je pravda že v IT ten rozdíl není tak dramatický. Ale i tam management spíš platově začíná tam, kde vývojáři končí. Ono je to vlastně logické, když si vezmeš, jak se rozhoduje o platech.
    CERMI_FOX
    CERMI_FOX --- ---
    KOLCON: ad 2 - kvalitní technik bývá o dost placen jak obyč management; přecijen najít kvalitního vývojáře a udržet ho je mnohem těžší než najít vyplňovače reportů a leštiče klik s drobnou schopností organizace (reálný rozhodnutí jsou stejně jen na úrovní C-level managementu)
    KOLCON
    KOLCON --- ---
    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...
    CERMI_FOX
    CERMI_FOX --- ---
    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.
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    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)
    DEFILA
    DEFILA --- ---
    oka, taky se pridam, abych zdejsi klub jen nesledoval

    Chapu, ze klub je primarne "programovani X+", ale jak casto se snazite vnimat senioritu sve pozice?
    Zacinal jsem (tenkrat) jako sysadmin, pak to bylo devops, sysops ci jine akronymy a ted jsme se presunuli k SRE s ohledem na infrastrukturu a do toho jsem prispival do ruznych projektu - takze jsem nebyl asi cistokrevny programator?; pak prisel prechod na manazerskou pozici a po sleze na seniornejsi manazerskou pozici -> tady jsem si rekl, ze potrebuju zmenu, prehodnotit a mozna pokracovat jinak.

    Tedy otazka do plena - zkousel jste se nekdo vratit na nizsi (ano, vim jak blbe to zni) senioritu? Z meho pohledu asi narazim na vic prekazek, nez bych cekal.
    AXTHEB
    AXTHEB --- ---
    DAVIDOWITCH: Tady bych chtěl poznamenat, že od doby co se snažím dělat TDD mám pocit, že že mně rovnou padá ta verze 2 ze 3.
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    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
    AXTHEB
    AXTHEB --- ---
    MARASAN: na kafce jsme zůstali, jen jsme si tu obsluhu napsali sami.
    SPIKE411
    SPIKE411 --- ---
    Je to sice o prodejcích, ale přijde mi to tak nějak relevantní, když se řeší ten zakázkový vývoj. V diskusi pod článkem to ještě trochu doplňuje.
    Pozor na Cimrmany a brouky Pytlíky. Tradiční pasti při obsazování pozic pro prodej softwaru - Lupa.cz
    https://www.lupa.cz/clanky/pozor-na-cimrmany-a-brouky-pytliky-tradicni-pasti-pri-obsazovani-pozic-pro-prodej-softwaru/

    Původní článek tady
    Tradiční pasti při obsazování B2B sales pozic pro prodej softwarových produktů | by Petr Dvořák | Wultra Blog CZ | Apr, 2022 | Medium
    https://medium.com/wultra-blog-cz/tradi%C4%8Dn%C3%AD-pasti-p%C5%99i-obsazov%C3%A1n%C3%AD-b2b-sales-pozic-pro-prodej-softwarov%C3%BDch-produkt%C5%AF-18e548d35fb7
    MARASAN
    MARASAN --- ---
    AXTHEB: cim jste nahradili Kafku?
    AXTHEB
    AXTHEB --- ---
    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.
    ALMAD
    ALMAD --- ---
    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.
    TOOMIX
    TOOMIX --- ---
    CERMI_FOX: zakázkový vývoj dělám teď 9 let a občas je to peklo. Technologický dluh v nějaké aplikaci dožene člověka třeba až po 15 letech a co by normálně udělal za hodinu dělá 3 dny
    CERMI_FOX
    CERMI_FOX --- ---
    ABAP: jo, zakázkový vývoj aplikací je z tohohle pohledu (a mnoho dalších) zlo, velmi se mi ulevilo, když se tím přestal živit, považuju to za jedno z nejlepších rozhodnutí v životě :) Ale i tam se dá schovat, pokud je to aktivní projekt a klient poptává pravidelně a v blocích. Pokud je to v maintenance, tak je třeba holt trpět a nový projekt udělat hezky.
    SATAI
    SATAI --- ---
    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).
    MLEKAR_STEIN
    MLEKAR_STEIN --- ---
    takova podkapitola k prepisovani.
    frameworky.
    1. jak se k nim stavite? Spise je chcete pouzivat, nebo je nemate radi?
    2. jak s nimi zachazite? jak casto musite vyrobit rovnak na ohybak?
    3. co se delate kdyz vyrobce frameworku skonci? pripadne to nahradi jinym, ktery by vyzadoval prepis?
    pripadne cokoli dalsiho.

    proc se ptam?
    pasl jsem kdysi jednu mensi aplikaci, ktera nebyla z nejmladsich, cca 15 let.
    byla castecne napsana v oracle apex, takze mela vsechny nectnosti oracle veci, byla pomala, bylo potreba ladit neustale databazi, v db bylo hromada ruznych pl/sql baliku, ktere se navzajem volaly. a cele to pouzivalo jakysi framework, ktery ale uz byl nekolik let mrtvy.
    vedle toho byl aplikacni server, ktery za tech patnact let nasbiral postupne tri frameworky. nevim uplne proc to tak bylo, protoze delaly vice mene to same, pochopitelne dva uz byly neudrzovane.
    no a ten aplikac mel memory leak. a i kdyz jsme to nevyvyjel, tak jsem dostal za ukol zjistit, proc to pamet zere. no, a problem byl v historicke mrtvole frameworku, u ktere vyvoj nakonec nevedel co s ni. prepis s nejeky novejsim fw nikdo nedokazal zaplatit, na to to bylo moc velky a zaroven kdyz se s palikacem pracovalo, tak sezral dostupnych dvacet giga rameti behem ctyr hodin a umrel. a tak to bylo v zacarovanem kruhu, kde to vadilo, ale nedalo se s tim moc delat.
    MLEKAR_STEIN
    MLEKAR_STEIN --- ---
    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. :)
    INDIAN
    INDIAN --- ---
    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).
    RATTKIN
    RATTKIN --- ---
    když je to interní produkt, tak se čas na refaktory hledá lépe, než když je to jednorázová zakázka..
    Kliknutím sem můžete změnit nastavení reklam