Wêrom gewoan jo kodearring opwurdearje sil jo net in bettere ûntwikkelder meitsje

Techlead Skyeng Kirill Rogovoy (flashhhh) jout in presintaasje op konferinsjes wêryn hy it hat oer de feardichheden dy't elke goede ûntwikkelder ûntwikkelje moat om de bêste te wurden. Ik frege him dit ferhaal te dielen mei Habra-lêzers, ik jou it wurd oan Kirill.

De myte oer in goede ûntwikkelder is dat hy:

1. Skriuwt skjinne koade
2. Kent in protte technologyen
3. Kodearje taken rapper
4. Kent in boskje algoritmen en ûntwerppatroanen
5. Kin elke koade refaktorearje mei Clean Code
6. Fergrieme gjin tiid op net-programmearring taken
7. 100% master fan jo favorite technology

Dit is hoe't HR ideale kandidaten sjocht, en fakatueres sjogge der dêrom ek sa út.

Mar myn ûnderfining seit dat dit net heul wier is.

Earst twa wichtige disclaimers:
1) myn ûnderfining is produkt teams, i.e. bedriuwen mei har eigen produkt, net útbesteegje; by it útbesteegjen kin alles hiel oars;
2) as jo in junior binne, dan sille net alle advizen fan tapassing wêze, en as ik jo wie, soe ik my no konsintrearje op programmearring.

Goede ûntwikkelder: realiteit

1: Better as gemiddelde koade

In goede ûntwikkelder wit hoe't jo koele arsjitektuer meitsje, koele koade skriuwe en net te folle bugs meitsje; Yn 't algemien docht hy it better as gemiddeld, mar hy is net yn' e top 1% fan spesjalisten. De measte fan 'e coolste ûntwikkelders dy't ik ken binne net sa geweldige kodearders: se binne geweldich yn wat se dogge, mar se kinne neat super-bûtengewoan dwaan.

2: Lost problemen op ynstee fan te meitsjen

Litte wy ús foarstelle dat wy in eksterne tsjinst yn it projekt moatte yntegrearje. Wy ûntfange de technyske spesifikaasjes, besjoch de dokumintaasje, sjogge dat der wat ferâldere is, begripe dat wy ekstra parameters moatte trochjaan, wat oanpassingen meitsje, besykje it allegear op ien of oare manier út te fieren en meitsje wat krom metoade goed wurket, einliks nei in pear fan dagen wy begripe dat wy kinne net trochgean sa. It standertgedrach fan in ûntwikkelder yn dizze situaasje is om werom te gean nei it bedriuwslibben en te sizzen: “Ik haw dit en dat dien, dizze wurket net sa, en dy wurket hielendal net, dus gean der sels út. ” In bedriuw hat in probleem: jo moatte ferdjipje yn wat der bard is, mei immen kommunisearje en besykje it op ien of oare manier op te lossen. De brutsen telefoan begjint: "Jo fertel him, ik sil har sms'je, sjoch wat se antwurden."

In goede ûntwikkelder, te krijen mei sa'n situaasje, sil sels kontakten fine, kontakt opnimme mei him op 'e tillefoan, it probleem besprekke, en as neat wurket, sil hy de juste minsken sammelje, alles útlizze en alternativen oanbiede (wierskynlik is d'r in oare eksterne tsjinst mei bettere stipe). Sa'n ûntwikkelder sjocht in saaklik probleem en lost it op. Syn taak is sletten as hy in saaklik probleem oplost, en net as hy wat tsjinkomt.

3: Besiket minimale ynspanningen te besteegjen om maksimale resultaten te krijen, sels as it krukkes skriuwen betsjut

Softwareûntwikkeling yn produktbedriuwen is hast altyd de grutste útjeftepost: ûntwikkelders binne djoer. En in goede ûntwikkelder begrypt dat in bedriuw it maksimale bedrach jild wol krije troch it minimum te besteegjen. Om him te helpen, wol in goede ûntwikkelder it minimumbedrach fan syn djoere tiid besteegje om de maksimale winst foar de wurkjouwer te krijen.

D'r binne hjir twa ekstremen. Ien is dat jo oer it algemien alle problemen kinne oplosse mei in kruk, sûnder lestich te meitsjen mei arsjitektuer, sûnder refactoring, ensfh. Wy witte allegear hoe't dit meastal einiget: neat wurket, wy skriuwe it projekt fanôf it begjin ôf. In oar is as in persoan besiket te kommen mei in ideale arsjitektuer foar elke knop, besteegje in oere op 'e taak en fjouwer op refactoring. It resultaat fan sa'n wurk sjocht der geweldich út, mar it probleem is dat it oan 'e saaklike kant tsien oeren duorret om in knop te foltôgjen, yn sawol it earste as twadde gefal, gewoan om ferskate redenen.

In goede ûntwikkelder wit hoe te balansearjen tusken dizze ekstremen. Hy begrypt de kontekst en makket it optimale beslút: yn dit probleem sil ik in kruk snije, om't dit koade is dy't ien kear yn 'e seis moanne oanrekke wurdt. Mar yn dizze iene sil ik lestich falle en alles sa goed mooglik dwaan, om't hûndert nije funksjes dy't noch moatte wurde ûntwikkele sille ôfhingje fan wat ik slagje.

4. Hat in eigen bedriuwsbehearsysteem en is by steat om te wurkjen oan projekten fan elke kompleksiteit dêryn.

Wurkje op prinsipes Taken wurde dien – as jo al jo taken yn in soarte fan tekstsysteem opskriuwe, gjin ôfspraken ferjitte, elkenien triuwe, oeral op tiid sjen litte, witte wat op dit stuit wichtich is en wat net wichtich is, ferlieze jo noait taken. It algemiene skaaimerk fan sokke minsken is dat as jo it wat mei har iens binne, jo noait soargen meitsje dat se ferjitte sille; en jo witte ek dat se alles opskriuwe en dan net tûzen fragen stelle, wêrop de antwurden al besprutsen binne.

5. Fragen en clarifies alle betingsten en ynliedingen

Ek hjir binne der twa utersten. Oan 'e iene kant kinne jo skeptysk wêze oer alle ynliedende ynformaasje. Minsken foar jo kamen mei wat oplossingen, mar jo tinke dat jo better kinne en begjinne opnij te besprekken oer alles wat foar jo kaam: ûntwerp, saaklike oplossingen, arsjitektuer, ensfh. Dit fergriemt in protte tiid foar sawol de ûntwikkelder as de minsken om him hinne, en hat in negative ynfloed op it fertrouwen binnen it bedriuw: oare minsken wolle gjin besluten nimme om't se witte dat dy keardel werom sil komme en alles brekke. It oare ekstreem is wannear't in ûntwikkelder alle ynliedende, technyske spesifikaasjes en saaklike winsken ûnderfynt as wat yn stien útsnien is, en pas as er te krijen hat mei in ûnoplosber probleem, begjint er nei te tinken oft er überhaupt docht wat er docht. In goede ûntwikkelder fynt hjir ek in middengrûn: hy besiket de besluten dy't foar of sûnder him makke binne te begripen, foardat de taak yn ûntwikkeling giet. Wat wol it bedriuw? Losse wy syn problemen op? De produktûntwerper kaam mei in oplossing, mar begryp ik wêrom't de oplossing sil wurkje? Wêrom kaam de teamlieder mei dizze bepaalde arsjitektuer? As der wat net dúdlik is, dan moatte jo gean freegje. Yn it proses fan dizze ferdúdliking kin in goede ûntwikkelder in alternatyf oplossing sjen dy't gewoan net earder by ien wie.

6. Ferbettert prosessen en minsken om dy hinne

D'r binne in protte prosessen om ús hinne geande - deistige gearkomsten, gearkomsten, scrums, technyske beoardielingen, koadebeoardielingen, ensfh. In goeie ûntwikkelder sil oerein komme en sizze: sjoch, wy komme byinoar en besprekke alle wiken itselde, ik begryp net wêrom, wy kinne dit oere likegoed oan Contra besteegje. Of: foar de tredde taak op rige kin ik net yn de koade komme, neat is dúdlik, de arsjitektuer sit fol gatten; Miskien is ús beoardielingskoade kreupel en wy moatte refaktorearje, litte wy de gearkomste elke twa wiken refaktorearje. Of by in koadebeoardieling sjocht in persoan dat ien fan syn kollega's in bepaald ark net effektyf genôch brûkt, wat betsjut dat hy letter opkomme moat en wat advys jaan moat. In goede ûntwikkelder hat dit ynstinkt; hy docht sokke dingen automatysk.

7. Excellent by it behearen fan oaren, sels as net in manager

Dizze feardigens slút goed oan by it tema fan "oplosse ynstee fan problemen te meitsjen." Faak stiet yn de tekst fan de fakatuere dêr't wy oanfreegje neat oer behear skreaun, mar dan, as je te krijen hawwe mei in probleem bûten jo kontrôle, moatte jo oaren noch op ien of oare wize beheare, wat fan har berikke, as jo fergetten - triuwe, soargje derfoar dat se alles begrepen. In goede ûntwikkelder wit wa't ynteressearre is yn wat, kin in gearkomste mei dizze minsken belje, ôfspraken opskriuwe, op 'e slach stjoere, op'e goeie dei herinnerje, soargje dat alles klear is, ek al is hy net persoanlik direkt ferantwurdlik foar dizze taak, mar syn resultaat hinget ôf fan syn útfiering.

8. Besjocht syn kennis net as dogma, stiet hieltyd iepen foar krityk

Elkenien kin in kollega fan in eardere baan ûnthâlde dy't net yn steat is om te kompromisearjen op syn technology en raast dat elkenien yn 'e hel sil ferbaarne foar guon ferkearde mutaasjes. In goede ûntwikkelder, as hy 5, 10, 20 jier yn 'e yndustry wurket, begrypt dat de helte fan syn kennis rot is, en yn 'e oerbleaune helte wit hy net tsien kear mear as hy wit. En elke kear as immen it net mei him iens is en in alternatyf biedt, is it gjin oanfal op syn ego, mar in kâns om wat te learen. Dit lit him folle flugger groeie as dy om him hinne.

Litte wy myn idee fan in ideale ûntwikkelder fergelykje mei de algemien akseptearre:

Dizze foto lit sjen hoefolle fan de hjirboppe beskreaune punten binne relatearre oan de koade, en hoefolle net. Untwikkeling yn in produktbedriuw is mar ien tredde programmearring, de oerbleaune 2/3 hat net folle te meitsjen mei koade. En hoewol wy in protte koade skriuwe, hinget ús effektiviteit sterk ôf fan dizze "irrelevante" twatredde.

Spesjalisaasje, generalisme en de 80-20 regel

As in persoan leart wat smelle problemen op te lossen, studearret lang en hurd, mar lost se dan maklik en ienfâldich op, mar hat gjin saakkundigens yn besibbe fjilden, dit is spesjalisaasje. Generalisme is as de helte fan 'e trainingstiid wurdt ynvestearre yn it gebiet fan eigen kompetinsje, en de oare helte yn besibbe gebieten. As gefolch, yn it earste gefal doch ik ien ding perfekt en de rest min, en yn 'e twadde doch ik alles min of mear goed.

De 80-20-regel fertelt ús dat 80% fan it resultaat komt fan 20% fan 'e ynspanning. 80% fan ynkomsten komt fan 20% fan klanten, 80% fan winst komt fan 20% fan meiwurkers, ensfh. Yn it ûnderwiis betsjut dit dat 80% fan 'e kennis wy krije yn' e earste 20% fan 'e bestege tiid.

D'r is in idee: kodearders moatte allinich koade, ûntwerpers moatte allinich ûntwerpe, analysten moatte analysearje, en managers moatte allinich beheare. Yn myn miening is dit idee giftig en wurket net heul goed. Dit giet net oer dat elkenien in universele soldaat moat wêze, dit giet oer it besparjen fan boarnen. As in ûntwikkelder op syn minst in bytsje begrypt oer behear, ûntwerp en analytyk, sil hy in protte problemen kinne oplosse sûnder oare minsken te belûken. As jo ​​in soarte fan funksje moatte meitsje en dan kontrolearje hoe't brûkers dêrmei wurkje yn in bepaalde kontekst, dy't twa SQL-fragen nedich binne, dan is it geweldich om de analist net mei dizze ôf te kinnen. As jo ​​in knop moatte ynbêde troch analogy mei besteande, en jo begripe de algemiene prinsipes, kinne jo it dwaan sûnder in ûntwerper te belûken, en it bedriuw sil jo tankje foar it.

Totaal: jo kinne 100% fan jo tiid besteegje oan it bestudearjen fan in feardigens oant de limyt, of jo kinne deselde tiid besteegje oan fiif gebieten, en yn elk nivo oant 80%. Nei dizze naïve wiskunde kinne wy ​​fjouwer kear safolle feardigens krije yn deselde tiid. Dit is in oerdriuwing, mar it yllustrearret it idee.

Related feardichheden kinne wurde trained net troch 80%, mar troch 30-50%. Nei't jo 10-20 oeren hawwe trochbrocht, sille jo merkber ferbetterje yn besibbe gebieten, in soad begryp krije fan 'e prosessen dy't yn har foarkomme en folle autonomer wurde.

Yn it hjoeddeistige IT-ekosysteem is it better om safolle mooglik feardigens te hawwen en gjin ekspert te wêzen yn ien fan har. Om't, yn it foarste plak, al dizze feardichheden fluch ferdwine, benammen as it giet om programmearring, en twad, om't 99% fan 'e tiid wy brûke net allinnich basis, mar seker net de meast ferfine feardichheden, en dit is genôch sels yn kodearring, sels yn cool bedriuwen.

En as lêste, training is in ynvestearring, en diversifikaasje is wichtich yn ynvestearrings.

Wat te learen

Dus wat te learen en hoe? In typyske ûntwikkelder yn in sterk bedriuw brûkt geregeldwei:

• kommunikaasje
• selsorganisaasje
• planning
• ûntwerp (meastentiids koade)
• en soms behear, liederskip, data analyze, skriuwen, werving, mentoring en in protte oare feardichheden

En praktysk gjin fan dizze feardichheden krúst op ien of oare manier mei de koade sels. Se moatte apart leard en opwurdearre wurde, en as dit net dien wurdt, bliuwe se op in heul leech nivo, wêrtroch't se net effektyf kinne wurde brûkt.

Yn hokker gebieten binne it wurdich te ûntwikkeljen?

1. Sêfte feardigens binne alles dat net oanbelanget it drukken op knoppen yn 'e bewurker. Dit is hoe't wy berjochten skriuwe, hoe't wy ús gedrage yn gearkomsten, hoe't wy kommunisearje mei kollega's. Dit lykje allegear foar de hân lizzende dingen te wêzen, mar hiel faak wurde se ûnderskat.

2. Self-organisaasje systeem. Foar my persoanlik is dit it ôfrûne jier in superwichtich ûnderwerp wurden. Under alle coole IT-arbeiders dy't ik ken, is dit ien fan 'e meast ûntwikkele feardichheden: se binne superorganisearre, se dogge altyd wat se sizze, se witte krekt wat se moarn, oer in wike, oer in moanne sille dwaan. It is nedich om in systeem om josels hinne te bouwen wêryn alle saken en alle fragen wurde opnomd; dit makket it wurk sels tige makliker en helpt tige om mei oare minsken om te gean. Ik fiel dat it ôfrûne jier, ûntwikkeling yn dizze rjochting my folle mear ferbettere hat as it ferbetterjen fan myn technyske feardichheden; Ik begon signifikant mear wurk te dwaan per ienheid fan tiid.

3. Proaktyf, iepen-minded en planning. De ûnderwerpen binne heul algemien en wichtich, net unyk foar IT, en elkenien soe se moatte ûntwikkelje. Proaktiviteit betsjut net wachtsje op in sinjaal om aksje te nimmen. Jo binne de boarne fan eveneminten, net reaksjes op harren. Iepenheid is de mooglikheid om alle nije ynformaasje objektyf te behanneljen, de situaasje te evaluearjen yn isolemint fan it eigen wrâldbyld en âlde gewoanten. Planning is in dúdlike fyzje fan hoe't de taak fan hjoed it probleem oplost foar de wike, moanne, jier. As jo ​​sjogge de takomst bûten in spesifike taak, it is folle makliker te dwaan wat jo nedich hawwe, en net bang nei de tiid om te realisearjen dat it wie fergriemd. Dizze feardigens is foaral wichtich foar in karriêre: jo kinne jierrenlang mei súkses berikke resultaten, mar op it ferkearde plak, en úteinlik alle opboude bagaazje ferlieze as it dúdlik wurdt dat jo yn 'e ferkearde rjochting bewege.

4. Alle relatearre gebieten nei it basisnivo. Elkenien hat har eigen spesifike gebieten, mar it is wichtich om te begripen dat troch 10-20 oeren tiid te besteegjen oan it nivo fan wat "bûtenlânske" feardigens, kinne jo in protte nije kânsen en kontaktpunten ûntdekke yn jo deistich wurk, en dizze oeren kinne genôch wêze oant it ein fan karriêre.

Wat te lêzen

D'r binne in protte boeken oer selsorganisaasje; it is in hiele yndustry wêr't guon frjemde jonges samlingen advys skriuwe en trainingen sammelje. Tagelyk is it ûndúdlik wat se sels yn it libben berikt hawwe. Dêrom is it wichtich om filters op de auteurs te setten, te sjen wa't se binne en wat se efter har hawwe. Myn ûntwikkeling en perspektyf waarden it meast beynfloede troch fjouwer boeken, allegear op ien of oare manier relatearre oan it ferbetterjen fan de hjirboppe beskreaune feardichheden.

1. Dale Carnegie "Hoe kinne jo freonen winne en minsken beynfloedzje". In kultusboek oer sêfte feardigens, as jo net witte wêr't jo moatte begjinne, kieze it is in win-win-opsje. It is boud op foarbylden, is maklik te lêzen, fereasket net folle ynspanning om te begripen wat jo lêze, en de ferwurven feardichheden kinne fuortendaliks tapast wurde. Oer it algemien behannelt it boek it ûnderwerp fan kommunikaasje mei minsken.

2. Stephen R. Covey "7 gewoanten fan heul effektive minsken". In miks fan ferskate feardigens, fan proaktiviteit oant sêfte feardigens, mei de klam op it berikken fan synergy as jo in lyts team moatte omsette yn in enoarme krêft. It is ek maklik te lêzen.

3. Ray Dalio "Principles". Bliuwt tema's fan iepenheid en proaktiviteit, basearre op 'e skiednis fan it bedriuw dat de auteur boude, dat hy 40 jier behearde. In protte hurd wûn foarbylden út it libben litte sjen hoe foaroardielen en ôfhinklik in persoan kin wêze, en hoe te ûntdwaan fan it.

4. David Allen, "Getting Things Done". Ferplichte lêzing om selsorganisaasje te learen. It is net sa maklik om te lêzen, mar it biedt in wiidweidige set ark foar it organisearjen fan libben en saken, ûndersiket alle aspekten yn detail en helpt jo te besluten wat jo krekt nedich binne. Mei har help haw ik myn eigen systeem boud wêrtroch ik altyd de wichtichste dingen kin dwaan sûnder de rest te ferjitten.

Jo moatte begripe dat gewoan lêzen net genôch is. Jo kinne op syn minst in boek yn 'e wike slikke, mar it effekt sil ferskate dagen duorje, en dan komt alles werom nei syn plak. Boeken moatte brûkt wurde as in boarne fan advys dy't daliks yn de praktyk beproefd wurdt. As jo ​​dit net dogge, dan sil alles wat se jouwe is wat ferbreding fan jo horizonten.

Boarne: www.habr.com