Mít pravdu

Bronislav Klučka on 29. 6. 2025 13:48

Má cenu mít vždycky pravdu? Co to znamená mít pravdu v softwarovém developmentu? Jak důležité je pro leadera mít pravdu? A kdy to všechno začne být arogance?

Měli jste někdy co dočinění s někým, kdo musel mí vždy pravdu?

Pohled developera

Použiji především tuto sekci pro vysvětlení celého problému.

Jako developeři si často myslíme, že jsme racionální. Nicméně, na základě zkušeností, nejsme. Stále jsme lidé a často děláme rozhodnutí na základě subjektivních preferencí a racionalizujeme je, abychom vypadali chytře. Dělání rozhodnutí na základě osobních preferencí není špatně; racionalizace je.

Mé předchozí vyjádření může znít zvláštně. Dělat rozhodnutí na základě osobních preferencí? Skutečně? Zkusím to ukázat na jídle.

• Je špatně nejíst vůbec. Budete trpět a zemřete. Myslím, že se všichni shodneme, že nejíst je objektivně špatně.
• Existuje silný argument pro to, že steak s bramborami je kvalitnější jídlo, než dort. Nicméně, kde přesně je "špatně"? Kde přesně je hranice mezi tím, že někdo sní 3 dorty denně a jednou porcí za týden? Která autorita určí, kde je "dobře" a kde je "špatně"?
• A nakonec, co je "správně": hovězí steak s bramborami nebo ryba s rýží? Můžete najít autoritu, která bude tvrdit, že jedno je lepší než druhé na základě nějaké metriky, najdu vám jinou autoritu, která bude tvrdit opak.

Od určité úrovně, pokud nemáte velmi specifické požadavky, na volbě tolik nezáleží. A dohady jsou jenom otázka ega, kde někdo chce "vyhrát".

Chystáte se napsat klasický backend pro webovou aplikaci se spoustou CRUD operací. A volíte mezi PHP a NodeJS. Otázka zní, která volba je lepší? Pokud nemůžete prokázat, že jedno je lepší než druhé ze všech úhlů pohledu, začne volba záležet na tom, které výhody jsou pro vás důležité a které nevýhodu nedůležité. Zkuste třeba hledat rozdíl ve výkonu mezi PHP a NodeJS (nápověda: je to naprosto zbytečné, není shoda ani na specifických metrikách).

Nicméně předpokládejme, že jedno je o 10 % lepší, než druhé ve výkonu (CPU performance). Ok a co z toho? Znamená to, že je daná volba lepší pro běžný CRUD backend? Na compute strávíte milisekundy, mnohem více času strávíte na přenosu dat po sítí a při komunikaci s DB. Pokud tato metrika není skutečně relevantní a neovlivňuje zákazníka, potom je mnohem důležitější, jak se vám v daném jazyce programuje.

PHP je často používáno jako "fire and forget" proces. NodeJS je často používán jako perzistentní server. Memory leaks nejsou tak velký problém v PHP, memory leaky v NodeJS (ECMAScript) mohou být velmi nepříjemné (closures). Pokud PHP spadne, obvykle spadne jenom jeden request. Pokud spadne NodeJS, spadne celý server. PHP vyhrává! Vážně? Použití NodeJS mi dává jednodušší a přímou kontrolu na HTTP protokolem a umožňuje mi použít nejrychlejší cache: in-memory cache. Memory leaky? Naučte se jazyk, monitorujte aplikaci. Pády? Opravte chyby. O trochu těžší, ale jednoduše řešitelné.

Takže znovu, na základě jaké objektivní a univerzální metriky je jedno lepší, než druhé?

Před pár týdny, team u zákazníka diskutoval NodeJS vs. PHP a z nějakého důvodu skončili u výkonnosti garbage collectoru (GC). To může být skvělá teoretická diskuze na téma aplikovaných strategií GC, ale prakticky? Pokud je vaší reálnou starostí výkon GC, máte všechno optimalizované do té míry, že problémem je výkon GC, pokud jsou požadavky na compute tak vysoké, že výkon GC je relevantní, prostě použijte Rust 😉.

• Není nic takového, jako nejlepší adresářová struktura, nejlepší implementace DDD nebo separation of concerns. Není nic takového jako nejlepší programovací jazyk, databáze, framework atd.
• Čím specifičtější řešení máte, tím více je omezeno jenom na specifické usecases.

Buď můžete mít pravdu, nebo můžete mít vztahy s lidmi.

Pohled leaders

Ve zkratce: radši budu mít team složený ze spolupracujících normálních developerů, než skupinu skutečně dobrých, ale arogantních individuí, kteří potřebují "mít pravdu".

A je to také falešná dichotomie. Existují skvělí developeři, kteří umí být skvělými členy teamu.

Není jednoduché propustit talentovaného člověka, který má komunikační problémy. Ale pokud takový člověk začne být problematický, je nutné, nechat ho jít. To není otázka vzdání se technologické excelence a mistrovství. Problém není v kódu, problém je v komunikaci.

Jak takového člověka poznáte?

• Je všechno strašně důležité? Je všechno otázka života a smrti? Musí být všechno "perfektní"? A jen tento člověk arbitrem toho, co je "perfektní"?
• Je ten člověk schopen ostatní vzdělávat, posouvat, nebo házejí rozkazy a příkazy?
• Bere si osobně, když "prohraje" diskuzi? Je naštvaný? Ignoruje dohody?
• Inspiruje ostatní kolem sebe, nebo je vysává?
• Podporuje ostatní, aby přišli s nápady, nebo prostě předkládá ostatním řešení?
• Musí udělat všechno, protože ostatní jsou příliš hloupí na to, aby to zvládli?

Dlouhodobé zdraví teamu je důležitější, než výkonnost libovolného jednotlivce.

A co potom, pokud takového člověka v teamu máte?

• Promluvte se teamem na téma spolupráce a větší důležitosti kooperace oproti "mít pravdu".
• Vysvětlete, že součástí jejich práce není jen psát kód, ale i spolupracovat s ostatními.
• Vysvětlete, že jsou zodpovědní nejen za zdraví kódu, ale i za zdraví teamu.
• Vysvětlete, že oprava špatného kódu je mnohem jednodušší, než oprava špatného teamu.
• Vysvětlete, že toto téma je pro vás velmi důležité a že neexistuje trade-off mezi kvalitou a kooperací
• Vysvětlete, že je to něco, na co se zaměříte.

Toto by mělo být jedno z vašich priorit tak jako tak.

Během one-on-one s člověkem, který tyto problémy způsobuje, dejte najevo, že jeho chování bylo důvodem pro výše zmíněnou iniciativu. Vysvětlete, za jakých podmínek jste ochotni pokračovat ve spolupráci.

Upravte teamové role. Toto chování je o síle/pozici, omezte ji. Jedná se nejen o formu trestu, ale i o příležitost pro růst takového člověka, ale i růst ostatních. Pokud má problémový člověk specifickou roli, distribuujte ji mezi ostatní.

Pokud se situace nelepší, ale daný člověk má stále velkou cenu pro váš vývoj, izolujte ho. Přidělte mu task, ve kterém může excelovat a omezte kontakt s ostatními.

A samozřejmě může dojít na i na řízenou náhradu takového člověka.

Sám můžu jít rychleji, ale společně dojdeme dál.

Pohled architekta

Jaká je zodpovědnost architekta? Systém funguje v rámci zadaných parametrů (počet uživatelů, náklady na provoz, apod.). Systém lze spravovat a dlouhodobě evolučně rozvíjet. To je high-level (hodně high-level) pohled na technologické aspekty této role. Existují další aspekty, ale zůstaňme pro teď u těchto. Jinými slovy, není zodpovědností architekta dělat krátkodobé plány a taktická rozhodnutí. Pokud vás team požádá o pomoc, pomozte. Pokud se rozvine diskuze, diskutujte. Nicméně neměli byste micromanagovat developery ani dělat všechna rozhodnutí.

Nastavte pro team jasné hranice. Nastavte high-level očekávání, ale nezasahujte do každodenní operativy teamu, pokud nejsou dané hranice a očekávání v ohrožení.

Nedělejte žádné volby za team, pokud nemusíte a buďte velmi opatrní i na rozhodování za team. Nechte team růst.

A ještě jedna věc: vzdělávejte team!