Názory k článku Zaučování juniorů trvá roky, ale stojí to za to, říká Maria Matějka z projektu BIRD

Prostě lidi zaplatit, to je celé.
Mě se u článku nelíbí to "jsme asociální" jako by to v dnešní době byl v IT nějaký standard. Běžně mám kolegy co chodí do posilovny, řeší stravu, to jestli mají značkové spodky, nebo jestli na ně poletí baby.
IT se proměnilo, je to normální dobře placený obor jako třeba právník. A u právníka taky nikdo nečeká, že to bude asociální knihomol který bude dělat svoji práci z lásky k řešení komplexních právních sporů, tak proboha proč tohle očekáváme v IT?

Souhlasím s Vámi, dneska už ajťáci nejsou jen podivní šmudlové někde ve sklepeních firem. ;-)

Ale vzpomněl jsem si na toho týpka, jak se jmenuje, Altair Valášek, co si myslí, že je kůň? Nebo zástupy bezejmenných obtloustlých ajťáků, co oblibují My Little Pony, co se oblékají jako malé holčičky/zvířátka v šatičkách nebo co to je... :-)) Já vím, to jsou ujeté extrémy.

Altair se určitě pobavil, když si tenhle komentář přečetl :D

Nevšiml jsem si žádného výrazného zastoupení My Little Pony mezi lidmi v IT branži - máte nějaké příklady těch "zástupů bezejmenných obtloustlých ajťáků", nebo je to jen další dojmologie?

Panove by si mohly vsimnout, ze v oboru se uz davno pohybuji i ajtacky ;-)

> Mě se u článku nelíbí to "jsme asociální" jako by to v dnešní době byl v IT nějaký standard. Běžně mám kolegy co chodí do posilovny, řeší stravu, to jestli mají značkové spodky, nebo jestli na ně poletí baby. (...)

Tak nějak bych si tipnul, že Maria bude o tom týmu vědět trošičku víc než ty, a tím pádem je v lepší pozici volit výrazivo. Neřekl bych, že někdo čeká od ajťáka, že bude {sem vložte popis charakteru}, ale když člověk dělá tu práci z lásky k řemeslu - ať je to truhlář, učitel nebo právník - tak v mnohém vyhrál a může na to být patřičně hrdý.

> Mě se u článku nelíbí to "jsme asociální"

Kde to tam vidíte? Já tam našel akorát "normálně komunikujeme v míře odpovídající asocialitě každého z nás". A to zní spíš jako že mají v týmu různé typy lidí.

Ano, humor IT, které to baví (vs. "dobře placený obor") zahrnuje i mírnou sebeironii.

Běžně mám kolegy co chodí do posilovny, řeší stravu, to jestli mají značkové spodky, nebo jestli na ně poletí baby.

Otázkou je, jestli ale jsou na své pozici v týmu opravdu pomocí, nebo spíše přítěží. Nechci tvrdit, že je tam nějaká relace typu ekvivalence, ale nejpoužitelnější z této sorty lidí, co jsem potkal, se vždycky totálně ztratil v detailech, přičemž podstatné věci mu unikaly, a jakýkoli kód jeho provenience se dal v průměru zredukovat faktorem 1:2 LOC.

Připadá mi, že spousta těchto typů do tohoto oboru jde jen kvůli vidině nadprůměrných příjmů. Což ostatně platí i u těch právníků. A proto se dnes tolik řeší, jak pokles průměrného IQ a schopností lidí v IT vykompenzovat o to inteligentnějšími a blbuvzdornějšími nástroji, tj. programovacími jazyky, knihovnami, frameworky a LLM.

Jenom o zaplaceni to taky neni...

V urcitou chvili (pokud teda nejedete nejakou silenou hypo) resite taky Work-Life balance...
- Jestli muzu do kanclu dojet v klidu
- Jestli kdyz cekam remeslnika muzu bejt na HO
- Jestli muzu pouzivat Linux
- Ze mam super kolegy a tym, kde si me lidi vazi a maji me radi
- Ze me napln bavi a netlucu jenom tickety

... Jako ty penize dokazou dost nahradit, ale prijde mi, ze v urcitou chvili se to zacne skladat trochu jinak

Za mne je optimalni vse plus ty penize. A podle toho se rdim...

Já bych hlavně dodal, jestli můžu dělat od června do září z chalupy. Protože já už v létě do kanclu prostě chodit nebudu, to bych raději dal výpověď.

Jako ano, ale zrovna oni fakt moc platit nechtějí. A když bych pak byl ve výsldku třeba na polovině, to už je fakt dost.

> Běžně mám kolegy co chodí do posilovny, řeší stravu, to jestli mají značkové spodky, nebo jestli na ně poletí baby.

Otázkou je, zda je to dobře.

26. 6. 2025, 14:16 editováno autorem komentáře

Já vám odpovím: jisté, že je to dobře, že lidé mají vlastní záliby a život.

Přesně. Ostatně zcela nedávno jsme reagoval na jejich inzerát, zaslal životopis a představu o penězích což byla celkem normální tržní cena, odpověděli neautomatizovaným mailem (což je šlechtí), ovšem něco ve smyslu, že je můj životopis sice velmi zaujal ale mé finanční požadavky jsou daleko nad jejich možnosti.

To pak je fakt těžké.

"Běžně mám kolegy co chodí do posilovny, řeší stravu, to jestli mají značkové spodky, nebo jestli na ně poletí baby."

Taky mám takové kolegy a jsou to pořád asociálové.

Uvádíte, že se při náboru orientujete hlavně podle schopnosti programovat v C ve více vláknech. Upřímně, implementovat multithreading v C je opravdu těžká úloha. Pokud to chcete po juniorech, tak se nedivím, že trpí, tohle je jednoznačně seniorní práce.

S multithreadingem by vám hodně pomohl Rust, neuvažovali jste o tom? Nemyslím tím přepsat všechno do Rustu, ale třeba zkusit implementovat nějakou novou funkcionalitu v Rustu? Taky by vám to mohlo pomoct s náborem, junioři obecně budou raději psát v Rustu než v C.

Mimochodom, zaujímalo by ma, aké ťažké je robiť thready v C. V Jave som robil, tam sa s tým robí výborne. V Rust úplne fantasticky. Ak človek nie je bota a dodržiava best practices pri práci s threadmi, tak je to dobré. C je v tomto nejak extra iné? V C som robil najviac tak multiprocessing a to už dávno, na škole.

26. 6. 2025, 11:02 editováno autorem komentáře

C je low level a nema nativni podporu threadu. Je to tam jako psat multithreading v asm. Celou implementaci od znova a nebo pouzit netransparentni libky.
Bud je to na rezimu "hurt me plenty" kdy je treba si napsat odznova ( sadismus akademicke sfery / not invented here ) a nebo pouzit extra knihovny - napr. pthread ( velmi spatne debugovatelna slizka) a nad to si dat spoustu rovnaku na ohejbaku jako valgrind nejaky debugger co umi replay atd.
Cele to ziskava zajimavou dimenzi pokud jde vylozene o cas na realtime systemech.

A presne kvuli takovym exkrementum nejsem programator.

Rozumiem, každý to rieši ináč a programátor aby ovládal všetko. Tak to sa potom nečudujem, že je problém zohnať ľudí.

> C je low level a nema nativni podporu threadu

C11?

Optional. Zkuste to podporovat u jednoduchych embedded systemu.

valgrind je single thread.

Pro debugging mt aplikace je lepsi TSAN.

Rekl bych ze helgrind a drd rozhodne nejsou mysleny jen na single thread debug :-) I kdyz je to jak drevena pinzeta na mikrooperace.

... proto nejsem programator. Protoze to nechci resit. Mam k vecem utilitarni pristup. Nebavi mne sahodlouhe diskuse o tom jestli se vec vyrabi nebo tvori. Protoze narozdil od progrosu je na mne brime funkce dane veci. Programatorum casto chybi reality check. V bode A je vase diskuse ktera nema konce a blizi se brzy bodu B. V bode B uz umiraji lidi nebo se sypou miliardy do kanalu. A nase akademicka particka stale tlacha o nicem. To si reste na meetingu s architekty a ne na krizove porade.

Teprve az kdyz to nasi matlalove domatlaji k nepouzitelnosti a _vec_ nenahraditelna jinak nefunguje tak zacinam programovat a zhodnotim co momentalne doba nabizi za nastroje.
Problemy tohoto typu nejsou ani pro mne zajimave a je to jen nudna iterace toho sameho co jsem v minulosti uz videl.

Nejde ani tak o thready jako takové, pustit thread v C je triviální, ale jde o všechno kolem. V C je nutné řešit memory management, je potřeba hlídat data races, C nemá ani RAII pro úklid prostředků... Je to problém i při single-thread programování (kromě data races) a při multithreadingu roste kognitivní komplexita tak nějak exponenciálně, je opravdu těžké všechno udržet v hlavě a udělat správně.

Rust nabízí řešení pro memory management, úklid prostředků i data races, tohle všechno hlídá překladač. Nechci se účastnit nějaké flamewar Rust versus cokoliv jiného, ale kdybych stál před rozohodnutím, jestli dělat multitreading v C, nebo to začít postupně předělávat do Rustu, tak je to jasná volba. Zvlášť když vím, že v C tam zůstanou bugy, které Rust odchytí (člověk ty chyby prostě udělá), vývoj v C bude pomalý a neseženu vývojáře, protože v C junioři dělat nechtějí.

A v rustu chtějí?

V rustu dělají většinou lidi co už dávno znají C a C++ a nechcou pořád řešit ty samé bugy dokola.

Multithreading není problém ani v C nebo C++, ale prostě to vyžaduje disciplínu a hodně testování, což rust tak trochu usnadňuje, protože v safe kódu garantuje to co v C/C++ garantovat nejde.

Pokud si myslíš, že disciplína a hodně testování dokáže zaručit, že nebudou chyby související s memory managementem, ownershipem objektů a data races, tak je to tvůj názor, který nesdílím. Další věc jsou náklady na vývoj, budeš to psát pomaleji a hodně testování navíc taky není zadarmo.

Tohle je tak pitomý komentář. Rust fakt není všespasitelný a to by si měli uvědomit lodi co ho všude propagují.

> V Jave som robil, tam sa s tým robí výborne

Jak v Javě, tak v C platí, že vytvořit nové vlákno je ta jednoduchá část. Napsat program tak, aby spolehlivě fungoval bez různých race conditions, to je ta složitější část. Bez znalosti použitého memory modelu (jak v C, tak v Javě), se některé věci mohou chovat někdy nepředvídatelně. Zápis do paměti v jednom vlákně nemusí být hned viditelný ostatním vláknům. Dokonce jednotlivé zápisy nemusejí probíhat v přesně stejném pořadí. A ani čtení.

Ano, v Javě máme hromadu pomůcek, jako Futures a Executors, které nás odstíní od největších pastí, pak není nutné používat přímo Thread a řešit synchronizaci na každém rohu. Ale i tady, zvlášť při sdíleném stavu, lze narazit.

Zdielané stavy a mutables treba obmeziť na minimum. Viem, že je to môj mokrý sen a v kóde, ktorý zdedím to tak nie vždy býva, ale dá sa to prežiť.

Spis si rikam jestli se cely ten projekt neubira podivnym smerem.

Prepsani do Rustu asi muzeme tezko ocekavat vzhledem k prednasce slecny (pani) Matejkove na FOSDEM 2025:

https://fosdem.org/2025/schedule/event/fosdem-2025-6606-imposing-memory-security-in-c/

Pokud se v tom projektu objevuji takove hruzy, pak misto reseni funkcnich problemu mate co delat abyste v tom byli schopni vubec neco udelat.

Proste ano, i v dnesni dobe lze programovat pomoci maker a C, ale pripomina mi to kopani zakladu lopatou zatim co sousedum prijede bagr. A neni se co divit ze do toho ma malokdo chut.

26. 6. 2025, 09:44 editováno autorem komentáře

Tak to přepiš a ukaž nám jak to bude všechno lepší a bezpečnější.

Proc by mel delat neco zadarmo jenom aby nekomu neco dokazal? Jaky je z toho realny uzitek?
Jeho prace to navic neni.

To sice není, ale kritizovat existující open source projekt jen kvůli tomu, že není v jazyce, v jakém by si ho někdo jiný předstatoval... Co na to jako odpovědět?

Už mi jen chybí další názor typu "kdyby radši dělali [přidej cokoliv co potřebuješ...]"

Je to komerčně vyvíjený projekt, který má zjevně svoje problémy, z velké části způsobené volbou C na začátku. Nikdo tady nenavrhoval všechno přepsat do Rustu, ale spíš Rust vyzkoušet pro novou funkcionalitu, což jde udělat relativně snadno, interoperabilita C a Rustu je dobrá,

Není to o nějaké ideologii, tak to tomu přistupuješ možná ty. Je to o tom, že jsou technické nástroje, např. Rust, které tomu projektu mohou v dlouhodobém horizontu hodně pomoct. Vývojáři BIRDu tento názor asi nesdílí, nicméně je to jejich boj a jejich peníze, to je asi tak všechno, co se k tomu dá říct.

Reagoval jsem na stiznosti uvedene v clanku ze na tom nikdo nechce delat.

Zjevne pouziti nastroju a postupu, ktere jsou vetsinou programatoru povazovanych za zastararale/podivne stezuje praci do te miry, ze i seniorni zamestnanci se boji do kodu zasahovat.

Nezlobte se na me, ale timto bych se jako (spolu)autor projektu moc nechlubil.

Přijde mi, že pokud v dnešní době veřejně prezentují projekt jako " Některé části našeho kódu (třeba filtry) jsou pak navíc prakticky černá magie, na kterou i seniorní sekce týmu sahá s bázní a třesením.", pak by se vedení projektu mělo zamyslet, zda by se něco nemělo dělat jinak. To se pak nelze divit, že nemohou sehnat nové lidí.

26. 6. 2025, 10:59 editováno autorem komentáře

Čili požadavek zní: sháníme zkušeného truhláře, který má praxi s ručními nástroji jako čepovka, dlátko, klasický dřevěný hoblík, s nimiž se u nás pracuje, a nejlépe, aby se vyznal i v problematice stavební truhlařiny, ale jsme neziskovka, takže nemáme rozpočet, abychom si ho mohli dovolit zaplatit. Tak sázíme na učně, protože ty si dovolit můžeme, ale musíme si je zaučovat, protože neumějí ani rovně uříznout kus prkna.

Řešení - buď si uvědomit, kolik stojí pracovní síla s požadovanou kvalifikací, nebo si pořídit formátovací pilu, egalizační brusku, protahovačku a místo hledání mistrů truhlářů hledat obsluhy strojů.

To je poptavka na tradicniho umeleckeho truhlare :-D Mozna jeste takoveho ktery vyhovi i prazskym pamatkarum :-P Spis bych rekl jeste v japonskem stylu kde je preference tradicnich rucnich nastroju. Vc. jejich udrzby.
Jenomze oni si ti dedove za to taky reknou slusne penize.

Junior si po dvou letech uvědomí, že už není junior. S čárkou v životopisu odejde tam, kde jsou peníze.
A s výchovou nováčků můžou začít znova od nuly.
Takový placený školní projekt.

To je ještě ten lepší případ. Horší je, když si junior myslí, že je dávno senior, a takové jsem už potkal :-)

Slibem povyseni kazdy rok na reviews nezarmoutis. Stejne jako kydem ze nejsou penize.
Ja to zas vidim tak ze proste v IT nelze nikdy byt senior.
Nakonec volim metriku: rekni mi kolik pruseru jsi vyrobil a jak jsi se z toho poucil.

I tuhle "taktiku" neni tezke prokouknout.

Jenomze proc by mel mit junior chut se dostat na seniorni pozice kdyz to nedostane adekvatne zaplaceno?
Lepsi je sbalit si svych par svestek (i te tajne v tekutem stavu co dostal od kolegu z Brna...) a zkusit to jinde. Nedava smysl zit svou karieru ze slibu a ztracet cas.

Ten projekt začal v roce 2000. Rust je z roku 2012, ale popularitu začal získávat až mnohem později. Jazyk D je z roku 2007. Jazyk Go 2009. Takže tyhle jazyky vůbec nebyly ve hře, protože neexistovaly. A k nějakým postupným přepisům jsem spíš skeptický. V úvahu připadalo C, C++ a Java. Zajímalo by mne, jak vypadalo rozhodování mezi C a C++. Určitě padaly argumenty, že C++ je moc složité a ošklivé, že s „čistým céčkem“ to bude jednodušší a kód srozumitelnější. Bylo by fajn si udělat nějakou upřímnou retrospektivu a vyhodnotit, zda to „čisté céčko“ stálo za to a jestli by SBRM (RAII) v C++ nepřineslo víc užitku. Je to také otázka, jestli se chceme radši potýkat s komplexitou programovacího jazyka, který se používá celosvětově a je k němu dostatek informací, nebo s komplexitou daného projektu, který zná jen pár lidí.

P.S. Případně se může vyjádřit nějaký zapřisáhlý lispař nebo haskellista, jestli by jejich oblíbený jazyk nebyl v tomhle případě lepší volbou :-)

Podle mě použít C byla blbost už tehdy. C++ měla být jasná volba. Nejde ani o to používat std kontejnery, ale třeba generika v C++ prostě stojí za to, a jestli potřebuju použít třeba linked list, tak ho chci implementovat jen 1x a ne na to mít plno maker, jak je v C zvykem. 1 implementace se totiž dobře testuje. To samé použití zámků, atd...

Dnes už by podle mě volba padla asi na rust - výkon to má víc než dostatečný na to, jaké garance ten jazyk poskytuje.

Na druhou stranu chtít po nich to do čehokoliv jiného přepsat je podle mě blbost. Já mám taky projekty v C++, které přepisovat do ničeho jiného nebudu - není na to čas ani motivace.

Tehdy byla ideologie, že "správný programátor zvládal C, zatímco C++ byla jenom pro ty, kdo neuměli spárovat malloc s free" ...

Výsledkem bylo, že každý C projekt měl svůj framework a způsoby, jak řešit věci, které v C++ byly vyřešené, přirozené, automatické a otestované.

Zajímalo by mě, zda tam byly i technické požadavky, které C++ eliminovaly. Chápu, že C++ má svoje nedostatky a třeba stále chybějící řešení pro supressed exceptions je naprostá katastrofa. Ale udělat projekt násobně komplexnější a pak si stěžovat na neefektivitu a náklady a během 25 let s tím nic neudělat...?

Ano, přepsat je blbost, pokud náklady převáží zisk. Ale tenhle projekt se relativně aktivně vyvíjí a zjevně má s volbou jazyka problémy. V případě přechodu na C++ nebo Rust může být změna postupná. Část může zvládnout LLM, pokud je kolem slušné testování...

Ono jestli ten projekt začal roku 2000, tak C++11 ještě nebylo a C++ mělo také své problémy (ne že teď je nemá).

Na druhej strane, C++ bolo značne pokročilé už vtedy, pre mňa je mílnikom moment, keď Andrei Alexandrescu vydal Modern C++ Design. A on publikoval už predtým, pamätám si kde som v C++ Users Journal čítal o RAII a aj to, kedy som tam bol naposledy. A boli aj ďalšie knihy o tom ako programovať v C++ od ďalších významých autorov. Navyše C++98 už existovalo, to síce nebolo ešte ako C++11, ale už jeho samotná existencia bola veľkou vecou.