Duševně upřímný programátor

Rád hledám charakteristiky, které popisují dobrého programátora nezávisle na konkrétních technologiích a programovacích jazycích. V knize Code Complete od Steva McConnella jsem narazil na skvělou pasáž, která se věnuje povahovým vlastnostem dobrého vývojáře. Rád bych se zastavil u jedné z nich. U duševní upřímnosti. Musím uznat, že jsem si během své vývojářské praxe prošel většinou nešvarů pramenících z jejího nedostatku. Některé odstraňuji dokonce doteď. :)

Nebuďte falešný expert

Pokud máte dostatek duševní upřímnosti, nesnažíte se působit jako expert, pokud jím v dané oblasti nejste. Jedná se o jakousi intelektuální skromnost, díky které se budete lépe rozvíjet. Je vhodnější přiznat, že s danou technologií nemáte dostatek zkušeností, že danou část frameworku neznáte, že si nejste jistí určitou definicí. Pokud přistupujete k problému s vědomím, že umíte spíše méně, je pro vás přirozenější naslouchat ostatním a tím se více učit.

Zkuste si kvantifikovat při každé otázce, jakou úroveň jistoty v ní máte. Pozor, pokud často dosahujete ve svých očích 100%, zbystřete. Může se jednat o narcismus! :)

Přiznejte se k chybě

Duševně upřímný programátor se k chybě přizná rychle a rozhodně. Postaví se k ní chlapsky (programátorky prominou) čelem. Kroutit se a obhajovat chybu je zbabělé. Někdo si dokonce myslí, že když chybu nepřizná, okolí si bude myslet, že není jeho. :) Nefér přístup k řešení chyby může dojít až tak daleko, že dotyčný získá pověst pyšného a přezíravého programátora. A takové pověsti je pak těžké se zbavit.

Udělat chybu není ostuda. Pokud však není způsobena nedůsledností. Každopádně je nutné se vždy z chyby poučit a přijmout opatření, aby se neopakovala.

Neignorujte varování

Oblíbeným sportem je ignorování warningů při sestavování aplikace. Přehlížíme varování, která mohou způsobit v budoucnu velké problémy. Častokrát hledáme přičiny problémů v aplikaci a přehlížíme, že nám překladač mává signalizačními tyčemi přímo před očima. Nedostatek duševní upřímnosti se zde projevuje naší bohorovností v přehlížení varování. "To neděláš dobře s těmi sirkami, Jaromíre!" :)

Snažte se dobře porozumět svému programu

"Zkusím si spustit program, abych vůbec pochopil, jak to tam dělám." A metodou pokusů a omylů a s využitím debuggeru zjišťujeme, jak náš vlastní program pracuje. Prostě mu nerozumíme. Přičin může být mnoho - nečitelný kód s vysokým stupněm složitosti, chybějící jednotkové testy s dokumentační funkcí, výpadky paměti, apod.

Pokud si připustíte, že programu nerozumíte a je potřeba zahájit nápravná opatření, jste na dobré cestě. Pusťte se do vylepšení návrhu, zlepšení čitelnosti, pokrytí testy. Prostě zvyšujte jednotlivá kritéria vnitřní kvality kódu. Jedině s tímto přístupem napíšete příští kód v lepší kvalitě již napoprvé.

Informujte reálně o aktuálním stavu

Nestíháte, ale nechcete to přiznat? Říkáte vedoucímu raději to, co by chtěl slyšet, místo objektivní skutečnosti? Pak dostáváte do problémů nejen sebe, ale právě i vedoucího. Jeho zodpovědností je řídit projekt a pokud je informován špatně, dělá špatná rozhodnutí. Pokud byste včas přiznali, že máte problémy, například že vám z objektivních příčin klesá produktivita, dobrý projekťák se vám vždy bude snažit pomoci.

Většina agilních vývojových metodologií napomáhá tomu, aby se informace o problémech a překážkách v postupu projektu dostaly co nejefektivněji od členů týmu k vedoucímu. Informujte o problémech na denních scrum schůzkách nebo i dříve. Buďte aktivní v řešení vyvstalých problémů. Vaše upřímnost bude oceněna a získáte v očích ostatních větší kredit.

Dávejte realistické časové odhady a buďte neústupní

Představte si, že jste požádáni o odhad pracnosti nové funkcionality. Pohovoříte s kolegy, sečtete jednotlivé odhady a dodáte celkové číslo. Vedení se vyleká a přitlačí vás, abyste udělali "lepší" a hlavně nižší odhad. Pokud půjdete přes svoje přesvědčení a magicky snížíte odhad, aniž byste definovali jaké ústupky musíte udělat, je to zle. Lžete opět sami sobě a necháváte se přitlačit do kouta. V případě realizace byste se zřejmě dostali do časového presu, následného stresu a včasné dokončení projektu může být ohroženo.

Trvat na svém se musí každý vývojář naučit. Málokdo to umí už od začátku. S postupným získáváním praxe se přesnost odhadů zlepšuje. Vysvětlete vedení, že fyzikální zákony (konkrétně časové) ještě měnit nedokážete a případné kompromisy by byly podobně špatné. Pokud je projekt pro vaši firmu zajímavý, můžete dát zákazníkovi samozřejmě nižší cenu, aby do projektu šel. Ale interně si v týmu nic nenalhávejte. Neupřímnost ničí pracovní vztahy.