Prečo len inovácia kódovania z vás neurobí lepšieho vývojára

Prečo len inovácia kódovania z vás neurobí lepšieho vývojára

Techlead Skyeng Kirill Rogovoy (flashhhh) prednáša na konferenciách prezentáciu, v ktorej hovorí o zručnostiach, ktoré by si mal každý dobrý vývojár rozvíjať, aby sa stal najlepším. Požiadal som ho, aby sa o tento príbeh podelil s čitateľmi Habra, dávam slovo Kirillovi.

Mýtus o dobrom vývojárovi je, že:

  1. Píše čistý kód
  2. Pozná veľa technológií
  3. Rýchlejšie kódovanie úloh
  4. Pozná množstvo algoritmov a návrhových vzorov
  5. Môže refaktorovať akýkoľvek kód pomocou čistého kódu
  6. Nestráca čas neprogramovacími úlohami
  7. 100% majster svojej obľúbenej technológie

Takto vidí HR ideálnych kandidátov a podľa toho aj voľné pracovné miesta vyzerajú.

Ale moja skúsenosť hovorí, že to nie je veľmi pravda.

Najprv dve dôležité upozornenia:
1) moja skúsenosť je produktové tímy, t.j. spoločnosti s vlastným produktom, nie outsourcing; pri outsourcingu môže byť všetko veľmi odlišné;
2) ak si junior, tak nie všetky rady budú použiteľné a na tvojom mieste by som sa zatiaľ sústredil na programovanie.

Dobrý vývojár: realita

1: Lepší ako priemerný kód

Dobrý vývojár vie, ako vytvoriť skvelú architektúru, napísať skvelý kód a nerobiť príliš veľa chýb; Vo všeobecnosti sa mu darí lepšie ako priemer, ale nepatrí medzi top 1 % špecialistov. Väčšina najúžasnejších vývojárov, ktorých poznám, nie sú až takí skvelí programátori: sú skvelí v tom, čo robia, ale nedokážu nič mimoriadne výnimočné.

2: Rieši problémy namiesto ich vytvárania

Predstavme si, že do projektu potrebujeme integrovať externú službu. Dostaneme technické špecifikácie, pozrieme sa na dokumentáciu, uvidíme, že je tam niečo zastarané, pochopíme, že musíme odovzdať ďalšie parametre, urobiť nejaké úpravy, pokúsiť sa to všetko nejako implementovať a urobiť nejaký krivý spôsob, aby fungoval správne, konečne po niekoľkých dní chápeme, že takto nemôžeme pokračovať. Štandardné správanie developera v tejto situácii je vrátiť sa k biznisu a povedať: „Urobil som to a to, toto nefunguje tak a tamto nefunguje vôbec, tak choďte na to sami. “ Podnik má problém: musíte sa ponoriť do toho, čo sa stalo, komunikovať s niekým a pokúsiť sa to nejako vyriešiť. Rozbitý telefón začne: "Povedz mu, ja jej napíšem, pozri, čo odpovedali."

Dobrý vývojár si v takejto situácii sám nájde kontakty, skontaktuje sa s ním telefonicky, prediskutuje problém a ak sa nič nepodarí, zoženie tých správnych ľudí, všetko vysvetlí a ponúkne alternatívy (pravdepodobne existuje iná externá služba s lepšou podporou). Takýto vývojár vidí problém v biznise a rieši ho. Jeho úloha je uzavretá, keď rieši obchodný problém, a nie vtedy, keď do niečoho narazí.

3: Snaží sa vynaložiť minimálne úsilie na dosiahnutie maximálnych výsledkov, aj keď to znamená písanie barlí

Vývoj softvéru v produktových spoločnostiach je takmer vždy najväčšou nákladovou položkou: vývojári sú drahí. A dobrý vývojár chápe, že firma chce získať maximálne množstvo peňazí minimom. Aby mu pomohol dobrý vývojár, chce minúť minimálne množstvo svojho drahého času na získanie maximálneho zisku pre zamestnávateľa.

Sú tu dva extrémy. Jedným z nich je, že vo všeobecnosti môžete vyriešiť všetky problémy pomocou barle, bez toho, aby ste sa obťažovali architektúrou, bez refaktorovania atď. Všetci vieme, ako to zvyčajne končí: nič nefunguje, projekt prepisujeme od začiatku. Ďalšia je, keď sa človek snaží vymyslieť ideálnu architektúru pre každé tlačidlo, pričom hodinu strávi úlohou a štyri refaktorovaním. Výsledok takejto práce vyzerá skvele, ale problém je v tom, že na obchodnej stránke trvá dokončenie tlačidla desať hodín, v prvom aj druhom prípade jednoducho z iných dôvodov.

Dobrý vývojár vie, ako balansovať medzi týmito extrémami. Chápe súvislosti a robí optimálne rozhodnutie: v tomto probléme striehnu barličku, pretože ide o kód, ktorý sa dotýka raz za pol roka. Ale v tomto sa budem trápiť a robiť všetko čo najsprávnejšie, pretože sto nových funkcií, ktoré sa ešte musia vyvinúť, bude závisieť od toho, čo sa mi podarí.

4. Má vlastný systém riadenia podniku a je schopný v ňom pracovať na projektoch akejkoľvek zložitosti.

Práca na princípoch Dokončiť veci – keď si všetky svoje úlohy zapíšete do nejakého textového systému, nezabudnete na žiadne dohody, každého postrčíte, všade sa objavíte včas, viete, čo je momentálne dôležité a čo nie, nikdy o úlohy neprichádzate. Všeobecnou charakteristikou takýchto ľudí je, že keď sa s nimi na niečom dohodnete, nikdy sa nebojíte, že zabudnú; a tiež viete, že si všetko zapisujú a nebudú sa potom pýtať tisíc otázok, o ktorých odpovediach sa už hovorilo.

5. Spochybňuje a objasňuje akékoľvek podmienky a úvody

Aj tu existujú dva extrémy. Na jednej strane môžete byť voči všetkým úvodným informáciám skeptický. Ľudia pred vami prišli s nejakými riešeniami, ale vy si myslíte, že to môžete urobiť lepšie a začať znovu diskutovať o všetkom, čo bolo pred vami: dizajn, obchodné riešenia, architektúra atď. To stráca veľa času pre vývojára aj pre jeho okolie a má to negatívny vplyv na dôveru v rámci spoločnosti: iní ľudia nechcú robiť rozhodnutia, pretože vedia, že ten chlap sa vráti a všetko rozbije. Druhým extrémom je, keď developer vníma akékoľvek úvodné, technické špecifikácie a obchodné želania ako niečo vytesané do kameňa a až keď stojí pred neriešiteľným problémom, začne uvažovať o tom, či vôbec robí to, čo robí. Dobrý vývojár tu nachádza aj strednú cestu: snaží sa pochopiť rozhodnutia urobené pred ním alebo bez neho, skôr ako sa úloha dostane do vývoja. Čo chce biznis? Riešime jeho problémy? Produktový dizajnér prišiel s riešením, ale chápem, prečo bude riešenie fungovať? Prečo vedúci tímu prišiel s touto konkrétnou architektúrou? Ak niečo nie je jasné, treba sa ísť opýtať. V procese tohto objasňovania môže dobrý vývojár vidieť alternatívne riešenie, ktoré jednoducho predtým nikoho nenapadlo.

6. Zlepšuje procesy a ľudí okolo vás

Okolo nás prebieha množstvo procesov – denné stretnutia, stretnutia, scrumy, technické recenzie, recenzie kódu atď. Dobrý vývojár vstane a povie: pozri, stretávame sa a diskutujeme o tom istom každý týždeň, nechápem prečo, mohli by sme túto hodinu stráviť aj na Contre. Alebo: pri tretej úlohe v rade sa neviem dostať do kódu, nič nie je jasné, architektúra je plná dier; Možno je náš kontrolný kód chabý a musíme refaktorovať stretnutie každé dva týždne. Alebo počas kontroly kódu človek vidí, že jeden z jeho kolegov nepoužíva určitý nástroj dostatočne efektívne, čo znamená, že musí prísť neskôr a poradiť. Dobrý vývojár má tento inštinkt, robí takéto veci automaticky.

7. Vynikajúci v riadení druhých, aj keď nie manažér

Táto zručnosť sa dobre hodí k téme „riešiť skôr ako vytvárať problémy“. V texte voľného miesta, o ktoré sa uchádzame, sa často nepíše nič o riadení, ale potom, keď sa stretnete s problémom, ktorý nemôžete ovplyvniť, stále musíte tak či onak riadiť ostatných, niečo od nich dosiahnuť, ak zabudol - zatlačte, uistite sa, že všetko pochopili. Dobrý developer vie, koho čo zaujíma, môže s týmito ľuďmi zvolať stretnutie, spísať dohody, poslať ich do slacku, pripomenúť v správny deň, uistiť sa, že je všetko pripravené, aj keď nie je osobne priamo zodpovedný za túto úlohu, ale jeho výsledok závisí od jej realizácie.

8. Nevníma svoje vedomosti ako dogmu, je neustále otvorený kritike

Každý si určite spomenie na kolegu z predchádzajúceho zamestnania, ktorý nie je schopný robiť kompromisy vo svojej technológii a kričí, že všetci zhoria v pekle za nejaké nesprávne mutácie. Dobrý vývojár, ak pracuje 5, 10, 20 rokov v brandži, chápe, že polovica jeho vedomostí je prehnitá a vo zvyšnej polovici nevie desaťkrát viac, ako vie. A vždy, keď s ním niekto nesúhlasí a ponúkne alternatívu, nie je to útok na jeho ego, ale príležitosť niečo sa naučiť. To mu umožňuje rásť oveľa rýchlejšie ako tí okolo neho.

Porovnajme moju predstavu ideálneho vývojára so všeobecne akceptovanou:

Prečo len inovácia kódovania z vás neurobí lepšieho vývojára

Tento obrázok ukazuje, koľko bodov popísaných vyššie súvisí s kódom a koľko nie. Vývoj v produktovej spoločnosti je len jedna tretina programovania, zvyšné 2/3 majú málo spoločného s kódom. A hoci píšeme veľa kódu, naša efektivita značne závisí od týchto „irelevantných“ dvoch tretín.

Špecializácia, všeobecnosť a pravidlo 80-20

Keď sa človek naučí riešiť nejaké úzke problémy, študuje dlho a tvrdo, no potom ich ľahko a jednoducho rieši, no nemá odbornosť v príbuzných odboroch, to je špecializácia. Generalizmus je, keď polovica tréningového času je investovaná do oblasti vlastných kompetencií a druhá polovica do súvisiacich oblastí. Podľa toho v prvom prípade robím jednu vec dokonale a zvyšok zle a v druhom robím všetko viac-menej dobre.

Pravidlo 80-20 nám hovorí, že 80% výsledku pochádza z 20% úsilia. 80 % príjmov pochádza od 20 % zákazníkov, 80 % zisku pochádza od 20 % zamestnancov atď. Vo vyučovaní to znamená, že 80 % vedomostí získame za prvých 20 % stráveného času.

Existuje myšlienka: kóderi by mali iba kódovať, dizajnéri by mali iba navrhovať, analytici by mali analyzovať a manažéri by mali iba riadiť. Podľa mňa je táto myšlienka toxická a nefunguje veľmi dobre. Tu nejde o to, že každý musí byť univerzálnym vojakom, ide o šetrenie zdrojov. Ak vývojár aspoň trochu rozumie riadeniu, dizajnu a analytike, bude schopný vyriešiť veľa problémov bez zapojenia ďalších ľudí. Ak potrebujete vytvoriť nejakú funkciu a potom skontrolovať, ako s ňou používatelia pracujú v určitom kontexte, čo si bude vyžadovať dva SQL dotazy, potom je skvelé, že tým nebudete môcť rozptyľovať analytika. Ak potrebujete vložiť tlačidlo analogicky s existujúcimi a rozumiete všeobecným princípom, môžete to urobiť bez zapojenia dizajnéra a spoločnosť vám za to poďakuje.

Celkom: môžete stráviť 100 % svojho času štúdiom zručnosti až po limit, alebo môžete rovnaký čas venovať piatim oblastiam, pričom v každej z nich dosiahnete úroveň až 80 %. Podľa tejto naivnej matematiky môžeme za rovnaký čas získať štyrikrát toľko zručností. Je to prehnané, ale ilustruje to myšlienku.

Súvisiace zručnosti je možné trénovať nie o 80%, ale o 30-50%. Po strávení 10-20 hodín sa výrazne zlepšíte v súvisiacich oblastiach, získate veľa vedomostí o procesoch, ktoré sa v nich vyskytujú a stanete sa oveľa viac autonómnymi.

V dnešnom IT ekosystéme je lepšie mať čo najviac zručností a nebyť odborníkom v žiadnej z nich. Pretože po prvé, všetky tieto zručnosti sa rýchlo vytrácajú, najmä čo sa programovania týka, a po druhé preto, že 99% času používame nielen základné, ale určite nie najsofistikovanejšie zručnosti a to stačí aj pri kódovaní, dokonca aj v cool spoločnosti.

A napokon, vzdelávanie je investícia a pri investíciách je dôležitá diverzifikácia.

Čo učiť

Čo teda učiť a ako? Typický vývojár v silnej spoločnosti pravidelne používa:

  • komunikácia
  • sebaorganizácie
  • plánovanie
  • dizajn (zvyčajne kód)
  • a niekedy manažment, vedenie, analýza údajov, písanie, nábor, mentoring a mnoho ďalších zručností

A prakticky žiadna z týchto zručností sa neprelína so samotným kódom. Treba ich učiť a upgradovať samostatne, a ak sa tak nestane, zostanú na veľmi nízkej úrovni, čo neumožňuje ich efektívne využitie.

V ktorých oblastiach sa oplatí rozvíjať?

  1. Soft skills sú všetko, čo sa netýka stláčania tlačidiel v editore. Takto si píšeme správy, ako sa správame na poradách, ako komunikujeme s kolegami. To všetko sa zdá byť samozrejmosťou, no veľmi často sa podceňuje.

  2. Samoorganizačný systém. Pre mňa osobne sa to za posledný rok stalo superdôležitou témou. Spomedzi všetkých skvelých IT pracovníkov, ktorých poznám, je to jedna z najrozvinutejších zručností: sú super organizovaní, vždy robia to, čo hovoria, presne vedia, čo budú robiť zajtra, o týždeň, o mesiac. Je potrebné okolo seba vybudovať systém, v ktorom sú všetky záležitosti a všetky otázky zaznamenané, čo značne uľahčuje samotnú prácu a výrazne pomáha pri interakcii s inými ľuďmi. Mám pocit, že za posledný rok ma vývoj v tomto smere zlepšil oveľa viac ako zlepšovanie technických zručností, začal som robiť podstatne viac práce za jednotku času.

  3. Aktívny, otvorený a plánujúci. Témy sú veľmi všeobecné a dôležité, nie sú jedinečné pre IT a každý by ich mal rozvíjať. Proaktivita znamená nečakať na signál na akciu. Ste zdrojom udalostí, nie reakcií na ne. Otvorenosť je schopnosť objektívne zaobchádzať s každou novou informáciou, hodnotiť situáciu izolovane od vlastného svetonázoru a starých zvykov. Plánovanie je jasná vízia toho, ako dnešná úloha rieši problém na týždeň, mesiac, rok. Ak vidíte budúcnosť za konkrétnou úlohou, je oveľa jednoduchšie urobiť to, čo potrebujete, a nebojte sa po čase si uvedomiť, že to bolo zbytočné. Táto zručnosť je obzvlášť dôležitá pre kariéru: môžete roky úspešne dosahovať výsledky, ale na nesprávnom mieste, a nakoniec stratiť všetku nahromadenú batožinu, keď je jasné, že ste sa pohybovali nesprávnym smerom.

  4. Všetky súvisiace oblasti na základnú úroveň. Každý má svoje špecifické oblasti, ale je dôležité pochopiť, že ak strávite 10 – 20 hodín času na zlepšovanie niektorých „cudzích“ zručností, môžete objaviť veľa nových príležitostí a kontaktných bodov vo svojej každodennej práci. stačí do konca kariéry.

Čo čítať

Existuje veľké množstvo kníh o sebaorganizácii; je to celé odvetvie, kde niektorí podivní chlapci píšu zbierky rád a zbierajú školenia. Zároveň nie je jasné, čo oni sami v živote dosiahli. Preto je dôležité dať na autorov filtre, pozrieť sa, kto sú a čo majú za sebou. Môj vývoj a rozhľad najviac ovplyvnili štyri knihy, pričom všetky sa tak či onak týkali zlepšovania vyššie popísaných zručností.

Prečo len inovácia kódovania z vás neurobí lepšieho vývojára1. Dale Carnegie „Ako získavať priateľov a pôsobiť na ľudí“. Kultová kniha o mäkkých zručnostiach, ak neviete, kde začať, výber je obojstranne výhodná možnosť. Je postavená na príkladoch, ľahko sa číta, nevyžaduje veľké úsilie na pochopenie prečítaného a nadobudnuté zručnosti je možné okamžite aplikovať. Celkovo kniha pokrýva tému komunikácie s ľuďmi.

Prečo len inovácia kódovania z vás neurobí lepšieho vývojára2. Stephen R. Covey „7 návykov vysoko efektívnych ľudí“. Mix rôznych zručností, od proaktivity až po mäkké zručnosti, s dôrazom na dosiahnutie synergie, keď potrebujete zmeniť malý tím na obrovskú silu. Tiež sa to ľahko číta.

Prečo len inovácia kódovania z vás neurobí lepšieho vývojára3. Ray Dalio "Princípy". Odhaľuje témy otvorenosti a proaktivity, vychádzajúce z histórie firmy, ktorú autor vybudoval a ktorú riadil 40 rokov. Veľa ťažko vybojovaných príkladov zo života ukazuje, aký môže byť človek predsudkový a závislý a ako sa ho zbaviť.

Prečo len inovácia kódovania z vás neurobí lepšieho vývojára4. David Allen, „Getting Things Done“. Povinné čítanie, aby ste sa naučili sebaorganizácii. Nečíta sa tak ľahko, ale poskytuje komplexný súbor nástrojov na organizovanie života a záležitostí, podrobne skúma všetky aspekty a pomáha vám rozhodnúť sa, čo presne potrebujete. S jej pomocou som si vybudoval vlastný systém, ktorý mi umožňuje robiť vždy tie najdôležitejšie veci bez toho, aby som zabudol na zvyšok.

Musíte pochopiť, že len čítanie nestačí. Môžete prehltnúť aspoň knihu týždenne, ale efekt vydrží niekoľko dní a potom sa všetko vráti na svoje miesto. Knihy by mali slúžiť ako zdroj rád, ktorý sa okamžite preverí v praxi. Ak to neurobíte, jediné, čo vám poskytnú, je rozšírenie vašich obzorov.

Zdroj: hab.com

Pridať komentár