O mně

K programování jsem se dostal v roce 2004. Od začátku jsem pracoval na systémech s přímým dopadem na provoz firem. Poměrně brzy jsem pochopil, že dodávat funkce je jen část práce. Ta důležitější část spočívá v domýšlení důsledků technických rozhodnutí – pro data, procesy i lidi, kteří se na systém denně spoléhají.

Vývoj pro mě nikdy nebyl izolovaná technická činnost. Vždy byl součástí širšího kontextu provozu, odpovědnosti a reálných dopadů.

Moje práce se postupně posouvala od implementace jednotlivých částí k navrhování řešení, která obstojí v reálném provozu. Nevnímám to jako skoky, ale jako navazující etapy:

• Podnikové systémy a ERP – provoz, procesy a data v každodenní realitě.
• Globální platformy – core business logika a pravidla, která musí zůstat konzistentní v čase.
• Bankovnictví a energetika – stabilita, bezpečnost, auditovatelnost a odpovědnost za produkční provoz.
• Zdravotnictví – software, který musí fungovat spolehlivě v konkrétních situacích.
• Nezávislá praxe – role technického partnera a práce s dlouhodobým přínosem.

První výrazná část mé profesní dráhy byla spojená s podnikovými systémy v reálném provozu. Nešlo o izolovaný vývoj, ale o systémy, které denně používali lidé napříč firmou – od provozu až po vedení.

Zažil jsem situace, kdy kvůli chybě nebylo možné prodávat ani vyrábět, kdy byla zablokovaná fakturace nebo kdy se do účetnictví propsala špatná data. Samotná oprava bývala často rychlá, ale testování a bezpečné nasazení do produkce trvalo další hodiny. Rozdíl mezi „opraveno" a „bezpečně v provozu" byl v těchto chvílích velmi konkrétní.

Ne všechny kritické problémy měly čistě technickou příčinu. Často šlo o kombinaci složitosti systému, nedomyšlených souvislostí a rozhodnutí mimo samotný vývoj. V takových situacích nebylo cílem hledat viníka, ale pochopit celý řetězec příčin a vrátit systém do stabilního stavu.

Občas to znamenalo i řízené zásahy přímo do databáze. Vždy jako krajní řešení – vědomé, dohledatelné a provedené s jasným plánem, jak zabránit opakování stejného typu problému.

Na globální ERP platformě jsem se podílel na vývoji core business logiky, zejména daňového enginu. Šlo o centrální část systému, která ovlivňovala chování celé platformy napříč různými typy dokladů a scénáři.

Každá změna byla zásahem do existujícího chování systému. Napsání kódu bylo často ta jednodušší část. Těžší bylo domyslet dopady změny a zajistit, že systém zůstane konzistentní i po dalších úpravách. Změny se zaváděly k jasně definovanému datu a často zahrnovaly i transformaci existujících dat.

Odpovědnost pro mě nekončila merge requestem. Důležité bylo, aby systém zůstal dlouhodobě předvídatelný, udržitelný a srozumitelný i pro další vývoj.

V bankovním prostředí jsem pracoval s rozsáhlou architekturou a přísnou bezpečnostní politikou. Systémy byly rozdělené do velkého množství částí a vyžadovaly koordinaci napříč týmy i rolemi.

Moje role spočívala ve vývoji, orientaci v architektuře a hledání řešení, která byla technicky správná, bezpečná a realizovatelná v rámci existujících procesů. U změn s vyšším rizikem jsem rozhodnutí nekoncentroval jen na sebe – konzultoval jsem je a aktivně hledal protiargumenty.

Některá rozhodnutí byla nepopulární, ale považoval jsem za důležitější nést krátkodobé napětí než dlouhodobé následky špatně zvoleného řešení.

Většinu kariéry pracuji v týmech. Jen výjimečně se stává, že bych fungoval úplně sám. Často působím jako mentor – aktuálně spolupracuji s přibližně deseti lidmi napříč projekty a technologiemi.

Když týmu chybí směr nebo technické vedení, pomáhám nastavit rámec: cíl, priority, způsob rozhodování a ověřování dopadu. Ne formálně, ale prakticky – vytvořením struktury, ve které může tým fungovat efektivně.

Už v první praxi jsem se stal zástupcem vedoucího programátorů. V prostředí NetSuite jsem byl prvním vývojářem na projektu a postupně jsem technicky vedl tým složený z vývojářů, QA a business rolí. Nešlo o řízení lidí shora, ale o jasný směr, rozhodování a předvídatelné dodávky.

Mentoring a technické vedení pro mě nejsou role, ale přirozený důsledek způsobu, jakým pracuji.

Podílel jsem se na vývoji mobilní aplikace pro telemedicínu v React Native. Aplikaci používali pacienti i lékaři v situacích, kde nebyl prostor pro složitost nebo nejasnosti.

Důraz byl kladen na bezpečnost dat, stabilitu, práci s výpadky konektivity a srozumitelnost ovládání. Tahle zkušenost mě utvrdila v tom, že dobré řešení není nutně to nejsložitější, ale to, které funguje spolehlivě ve chvíli, kdy na tom skutečně záleží.

Od roku 2022 pracuji jako nezávislý vývojář a technický konzultant. Klienti mě často oslovují ve chvíli, kdy je potřeba stabilizovat systém, najít příčinu problému a bezpečně vrátit provoz do normálu.

Když přebírám odpovědnost, nedělám to impulzivně. Dělám to ve chvíli, kdy rozumím problému, dokážu si spočítat rizika a vidím realistickou cestu k řešení. Pokud tomu nevěřím, odpovědnost nepřebírám – ne proto, že bych se jí vyhýbal, ale proto, že falešná jistota je v kritických systémech nebezpečná.

V krizových situacích si chráním prostor na soustředění. Otevřeně komunikuji, co dělám, kdy se ozvu a jaký je další krok. Zbytečný tlak a neustálé vyrušování považuji za riziko – ne pro sebe, ale pro výsledek. Klid a koncentrace jsou v těchto chvílích součástí řešení.

Dlouhodobě prosazuji postupné dodávky změn. Dodávat příliš mnoho změn najednou výrazně zvyšuje riziko a zároveň snižuje schopnost systém rychle opravit, pokud se něco pokazí.

Projekty beru jako společnou práci na řešení, ne jako seznam úkolů. Zajímá mě kontext, cíl a dopad rozhodnutí. Když něco nedává smysl, říkám to otevřeně a prezentuji to jako podklad k diskuzi.

Existují hranice, za které nejdu. Pokud se má systém měnit bez jasného cíle, bez pochopení dopadů nebo pod tlakem „hlavně rychle", považuji za svou povinnost to říct. Krátkodobý klid nikdy nevyměňuji za dlouhodobé riziko.

Používám moderní nástroje včetně AI asistence. Pomáhají mi zrychlit analýzu a odbavit rutinu, ale architektura, rozhodnutí a odpovědnost zůstávají vždy na mně.

Nezůstávám na projektech setrvačností. Zůstávám tam, kde vidím vlastní přínos.