Změna je dobrá aneb proč se nebát nového projektu

Já si tohoto na sobě začal všímat v průběhu loňského léta. Ať už byl den v práci lepší či horší, domů jsem vždy přišel skleslý a otrávený. Na projektu jsem byl tři roky, až na výjimky se zde řešily více či méně podobné softwarové problémy napříč různými zařízeními, takže se práce začala stávat poměrně rutinní. K tomu jsme pracovali v zastaralé technologii. 

Jediné, co se měnilo, byla atmosféra u zákazníka. Bohužel ne k lepšímu. Začínala se projevovat nejistota s ohledem na výzvy současné doby a tendence některých korporátů činit impulzivní rozhodnutí, sice s dobrými úmysly, ale nedostatečnou analýzou rizik. 

Všechny tyto aspekty mě vedly k rozhodnutí požádat o změnu projektu. Bylo mi jasné, že to nepůjde ze dne na den, nicméně alespoň vidina světla na konci tunelu učinila poslední týdny a měsíce na projektu snesitelnějšími. 

Na dvou židlích laptopech současně 

Uplynulo to jako voda z očekávání se stává realita. Těšení se doplňuje nervozita a strach z neznáma, protože opouštím pro mě už dobře známý píseček. 

Takže zatímco na jednom laptopu dokončuji a odevzdávám poslední úkoly z předchozího projektu, na druhém si chystám pracovní prostředí, tedy instaluji klient pro Git, Docker, Node, všechny doplňky Visual Studia a zároveň několikrát ujišťuji Microsoft Authenticator, že se opravdu chci přihlásit na toto zařízení. 

Samozřejmě s tím souvisí i tzv. „nalejvárny“ ohledně nového projektu. Naskočit do rozjetého vlaku není nikdy jednoduché, ale musím nový tým pochválit, že prakticky všechno bylo někde zapsáno a zdokumentováno, což přechod značně usnadnilo. Přestože jsem se chvílemi hůře orientoval mezi tím, kde co najdu, protože materiály byly roztříštěny mezi Github, Loop a Teams, vždy se našel někdo, kdo věděl, kam mě nasměrovat. 

Velký pomocník (a jedna z novinek pro mě) byl také vývoj v devcontaineru, který řešil spoustu porodních bolestí a závislostí za mě. Směle jsem se tak mohl pustit do prvního ticketu, který mi byl přiřazen. 

Všechno jinak 

To znamená začít pracovat v novějších technologiích, na které jsem se tak těšil. Najednou tak dělám v nejnovějším .NET 10 místo stařičkého .NET Frameworku 4.8. Zdokonalím se také ve frontendu, kde si osvěžím práci s Angularem a prohloubím tak své znalosti v další technologii. 

Novinkou je pro mě také projekt s fungujícími procesy. Na předchozím projektu se code review dělalo minimálně, pull requesty vůbec. „Pokud to nějak funguje, tak to zamerguj.“ Což pochopitelně vyvolává další obavy a způsobuje tzv. „imposter syndrom“. Začnete si pokládat otázky jako – je můj kód dostatečně dobrý? Nepřinesl jsem si z minulého projektu nějaké špatné návyky? Stačí mi moje znalosti? Nebudu ten projekt spíš brzdit? 

Odpovědi na tyhle otázky stejně nezjistíte jinak než vytvořením toho prvního pull requestu. Samozřejmě se neobešel bez zpětné vazby. Ať už se jednalo o dodržování architektury a strukturování projektu v repozitáři nebo jen styl pojmenovávání metod. Nikdo si nechce přečíst, že něco dělá špatně. Důležité je ale mít na paměti, že to není kritika práce, nýbrž návod, jak mít výsledný produkt co nejkvalitnější, nejpřehlednější a nejčitelnější.  

Jinak taky probíhaly stand-upy nebo grooming. Na stand-upech se nemluvilo, jen aby každý něco řekl, ale řešily se konkrétní problémy. Stejně tak byl grooming vždy zaměřený na věc, co byla nutná místo prohlášení „tady máte backlog, řekněte si, kdo co chcete dělat“. 

Najednou se tak z nudné byrokracie staly plodné schůzky, kde jsem cítil jejich smysl a mohl se navíc domluvit s kolegy například na tom, kdo se na koho bude “rebasovat”. Nebo se připomenout, že jsem jim psal na Teams a zůstal bez odpovědi.  

První týden dva jsem na schůzkách spíš poslouchal, především, abych nasál co nejvíc informací o vyvíjené aplikaci. To mi pomohlo zasadit si do kontextu přibývající pull requesty, ze kterých jsem pak mohl lépe odkoukat styl práce, především na frontendu, se kterým jsem moc zkušeností neměl. 

Časově se navíc můj přesun trefil do doby, kdy doslova explodovaly AI jazykové modely Claude, které se staly mým parťákem nejen na vývoj, ale zpočátku i na vysvětlování logiky, závislostí a celkově na hloupé dotazy, kterými bych ostatní lidské kolegy zdržoval. Tedy ne že bych se jich neptal na (pro ně možná) zjevné věci, ale počet dotazů byl copilotem značně zredukován. 

Lessons learned 

I když nebylo vždy vše růžové, byl jsem ze změny projektu nadšený. Především normální a fungující tým mi dost zlepšil náladu v práci i po ní, čímž eliminoval pocity znechucení, se kterými jsem se potýkal. 

Nový projekt však měl termín dokončení, který v době vydání článku již dávno uplynul. V dohledné době mě tak tohle všechno bude čekat znovu. Ale svého rozhodnutí rozhodně nelituji a udělal bych ho znovu! Vyzkoušel jsem si totiž spolupráci s jinými kolegy, v jiných technologiích, s lehce odlišným řízením projektu. Především mi ale (subjektivně) přijde, že během několika měsíců jsem se znalostně posunul víc než za předchozí rok na projektu, kde jsem si byl možná až příliš jistý v kramflecích.  

Načerpal jsem také cenné zkušenosti, které mohu zúročit na příštích projektech, a nebudu mít takové obavy ze svého začlenění. Už totiž vím, že snad každý programátor má na novém projektu pocit, že se tam ocitl omylem. Že adaptace zkrátka trvá a nikdo nebude první týdny doručovat featury tak rychle jako po dvou měsících. A že změny není nutné se bát. Naopak nám může přinést spoustu nových zkušeností.