Mít pravdu

Má cenu mít vždycky pravdu? Co to znamená mít pravdu v softwarovém vývoji? Jak důležité je pro lídra 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ít vždy pravdu?

Pohled developera

Použiji především tuto sekci k 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ělat 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í tři dorty denně a jednou porcí týdně? 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, já vám najdu jinou autoritu, která bude tvrdit opak.

Od určité úrovně, pokud nemáte velmi specifické požadavky, na volbě už tolik nezáleží. A dohady jsou jen 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 Node.js. 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ýhody jsou nedůležité. Zkuste třeba hledat rozdíl ve výkonu mezi PHP a Node.js (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 to znamená? Znamená to, že je daná volba lepší pro běžný CRUD backend? Na výpočty strávíte milisekundy, mnohem více času strávíte na přenosu dat po síti a při komunikaci s databází. 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 proces typu „fire and forget“. Node.js je často používán jako perzistentní server. Memory leaks nejsou tak velký problém v PHP, memory leaks v Node.js (ECMAScript) mohou být velmi nepříjemné (closures). Pokud PHP spadne, obvykle spadne jenom jeden request. Pokud spadne Node.js, spadne celý server. PHP vyhrává! Vážně? Použití Node.js mi dává jednodušší a přímou kontrolu na HTTP protokolem a umožňuje mi použít nejrychlejší cache: in-memory cache. Memory leaks? 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 tým u zákazníka diskutoval Node.js 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á diskuse na téma aplikovaných strategií GC, ale v praxi? Pokud je vaší reálnou starostí výkon GC, máte všechno optimalizováno do té míry, že problémem skutečně je výkon GC, pokud jsou požadavky na výpočty tak vysoké, že výkon GC je relevantní, prostě použijte Rust. 😉

Neexistuje něco jako nejlepší adresářová struktura, nejlepší implementace DDD nebo separation of concerns. Neexistuje něco jako nejlepší programovací jazyk, databáze, framework atd.

Čím specifičtější řešení máte, tím více je omezeno pouze na specifické use-cases.

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

Pohled leadera

Ve zkratce: raději budu mít tým složený ze spolupracujících normálních developerů, než skupinu skutečně dobrých, ale arogantních jednotlivců, 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 týmu.

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é ho nechat 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 skutečně tak důležité? Je všechno otázka života a smrti? Musí být všechno „dokonalé“? A je tento člověk jediným arbitrem toho, co je „dokonalé“?

• Je ten člověk schopen ostatní vzdělávat a posouvat, nebo hází jen rozkazy a příkazy?

• Bere si osobně, když „prohraje“ diskusi? Je naštvaný? Ignoruje dohody?

• Inspiruje ostatní kolem sebe, nebo je jen vysává?

• Podporuje ostatní, aby přišli s nápady, nebo jim rovnou předkládá řešení?

• Musí udělat všechno, protože ostatní jsou příliš neschopní na to, aby to zvládli?

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

A co dělat, pokud takového člověka v týmu máte?

• Promluvte s týmem o spolupráci a větší důležitosti kooperace oproti „mít pravdu“.

• Vysvětlete jim, ž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í týmu.

• Vysvětlete, že opravit špatný kód je mnohem jednodušší než opravit špatný tým.

• Vysvětlete, že toto téma je pro vás velmi důležité a že neexistuje kompromis mezi kvalitou a kooperací.

• Vysvětlete, že je to něco, na co se budete zaměřovat.

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 týmové role. Toto chování je o síle a 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, rozdělte 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 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 musí být možné 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 tým 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 tým jasné hranice. Nastavte high-level očekávání, ale nezasahujte do každodenní operativy týmu, pokud nejsou dané hranice a očekávání ohrožena.

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

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