LARS_GUNNER: Tak - Niagara (UltraSPARC T1, UltraSPARC T2+) to je ~2006.

MLEKAR_STEIN: I dnes se mi stane, ze mi prijde nabidka na zakazku !ASAP! a kdyz dojde na review s dotycnym koncovym odberatelem, tak zjistim, ze tam maji "problemy s kapacitami", tedy bordel v organizaci prace a potrebuji externi pracovniky, kteri by pokryli "kratkodoby napor na release", tedy bordel v organizaci prace.
Uz ani nezminuji, ze k nam kdysi dojel nejakej frajer s peknou kravatou a Rolexkama a zacal nam nabizet cool produkty jejich noveho SW StartUpu. Po jednani si stezoval rediteli, ze jsem velmi neprijemny a ze me u finalniho jednani nechce. Reditel byl na me trochu nasranej, ale na me nalehani zaradil do schvalovaciho jednani otazku na personalni vybaveni jejich firmy. Z borce vypadlo, ze programatory jeste nemaj, protoze je budou outcourcovat az podle toho kolik podepisou smluv. XD

IXTREMIST:
Ja pred lety delal pro pro jednu nemeckou firmy mezi jejiz klienty patrila nechvalne znama UBS. Resilo se testovani jejich SW systemu, takze clovek tam neco poslal, pak mel SW sondu nekam dovnitr tech systemu a tam se dival, jestli je tam to co tam ma byt.

Clovek co delal s UBS na tom testovani mi popisoval jak to zhruba vypada pro ten core business. Stovky (tisice) amd64 serveru s Windowsama a .NETem co resili SOAP rozhrani pro ruzne klienty (byla doba, kdy byl SOAP cool). Tyhle servery ale jen krmili desitky (stovky) neuveritelne drahejch Sun/Fujitsu serveru (takovych tech veci s Niagarou vevnitr, pamatujete tu eru?) pres CORBA rozhrani (byla doba pred SOAPem, kdy byla cool CORBA :-). No tyhle Suny jen krmili jeden IBM mainframe kterej jedinej delal neco uzitecneho.

Co na tom byla pravda nevim, ja sam jsem u toho nebyl. Ale historka je to dobra a asi i uveritelna.

Pokud mam spravne informace, tak nejake pretezovani lidi uz dnes neprichazi v uvahu. Moje komunikace s automotive sferou v poslednich dvou letech odpovida tomu, ze jim v obrovskem objemu utikaji lide. Nejedna se o nejake mini vypadky a hastereni mezi jednotlivci, ale o napr. cele SW oddeleni, ktere se proste sebere a jde do prdele :) . Chapu, ze takovemu tomu "grafovemu" managementu se asi utect neda, ale pokud cele odvetvi proroste touhle chaskou, bude asi do budoucna rychle vymalovano. Napr. byvaly klient nedokazal pochopit, ze se cely svet netoci kolem jeho ega a jeho zamestnanci nejsou ochotni pracovat se stejnym nasazenim, jako jednatel firmy. Zacal se obalovat takovym tim vakuovym managementem, ktery jej zacal utvrzovat v jeho zkreslene realite a nyni je bez programatoru a hudrujici na cely svet. Nepochopeni principu zamestnaneckeho pomeru je bohuzel az prilis caste a jako zivnostnik to pocituji dost.

JARDABEREZA: podepisuju..

navic tenhle tlak na maximalni vykon a hodnoceni podle podaneho vykonu zabiji tymovou spolupraci, lidi nemaji motivaci si navzajem pomahat / ucit se.

na podobny tema:

OKR Distractions
https://www.netmeister.org/blog/okr-distractions.html
https://www.netmeister.org/blog/performance-review.html

IXTREMIST: Spousta casti spousty bank bezi na .NETu a Windows.

IXTREMIST: Co na tom vidíš vtipného?

IXTREMIST: má to i frontend, ale hlavní je backend. Jako Indy jsme zkoušeli taky, ale to byla tragédie největší, 30 stránkové CV "expert ve všem" a pak nebyl schopný poskládat jednoduchý patterny natož join v sql :)

Cca rok zpět jsem viděl IT startup se sídlem v Maledivách. Ale chtěli jenom full-remote... takže nezájem. Jedno z mála míst, kde bych to bral obráceně :-D

NAVARA: jj, Covid posunul práci z domu neuvěřitelně dopředu I firmy, které odmitaly nějaké Ho teď jedou 50/50
docela by mě zajímalo, kam se to posune s ohledem na extrémní náklady pronájmu kanclu (rozuměj budova pro 1k lidi)

Lidi si holt začali více vážit svého vlastního času a nechtějí pálit 2-3 hodiny omezeného času života denně přípravou a na cestách do/z práce (a grátis k tomu), tuplem když to není třeba, jen pro modré oči svých šéfů. A i těm, kteří si předtím neuvědomovali jak moc času to je, to ukázaly černé na bílém pandemické omezení.

CERMI_FOX: Spousta firem má problém např. s homeoffice. Už několikrát se mě snažil přetáhnout Broadcom nebo Atos, za dvojnásobek peněz co beru. Ale nemají homeoffice, takže smolíček....

QWWERTY: ja s tebou naprosto souhlasim, ale vzhledem k tomu, ze nejsme schopny najit dobry lidi, abychom mohli jet nejvice na 100% je scifi, tak najit jeste vic lidi uz je dvojity scifi.
Leda byste tu nekdo mel jiny hiring trik nez zahazet lidi nesmyslem penez :-) (disclaimer, aby to nekdo nepochopil spatne - delam si srandu :) )

CERMI_FOX: pracovat na 100-150% je blbost. viz co pise MLEKAR_STEIN - optimalni utilizace je okolo 60-80%
u auta taky nejezdis tak, ze by jsi vetsinu casu tocil motor do maximalnich otacek, protoze i kdyz to kratkodobe zvladne, tak to pro neho rozhodne neni dlouhodobe dobry.
nektery systemy maji jeste min - napr. u SS7 se pocita s maximalni utilizaci 40% jednotlivych elementu, kvuli redundanci a rezerve
zajimavy, ze neni problem tenhle koncept aplikovat na techniku, ale z nejakyho duvodu je to u "human resources" strasny problem.

ano, mas flakajici se lidi, mas pomalejsi lidi, ale reseni neni pretizit zbytek teamu, ale bud je vyhodit nebo je preradit na praci, kterou zvladnou.
napr. na ne hodit rutinni udrzby, jednodusi tasky, etc.. coz uvolni ruce aktivnejsim jedincum pracovat na slozitejsich vecech

kdyz zatizis lidi trvale na 100+% tak driv nebo pozdeji odpadnou. navic nemaji rezervu ve chvili, kdy je potreba vykryt spicku. na co ti je, ze mas high-perf jedince, na kterym stoji spousta projektu a kdyz ti vyhori, tak vsechno co na nem stoji zacne mit problemy?
asi tusim, ze to vyvolava konflikt wellbeing vs performance priorit a neni jednoduchy najit optimum. a ze pokud jedna firma zdime lidi na maximum a ta druha jim dava prostor, tak ta prvni muze generovat vetsi profit a obecne se pohybovat rychleji, coz tlaci tu druhou, aby to zacala v ramci konkurenceschopnosti delat taky. ale pak je imho potreba ty lidi aspon rotovat mezi high-perf a recovery stavama.