Techlead Skyeng Kirill Rogovoy () přednáší na konferencích, ve kterých mluví o dovednostech, které by měl každý správný vývojář rozvíjet, aby se stal nejlepším. Požádal jsem ho, aby se o tento příběh podělil se čtenáři Habra, dávám slovo Kirillovi.
Mýtus o dobrém vývojáři je, že:
- Píše čistý kód
- Zná spoustu technologií
- Rychlejší kódování úloh
- Zná spoustu algoritmů a návrhových vzorů
- Může refaktorovat jakýkoli kód pomocí Clean Code
- Neztrácí čas neprogramovacími úkoly
- 100% mistr vaší oblíbené technologie
Takto vidí HR ideální kandidáty a podle toho také vypadají volná místa.
Moje zkušenost ale říká, že to není příliš pravda.
Nejprve dvě důležitá prohlášení:
1) moje zkušenost je produktové týmy, tzn. společnosti s vlastním produktem, nikoli outsourcingem; v outsourcingu může být vše velmi odlišné;
2) pokud jsi junior, tak ne všechny rady budou použitelné a na tvém místě bych se zatím soustředil na programování.
Dobrý vývojář: realita
1: Lepší než průměrný kód
Dobrý vývojář ví, jak vytvořit skvělou architekturu, napsat skvělý kód a nedělat příliš mnoho chyb; Obecně si vede lépe než průměr, ale nepatří mezi top 1 % specialistů. Většina z nejlepších vývojářů, které znám, nejsou tak skvělí kodéři: jsou skvělí v tom, co dělají, ale nedokážou nic mimořádně výjimečného.
2: Spíše řeší problémy než je vytváří
Představme si, že do projektu potřebujeme integrovat externí službu. Dostaneme technické specifikace, podíváme se na dokumentaci, uvidíme, že je tam něco zastaralé, pochopíme, že musíme předat další parametry, provést nějaké úpravy, pokusit se to všechno nějak implementovat a zařídit, aby nějaká křivá metoda fungovala správně, konečně po pár dní chápeme, že takto nemůžeme pokračovat. Standardní chování vývojáře v této situaci je vrátit se k podnikání a říct: „Udělal jsem to a to, tohle nefunguje tak a tamto vůbec, tak si na to jděte sami. “ Podnik má problém: musíte se ponořit do toho, co se stalo, komunikovat s někým a pokusit se to nějak vyřešit. Rozbitý telefon začne: "řekni mu, já jí napíšu, podívej se, co odpověděli."
Dobrý vývojář, tváří v tvář takové situaci, si sám najde kontakty, spojí se s ním na telefonu, probere problém, a když se nic nedaří, sežene ty správné lidi, vše vysvětlí a nabídne alternativy (s největší pravděpodobností existuje další externí služba s lepší podporou). Takový vývojář vidí obchodní problém a řeší ho. Jeho úkol je uzavřen, když řeší obchodní problém, a ne když do něčeho narazí.
3: Snaží se vynaložit minimální úsilí k dosažení maximálních výsledků, i když to znamená psaní berliček
Vývoj softwaru v produktových společnostech je téměř vždy největší nákladovou položkou: vývojáři jsou drazí. A dobrý vývojář chápe, že firma chce získat maximální množství peněz tím, že utratí minimum. Aby mu pomohl, dobrý vývojář chce vynaložit minimální množství svého drahého času, aby získal pro zaměstnavatele maximální zisk.
Jsou zde dva extrémy. Jedním z nich je, že obecně můžete vyřešit všechny problémy s berličkou, aniž byste se obtěžovali architekturou, bez refaktoringu atd. Všichni víme, jak to obvykle končí: nic nefunguje, přepisujeme projekt od začátku. Další je, když se člověk snaží vymyslet ideální architekturu pro každé tlačítko, hodinu stráví nad úkolem a čtyři refaktorováním. Výsledek takové práce vypadá skvěle, ale problém je v tom, že na obchodní stránce trvá dokončení tlačítka deset hodin, a to v prvním i druhém případě, prostě z jiných důvodů.
Dobrý vývojář ví, jak balancovat mezi těmito extrémy. Chápe souvislosti a učiní optimální rozhodnutí: v tomto problému přiříznu berličku, protože jde o kód, který se dotýká jednou za půl roku. Ale v tomto se budu trápit a dělat vše co nejsprávněji, protože sto nových funkcí, které je třeba ještě vyvinout, bude záviset na tom, co se mi podaří.
4. Má vlastní systém řízení podniku a je schopen v něm pracovat na projektech jakékoli složitosti.
Práce na principech – když si všechny své úkoly zapisujete do nějakého textového systému, nezapomínáte na žádné domluvy, na všechny tlačíte, všude se objevujete včas, víte, co je a co není momentálně důležité, nikdy o úkoly nepřijdete. Obecnou charakteristikou takových lidí je, že když se s nimi na něčem dohodnete, nikdy se nebojíte, že zapomenou; a také víte, že si vše zapisují a nebudou se pak ptát na tisíc otázek, na které se již mluvilo.
5. Zpochybňuje a objasňuje jakékoli podmínky a úvody
I zde existují dva extrémy. Na jednu stranu můžete být ke všem úvodním informacím skeptičtí. Lidé před vámi přišli s nějakými řešeními, ale vy si myslíte, že to můžete udělat lépe a začít znovu diskutovat o všem, co bylo před vámi: design, obchodní řešení, architektura atd. To ztrácí spoustu času pro vývojáře i jeho okolí a má to negativní dopad na důvěru ve společnosti: ostatní lidé nechtějí dělat rozhodnutí, protože vědí, že ten chlap se vrátí a všechno rozbije. Druhým extrémem je, když vývojář vnímá jakékoliv úvodní, technické specifikace a obchodní přání jako něco vytesaného do kamene, a teprve když stojí před neřešitelným problémem, začne přemýšlet, zda vůbec dělá to, co dělá. Dobrý vývojář zde také nachází střední cestu: snaží se porozumět rozhodnutím učiněným před ním nebo bez něj, než se úkol dostane do vývoje. Co chce podnikání? Řešíme jeho problémy? Produktový designér přišel s řešením, ale chápu, proč bude řešení fungovat? Proč vedoucí týmu přišel s touto konkrétní architekturou? Pokud vám něco není jasné, musíte se jít zeptat. V procesu tohoto objasňování může dobrý vývojář vidět alternativní řešení, které prostě nikoho předtím nenapadlo.
6. Zlepšuje procesy a lidi kolem vás
Kolem nás probíhá spousta procesů – každodenní schůzky, meetupy, skrumáže, technické recenze, recenze kódu atd. Dobrý vývojář vstane a řekne: hele, my se scházíme a diskutujeme každý týden o tom samém, nechápu proč, mohli bychom tu hodinu strávit na Contře. Nebo: u třetího úkolu v řadě se nemohu dostat do kódu, nic není jasné, architektura je plná děr; Možná je náš kontrolní kód lame a potřebujeme refaktorovat, refaktorujme setkání každé dva týdny. Nebo při kontrole kódu člověk vidí, že jeden z jeho kolegů nevyužívá určitý nástroj dostatečně efektivně, což znamená, že musí přijít později a poradit. Dobrý vývojář má tento instinkt, dělá takové věci automaticky.
7. Vynikající v řízení ostatních, i když ne manažer
Tato dovednost se dobře pojí s tématem „řešit spíše než vytvářet problémy“. V textu volného místa, o které se ucházíme, se často nepíše nic o managementu, ale pak, když stojíte před problémem, který nemůžete ovlivnit, musíte stejně řídit ostatní tak či onak, dosáhnout od nich něčeho, pokud zapomněl - zatlačte, ujistěte se, že všemu rozuměli. Dobrý vývojář ví, koho co zajímá, může s těmito lidmi svolat schůzku, sepsat dohody, poslat je do slacku, připomenout ve správný den, ujistit se, že je vše připraveno, i když za to není osobně přímo odpovědný tento úkol, ale jeho výsledek závisí na jeho provedení.
8. Nevnímá své znalosti jako dogma, je neustále otevřený kritice
Každý si může vzpomenout na kolegu z předchozího zaměstnání, který není schopen slevit ze své technologie a křičí, že všichni shoří v pekle za nějaké špatné mutace. Dobrý vývojář, pokud pracuje 5, 10, 20 let v oboru, chápe, že polovina jeho znalostí je prohnilá a ve zbývající polovině neví desetkrát víc, než ví. A pokaždé, když s ním někdo nesouhlasí a nabízí alternativu, není to útok na jeho ego, ale příležitost se něco naučit. To mu umožňuje růst mnohem rychleji než jeho okolí.
Porovnejme moji představu ideálního vývojáře s obecně přijímanou:
Tento obrázek ukazuje, kolik bodů popsaných výše souvisí s kódem a kolik nikoli. Vývoj v produktové společnosti tvoří pouze jednu třetinu programování, zbývající 2/3 mají s kódem pramálo společného. A přestože píšeme hodně kódu, naše efektivita do značné míry závisí na těchto „irelevantních“ dvou třetinách.
Specializace, generalismus a pravidlo 80-20
Když se člověk naučí řešit nějaké úzké problémy, studuje dlouho a tvrdě, ale pak je řeší snadno a jednoduše, ale nemá odbornost v příbuzných oborech, to je specializace. Generalismus je, když polovina tréninkového času je investována do oblasti vlastních kompetencí a druhá polovina do příbuzných oblastí. Podle toho v prvním případě dělám jednu věc dokonale a zbytek špatně a ve druhém dělám všechno víceméně dobře.
Pravidlo 80-20 nám říká, že 80 % výsledku pochází z 20 % úsilí. 80 % příjmů pochází od 20 % zákazníků, 80 % zisku pochází od 20 % zaměstnanců a tak dále. Ve výuce to znamená, že 80 % znalostí získáme za prvních 20 % stráveného času.
Existuje myšlenka: kodéři by měli pouze kódovat, návrháři by měli pouze navrhovat, analytici by měli analyzovat a manažeři by měli pouze spravovat. Podle mého názoru je tato myšlenka toxická a nefunguje příliš dobře. Nejde o to, aby každý musel být univerzálním vojákem, jde o úsporu zdrojů. Pokud vývojář alespoň trochu rozumí správě, designu a analýze, bude schopen vyřešit mnoho problémů bez zapojení dalších lidí. Pokud potřebujete vytvořit nějakou funkci a pak zkontrolovat, jak s ní uživatelé pracují v určitém kontextu, což bude vyžadovat dva SQL dotazy, pak je skvělé, že tím nebudete moci rozptylovat analytika. Pokud potřebujete vložit tlačítko analogicky ke stávajícím a rozumíte obecným principům, můžete to udělat bez zapojení designéra a společnost vám za to poděkuje.
Celkem: můžete strávit 100 % svého času studiem dovednosti až do limitu, nebo můžete strávit stejný čas pěti oblastmi, přičemž v každé dosáhnete úrovně až 80 %. Podle této naivní matematiky můžeme za stejnou dobu získat čtyřikrát více dovedností. To je nadsázka, ale ilustruje to myšlenku.
Související dovednosti lze trénovat ne z 80 %, ale z 30-50 %. Po strávení 10-20 hodin se znatelně zlepšíte v souvisejících oblastech, získáte mnoho porozumění procesům v nich probíhajících a stanete se mnohem autonomnějšími.
V dnešním IT ekosystému je lepší mít co nejvíce dovedností a nebýt odborníkem v žádné z nich. Protože za prvé všechny tyto dovednosti rychle vyprchají, zvláště co se programování týče, a za druhé proto, že 99 % času používáme nejen základní, ale rozhodně ne ty nejsofistikovanější dovednosti, a to stačí i v kódování, a to i v cool společnosti.
A konečně, školení je investice a v investicích je důležitá diverzifikace.
Co učit
Co tedy učit a jak? Typický vývojář v silné společnosti pravidelně používá:
- sdělení
- sebeorganizace
- plánování
- design (obvykle kód)
- a někdy management, vedení, analýza dat, psaní, nábor, mentoring a mnoho dalších dovedností
A prakticky žádná z těchto dovedností se nekříží s kódem samotným. Je třeba je učit a upgradovat samostatně, a pokud se tak nestane, zůstanou na velmi nízké úrovni, což neumožňuje jejich efektivní využití.
V jakých oblastech se vyplatí rozvíjet?
Soft skills jsou vše, co se netýká mačkání tlačítek v editoru. Takhle píšeme zprávy, jak se chováme na poradách, jak komunikujeme s kolegy. To vše se zdá být samozřejmé, ale velmi často se podceňují.
Samoorganizační systém. Pro mě osobně se to za poslední rok stalo superdůležitým tématem. Mezi všemi skvělými IT pracovníky, které znám, je to jedna z nejrozvinutějších dovedností: jsou super organizovaní, vždy dělají, co říkají, přesně vědí, co budou dělat zítra, za týden, za měsíc. Je potřeba si kolem sebe vybudovat systém, do kterého se budou zaznamenávat všechny záležitosti a všechny otázky, což značně usnadňuje samotnou práci a výrazně napomáhá interakci s ostatními lidmi. Mám pocit, že za poslední rok mě vývoj v tomto směru zlepšil mnohem více než zlepšení technických dovedností, začal jsem dělat podstatně více práce za jednotku času.
Proaktivní, s otevřenou myslí a plánování. Témata jsou velmi obecná a zásadní, nejsou specifická pro IT, a každý by je měl rozvíjet. Proaktivita znamená nečekat na signál k akci. Vy jste zdrojem událostí, ne reakcí na ně. Otevřenost je schopnost objektivně zacházet s každou novou informací, vyhodnotit situaci izolovaně od vlastního vidění světa a starých zvyků. Plánování je jasnou vizí toho, jak dnešní úkol řeší problém na týden, měsíc, rok. Pokud vidíte budoucnost za určitým úkolem, je mnohem snazší udělat to, co potřebujete, a nebát se po čase uvědomit si, že to bylo promarněné. Tato dovednost je zvláště důležitá pro kariéru: můžete úspěšně dosahovat výsledků roky, ale na špatném místě, a nakonec ztratit všechna nahromaděná zavazadla, když je jasné, že jste se pohybovali špatným směrem.
Všechny související oblasti na základní úroveň. Každý má své specifické oblasti, ale je důležité pochopit, že když strávíte 10–20 hodin času na vylepšování nějaké „cizí“ dovednosti, můžete objevit mnoho nových příležitostí a styčných bodů ve své každodenní práci. stačí do konce kariéry.
Co číst
Existuje mnoho knih o sebeorganizaci; je to celé odvětví, kde nějací podivní lidé píší sbírky rad a shromažďují školení. Zároveň není jasné, čeho oni sami v životě dosáhli. Proto je důležité na autory nasadit filtry, podívat se, kdo jsou a co mají za sebou. Můj vývoj a rozhled nejvíce ovlivnily čtyři knihy, všechny se tak či onak týkaly zlepšování dovedností popsaných výše.
1. Dale Carnegie „Jak získávat přátele a působit na lidi“. Kultovní kniha o měkkých dovednostech, pokud nevíte, kde začít, výběr je oboustranně výhodná. Je postavena na příkladech, dobře se čte, nevyžaduje velké úsilí k pochopení čteného a nabyté dovednosti lze okamžitě aplikovat. Celkově kniha pokrývá téma komunikace s lidmi.
2. Stephen R. Covey „7 návyků vysoce efektivních lidí“. Mix různých dovedností, od proaktivity po měkké dovednosti, s důrazem na dosažení synergie, když potřebujete z malého týmu udělat obrovskou sílu. Je to také snadné čtení.
3. Ray Dalio "Principy". Odhaluje témata otevřenosti a proaktivity, vycházející z historie firmy, kterou autor vybudoval a kterou řídil 40 let. Mnoho těžce získaných příkladů ze života ukazuje, jak předpojatý a závislý člověk může být a jak se jich zbavit.
4. David Allen, „Getting Things Done“. Povinná četba, abyste se naučili sebeorganizaci. Není to tak snadné čtení, ale poskytuje komplexní sadu nástrojů pro organizaci života a záležitostí, podrobně zkoumá všechny aspekty a pomůže vám rozhodnout se, co přesně potřebujete. S její pomocí jsem si vybudoval vlastní systém, který mi umožňuje vždy dělat to nejdůležitější, aniž bych zapomněl na zbytek.
Musíte pochopit, že pouhé čtení nestačí. Můžete spolknout alespoň knihu týdně, ale účinek vydrží několik dní a pak se vše vrátí na své místo. Knihy by měly být využívány jako zdroj rad, který je ihned ověřen v praxi. Pokud to neuděláte, jediné, co poskytnou, je nějaké rozšíření vašich obzorů.
Zdroj: www.habr.com
