Seniorita je pojem z oblasti společenských vztahů. Vyjadřuje nadřazenost osoby nebo skupiny na základě vyššího věku nebo délky zastávání určité pozice. Takže senior je buď člověk staršího věku nebo pracující déle na nějaké pozici. Junior je autonymum.
Tímto příspěvkem se pokusím odpovědět na tyto komplexní otázky:
- Jak je definována "kvalita vývojáře"?
- Jak vlastně délka profesní kariéry souvisí s vlastní kvalitou vývojáře?
Dlouho jsem přemýšlel nad tím, jak téma uchopit. Nakonec jsem dal dohromady několik vstupů:
- moje pozorování kolegů a toho, co se mi na jejich profesním chování líbí,
- reakce lidí na můj anketní tweet,
- seznam znalostí a dovedností, které považuji za důležité.
A výstupem se stal Honza.
Honza je kompendiem zkušeností a profesní efektivity. Je to kombinace mnoha profesních rolí - architekt, analytik, programátor, manažer, projekťák, atd. A také je to někdo, kdo reálně neexistuje. Je to ideál vývojáře, na kterém si zkusíme popsat, co všechno může mít na naši práci pozitivní vliv.
Honzův profil by nám tedy mohl pomoci s odpovědí na první otázku. Na tu druhou si odpovíme ke konci příspěvku.
Honza a práce
Honza je pracovitý a vytrvalý. To je základ.
Nevyhýbá se úkolům. Samozřejmě chápe, že práce bude vždy více než je dostupného času. Snaží se proto správně pracovat s prioritami. Rozumí, že každá záležitost obnáší investici ve formě času a generuje určitou hodnotu. Nenechá se odlákat od aktuálního prioritního úkolu pouze tím, že se právě objevil méně prioritní ale zato atraktivnější úkol.
Umí dotahovat úkoly ke zdárnému konci. Nenechá se odradit překážkami. Je orientovaný na výsledek. Ne však na úkor kvality. Má soubor profesních zásad, které dodržuje i pod projektovým tlakem. Na druhou stranu ví, kdy je z nich možné a vhodné mírně ustoupit a jaké to bude mít důsledky. Ty je potřeba správně komunikovat.
Má vybudované návyky, které mu pomáhají dělat práci efektivně. Umí si den rozdělit do delších bloků hluboké práce bez vyrušování. Umí si organizovat inbox a backlog přes všechny své profesní role. Reaguje na pracovní požadavky podle jejich důležitosti. Umí říkat NE.
Honza a kolegové
S Honzou je příjemné pracovat.
Čím komplexnější projekt, tím větší tým a tím důležitější chemie mezi lidmi. Honza si důležitost vztahů uvědomuje. Je empatický. Chápe rozdíly v typologiích osobností. Dokáže být asertivní.
Nezdůrazňuje svoji senioritu v týmu. Respekt si buduje svojí profesionalitou a tím, že respektuje ostatní. Povzbuzuje své kolegy k samostatnosti a k tomu nebát se zkoušet nové věci a hledat optimálnější řešení. Spoluvytváří pozitivní atmosféru, ve které se všem dobře pracuje. Svůj názor se snaží prosadit věcným způsobem.
Honza je pokorný. Nemá ve zvyku neustále hledat problémy pouze u druhých, když se něco nepodaří. Začně tím, že si vyhodnotí svůj podíl na problému jako první. Chápe, že i on dělal, dělá a bude dělat chyby. Nevymlouvá se, když se mu něco nepovede. Vysvětlí okolnosti, které vedly k jeho chybě a upraví své pracovní postupy a chování tak, aby se stejná chyba v budoucnu neopakovala.
Snaží se konfliktům předcházet a pokud už nastanou, tak je zmírňovat. Pokud něco nefunguje, neuchyluje se k osobní kritice kolegů. Je věcný. Nepomlouvá. Snaží se aktivně hledat příčiny problémů a ty pak konstruktivně řešit. Dokáže konstruktivně přijmout zpětnou vazbu na svoji práci. Pokud sám zpětnou vazbu poskytuje, pak nekonfliktním způsobem. Kolegové tak nemají pocit, že jsou kritizováni, ale že jsou podporováni k lepším výsledkům.
Honza zná základní principy koučinku a umí je v praxi použít. Pomáhá tím kolegům v uvědomění si jejich aktuální profesní situace a toho, kam by se mohli posunout a jakým způsobem. Takto přirozeně tým rozvíjí a pomáhá jeho členy motivovat.
Mluví otevřeně a transparentně. Buduje důvěryhodné prostředí, nemanipuluje s informacemi, poskytuje je všem konzistentním způsobem. Kolegy nezdržuje přílišným tlacháním na poradách.
Honza jako architekt řešení
Honza už chápe, že zákazník na začátku projektu často přesně neví co chce. Honzu netrápí, že nemá často přesné zadání. Chápe to jako příležitost pomáhat zákazníkovi už od začátku s hledáním řešení. Co jej občas trápí je, když se po něm chce estimace příliš hrubého zadání. Je si vědom, že taková estimace v ranné fázi projektu je pouze loterie, která se hraje hlavně proto, aby měl zákazník rámcovou představu o nákladnosti projektu. Nesnaží se dodat konkrétní číslo, ale spíše rozpětí optimistického a pesimistického odhadu. Rozloží si problém na menší celky a ty estimuje zvlášť. Umí zákazníkovi vysvětlit rizika takové estimace a obsažené stupně volnosti.
Honza se snaží aktivně porozumět rizikům projektu. Tato rizika srozumitelně popíše, navrhne protiopatření a vykomunikuje je směrem k zákazníkovi. Zkušenost mu velí, že největší rizika vznikají při integraci aplikace s externími systémy a při závislosti na úkolech, které musí zajisti zákazník sám.
Honza má zkušenosti s agilními projekty i vodopádem. Pracoval v režimu Fix-time-fix-price i Time-&-Material. Dokáže je porovnat z různých perspektiv. Preferuje agilní přistup, ale chápe, že každá metodologie je vhodná pro jiný typ projektu. Chápe, že zadavatel má určitý přístup k řešení projektů, který někdy nelze úplně změnit. Nejdříve si tedy nechá vysvětlit problém, který je potřeba řešit a teprve potom navrhuje typ metodiky. Ne obráceně. Umí vyargumentovat vhodnost jednotlivých přístupů a zohlednit připomínky zákazníka.
Honza zná principy Scrumu, Kanbanu, extrémního programování i vodopádu. Je si vědom, že málokdy se na projektu jedná o jednu striktní metodiku. Často dochází k hybridnímu modelu s prvky více metodik současně. Umí v takovém prostředí fungovat. Dokáže poznat, kdy to způsobuje problémy a kdy naopak to projektu prospívá. Uvědomuje si, že získávání zpětné vazby na práci týmu od zákazníka je klíčové pro úspěch projektu v každé metodice.
Honza jako analytik
Honza dobře chápe, že za vznikem dobrého softwarového produktu je obvykle symbióza správného technického řešení a pochopení byznysových potřeb. Aktivně se snaží porozumět byznysové doméně. Chápe, že jednoznačný doménový glosář redukující používání synonym je základem plynylé komunikace a snižuje míru neporozumění v rámci projektového týmu.
Honza umí naslouchat potřebám zákazníka, pomáhat s návrhem řešení a formalizovat požadovanou funkcionalitu ve formě use cases. Rutinně používá UML a kreslí diagramy případů užití, aktivitní diagramy, sekvenční diagramy a další.
Honza je schopen definovat funkcionální epiky a jejich rozpad na user stories. Nepodceňuje správnou formulaci všech tří hlavních částí story. Rozumí důležitosti formy a obsahu akceptačních kritérií, Definition of Ready a Definition of Done.
Když je na projektu nějaká velká neznámá nebo vysoce komplexní část, umí si s tím poradit. Nepřeceňuje význam verbální diskuze. Pozná, kdy je lepší přestat mluvit a udělat první krok k řešení problémů. Raději udělá první krok špatným směrem, než dlouho váhat a neudělat žádný. I pozdější uvědomění si nesprávného postupu je progres.
Honza nepodceňuje důležitost definice nefunkcionálních požadavků. Aktivně se zákazníkem řeší požadavky na zabezpečení, odezvu systému, propustnost, podporované prohlížeče, apod. Je si vědom toho, že právě tyto záležitosti mají často zásadní vliv na architekturu řešení.
Honza jako technický vedoucí týmu
Honza spolu s týmem nastavuje pravidla pro psaní kódu. Společně integrují nástroje pro statickou a dynamickou analýzu. Sdílejí si týmové šablony a code snippety. Snaží se zajistit rozumnou míru standardizace, která práci celého týmu zefektivňuje.
Honza chápe důležitost automatizace CI a CD procesů. Proto trvá na jejich správném nastavení již od začátku vývoje.
Honzovi je jasné, že správně prováděná code review jsou velkým přínosem pro kvalitu výstupu. Zároveň dbá na to, aby způsob komunikace v rámci review byl profesionální a konstruktivní. Chce, aby to byl proces učení a společného hledání lepšího řešení.
Honza si je vědom, že každý softwarový projekt je postupně zatížen technickým dluhem, se kterým se musí pracovat. Zná postupy jak redukovat míru jeho vzniku už ve fázi návrhu. V týmu aktivně používají Boyscout-rule. Zároveň však dokáže poznat, kdy je už další umořování technického dluhu ekonomicky neefektivní.
Komunikuje technické záležitosti srozumitelným způsobem produkťákům a mecenášům projektu tak, aby zajistil adekvátně robustní řešení. Větší refaktoring domluví jako technickou user story naplánovanou s vědomím zákazníka v souvislosti s funkcionální změnou v souvisejím kódu. Dělat refaktoring bez motivace rozšíření stávající funkcionality nebo optimalizace výkonu nepovažuje za opodstaněné.
Honza nabádá kolegy, aby přicházeli s nápady na vhodné nástroje a knihovny, které by práci na projektu vylepšily. Nejdříve si však jejich použití odprototypují a posoudí jejich přínos. Je přiměřeně konzervativní v použití nových věcí. Mnohokrát již dříve zjistil, že vhodnost technologie se nedá posoudit hned, ale spíše později při aplikaci na komplexnější záležitosti. Použití takové neprověřené technologie považuje za riziko a tak s ním i nakládá.
Honza jako programátor
Anatomii vývojového cyklu specifikace-analýza-návrh-implementace-verifikace má Honza stále v podvědomí. Snaží se tyto fáze ve svých postupech logicky oddělit.
Když začíná pracovat na novém úkolu, začne analýzou problému. Pokud problém obsahuje neurčitost, kterou potřebuje vyjasnit, neváhá sáhnout k prototypování. Udělá rychlý prototyp, který mu pomůže pochopit problém a ukáže možné cesty k řešení problému. Prototyp pak zahodí a nepodléhá lákadlu jeho použítí přímo v produkčním kódu.
Součástí Honzovy analýzy je obvykle také rozpad problému do menších celků. Tyto menší celky jsou pak lépe uchopitelné. Veškeré nejasné a problematické části zadání strukturovaně sepíše a prodiskutuje s autorem požadavku.
Ve fázi návrhu si rád pomůže nakreslením některého z UML diagramů. Pro statický pohled na řešení používá komponentový diagram a diagram tříd. Pro dynamický pohled aktivitní, sekvenční nebo stavový.
Někdy mu také pomůže TDD přístup. Jednotkovými testy postupně definuje rozhraní komponenty a iterativně její sémantiku. Snaží se o konzistentní a dostatečně samopopisný názvy testů, které poslouží jako aktuální dokumentace ke komponentám. Ze složitosti zápisu jednotkových testů dostává okamžitě zpětnou vazbu na návrh komponent a jejich složitost.
Honza si bez jednotkových testů nedokáže vývoj představit. Není však radikálním zastáncem 100% pokrytí kódu u komponent, u kterých je přínos jednotkových testů velmi malý oproti nákladům na jejich vytvoření a údržbu.
Při návrhu komponent používá Honza kombinaci různých best practices a návrhových vzorů. Základem jsou pro něho SOLID principy. Bez použití IoC kontejneru a Dependency Injection si už nedovede své projekty ani představit. Má rád volné vazby mezi komponentami, nízká čísla u metrik závislostí a vysokou soudržnost. Díky tomu může psát testy efektivním způsobem.
Pro Honzu bylo přečtení knížky Clean Code důležitým profesním milníkem. Začal přemýšlet nad svým kódem jinak. Zaměřuje se na dobré pojmenování, zkracuje metody, snižuje cyklomatickou složitost, redukuje parametry, více přemýšlí nad ošetřením možných chybových stavů. Obecně se více dívá na kód z pohledu čtenáře než autora. Zásadní důraz klade na dobrou čitelnost a samodokumentovatelnost kódu. Ovládá nejpoužívanější techniky refaktoringu právě pro dosažení lepší struktury a udržovatelnosti kódu.
Integračními testy si ověří funkčnosti přes celý aplikační stack.
Otázky výkonu Honza řeší již při návrhu architektury. Rozumí také výkonostním aspektům frameworkových komponent a vlastního jazyka. Nenechá se však vlákat do pasti dopředné optimalizace při psaní komponent. Tu provádí až poté, co má nejdříve funkční řešení.
Honza se snaží své hlavní softwarové nástroje ovládat pouze z klávesnice bez nutnosti použití myš. Aktivně se učí klávesové zkratky. Píše bez překlepů. Psaní na klávesnici pravidelně trénuje.
Honzovy znalosti jazyků a technologií
Ve svém hlavním programovacím jazyce se cítí velmi komfortně. Na druhou stranu si uvědomuje, že získat hlubokou expertízu v použití hlavních knihoven platformy je běh na dlouhou trať. Aktivně proto hledá možnosti, jak si zvé znalosti rozšířit. Čte si blogy, porovnává různá řešení stejného problému na Stackoverflow, prototypuje alternativy, diskutuje s kolegy.
Honza má rozsáhlé teoretické znalosti v oblasti softwarového inženýrství. Díky nim dokáže rychleji najít optimálnější řešení problému. Ví co hledá a umí si dát věci do souvislostí.
Má zkušenosti s jazyky a technologiemi napříč celým stackem. Dokáže napsat aplikace běžící na serveru, v prohlížeči i na mobilních zařízeních. Díky takto širokému záběru chápe souvislosti a umí navrhnout správně komunikační rozhranní. Rozumí protokolům REST, GraphQL, gRTC i SOAP.
Honza zná principy hlavních cloudových platforem. Umí navrhnout a nakonfigurovat ideální mix cloudových služeb podle potřeb daného projektu. Rozumí Dockeru a Kubernetes.
Jak dlouho je už Honza v oboru?
A odpověď na druhou otázku je ... Nevím.
Dle mého názoru se délka kariéry v IT často přeceňuje. Já sám znám několik relativně mladých vývojářů, kteří mají k Honzovi blíže než jiní, kteří ještě programovali v Turbo Pascalu. Ale rozhodně z toho nemůžeme dělat pravidlo.
Co můžeme z tak komplexního Honzova profilu tedy vyvodit? Dostat se na vysokou úroveň mnoha dovedností vyžaduje spoustu času stráveného praktikováním. To bezesporu. U některých vlastností jsou navíc nutné i životní zkušenosti, které formují především sociální inteligenci.
Důležitou složkou naší osobnosti jsou charakterově volní vlastnosti. Spolehlivost, pracovitost, zásadovost, ... Jejich správné nastavení má zřejmě zásadní vliv na rychlost profesního růstu.
Velký dopad má také to, v jakém prostředí a týmu se vývojář vyvíjel. Při dobrém vedení se může začínající perspektivní vývojář během krátkého období hodně posunout. Proto je zřejmě výhodné, aby byli mladí ve více flexibilním prostředí s variabilnějšími projekty. Samozřejmě za asistence zkušených kolegů.
Zkusme být jako Honza ...
... ale nestresujme se z toho, že takoví nejsme. Pracujme na sobě. Každý úkol je příležitostí se něco nového naučit, zlepšit se, zkusit jiný postup. Odměnou nám bude dobře odvedená práce a spokojenost. A o to přeci jde.
Vox populi
Tady si můžete přečíst, co si o tématu myslí kolegové z Twitteru. Děkuji všem za reakce.
Chystám blogpost "Starý junior, mladý senior". Jaké dovednosti / charakteristiky podle vás nejvíce odlišují skutečně seniorního vývojáře od neseniorního? Díky za názor nebo RT.
— Robert Dresler (@rdresler) January 22, 2022
