Přejít k navigační liště

Zdroják » Různé » Jak býti seniorním inženýrem

Jak býti seniorním inženýrem

Články Různé

Překlad populárního článku. Obsahuje výčet povinných vlastností zralého inženýra a mnohem víc. Pro velkou délku jsme rozdělili do dvou článků.

Nálepky:

Kolem akademických titulů a názvů pracovních pozic se toho zbytečně moc nadělá. Kdekdo se nazývá senior vývojářem, ale co to skutečně znamená býti seniorním inženýrem? S laskavým svolením Johna Allspawa jsem přeložil jeho článek On Being A Senior Engineer.

Myslím, že v našem oboru dobře víme, jak se stát produktivním inženýrem. Ačkoliv existuje kopec manažerských knih o roli „expertů“ a roli netechnických jednotlivců, neznám moc moderních knih ani článků, které by mohly objasnit, jak se stát dobrým seniorním inženýrem. Až na jednu významnou výjimku, Kate Matsudaira, která nedávno psala o kulturním aspektu inženýrství.

Přitom hodně úspěšných inženýrů, které znám, vzpomíná na mentora, který je naučil, co to znamená být „seniorní“.

Stoprocentně souhlasím se slovy svého přítele Thea, který ono býti seniorním popsal ve své kapitole v knize Web Operations (vyšlo v O’Reilly):

Generace X (a dokonce víc generace Y) je kulturou okamžitého uspokojení. Pracoval jsem s ohromujícím počtem inženýrů, kteří očekávali kariérní cestu, která je, protože jsou chytří, během pěti let dovede na vyšší technické pozice. Ale to je prostě v takovém počtu nemožné. Ne každý může být seniorní. Pokud se po pěti letech stanete seniorní, jste na špici? Nezískáte za dalších pět let víc neocenitelné zkušenosti? Co pak? “Super inženýr”? Dalších pět let? „Nadupaný inženýr“? Dávám to za vinu mládí našeho oboru. Pravdou je, že velmi málo inženýrů je v oboru web operations patnáct let. Kvůli dynamice našeho oboru si mnozí zvolili postup na manažerské pozice nebo riskli podnikatelskou dráhu.

Theo má pravdu: web operations je stále celkem mladý obor. Takže nemůžeme být překvapení, pokud lidé mající titul „senior“ podle očekávání projevují nevyspělé chování (a to jak technické tak i netechnické). Pokud jste nečetli Theovu kapitolu, tak ji vřele doporučuji.

Ovšem co vlastně v tomto oboru znamená být „seniorní“? Já samozřejmě mám představu, co to znamená, protože jsem zodpovědný za nábor, podporu a za udržení inženýrů, kteří jsou považováni za seniorní. Panuje představa, že existuje laťka, které je dobré v rámci kariérního růstu dosáhnout, ale musím dodat, že zmíněná kritéria vytváří široké spektrum, nikoliv jen jednoduchý seznam, který byste si odfajfkovali. Neprobudíte se jednoduše jednoho dne s tím, že už jste „senior“ jen proto, že vám s povýšením změnili i titul. Seniorní inženýři neví vše. Nejsou dokonalí ve svých technických znalostech a jsou s tím naprosto vyrovnaní.

Abych nezaměňoval tituly, které už jsou samy nejasné, budu občas hovořit o inženýrské zralosti.

Konkrétně: od „seniorního“ inženýra očekávám, že je to zralý inženýr.

Přeskočím tu část, ve které bych mohl vyjmenovat technické oblasti, které by měl zralý inženýr na dostatečné úrovni ovládat nebo jim rozumět (jako jsou sítě, souborové systémy, algoritmy atd.). Místo toho zdůrazním osobní vlastnosti, které mi naznačují, že někdo může v oblasti inženýrství pozitivně ovlivnit firmu nebo byznys.

Na serveru Quora se mě jednou někdo zeptal: „Jaké jsou vlastnosti (jiné než technické schopnosti/zkušenosti), které dělají skvělého viceprezidenta Technical operations?“ Seznam vlastností, které jsem tehdy zmínil, odpovídal vlastnostem, o které neustále usiluji já sám. Tento článek je oné odpovědi podobný.

Jako první můžu prohlásit, že seniorní inženýr v oblasti webového vývoje a operations má ty samé vlastnosti jako seniorní inženýr v jiných oborech (strojírenství, elektro, chemie atd.), kde se uplatňují Nepsané zákony inženýrství. Opět, pokud jste nečetli, prosím učiňte tak. Kniha byla původně napsaná v roce 1994 a vydaná Americkou společností strojních inženýrů. Pěkná ukázka je zde.

Ačkoliv struktura knihy a styl působí trochu staromódně („…zdržte se klení na pracovišti…“ nebo „… muži by měli věnovat náležitou pozornost holení a zastřihování bradky a kníru…“), nastiňuje netechnická očekávání, zodpovědnost, vnitřní provoz inženýrských společností. Rovněž popisuje, jak by se manažeři a zralí inženýři mohli chovat.

Myslící muž

Zdroj obrázku: Wikipedia

Výčet povinných vlastností zralého inženýra

Všechny články, které se snaží popsat ony vlastnosti, musí obsahovat spoustu odrážek. Mezi inženýry se dost sdílí. Proto dám taky nějaké k dobru. Některé jsou z mé hlavy, jiné jsem vzal z různých zdrojů, hodně jich je z již zmíněné knihy Nepsané zákony inženýringu.

Zralí inženýři vyhledávají konstruktivní kritiku svého designu

Každý inženýr, které ho jsem potkal, se až do dokončení designu bude neustále ptát svých kolegů následující:

  • „Co jsem mohl opomenout?“
  • „Jak tohle nebude fungovat?“
  • „Můžeš prosím co nejvíc oponovat mému myšlení ohledně tohoto?“
  • „I když je to technická záležitost, je dostatečně srozumitelná pro zbytek organizace, aby ji provozovali, opravovali a rozšiřovali?“

Protože vědí, že cokoliv udělají, nikdy to nebude jen v jejich rukách, a dobré review je to, co dělá designová rozhodnutí lepšími. Jak bylo řečeno jinde: „žadoní o špatné zprávy“.

Zralí inženýři rozumí tomu, že jsou vnímáni i z netechnické stránky

Být schopný napsat Bloomův filtr v Erlagu nebo vícevláknové aplikace v C i ve spánku nestačí. Na ničem z toho nezáleží, pokud s vámi nikdo nechce pracovat. Zralí inženýři vědí, že jakkoliv úplný, elegantní nebo kvalitní je jejich design, nesejde na tom, pokud s nimi nikdo nechce pracovat, protože jsou kokoti. Povýšenost, shazování někoho, narcismus a egoistické chování vysílají signál ostatním inženýrům (možná tiše): „Nepřibližujte se!“ Součást spokojenosti v inženýrství pramení z radosti ze společnosti lidí, se kterými pracujete na designu a výrobě. Inženýr, který někoho rychle nazve pitomcem, je předurčen ke zpomalení své kariéry.

To rovněž znamená, že zralí inženýři jsou si v komunikaci vědomi vlastních kvalit. Což neznamená, že každý zralý inženýr komunikuje perfektně, pouze že mají představu, kde by se mohli zlepšit, a neustále si to ověřují u kolegů a manažerů. Snaží se o asertivitu, nikoliv pasivitu nebo agresivitu.

Už jsem to zmiňoval jinde a musím znovu zdůraznit, že míra, jak s vámi ostatní chtějí pracovat, je přímo úměrná tomu, jak úspěšný budete ve své kariéře inženýra. Buďte inženýr, se kterým chce každý pracovat.

Neříkám, že byste se měli stydět konstruktivně kritizovat (nebo takovou kritiku přijímat) práci inženýrů (na rozdíl od inženýrské osobnosti), ze strachu, že někoho naserete. Je rozdíl mezi tím nazvat někoho blbcem a poukázáním na chyby v jeho kódu. Theo poukázal na další možné oblasti, kde náš obor může dospět:

„My, stejně jako naše průmyslové odvětví, se musíme zdržet kritiky lidský povahových vlastností a podmínek, ale nesmíme se stydět kritizovat práci nebo produkt. Potřebujeme hroší kůži a schopnost přijímat kritiku skrze čočky, které se pokusí eliminovat zaměření na osobnost.
Budou existovat kokoti, ale těm bychom se měli vyhýbat. Ovšem postoj, že něčí kód je jeho dítě, by měl skončit. Kód nemá pocity, komplexy, a určitě neprojevuje nejdůležitější rys (schopnost se rozmnožovat) nést váš genom.“

Podívejte se také na body 2 a 10 z Deseti přikázání neegoistického programování (budou uvedeny v druhé části článku – pozn. red.).

Domnívám se, že vychází z knihy Nepsané zákony inženýringu (zvýraznil autor článku):

Buďte opatrní, komu posíláte kopie dopisů, poznámek…, když jsou dotčeny zájmy ostatních oddělení.
Mnoho škody bylo napácháno mladíky, kteří rozesílali zápis obsahující škodlivé nebo ztrapňující vyjádření. Pro nováčka je pochopitelně občas obtížné rozpoznat v takových dokumentech „dynamit“, ale obecně je pravděpodobné, že problémy způsobí klepnutí někoho přes prsty nebo odhalení vážné slabiny. Pokud se to týká širokého pléna, ovlivní výrobu nebo zákazníka, měli byste raději předem získat schválení od šéfa nebo si být dostatečně jistí v kramflecích.

To samozřejmě podtrhuje staromódnost knihy, ale věřím, že i v moderní éře je hlavní myšlenka stále pravdivá. Nic neznačí víc, že máte nedostatek nadhledu a povědomí, než chabě vymyšlený a nekonstruktivní tweet s jedovatou urážkou. Poplivat komplexní technologii ve 140 znacích, to je to chyba junior inženýra.

Rozhodně si takového typu veřejných poznámek všímám (podobně jako zmiňoval Christopher Brown ve své přednášce na Velocity London), abych je mohl zohlednit, kdyby se dotyční někdy ucházeli o práci v Etsy (Etsy.com – společnost, kde autor článku pracuje – pozn. red.).

Zralí inženýři se nestydí dělat odhady a vždy se v nich snaží zlepšit

Z Nepsaných zákonů:

Sliby, časový plán a odhady jsou nutné a důležité nástroje v dobře spořádaném byznysu. Mnoho inženýrů selhává, protože si to neuvědomují, nebo se zpravidla pokouší vyhýbat se protivné zodpovědnosti ze závazků. Musíte slibovat na základě svých vlastních odhadů za části, za které jste zodpovědní, spolu s odhady od spolupracujících odděleních za jejich vlastní části. Nikdo se z toho nesmí vyvléci se starou známou výmluvou: „Nemůžu to slíbit, protože to záleží na mnoha neznámých faktorech.“

Vyhýbání se zodpovědnosti za odhady je jiný způsob, jak říct: „Nejsem připravený na to, aby na mně byly závislé kritické části infrastruktury.“ Všechen byznys závisí na odhadech a všichni inženýři pracující na projektu jsou zapojeni ve společné činnosti, což znamená, že mají zodpovědnost k ostatním být předvídatelnými. Zralí inženýři obecně zvládnou pracovat s nenulovým množstvím nejistoty a rizika.

Zralí inženýři mají vrozený smysl předjímat, i když nevědí, co dělají

Tenhle kód vypadá dobře, jsem na sebe pyšný. Požádal jsem ostatní o review a zohlednil jsem jejich připomínky. A nyní: jak dlouho bude trvat, než to bude přepsané? Jak to ovlivní využití zdrojů v produkci? Jaké očekávám navýšení nebo pokles CPU/paměti/disku/sítě? Porozumí ostatní tomuto kódu? Usnadňuji ostatním rozšiřování nebo zkoumání tohoto kódu?

Zralí inženýři chápou, že ne všechny jejich projekty se skládají z práce pro rockové hvězdy

Jakkoliv podřadná a triviální se vaše úloha může z počátku jevit, věnujte jí nejlepší úsilí.

Mít vše hotovo znamená dělat věci, které vás nebaví. Nehledě na to, jak sexy projekt je, vždycky tam budou nudné úkoly. Jednotvárné úlohy. Úlohy, které by méně zralí inženýři mohli považovat pod svou úroveň nebo nehodné jejich pozice. Můj dobrý přítel, Kellan Elliot-McCrea (technický ředitel v Etsy), o tom řekl:

„Občas je skrytý půvab jednotvárných úloh v jejich jednoduchosti a projev zralosti je dokončit je rychle a pokračovat dál. Občas jsou úlohy jednotvárné, protože vyžadují extrémní disciplínu a maximální délku soustředění. Je to zvláštní jev, že nejjednotvárnější úlohy, vyřešené jen těmi nejzkušenějšími inženýry, jsou rovněž nejděsivější.“

Zralí inženýři vyzvednou schopnosti a odborné znalosti ostatních

V určitém okamžiku rozeznají, že se jejich potenciál nemůže uplatňovat osaměle. Uznají, že jednotlivec může vykonat jen určité množství práce, a že nejlepší inženýrské počiny vytvořily týmy, nikoliv jediný geniální a osamocený inženýr. Dobře to popisuje Tom Limoncelli ve svém příspěvku.

V Etsy tomu říkáme „velkorysý přístup“. Velkorysý přístup je jednou z našich klíčových inženýrských hodnot, ale také hlavní zodpovědností lidí na pozici hlavního inženýra. Tito inženýři tráví čas tím, že se ujišťují, zda juniorštější nebo nový inženýři neseznámení s technologií nebo procesy rozumí nejen tomu, co dělají, ale rovněž proč to dělají. „Učit rybařit“ je nutná dovednost pro tuto úroveň a vyžaduje jak trpělivost, tak perspektivu investic do zbytku organizace.

Takže místo: „Dobrá, uhni a nech mě to udělat za tebe,“ raději: „Dobrá, pojďme na tom pracovat spolu. Můžu ti ukázat, jak to píšu. Pak to zkusíš ty a já se podívám, jestli víš co, jak a proč dělat.“

Zralí inženýři dělají jasný kompromis ve svých úsudcích a rozhodnutích

Uvědomují si, že všechna inženýrská rozhodnutí, implementace a návrhy posuzujeme na škále, tj. nežijeme v binárním světě. Mohou rychle ukázat na kontext, kde jeden úspěšný přístup nebo řešení mohly fungovat a kde naopak ne. Vědí, že nelze být efektivní a zároveň pečlivý (princip ETTO), že většina práce leží na osách optimální a křehký a že problémy, které řeší, jsou akutní nebo chronické.

Vědí, že pracují s celým spektrem perfektní-nedokonalý a jsou s tím smíření. Snaží se totiž v návrhu jasně vyjádřit, co je perfektní a co nedokonalé. Později, když se už návrh nerozšiřuje, nebo se má nahradit či přepsat, můžou zhodnotit, jak krátkozraká jejich raná rozhodnutí byla, ale raději si řeknou: „Jasně, dostali jsme se s tím až sem a věděli jsme, že to budeme jednou muset rozšířit nebo změnit. Vypadá to, že ono jednou je teď, tak do práce!“ místo pasivní agrese: a nekonstruktivními poznámkami (jako „ty idioti to neudělali napoprvé správně!“ a „říkal jsem jim, že to nebude fungovat!” nebo „osekali zadání!“).

Existuje mnoho výstižných citátů které osvětlují pohled na kompromisy a zralí inženýři vědí, že všechny filozofií zatěžkané citáty jsou něčím omezené (včetně těch, které jsem vybral):

  • „Předčasná optimalizace je zdrojem všeho zla.“ – velmi zneužívaná zásada, už jsem o tom psal. Na to navazuje (vzato odsud) „Porozumění tomu, co je předčasné, odděluje seniorní inženýry od juniorních.“
  • „Ten správný nástroj pro práci“ – další zneužívaný. Rozumný úmysl, kdo by chtěl použít nástroj, který není vhodný? Dovedeno do extrému může napáchat víc škody než užitku. Tesař nepotřebuje všechny možné velikosti kladiv, ačkoliv by se mu někdy mohly hodit. Proč? Protože vláčet s sebou tolik kladiv, starat se o ně a vybrat si z nich představuje nějaký náklad.

Shrnutí ohledně kompromisů je, že v každém projektu se osekává zadání. Nezralí inženýři to objeví až zpětně. Zralí inženýři si to vyjasní na začátku projektu, akceptují to a berou to jako součást dobrého inženýringu.

Zralí inženýři nepraktikují CYAE (“Cover Your Ass Engineering”)

Pokud se někdo nesnaží porozumět tomu, jak jeho kód (nebo infrastruktura) může být ovlivněn ostatními částmi systému nebo byznysu, je to ztracený případ. Krytí vlastního zadku vysílá jasný signál, že jste někdo, kdo je ochotný z ostatních učinit obětního beránka, když dojde na lámání chleba. Zralí inženýři se k tomu postaví čelem a přijmou odpovědnost, která jim byla svěřena. Pokud nemají potřebnou autoritu, aby odpovědnost mohli nést, hledají způsoby, jak to napravit.

Příklad CYAE je: „Tohle není moje chyba. To oni to rozbili, použili to špatně. Já jsem to udělal přesně podle specifikace a nemůžu za jejich chyby nebo za nesprávnou specifikaci.“

Zralí inženýři jsou empatičtí

O složitých projektech obvykle rozhoduje více lidí. Designéři, projektoví manažeři, inženýři z provozu, vývojáři a obchodníci, ti všichni mají své cíle a pohled na věc. Zralí inženýři si uvědomují, že tyto cíle a pohledy se můžou lišit. Rozumí tomu, takže můžou najít správný směr své práce. Být empatický znamená být schopný vidět projekt pohledem někoho jiného a brát to v potaz během své práce.

Rozpor v cílech je vlastní veškeré inženýrské práci a stěžovat si na to (místo přijetí toho jako nutné podmínky úspěchu) je známka nevyzrálého inženýra.

Planě si nestěžují

Místo toho soudí na základě empirických důkazů a navrhují možnosti řešení problému, který identifikovali. Jeden můj skvělý manažer mi řekl, abych nikdy nechodil za šéfem s žádnou stížností, aniž bych měl alespoň jeden (v lepším případě více) návrh na řešení. I kdybyste měli ukázat jen to, že jste se problém snažili vyřešit, je lepší než plané stížnosti.

Zralí inženýři jsou si vědomi kognitivních zkreslení

Nechci tím říct, že každý zralý inženýr potřebuje diplom z psychologie, ale kognitivní zkreslení je to, co v určité fázi limituje vývoj inženýrské kariéry. I když si nejsou vědomi podrobností, jak tato zkreslení vypadají nebo jak se před nimi chránit, ti nejzralejší inženýři, které znám, si uvědomují, že jim (stejně jako ostatní) podléhají.

Jádro inženýrské denní práce je ve zkoumání empirických důkazů. Jednoduše řečeno: „Ukaž mi data!”. Potíž s kognitivním zkreslením je v tom, že můžeme být v blažené nevědomosti toho, kdy náš mozek interpretuje data způsobem, který se příčí empirickým datům, a může mít překvapivý vliv na to, jak děláme svou práci.

Podrobný výčet najdete na Wikipedii, zde uvádím seznam těch, kterým inženýři (včetně mě) padli za oběť.

  • Zkreslení sloužící sobě – Pokud je něco dobré, tak možná proto, že jsem něco udělal. Pokud je to špatné, tak to nejspíš udělal někdo jiný.
  • Základní atribuční chyba – Něčí špatné pracovní výsledky musí mít něco společného s tím, jakou má povahu (hloupý, nešikovný, lajdák apod.). Zatímco pokud mám špatné výsledky já, tak jedině kvůli vnějším okolnostem, tlaku, kterému jsem byl vystaven atd.
  • Předsudek zpětného ohlédnutí – (říká se, že jde o nejvíce zkoumaný jev v historii moderní psychologie) „Bylo mi to jasný od začátku!“ Jde o velmi silný sklon vidět minulost jednodušeji, než ve skutečnosti byla. Můžete říct, že jde o předsudek zpětného ohlédnutí, jestliže zazní „měli…, “ nebo „jak nemohli vidět, že je to tak zřejmé.“
  • Klam výsledku – Stejně jako předchozí se objevuje po překvapivé nebo negativní události. Pokud událost způsobila velkou škodu (je drahé se s ní vypořádat) nebo byla závažná, tak jsou rozhodnutí nebo akce, které k tomu přispěly, hodnoceny jako velmi hloupé, lehkovážné nebo nedbalé. Odsouzení je přímo úměrné závažnosti události.
  • Optimistické plánování – Být optimističtější v odhadech, kolik času daný projekt zabere.

Existuje spousta dalších zkreslení a všechny mě fascinují. Mohl bych trávit hodiny jejich studiem. Doporučuji si o nich víc přečíst, pokud vás zajímá, jak může být omezena vaše efektivita.

Pokračování příště

Druhou část uvedeme za týden v samostatném článku.

Komentáře

Subscribe
Upozornit na
guest
19 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
AugiCZ

To formátování je strašný – nedá se to číst :(

Martin Hassman

Co přesně ti vadí? Já to čtu v pohodě, tak netuším.

Martin

Obludné mezery mezi odstavci, odstavce obsahující sotva jeden řádek textu, často dokonce několik takových odstavců za sebou, chaotické používání kurzívy – fakt vám nic z toho nevadí? No ale co na tom, on ani ten obsah za moc nestojí.

Martin Hassman

On zrovna ne každý obsahu tohodle článku dorostl. Drželi jsme se originálu, mně se to čte dobře, proto si zjišťuji detaily. 8-)

AugiCZ

Ano, přesně tyhle problémy s formátováním jsem myslel.
Jinak ten obsah mi taky nepřijde nic moc – autor tam hrozně přeskakuje z myšlenky na myšlenku a dohromady to působí dost nesourodě (~hromada výkřiků poskládaných bez ladu a skladu za sebe).

martin

To bolo myslene ako priklad „neseniorskeho“ pristupu ;)

Pavel Lang

A kde je to „já bych to napsal líp…“? Není to sdělení toho článku — přijít s návrhem (a ne s nekonstruktivní kritikou)?:-)

No přiznávám, že jsem to přečetl s jednou odbočkou (psal jsem email úplně o něčem jiném)…

Článek byl o emocích, které junioři mají. A musím přiznat, že naučit se respektovat kolektiv je největší výzva pro každého očarovaného supernadaného sólo programátora/kodéra/kohokoliv… Výtky (na chování lidí k lidem) z tohoto článku se dají aplikovat obecně.

Díky za počtení

Martin Hassman

Nestačí, že tu už je nic moc a špatně se to čte? 8-)

Pavel Lang

A je to trefná poznámka. Odkazovaný článek má pravdu, ale o čem bychom psali, kdyby to občas někdo neudělal? A musím říct, že jsem se dost poučil a měl jsem dost volnosti na to, abych tyhle chyby dělal taky. A kdo si to nezkusí, bude věřit tomu, že to tak není.

A proto je občas potřeba oholit vousy a podívat se proti větru, aby to pěkně zaštípalo :-)

Málokdo se učí z cizích chyb a je nesmysl tvrdit, že „ jsem to nikdy neudělal“, takový člověk nerozumí právě ani sám sobě, nehledá kritiku a čtení tohoto článku je pro něj zbytečné :-)

Radek

Připomíná mi to výčet vlastností dokonalého muže:

  • nekouří
  • nepije
  • neexistuje
Pavel Lang

Chybí mi tu [I like it!] :-)

foobar

.. a co kdyz tu je?

Martin Pecka

Styl prekladu se mi nelibi – velmi spatne se Cechovi cte. Nez to prekladat z anglictiny mechanicky, to uz by tu radsi mel byt jen odkaz na original. Od ceskeho prekladu ocekavam cesky slovosled, hezke ceske vety atd. Toho je v tomto clanku opravdu poskrovnu. Mohu-li se primluvit, ve druhe casti radeji obetovat trochu presnosti prekladu na vrub citelnosti.

Martin Hassman

Tenhle text byl na překlad poměrně náročný, přiznávám, že já osobně jsem se na jeho překlad necítil a jsem rád, že se toho Luboš chopil. Já myslím, že výsledek je dost dobrý; tohle není beletrie, nesoutěžíme o cenu Karla Čapka. Pokud můžete uvést kontrétní problematické případy, které se v textu opakují, budeme rádi, prostor pro zlepšení tu rozhodně je.

Xmen

Mozno by nebolo zle nahradit ten vulgarzimus inym slovom alebo ho aspon ciastocne vyhviezdickovat. Predsa su tu hlavne odborne clanky tak nebudme prasata.

Martin Hassman

To je pěkný příklad jazykové bariéry, v češtině to slovo totiž vulgární není a mě při schvalování článku nenapadlo, že ve slovenštině je to jinak. Omlouváme se, ale měnit to teď už nebudeme.

Anonymous

Coze? Vzdyt „kokot“ je do vyznamu i sprostosti stejny jako slovo „curak“. To, ze tak bezne mluvi Kalousek, je vec jina.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.