Po štěstí a talentu se dneska podíváme na motivaci. Možná vás teď zajímá, co ten nadpis znamená, vždyť o motivaci se v managementu a leadershipu velmi často. Bavíme se o tom, čím zaměstnance motivovat, bavíme se o vnitřní a vnější motivaci… Přesto je motivace asi nejvíce přeceňovaný pocit.
Scatter-Gather je další z rodiny návrhových vzorů, které se věnují separation of concern - oddělení zodpovědnosti. Hlavním přínosem scatter-gather vzoru je paralelizace - možnost vykonávat několik operací najednou a je tedy vhodný pro prostředí, jazyky, které paralelizaci nabízejí, mají thready, workery, nebo umí spustit nové procesy.
V pokračování série o faktorech, které ovlivňují úspěch se dneska podíváme na talent. Pokud jste nečetli článek o štěstí, doporučuji. Hodně faktorů je podobných a nebudu je vysvětlovat znovu.
Nicméně, na rozdíl o štěstí, talent už má praktický dopad na úspěch (dá se s ním pracovat). Co to ale je talent? Podle mě si hodně lidí vykládá talent špatně.
Hodně lidí si talent vykládá jako něco, co dá člověku náskok a to není pravda.
Štěstí o kterém chci dneska mluvit není "Ty máš štěstí, vyhrál jsi loterii", ale "Ty máš štěstí, že máš tak skvělé kolegy, že máš takové skvělé nabídky" atd. To první je takřka vždycky štěstí. To druhé takřka nikdy. A přesto se to dá zaslechnou často...
Nicméně, takžka nikdy to nemá co společného se štěstím.
V minulém článku jsem se věnoval rules engine patternu, patternu, jehož motivací je separation of concerns, high cohesion and low coupling. Dneska v tom budeme pokračovat dalším patternem, který podporuje tyto principy: pipeline
Návrhové vzory jsou jako nástroje ve vaší dílně. Dokáží výrazně zjednodušit jak psaní kódu, tak kód samotný. Dnes začneme ukázkami patternů specificky se vzorem s názvem Rules Engine.
Rules engine vám umožní zlepšit jak separation of concerns, tak high cohesion and low coupling a výrazně tím snížit míru komplexity kódu.
"Softwarová architektura je návrh API, databáze a měla by být robustní a stabilní."
Na předchozí větě není skoro nic pravda. Moderní softwarová architektura je něco velmi jiného. Chybí to hlavní. To, co je vlastně cílem architektury.
Co je tedy softwarová architektura?
Spoustu věcí lze nahradit nebo získat znovu. Dům, auto, peníze - vše lze nahradit. Existuje ale něco, co je cennějšího, než peníze či zlato. Čas. Čas je skvělý zdroj; všichni ho máme stejně - 24 hodin denně. Není možné mít více, jediné, co je možné, je rozhodovat o jeho využití.
Slyšeli jste někdy lidi říkat "nemám dost času"? Nemyslím tím úkoly a deadlines. Nemluvím o práci, někdy jsou deadlines příliš krátké, úkoly příliš velké a není čas je dokončit. Mluvím o "Chtěl bych se tohle naučit, ale nemám čas."
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?
Prozkoumáme pohled developera, leadera a architekta.
V návaznosti na předchozí článek budu pokračovat k komplexitě škálování, komplexita podpůrných částí a náhodné komplexitě, typech, které je možné managovat, redukovat a dokonce i odstranit.
Komplexita je úhlavní nepřítel softwarového designu a architektury. Primárním úkolem softwarového architekta je odstranit, redukovat a spravovat komplexitu, v tomto pořadí. Ale co když samotná podstata problému, který řešíte, je komplexní? Co potom? Co vůbec znamená managovat komplexitu a co je vůbec komplexita?
Existuje několik typů softwarové komplexity a každý typ vyžaduje jiný přístup.
Vývojáři používají slovo "abstrakce" běžně, nicméně často s omezeným chápáním významu. Pro většinu, koncept abstrakce byl zastíněn jejím použitím v některých jazycích pro označení metody nebo třídy, která musí být děděna a přetížena. Stejně tak "použij abstrakci" pro spoustu developerů znamená "napiš abstraktní třídu".
Abstrakce je jednou z nejdůležitějších technik pro docílení decouplingu a stabilizaci veřejného rozhraní na všech úrovních.
Existuje několik způsobů, jak vytvořit modulit a jeden z nich si dneska ukážeme. Ty důležité části, na které se dneska zaměříme jsou: Aplikační vrstva, Business vrstva, Fasády a Repositáře, Event bus/broker, CQ Router a Utilities.
Pochopení rolí a rozdělení těchto částí je základem pro napsání kódu, který neskončí jako "big ball of mud".
Monolitický styl má špatnou reputaci, nicméně je vhodnou volbou pro menší aplikace. Problémem není nutně monolit, ale spíš způsob jeho implementace.
Proč zvolit monolit na místo distribuované architektury (např. microservices)? Networking mezi jednotlivými komponentami představuje novou sadu problémů. Existují benefity stejně, jako nevýhody.
Modulární monolit - modulit je vhodná volba, jak začít psát aplikaci.
"Měli byste být loajální k firmě, sdílet její cíle a přijmout její hodnoty." K tomu nedojde. Nechápejte mě špatně, neříkám "To neudělám", říkám, že to se nestane, nemůže se to stát, není to možné.
Lidé nejsou loajální k firmě, jsou loajální k lidem ve firmě díky kultuře, která je lidmi vytvořena.
Někteří lidé si myslí, že dependency injection by mělo být použité všude a je nejnovější technologií. Podobně, někteří lidé si myslí, že layered architecture vyřeší všechno a další si myslí to samé o microservices.
Někteří lidé si myslí, že serverless je vhodné vždy, další, že vše by mělo být napsané v Rustu na backednu a Vue3 na frontendu.
Někteří lidé si myslí, že stačí na jednoho člověka nalepit Product Owner, na jiného Scrum Master, poslat je na 2denní certifikační kurz, mít standupy, reviews, retrospektivy, používat Jiru a máte agilní team, který praktikuje Scrum.
Toto vše má jeden společný atribut: nepochopení hodnot a principů.
Proč děláte to, co děláte? Co vás motivuje k tomu, jít do práce? Podle čeho rozhodujete? Čeho chcete pracovně dosáhnout?
tl;dr - nejsou to peníze.
Pevně věřím, že existují hodnoty, které jsou důležitější než peníze. Hodnoty, které vytvářejí lepší, udržitelnější business model a zároveň generují peníze. Těmi hodnotami jsou: zákazník, team a kvalita; a jdou ruku v ruce.