Bystroushaak's blog / Czech section / Programování / Jak se stát programátorem / Jak se začít živit programováním

Jak se začít živit programováním

Většina toho, co jsem popsal v Jak a proč se stát programátorem je vhodná pro naprosté začátečníky, protože ti mi reálně píšou. Nyní bych se ale rád zaměřil i na středně pokročilé programátory, kteří se rozhodli začít programovat komerčně.

👉
Pokud patříte mezi pokročilé programátory, možná vás spíš zaujme Algoritmus hledání programátorské práce 2021/4.

Dejme tomu, že jste se řídili mými radami, nebo možná ne, ale nyní umíte naprogramovat prakticky cokoliv, co vás napadne a není to příliš složité. Máte za sebou několik let programování, desítky, nebo stovky osobních projektů. Programy o velikosti od několika set po několik (desítek) tisíc řádek.

Narozdíl od začátečníků nebojujete s programovacím jazykem - máte ho v krvi a když píšete program, nemusíte googlit a slepovat kód z kusů, které najdete na internetu, ale prostě začnete psát a občas mrknete do manuálu, když si nejste jisti konkrétní funkcí. Knihovnu vašeho programovacího jazyka neznáte úplně nazpaměť, ale víte, které funkce tam přibližně jsou a které nejsou, co tam hledat a co ne. Víte kdy je vhodné sáhnout po již existujícím kusu API, či knihovně, a kdy implementovat vlastní funkčnost.

Co dál?

Jako začátečníci jste to měli lehké a cíl byl jasný - ovládnout programovací jazyk, který jste si vybrali, naprogramovat toho v něm co nejvíc, bavit se a zlepšovat se. Nyní jste však dospěli do bodu, kdy je programovací jazyk vaší součástí, kdy se z toho stal skoro způsob, jak přemýšlíte a tak se může stát, že najednou nevíte, co dál.

Věřte mi, že cíl se zas tak moc neliší - stále spočívá v učení se a zlepšování, ve snaze umět toho víc, být schopnější. Jen nyní tuto snahu přenesete ze samotného programovacího jazyka na programátorské řemeslo a na vás samotné.

Staňte se odborníkem

Ve chvíli, kdy zvládnete naprogramovat užitečné projekty se z vás stal programátor. Programátorů jsou ale na světě stovky tisíc. Co zrovna vás odlišuje od ostatních? Odborník se od amatéra pozná tím, že ví co dělá, jak to má udělat a je ve svém oboru maximálně efektivní. Je pěkné, že umíte programovat, ale umíte také tvořit elegantní programy? Dodržujete štábní kulturu danou jazykem, nebo si jedete podle svého?

Tenhle přídavek bych chtěl věnovat všem, kteří přemýšlejí, jak se stát skutečným programátorem, který je za to placený.

Hledání zaměstnání

Ve chvíli, kdy si řeknete, že už toho umíte dost a budete o tom přesvědčeni, přijde čas na hledání zaměstnání. Jak na to?

Vybudování portfolia

Jako programátor začátečník, ale i jako pokročilý programátor byste si měli vybudovat portfolio. Nějakou stránku, kde bude na jednom místě uvedené všechno, co jste kdy dělali, ideálně i s ukázkami kódu.

Naprosto ideální je v tomhle github. Ten jednak ukazuje, že se angažujete v opensource a baví vás to, ale také ukazuje přímo váš styl práce. Jakožto programátor a váš budoucí šéf, či kolega se můžu podívat jakým způsobem přemýšlíte, jak píšete kód, jak zvládáte abstrakci a tak dál. Taky vidím, že jste ovládli alespoň základy GITu (tomu se pak věnuji v dalších kapitolách).

Dokonce i když skoro nic neumíte a jste jen začátečníci, stejně házejte všechny svoje věci na github. I když to budou jen jednoduché projekty, implementace domácích úkolů, a tutoriálů, tak vám to nemůže uškodit, jen pomoct.

Tohle mi například sehnalo první práci. Poslal jsem životopis a v něm odkaz na github. Na pohovoru jsme se pak bavili jen o mých projektech, místo abych musel dělat testy a dokazovat jak moc jsem užitečný a kolik toho umím. Věřte mi, že jsem se mnohem radši bavil o svém projektu, kde jsem mohl vysvětlit proč jsem se rozhodl k tomu kterému řešení.

Hledání práce

Poté co si sepíšete pěkný přehledný životopis na maximálně dvě A4 strany (víc nikoho nezajímá a nikdo to číst nebude), přijde čas najít si konkrétní práci. Pokud máte štěstí, dohodí vám jí kamarád, nebo známý. Pokud ne, musíte si jí najít sami. Jak na to?

Z velké míry stačí procházet jednotlivé inzeráty na jobsech, startupjobsech a podobných portálech a posílat jako odpověď svůj životopis na nabídky, které se vám zamlouvají. Taky můžete procházet i jednotlivé weby různých firem, občas tam bývá záložka zaměstnání, nebo kariéra.

Předně bych rád řekl k inzerátům - naprosto nehleďte na to, co v nich je napsáno. Inzeráty píší lidé, kteří nemají vůbec tušení, jak to reálně chodí, ani co bude vaše práce. Úplně můžete ignorovat požadavky na vzdělání, to nikoho reálně moc nezajímá. Vykašlat se taky můžete na většinu technologií, které zaměstnavatel hledá, s dvěma výjimkami:

Zbytek je více/méně omáčka, kterou jeden zaměstnavatel opisuje od druhého a nikdo pořádně neví co chce, ani co to znamená a když už náhodou ano, tak stejně rádi přijmou člověka co je ochotný se to naučit, i když to zrovna teď neumí.

Tohle je mimochodem moje první rada k pohovoru. Když se vás zeptají, jestli umíte technologii X a vy jí neumíte, nelžete o tom. Prostě s klidem řekněte, že jste s X nikdy nedělali, dělali jste s Y, které je možná trochu podobné, ale nemáte problém se X doučit za běhu, s tím plně počítáte, to je přece samozřejmé v každé práci, ne?

Tím jednak zanecháte dobrý dojem, protože nemáte důvod si vymýšlet (nikdo neumí všechno), ale taky ukážete, že jste ochotní se učit a berete to jako samozřejmost.

O co jde u programátorského pohovoru

Za poslední tři roky jsem byl několikrát u nabírání nových lidí jako technický konzultant. Vyjadřoval jsem se k životopisům, seděl jsem na přijímacích pohovorech a pokládal zájemcům o práci otázky, abych zjistil, jestli skutečně mají znalosti, které prezentují v životopisu, nebo ne.

O co nám v těch firmách kde jsem pracoval u pohovoru šlo?

Ze všeho nejmíň nás zajímalo, kolik technologií uchazeč o zaměstnání umí, pokud vynechám samotný programovací jazyk. Osobně jsem vždycky chtěl vědět především co pro něj programování znamená. Je to pro něj jen práce, nebo i koníček? Baví ho to? Je schopný se sám učit?

To poslední pro nás vždy bylo nejvíc podstatné, protože nikdo kdo k nám přijde neumí všechno, co používáme. Každá firma kde jsem pracoval měla hodně unikátní řešení, někde se používala izraelská zařízení za desítky milionů, jinde historicky existovala vlastní implementace message queue, v další jsme zase používali nově vzniklé technologie, o kterých skoro nikdo neslyšel (specifická time series databáze).

Šance, že člověk, který k nám nově přijde, bude tohle všechno umět je v praxi nulová. Chtěli jsme vědět, že se nováček bude umět, a hlavně bude ochotný učit. Že se nelekne a neuteče po prvním týdnu, ani nebude mít depresi, že to nikdy nezvládne.

Každý z nás takhle začínal. Po přijetí na nás firma navalí tolik věcí, že trvá týden jen si udělat základní představu a celé měsíce až roky než člověk získá detailní přehled. Každý má chuť utéct, když vidí tu horu, jenž bude muset zdolat. Co mají programátorské pohovory za úkol je oddělit lidi, kteří na to nemají od těch, co ano.

Selhání

Pokud selžete, neberte si to osobně. Pravděpodobně přišlo víc programátorů, nebo to prostě nebyla firma pro vás. Moc nad tím nepřemýšlejte. To se prostě stává a stávat bude. Jednoduše se seberte a zaspamujte dvacet dalších inzerátů, dokud nedostanete další nabídky.

Když jsem byl kdysi odmítnut po prvních asi pěti pohovorech, dost mě to štvalo a dodneška si to pamatuji velmi výrazně. Časem jsem ale pochopil, že to je všechno neosobní a nemá smysl se tím moc zabývat. Tak to prostě je a bude, a nic to neznamená.

Úspěch

Dřív nebo později se vám to povede. Potom nastává většinou čas na prohlídku u doktora a poté nástup do zaměstnání.

Prvních čtvrt roku budete většinou ve zkušební době. To znamená, že vás zaměstnavatel může kdykoliv bez důvodu vyhodit a taky vy můžete kdykoliv odejít. Po dobu zkušebky je dobré chodit přesně na čas, snažit se být sociální a projevovat iniciativu. Obecně se snažit zanechat dobrý dojem.

Věci, které se musíte naučit

Jak jsem psal - nikdo nezná všechno a firmy s tím ve většině případů počítají, speciálně pak na juniorských pozicích. Co se tedy budete muset všechno naučit?

Projekt, na kterém pracujete

Předně samozřejmě musíte pochopit projekt, na kterém pracujete. Tohle bývá většinou největší nálož, protože v případě libovolného týmu nebývá zrovna malý, obsahuje integrace se spoustou systémů, běží na spoustě serverů a ve většině případů nebývá dobře zdokumentován.

Výhodou naopak je, že se můžete ptát kolegů, což vám doporučuji se naučit hned ze začátku.

Teamová komunikace

Obecně si uvědomte, že odteď nejste sami za sebe, jste součást teamu. Lidi se na vás budou spoléhat, že uděláte vaší práci, a stejně tak se budete spoléhat vy na ostatní, že udělají tu jejich.

Také pravděpodobně dostanete svého mentora - někoho, kdo vám bude radit, zaškolovat vás do základů práce a kdo bude zodpovídat za to, že se neztratíte. Zvykněte si se s ním bavit o systému a práci.

Pokud něco nevíte, prostě se zeptejte, jestli má čas („máš na mě chvilku?“) a ptejte se a nechte si to vysvětlit. Piště si poznámky.

Většina firem bude mít taky způsoby elektronické komunikace. Email, někde mívají Jabber, spousta společností má poslední dobou Slack, nebo nějakou alternativu.

Zvykněte si komunikovat se všemi lidmi ve firmě, i když to může být ze začátku docela zastrašující. Například vám kolega mentor řekne, že neví, ať se dojdete zeptat adminů. Mentálně se připravte, že tohle se bude stávat každou chvíli.

Code review

V mnoha firmách je také běžné, že než bude váš kód začleněn do firemního repozitáře, někdo jiný se k němu bude muset vyjádřit a zkritizovat ho. Stejně tak vy se budete muset pravidelně vyjadřovat ke kódu vašich kolegů. Cílem je samozřejmě vyhnout se špatnému kódu a špatným rozhodnutím.

Kritika

Dříve nebo později se vám to určitě stane - někdo se podívá na váš kód a celý ho zkritizuje. Pokud budete mít štěstí, řekne jen, že se jedná o špatný kód. Pokud ne, tak řekne, že jde o největší sračku, kterou kdy viděl a měli byste to celé zahodit a předělat a že kdyby to napsal on, tak se jde zabít.

Neberte si to osobně.

Stalo se to mně, stalo se to ostatním. Sám jsem to udělal. Stane se to i vám.

Je dobré si uvědomit, že kritika není útokem na vás. Vy a výsledky vašich činností jsou dvě zcela rozdílné věci. Když někdo kritizuje vaši práci, říká vám, že byste se měli zlepšit, nikoliv, že jako člověk jste špatní. Berte to jako podnět pro další rozvoj, ne jako útok.

Myslete na to i když budete dávat kritiku. Bývalý kolega v minulé práci rozbrečel svojí kritikou jiného kolegu tak, že se z toho zhroutil a utekl z práce a už nechtěl nikdy přijít. Šéf ho pak musel přesvědčovat až do půlnoci, aby výpověď nedával a že kritika kódu není kritikou jeho samotného. Myslete na to, až budete kritizovat.

Štábní kultura

Každý team má nějaké svoje pravidla ohledně toho, jak psát kód. Používají se k odsazování tabulátory, nebo mezery? Jak dlouhé jsou řádky? Jak se rozdělují dlouhé metody? Používá se spousta parametrů, nebo se vytváří wrapper objekt?

Podobných otázek bude spousta a každý team by měl mít někde na interní wiki tato pravidla popsaná.

Verzovací systémy

V naprosté většině případů půjde dneska o GIT, občas Mercurial, nebo SVN. Opět platí, že se musíte učit za běhu.

Ve zkratce jde o způsob, jakým sledujete změny ve zdrojových kódech a jak tyhle změny dodáváte kolegům tak, aby nedocházelo ke konfliktům. Dneska je pro mě naprosto nepředstavitelné, že bych kdy mohl pracovat bez nějakého systému na správu verzí. Nestačí ale jen umět verzovat samotný projekt, nutná je také schopnost používat verzovací systém ve více lidech.

Když jsem nastupoval do první firmy, uměl jsem používat základy GITu, protože jsem měl vlastní github. Nikdy dřív jsem ale nepracoval v teamu, a tak jsem se musel naučit jak s GITem pracovat, aby jsme se přitom vzájemně nezabili a aby nedocházelo ke konfliktům. Doporučuji se to naučit dopředu, alespoň si tak odlehčíte po nástupu.

Určitě si nastudujte „gitflow“, většina firem bude používat buď přímo toto, nebo něco hodně podobného. Naučte se tagovat, vytvářet různé branche, mergovat, cherrypickovat commity. Není to tak těžké a za den se dá většina z toho pochopit.

Unittesty

Začátečníci a neprofesionálové typicky hodně zanedbávají unittesty a o integračních testech většinou ani neslyšeli. Minimálně unittesty by měl mít každý projekt a osobně si už vůbec neumím představit, že bych někdy pracoval na libovolném projektu bez nich.

O co jde? Ve zkratce jde o to, že na každou funkci, každý objekt a každou metodu, kterou budete v kódu mít napíšete test, který kontroluje, jak se chová. Je to pracné, možná pracnější, než samotné programování funkcionality, ale z dlouhodobého hlediska se to rozhodně vyplatí a umožní vám to provádět změny bez starosti o to co jste svými úpravami zrovna rozbili.

Zjistěte si, co to všechno obnáší. Použijte je na vlastní projekty. Tohle je něco, co po vás bude každý zaměstnavatel zcela jistě chtít, vyplatí se být připraven.

Osobně jsem unittesty začal používat asi čtvrt roku před nástupem do první programátorské práce a hodně mi to pomohlo.

Dokumentace

Ještě jsem nepotkal začátečníka, který by uměl správně dokumentovat kód. Celá problematika se dá rozdělit na dvě úrovně:

Technická

Kód se dá dokumentovat na mnoha úrovních. Pravděpodobně jste všichni slyšeli o komentářích. Ty vysvětlují některé části kódu. To je první úroveň, kterou většinou zvládají i začátečníci.

# is the file/unpacked archive in this `path`?
if file_hash in files:
    full_path = os.path.join(path, file_hash)
 
    if os.path.isfile(full_path):
        return PathAndHash(path=full_path, hash=file_hash)
 
    return PathAndHash(path=full_path + "/", hash=file_hash)

Druhá úroveň jsou docstringy. Tedy dokumentace jednotlivých metod. Zde už mají začátečníci většinou problém, protože sami pro sebe většinou nemají potřebu kód moc dokumentovat a tak se to nemají kde pořádně naučit:

def _get_hash(self, file_obj):
    """
    Compute hash for the `file_obj`.

    Attr:
        file_obj (obj): File-like object with ``.write()`` and ``.seek()``.

    Returns:
        str: Hexdigest of the hash.
    """
    size = 0
    hash_buider = self.hash_builder()
    for piece in self._get_file_iterator(file_obj):
        hash_buider.update(piece)
        size += len(piece)
 
    file_obj.seek(0)
 
    return "%s_%x" % (hash_buider.hexdigest(), size)

Třetí úroveň je externí dokumentace a zde jsem ještě neviděl jediného uchazeče o zaměstnání, který by jí zvládal. Jedná se o externí soubory, které popisují celý projekt, obsahují například obrázky, ale i všechny docstringy ze všech modulů a metod. Jak to vypadá je možné vidět například tady:

Všimněte si, že tato dokumentace obsahuje i informace o tom, jak projekt nainstalovat, jak spustit testy, kde se nachází, jak ho použít, jaké jsou v něm komponenty a tak podobně.

Pokud děláte v pythonu, podívejte se na Sphinx (a napoleon!), jinak třeba doxygen, javadoc a tak podobně.

Filosofická

Filosofická úroveň se zabývá tím, co má a co nemá smysl psát do dokumentace. Například naprostá většina začátečníků píše první úroveň dokumentace (komentáře v kódu) špatně a vysvětluje co se v kódu děje, místo aby vysvětlovali proč se to děje.

Taky ukázka druhé úrovně - docstringů u metod - by mohla být v některých jazycích považována za příliš ukecanou. Problém je, že python je dynamický jazyk, takže většinou dokumentaci tohohle typu časem opravdu oceníte, a když už ne vy, tak vaši kolegové určitě.

Dokumentací se dále zabývají knihy zmiňované v kapitole níže.

Packaging

Stejně jako pokročilejší dokumentaci, ještě jsem nepotkal začátečníka, který by uměl svůj kód zabalit. Jakmile budete někde pracovat, s velikou pravděpodobností budete muset váš kód i nějak distribuovat, když už ne k zákazníkům, tak na cílové servery, kde poběží.

V případě pythonu se to řeší balením tak, aby se jednotlivé balíčky daly nainstalovat pomocí PIPu. Cest jak toho dosáhnout je několik, proto si vygooglete tu svojí.

Například výše uvedený balíček systému edeposit je možné nainstalovat příkazem:

pip install -U edeposit.amqp.ltp

A takhle se také instaluje a updatuje na serverech. To je možné díky tomu, že se jedná o opensource. V případě closed source možná budete mít vlastní repozitář, nebo třeba budete vyrábět .deb balíčky, nebo sestavovat binární distribuce.

K balíčkování patří také specifikace závislostí. Používá váš kód nějakou knihovnu? V jaké verzi? Jste si jisti, že má správnou licenci? Jak se bude instalovat, kde bude specifikovaná jako závislost, kdo se bude starat o updatování na nové verze?

Je dobré se to trochu naučit předem. Podívejte se na různé systémy a udělejte si přehled alespoň abyste věděli co je co.

Deployment

Tohle je kapitola sama o sobě, která velmi záleží na tom co konkrétně se kde používá. Už jsem zažil všechno od ručního kopírování balíčků na server, po interní repozitáře a systémy ala puppet, a v poslední době taky spoustu věcí kolem kubernetu, jenkinsu, spinnakeru a tak podobně.

Osobní rozvoj

Jakmile budete mít základy za sebou, je dobré nezatuhnout na úrovni na které jste až do důchodu, protože jinak vás dříve nebo později někdo nahradí, nebo práce začne nudit.

Knihy

Pro středně pokročilé programátory určitě doporučuji následující knihy:

Tyhle knihy vás nebudou učit jazyky, nejsou to učebnice v tom smyslu, v jakém jste se nimi setkávali dřív. Naučí vás jak si ušetřit práci, co dělat a co nedělat. Naučí vás přemýšlet o programování jinak a psát elegantní a kvalitní kód.

Architektura

Jakmile za sebou budete mít pár projektů, začnete vidět vzory v tom jak se vlastně aplikace vytvářejí, co se pořád opakuje, co je dobré dělat a nedělat, jak navrhnout větší systémy a čemu se raději vyhnout. Tomu se obecně říká architektura.

Začátečníkům to nebude moc platné, ale pokročilejším uživatelům určitě nelze než doporučit se o architekturu zajímat. Sežeňte si knihy na tohle téma, bavte se o tom s kolegy, diskutujte o tom na internetu, pište a čtěte blogy.

Algoritmy

Stejně tak je dobré si pořídit knihy o algoritmech, nebo se zapsat někam na courseru a učit se psát efektivní algoritmy. S tím se setkáte i v každodenní práci, minimálně na úrovni odhadování složitosti vašeho kódu pomocí něčeho, čemu se říká Big O notace.

Tohle časem určitě budete potřebovat, o algoritmy je ale dobré se zajímat i obecně.

CompSci

Jak říká Alan Kay: „Úhel pohledu stojí za 80 bodů IQ.“ Co tím myslí? Že se vyplatí stát na zádech gigantů, protože dohlédnete dál.

Computer science je obor starý desítky let, ve kterém extrémně inteligentní lidi vymysleli extrémně inteligentní teorie a nápady, prošlapali schůdné cesty a našli cesty, které schůdné nejsou.

Je dobré mít o tom představu. Stejně tak je dobré se naučit různé „exotické“ jazyky, které nejsou mainstream. Erlang, Lisp, Smalltalk, Haskell. Všechny vám masivně zvednou přehled a změní způsob myšlení, i kdybyste je pak už nikdy nepoužili.

Become a Patron