ProHoster > Blogs > interneta ziņas > Kāpēc tikai kodÄ“Å”anas jaunināŔana nepadarÄ«s jÅ«s par labāku izstrādātāju?

Kāpēc tikai kodÄ“Å”anas jaunināŔana nepadarÄ«s jÅ«s par labāku izstrādātāju?

Kāpēc tikai kodÄ“Å”anas jaunināŔana nepadarÄ«s jÅ«s par labāku izstrādātāju?

Tehniskais vadÄ«tājs Skyengs Kirils Rogovojs (flashhhh) uzstājas ar prezentāciju konferencēs, kurās stāsta par prasmēm, kas jāattÄ«sta katram labam izstrādātājam, lai kļūtu par labāko. Es lÅ«dzu viņu padalÄ«ties ar Å”o stāstu ar Habra lasÄ«tājiem, dodu vārdu Kirilam.

MÄ«ts par labu izstrādātāju ir tāds, ka viņŔ:

  1. Raksta tīru kodu
  2. Pārzina daudzas tehnoloģijas
  3. KodÄ“Å”anas uzdevumi ātrāk
  4. Zina virkni algoritmu un dizaina modeļu
  5. Var pārveidot jebkuru kodu, izmantojot Clean Code
  6. Netērē laiku ar programmÄ“Å”anu nesaistÄ«tiem uzdevumiem
  7. 100% jūsu iecienītākās tehnoloģijas meistars

Šādi HR redz ideālus kandidātus, un attiecīgi arī vakances izskatās Ŕādi.

Bet mana pieredze saka, ka tas nav īsti taisnība.

Pirmkārt, divas svarīgas atrunas:
1) mana pieredze ir produktu komandas, t.i. uzņēmumi ar savu produktu, nevis ārpakalpojumu; ārpakalpojumos viss var bÅ«t ļoti atŔķirÄ«gs;
2) ja esi juniors, tad ne visi padomi bÅ«s piemērojami, un, ja es bÅ«tu tavā vietā, es Å”obrÄ«d koncentrētos uz programmÄ“Å”anu.

Labs izstrādātājs: realitāte

1: labāks par vidējo kodu

Labs izstrādātājs zina, kā izveidot lielisku arhitektÅ«ru, rakstÄ«t forÅ”u kodu un neizraisÄ«t pārāk daudz kļūdu; Kopumā viņam veicas labāk par vidējo, taču viņŔ nav speciālistu pirmajā 1% skaitā. Lielākā daļa no stilÄ«gākajiem izstrādātājiem, kurus es pazÄ«stu, nav tik lieliski kodētāji: viņi ir lieliski savā darbÄ«bā, taču viņi nevar paveikt neko Ä«paÅ”i neparastu.

2: atrisina problēmas, nevis tās rada

Iedomāsimies, ka mums projektā jāintegrē ārpakalpojums. Saņemam tehniskās specifikācijas, paskatāmies dokumentāciju, redzam, ka tur kaut kas ir novecojis, saprotam, ka vajag izlaist papildus parametrus, veikt dažas korekcijas, mēģināt to visu kaut kā ieviest un likt pareizi strādāt kaut kādai greizai metodei, beidzot, pēc pāris dienu laikā mēs saprotam, ka mēs nevaram tā turpināt. Izstrādātāja standarta uzvedÄ«ba Å”ajā situācijā ir atgriezties biznesā un teikt: ā€œEs izdarÄ«ju to un to, Å”is nedarbojas tā, un tas nedarbojas vispār, tāpēc ej izdomā pats. ā€ Uzņēmumā ir problēma: jums ir jāiedziļinās notikuÅ”ajā, jāsazinās ar kādu un jāmēģina to kaut kā atrisināt. Sākas salauztais telefons: "Tu viņam pasaki, es viņai uzrakstÄ«Å”u, paskaties, ko viņi atbildēja."

Labs izstrādātājs, saskaroties ar Ŕādu situāciju, pats atradÄ«s kontaktus, sazināsies ar viņu pa telefonu, pārrunās problēmu un, ja nekas neizdosies, tad savāks Ä«stos cilvēkus, visu izskaidros un piedāvās alternatÄ«vas (visticamāk, ka ir arÄ« cita ārējais pakalpojums ar labāku atbalstu). Šāds izstrādātājs redz biznesa problēmu un risina to. Viņa uzdevums ir slēgts, kad viņŔ atrisina biznesa problēmu, nevis tad, kad viņŔ kaut ko uzduras.

3: cenÅ”as tērēt minimālu piepÅ«li, lai iegÅ«tu maksimālu rezultātu, pat ja tas nozÄ«mē kruÄ·u rakstÄ«Å”anu

Programmatūras izstrāde produktu uzņēmumos gandrīz vienmēr ir lielākā izdevumu pozīcija: izstrādātāji ir dārgi. Un labs izstrādātājs saprot, ka bizness vēlas iegūt maksimālo naudas summu, iztērējot minimālo. Lai viņam palīdzētu, labs attīstītājs vēlas tērēt minimālu sava dārgā laika daļu, lai darba devējs iegūtu maksimālu peļņu.

Å eit ir divas galējÄ«bas. Viens ir tas, ka visas problēmas kopumā var atrisināt ar kruÄ·i, neuztraucoties ar arhitektÅ«ru, bez pārstrukturÄ“Å”anas utt. Mēs visi zinām, kā tas parasti beidzas: nekas nedarbojas, mēs pārrakstām projektu no nulles. Cits gadÄ«jums ir tad, kad cilvēks mēģina izdomāt ideālu arhitektÅ«ru katrai pogai, veltot vienu stundu uzdevumam un četras ā€“ pārstrukturÄ“Å”anai. Šāda darba rezultāts izskatās lieliski, taču problēma ir tā, ka biznesa pusē pogas aizpildÄ«Å”ana aizņem desmit stundas, gan pirmajā, gan otrajā gadÄ«jumā vienkārÅ”i dažādu iemeslu dēļ.

Labs izstrādātājs zina, kā balansēt starp Ŕīm galējÄ«bām. ViņŔ saprot kontekstu un pieņem optimālo lēmumu: Å”ajā problēmā es nogriezÄ«Å”u kruÄ·i, jo tas ir kods, kuram pieskaras reizi pusgadā. Bet Å”ajā es apnikÅ”u un darÄ«Å”u visu pēc iespējas pareizi, jo no tā, kas man izdosies, bÅ«s atkarÄ«gi simts jaunu funkciju, kas vēl jāizstrādā.

4. Ir sava biznesa vadības sistēma un spēj tajā strādāt pie jebkuras sarežģītības projektiem.

Darbs pēc principiem Getting Things Done ā€“ pierakstot visus savus uzdevumus kaut kādā teksta sistēmā, neaizmirstiet par lÄ«gumiem, visus pagrÅ«dināt, visur ierasties laicÄ«gi, zināt, kas Å”obrÄ«d ir svarÄ«gi un kas nav svarÄ«gi, jÅ«s nekad nezaudējat uzdevumus. VispārÄ«ga Ŕādu cilvēku Ä«paŔība ir tāda, ka, kad jÅ«s par kaut ko vienojaties ar viņiem, jÅ«s nekad neuztraucaties, ka viņi aizmirsÄ«s; un tu arÄ« zini, ka viņi visu pieraksta un pēc tam neuzdos tÅ«kstoÅ” jautājumu, uz kuriem atbildes jau ir apspriestas.

5. ApÅ”auba un precizē visus nosacÄ«jumus un ievadus

ArÄ« Å”eit ir divas galējÄ«bas. No vienas puses, jÅ«s varat bÅ«t skeptiski pret visu ievadinformāciju. Cilvēki pirms jums nāca klajā ar dažiem risinājumiem, bet jÅ«s domājat, ka jÅ«s varat darÄ«t labāk un sākt no jauna apspriest visu, kas bija pirms jums: dizains, biznesa risinājumi, arhitektÅ«ra utt. Tas tērē daudz laika gan izstrādātājam, gan apkārtējiem, kā arÄ« negatÄ«vi ietekmē uzticÄ“Å”anos uzņēmumā: citi cilvēki nevēlas pieņemt lēmumus, jo zina, ka Å”is puisis atgriezÄ«sies un visu sabojās. Otra galējÄ«ba ir tad, kad izstrādātājs jebkuru ievadu, tehniskās specifikācijas un biznesa vēlmes uztver kā kaut ko akmenÄ« cirstu, un tikai tad, kad saskaras ar neatrisināmu problēmu, viņŔ sāk domāt, vai viņŔ vispār dara to, ko dara. Labs izstrādātājs Å”eit atrod arÄ« vidusceļu: viņŔ cenÅ”as izprast lēmumus, kas pieņemti pirms viņa vai bez viņa, pirms uzdevums nonāk izstrādē. Ko vēlas bizness? Vai mēs risinām viņa problēmas? Produkta dizainers nāca klajā ar risinājumu, bet vai es saprotu, kāpēc risinājums darbosies? Kāpēc komandas vadÄ«tājs nāca klajā ar Å”o konkrēto arhitektÅ«ru? Ja kaut kas nav skaidrs, tad jāiet pajautāt. Å Ä«s precizÄ“Å”anas procesā labs izstrādātājs var ieraudzÄ«t alternatÄ«vu risinājumu, kas vienkārÅ”i nevienam iepriekÅ” nebija ienācis prātā.

6. Uzlabo procesus un cilvēkus sev apkārt

Mums apkārt notiek ļoti daudz procesu ā€“ ikdienas tikÅ”anās, tikÅ”anās, sapulces, tehnoloÄ£iju apskati, kodu apskati utt. Labs izstrādātājs piecelsies un teiks: skaties, mēs sanākam kopā un katru nedēļu apspriežam vienu un to paÅ”u, es nesaprotu, kāpēc, mēs varētu tikpat labi pavadÄ«t Å”o stundu uz Contra. Vai arÄ«: jau treÅ”o uzdevumu pēc kārtas nevaru iekļūt kodā, nekas nav skaidrs, arhitektÅ«ra ir caurumu pilna; VarbÅ«t mÅ«su pārskatÄ«Å”anas kods ir vājÅ”, un mums ir jāreaģē, pārveidosim tikÅ”anos ik pēc divām nedēļām. Vai arÄ« koda pārskatÄ«Å”anas laikā cilvēks redz, ka kāds no viņa kolēģiem nelieto noteiktu rÄ«ku pietiekami efektÄ«vi, un tas nozÄ«mē, ka viņam vēlāk jānāk klajā un jāsniedz padoms. Labam izstrādātājam ir Ŕāds instinkts; viņŔ Ŕādas lietas dara automātiski.

7. Lieliski pārvalda citus, pat ja ne menedžeris

Å Ä« prasme labi saskan ar tēmu ā€œproblēmu risināŔana, nevis radÄ«Å”anaā€. Bieži vien vakances tekstā, uz kuru piesakāmies, nekas nav rakstÄ«ts par menedžmentu, bet tad, saskaroties ar problēmu, kas nav no tevis atkarÄ«ga, vienalga tā vai citādi ir jāvada citi, jāpanāk kaut kas no viņiem, ja tu aizmirsu - spiediet, pārliecinieties, ka viņi visu saprata. Labs izstrādātājs zina, kurÅ” par ko interesējas, var sasaukt tikÅ”anos ar Å”iem cilvēkiem, pierakstÄ«t lÄ«gumus, nosÅ«tÄ«t slinkumam, atgādināt Ä«stajā dienā, pārliecināties, ka viss ir gatavs, pat ja viņŔ personÄ«gi par to nav tieÅ”i atbildÄ«gs. Å”o uzdevumu, bet viņa rezultāts ir atkarÄ«gs no tā izpildes.

8. Neuztver savas zināŔanas kā dogmas, pastāvÄ«gi ir atvērts kritikai

Ikviens var atcerēties kādu kolēģi no iepriekŔējā darba, kurÅ” nespēj piekāpties savā tehnoloÄ£ijā un kliedz, ka visi degs ellē dažu nepareizu mutāciju dēļ. Labs izstrādātājs, ja viņŔ nostrādā 5, 10, 20 gadus nozarē, saprot, ka puse no viņa zināŔanām ir sapuvusi, un atlikuÅ”ajā pusē viņŔ nezina desmit reizes vairāk, kā zina. Un katru reizi, kad kāds viņam nepiekrÄ«t un piedāvā alternatÄ«vu, tas nav uzbrukums viņa ego, bet gan iespēja kaut ko iemācÄ«ties. Tas viņam ļauj augt daudz ātrāk nekā apkārtējie.

SalÄ«dzināsim manu priekÅ”statu par ideālu izstrādātāju ar vispārpieņemto:

Kāpēc tikai kodÄ“Å”anas jaunināŔana nepadarÄ«s jÅ«s par labāku izstrādātāju?

Å ajā attēlā parādÄ«ts, cik daudzi no iepriekÅ” aprakstÄ«tajiem punktiem ir saistÄ«ti ar kodu un cik nav. Izstrāde produktu uzņēmumā ir tikai viena treÅ”daļa programmÄ“Å”ana, pārējām 2/3 ir maz sakara ar kodu. Un, lai gan mēs rakstām daudz koda, mÅ«su efektivitāte lielā mērā ir atkarÄ«ga no Ŕīm "neatbilstoÅ”ajām" divām treÅ”daļām.

Specializācija, ģenerālisms un 80-20 likums

Kad cilvēks iemācās risināt kādas Å”auras problēmas, ilgi un cÄ«tÄ«gi mācās, bet pēc tam tās viegli un vienkārÅ”i risina, bet viņam nav pieredzes saistÄ«tās jomās, tā ir specializācija. Ä¢enerālisms ir tad, kad puse no apmācÄ«bas laika tiek ieguldÄ«ta savas kompetences jomā, bet otra puse ar to saistÄ«tās jomās. AttiecÄ«gi pirmajā gadÄ«jumā es vienu lietu daru perfekti un pārējo slikti, bet otrajā visu izdaru vairāk vai mazāk labi.

Noteikums 80-20 mums saka, ka 80% rezultāta nāk no 20% no piepÅ«les. 80% ieņēmumu nāk no 20% klientu, 80% peļņas nāk no 20% darbinieku utt. MācÄ«bā tas nozÄ«mē, ka 80% zināŔanu mēs iegÅ«stam pirmajos 20% pavadÄ«tā laika.

Ir ideja: kodētājiem vajadzētu tikai kodēt, dizaineriem tikai projektēt, analÄ«tiÄ·iem jāanalizē, un vadÄ«tājiem vajadzētu tikai pārvaldÄ«t. Manuprāt, Ŕī ideja ir toksiska un nedarbojas ļoti labi. Å eit nav runa par to, ka ikvienam ir jābÅ«t universālam karavÄ«ram, bet gan par resursu taupÄ«Å”anu. Ja izstrādātājs vismaz nedaudz saprot pārvaldÄ«bu, dizainu un analÄ«zi, viņŔ varēs atrisināt daudzas problēmas, neiesaistot citus cilvēkus. Ja jums ir jāizveido kāda veida funkcija un pēc tam jāpārbauda, ā€‹ā€‹kā lietotāji ar to strādā noteiktā kontekstā, kam bÅ«s nepiecieÅ”ami divi SQL vaicājumi, ir lieliski, ja ar to varat nenovērst analÄ«tiÄ·a uzmanÄ«bu. Ja jums ir nepiecieÅ”ams iegult pogu pēc analoÄ£ijas ar esoÅ”ajām un jÅ«s saprotat vispārÄ«gos principus, varat to izdarÄ«t, neiesaistot dizaineru, un uzņēmums jums par to pateiks paldies.

Kopā: varat tērēt 100% sava laika, lai apgÅ«tu prasmi lÄ«dz galam, vai arÄ« varat pavadÄ«t to paÅ”u laiku piecās jomās, katrā sasniedzot lÄ«dz pat 80%. Sekojot Å”ai naivai matemātikai, vienā un tajā paŔā laikā mēs varam iegÅ«t četras reizes vairāk prasmju. Tas ir pārspÄ«lēts, bet tas ilustrē ideju.

SaistÄ«tās prasmes var trenēt nevis par 80%, bet par 30-50%. Pavadot 10-20 stundas, tu manāmi pilnveidosies radniecÄ«gās jomās, iegÅ«si daudz izpratnes par tajās notiekoÅ”ajiem procesiem un kļūsi daudz autonomāks.

MÅ«sdienu IT ekosistēmā labāk ir iegÅ«t pēc iespējas vairāk prasmju, nevis bÅ«t ekspertam nevienā no tām. Jo, pirmkārt, visas Ŕīs prasmes ātri izgaist, it Ä«paÅ”i, ja runa ir par programmÄ“Å”anu, un, otrkārt, tāpēc, ka 99% gadÄ«jumu mēs izmantojam ne tikai pamata, bet noteikti ne tās sarežģītākās prasmes, un ar to pietiek pat kodÄ“Å”anā, pat forÅ”i uzņēmumi.

Un visbeidzot, apmācība ir ieguldījums, un ieguldījumos ir svarīga diversifikācija.

Ko mācīt

Tātad, ko mācīt un kā? Tipisks izstrādātājs spēcīgā uzņēmumā regulāri izmanto:

  • komunikāciju
  • paÅ”organizācija
  • plānoÅ”ana
  • dizains (parasti kods)
  • un dažreiz vadÄ«bas, vadÄ«bas, datu analÄ«zes, rakstÄ«Å”anas, darbā pieņemÅ”anas, mentoringa un daudzas citas prasmes

Un praktiski neviena no Ŕīm prasmēm nekrustojas ar paÅ”u kodu. Tie ir jāmāca un jāpilnveido atseviŔķi, un, ja tas netiks izdarÄ«ts, tie paliks ļoti zemā lÄ«menÄ«, kas neļauj tos efektÄ«vi izmantot.

Kurās jomās ir vērts attīstīties?

  1. MÄ«kstās prasmes ir viss, kas neattiecas uz pogu nospieÅ”anu redaktorā. Tā mēs rakstām ziņas, kā uzvedamies sapulcēs, kā komunicējam ar kolēģiem. Å Ä·iet, ka tās visas ir paÅ”saprotamas lietas, taču ļoti bieži tās tiek novērtētas par zemu.

  2. PaÅ”organizācijas sistēma. Man personÄ«gi Ŕī pēdējā gada laikā ir kļuvusi par Ä«paÅ”i svarÄ«gu tēmu. Starp visiem forÅ”ajiem IT darbiniekiem, ko pazÄ«stu, Ŕī ir viena no attÄ«stÄ«tākajām prasmēm: viņi ir superorganizēti, vienmēr dara to, ko saka, precÄ«zi zina, ko darÄ«s rÄ«t, pēc nedēļas, pēc mēneÅ”a. Ap sevi ir jāveido sistēma, kurā tiek ierakstÄ«ti visi jautājumi un visi jautājumi, tas ievērojami atvieglo paÅ”u darbu un ļoti palÄ«dz mijiedarboties ar citiem cilvēkiem. JÅ«tu, ka pēdējā gada laikā attÄ«stÄ«ba Å”ajā virzienā mani ir uzlabojusi daudz vairāk, nekā uzlabojusi tehniskās prasmes, sāku darÄ«t ievērojami vairāk darba laika vienÄ«bā.

  3. ProaktÄ«vs, atvērts un plānojoÅ”s. Tēmas ir ļoti vispārÄ«gas un svarÄ«gas, nav tikai IT, un tās ir jāizstrādā ikvienam. Proaktivitāte nozÄ«mē negaidÄ«t signālu, lai sāktu rÄ«koties. JÅ«s esat notikumu avots, nevis reakcija uz tiem. AtvērtÄ«ba ir spēja objektÄ«vi izturēties pret jebkuru jaunu informāciju, izvērtēt situāciju atrauti no sava pasaules uzskata un vecajiem ieradumiem. PlānoÅ”ana ir skaidra vÄ«zija par to, kā Å”odienas uzdevums atrisina problēmu nedēļā, mēnesÄ«, gadā. Ja redzat nākotni ārpus konkrēta uzdevuma, ir daudz vieglāk darÄ«t to, kas jums nepiecieÅ”ams, un nebaidieties pēc laika saprast, ka tas ir bijis veltÄ«gi. Å Ä« prasme ir Ä«paÅ”i svarÄ«ga karjerā: gadiem ilgi var veiksmÄ«gi sasniegt rezultātus, bet nepareizajā vietā un galu galā pazaudēt visu uzkrāto bagāžu, kad kļūst skaidrs, ka virzāties nepareizā virzienā.

  4. Visas saistÄ«tās jomas lÄ«dz pamata lÄ«menim. Katram ir savas specifiskās jomas, taču ir svarÄ«gi saprast, ka, veltot 10-20 stundas laika kādas ā€œsveÅ”asā€ prasmes pilnveidoÅ”anai, var atklāt daudz jaunu iespēju un saskarsmes punktu ikdienas darbā, un Ŕīs stundas var pietiks lÄ«dz karjeras beigām.

Ko lasīt

Ir ļoti daudz grāmatu par paÅ”organizÄ“Å”anos; tā ir vesela nozare, kurā daži dÄ«vaini puiÅ”i raksta padomu krājumus un apkopo apmācÄ«bas. Tajā paŔā laikā nav skaidrs, ko viņi paÅ”i dzÄ«vē ir sasnieguÅ”i. Tāpēc ir svarÄ«gi uzlikt filtrus autoriem, paskatÄ«ties, kas viņi ir un kas viņiem aiz muguras. Manu attÄ«stÄ«bu un skatÄ«jumu visvairāk ietekmēja četras grāmatas, visas vienā vai otrā veidā saistÄ«tas ar iepriekÅ” aprakstÄ«to prasmju uzlaboÅ”anu.

Kāpēc tikai kodÄ“Å”anas jaunināŔana nepadarÄ«s jÅ«s par labāku izstrādātāju?1. Deils Kārnegijs ā€œKā iegÅ«t draugus un ietekmēt cilvēkusā€. Kulta grāmata par mÄ«kstajām prasmēm. Ja nezināt, ar ko sākt, tās izvēle ir abpusēji izdevÄ«ga iespēja. Tas ir veidots uz piemēriem, ir viegli lasāms, neprasa daudz pūļu, lai saprastu lasÄ«to, un iegÅ«tās prasmes var uzreiz pielietot. Kopumā grāmata aptver saziņas ar cilvēkiem tēmu.

Kāpēc tikai kodÄ“Å”anas jaunināŔana nepadarÄ«s jÅ«s par labāku izstrādātāju?2. StÄ«vens R. Kovijs ā€œ7 ļoti efektÄ«vu cilvēku ieradumiā€. Dažādu prasmju sajaukums, sākot no proaktivitātes lÄ«dz vājām prasmēm, ar uzsvaru uz sinerÄ£ijas panākÅ”anu, kad neliela komanda jāpārvērÅ” par milzÄ«gu spēku. To ir arÄ« viegli lasÄ«t.

Kāpēc tikai kodÄ“Å”anas jaunināŔana nepadarÄ«s jÅ«s par labāku izstrādātāju?3. Rejs Dalio "Principi". Atklāj atvērtÄ«bas un proaktivitātes tēmas, balstoties uz autora uzbÅ«vētā uzņēmuma vēsturi, kuru viņŔ vadÄ«ja 40 gadus. Daudzi grÅ«ti iegÅ«ti piemēri no dzÄ«ves parāda, cik aizspriedumains un atkarÄ«gs var bÅ«t cilvēks un kā no tā atbrÄ«voties.

Kāpēc tikai kodÄ“Å”anas jaunināŔana nepadarÄ«s jÅ«s par labāku izstrādātāju?4. Deivids Alens, ā€œPadarÄ«t lietasā€. Obligātā literatÅ«ra, lai apgÅ«tu paÅ”organizÄ“Å”anos. Tas nav tik viegli lasāms, taču sniedz visaptveroÅ”u rÄ«ku komplektu dzÄ«ves un lietu organizÄ“Å”anai, detalizēti izskata visus aspektus un palÄ«dz izlemt, kas tieÅ”i jums ir nepiecieÅ”ams. Ar viņas palÄ«dzÄ«bu es izveidoju savu sistēmu, kas ļauj man vienmēr darÄ«t vissvarÄ«gākās lietas, neaizmirstot par pārējo.

Jums jāsaprot, ka ar lasÄ«Å”anu vien nepietiek. Nedēļā var norÄ«t vismaz grāmatu, bet efekts saglabāsies vairākas dienas, un tad viss atgriezÄ«sies savās vietās. Grāmatas jāizmanto kā padomu avots, kas nekavējoties tiek pārbaudÄ«ts praksē. Ja jÅ«s to nedarÄ«siet, viss, ko viņi dos, ir jÅ«su redzesloka paplaÅ”ināŔana.

Avots: www.habr.com

Pievieno komentāru