Poznámky pro všechny (pracující s) programátory

Přečetl jsem si zase další knížku Vývojářův kód od Ka Wai Cheung. Vzhledem k mé špatné paměti jsem si z ní zapsal několik zajímavých postřehů. Některé souvisí s organizací práce obecně, jiné části jsou specifické pro zakázkovou výrobu a některé se pak týkají pouze vývoje software.

Normální lidé nemají vlastně tušení, co je to programování. Dokáží si představit práci architekta, designera, ale programování vlastně moc neznají. V knize Vývojářův kód to autor přirovnává k umění a mě nezbývá než souhlasit.

Programátor při práci totiž stejně jako skladatel nebo spisovatel vytváří své dílo a stále se k němu vrací  a upravuje ho, až se mu zdá dost dobré aby ho ukázal veřejnosti.

Zaměstnanecké benefity jsou krátkodobé povzbuzení. Skutečně, zvýšení platu nebo získání permanentky do divadla je sice hezká věc, ale časem si na to člověk zvykne. Když bude dělat práci, která ho ale nenaplňuje a bude ho otravovat, tak bude nadávat a na zaměstnanecké výhody rychle zapomene. (Samozřejmě, že kdo splácí hypotéku, potřebuje hodně peněz a tak to spousta lidí překousne.) Představte si ale práci, která vás baví, těšíte se do ní, protože víte, že zase budete pracovat s těmi skvělými lidmi, s těmi moderními nástroji, které vám usnadňují život, že vaše práce bude naplánovaná tak, že nebude docházet ke stresovým situacím a ještě budete mít čas vyhrazený na pokec s přáteli. Je to trošku ideální, ale takové zaměstnání i bez zaměstnaneckých výhod je podle mého názoru rozhodně lepší, než když 20 dní v měsíci 8 hodin denně otráveně dělám práci, která mě nebaví.

Produktivita

Neposouvejte termíny, je to demotivující, protože všem v týmu se tak vzdaluje vytoužený konec. Stanovte si termíny tak, abyste je zvládli. Klidně za cenu toho, že v první verzi bude pouze základní funkcionalita a tato verze ještě nebude např. dostupná pro širokou veřejnost.

Investujte do kvalitních nástrojů. Při práci, kterou děláte dnes a denně, sebemenší zdržení v delším časovém horizontu zvyšuje vaše náklady a často zkouší i vaše nervy. Autor knihy to popisuje špatnou klávesnicí, na které se zaměstnanec každou chvíli uklepne a musí po sobě chybu opravovat. Vynásobte si to hodinami strávenými v práci za rok a vyplatí se nám jednorázově investovat do klávesnice např. za tisíc korun. To stejné platí i o software, ale i o pracovních strojích pro dělníky apod.

Každý den vylepšete dvě věci, klidně to mohou být detaily v podobě přidání nápovědy k tlačítkům. (To se týká spíš dlouhodobě vyvíjených aplikací.)

Pracujte mimo ložnici. Vyhraďte si pracovní místo a čas. Oddělte svůj soukromý život od práce.

Obvykle, když si přečtu nějakou knihu související s mojí profesí, tak se snažím vyzkoušet některé myšlenky. Z této knihy jsem si hned zavedl osobní seznam úkolů, který se dělí na 3 části.

• dnes
• zítra
• později

Každý tvůrčí člověk se potřebuje občas soustředit a být nerušený, jenomže pokud spolupracujete s ostatními v týmu nebo přímo se zákazníky, tak je dost obtížné takový čas najít. Já osobně to řeším tím, že přijdu do práce dřív než ostatní a tím mám např. svoje dvě hodiny nerušené práce. V knize Vývojářův kód je popsané střídání lidí v týmů, kteří kromě své hlavní práce komunikují s ostatními mezi tím, co týmoví kolegové využívají svůj vyhrazený čas.

MY to navrhneme, pak SE to ještě musí realizovat a už to bude hotové. Velmi časté zobecnění osob, které slyším snad každý den. Stejně tu danou práci dělají konkrétní lidé, tak proč je hned neurčit. A když nevím, kdo to bude dělat, tak určím přesně toho, kdo o tom rozhodne a ideálně i do kdy o tom rozhodne.

Další kapitola o složitosti popisuje mimo jiné i kdy refaktorovat a jak jednoduchost vzbuzuje dojem nedokonalosti a nízké hodnoty. Ka Wai Cheung v knize píše, že pohled na jednoduchou lacinou aplikaci z pohledu programátora může být úplně odlišný od pohledu zákazníka, pro kterého tato triviální věc má obrovskou hodnotu, protože přinese každodenní zjednodušení a urychlení práce.
Např. každodenní import dat, jejich roztřídění a vytvoření součtů může být pro programátora otázka několika hodin (pokud má přesné zadání), ale zákazník by takovou práci musel dělat každý den aspoň hodinu. Takže pokud to zase vynásobíte počtem dnů v roce, je to pro něj velká úspora peněz.

S tím pak může souviset, jak vlastně ohodnotit svoji práci. Hodnota není jen čas. Tak ale asi hodnotí většina programátorů. Však se nás taky na to v práci ptají: „Jak dlouho ti to zabere? Dej mi odhad, já to pak vynásobím hodinovou sazbou, přidám nějakou vatu a pošlu nabídku zákzaníkovi.“ To je vlastně prodej služby programátora. Lepší by bylo prodávat produkt, který může mýt vyšší cenu než jen hodiny programátora.

Učení

Vyučuj pomocí příkladů a nezacházej do detailů a výjimek.
Kapitola o učení pouze potvrzuje to, co jsem si už sám vyzkoušel. Ten kdo věcem rozumí, se často neumí vcítit do kůže neznalého. Ještě horší to je, když učitel od začátku vysvětluje i všechny detaily a výjimky. Někdy je skutečně lepší malá lež, než složitá pravda. Snažil jsem se takhle učit HTML/CSS a často jsem říkal: „… je to tak a tak, kromě …. a někdy to může být i takhle …., ale v tomhle případě to ale funguje trošku jinak …“.

Zákazníci

Ukažte zákazníkovi, jak se aplikace skutečně programuje/vytváří. Zákazníci si vymýšlí, často neví, co všechno se musí stát, než aplikace vlastně vznikne. Když uvidí, jak je to někdy složité, tak si pak nechají něco rozmluvit nebo je lépe přesvědčíte o lehčím řešení, které může mít pro zákazníka stejnou hodnotu.

Buďte na zákazníka hodní. On často neví, jak špatné zadání vám vlastně dal. Pohybuje se ve svém světě, kde všemu rozumí a netuší, že vy toho např. o možnostech oken, dveří a pantů moc nevíte. Stejně tak, když se vám po čase ozve, že mu nefunguje třeba zobrazení rezervací. Těch stránek se seznamem rezervací je v aplikaci asi pět, mohou se lišit tím, kdo je spouští a v jaký čas. Nebuďte líní zvednout telefon, abyste se zeptali, jak to vlastně myslel. Je to pořád rychlejší, než hledat chybu v celém systému. Emaily jsou taky svkělá věc, nejen kvůli tomu, že máte veškerou komunikaci evidovanou, ale někdy využijte všudy přítomných mobilů, ať nemusíte odcházet od práce a znovu se k ní vracet.
Když už víte, jací jsou zákazníci, tak se snažte respektovat projektové manažera, abyste se zákazníkem nemuseli hádat o termínech sami. Pousmál jsem se, když jsem četl podobný případ, kdy chtěl zákazník upravit nějaký jednoduchý popisek nebo přidat ikonku v okamžik, kdy jsem byl zabraný do problému, který měl řešit nějakou klíčovou vlastnost jiné části aplikace. Ale to, co je z našeho pohledu jako nepodstatný detail, může být pro zákazníka zrovna trn v oku, který nehodlá přehlédnout před zaplacením faktury.

Závěr

Pište kód, až nebude jiná možnost. 
Oddělte tvůrčí část od strojové a vytvořte si nástroje pro automatizaci strojové práce, pokud už takové neexistují. Často se dozvíte více o daném problému.

Vytvářejte aplikace tak, abyste na ně mohli být hrdí a buďte na hrdí.

Pozn.: Tento článek je stručným výtažkem velké části myšlenek, které najdete v níže uvedené knize, doplněné o mé názory. Rozhodně vám to nenahradí přečtení knihy samotné.

Zdroj:
CHEUNG, Ka Wai. Vývojářův kód: Poučte se z chyb jiných. 1. vyd. Překlad Andrea Hodaňová. Brno: Computer Press, 2013, 193 s. ISBN 978-80-251-3786-4.