Miksi pelkkä koodauksen päivittäminen ei tee sinusta parempaa kehittäjää?

Tekninen johtaja Skyeng Kirill Rogovoy (flashhhh) pitää konferensseissa esitelmän, jossa hän puhuu taidoista, joita jokaisen hyvän kehittäjän tulee kehittää tullakseen parhaaksi. Pyysin häntä jakamaan tämän tarinan Habran lukijoiden kanssa, annan sanan Kirillille.

Myytti hyvästä kehittäjästä on, että hän:

1. Kirjoittaa puhtaan koodin
2. Tietää paljon tekniikoita
3. Koodaustehtävät nopeammin
4. Tietää joukon algoritmeja ja suunnittelumalleja
5. Voi heijastaa minkä tahansa koodin puhtaalla koodilla
6. Ei tuhlaa aikaa ei-ohjelmointitehtäviin
7. 100 % suosikkiteknologiasi mestari

Näin HR näkee ihanteelliset ehdokkaat ja vastaavasti myös avoimet työpaikat näyttävät tältä.

Mutta kokemukseni sanoo, että tämä ei ole kovin totta.

Ensinnäkin kaksi tärkeää vastuuvapauslauseketta:
1) Kokemukseni ovat tuotetiimit, ts. yritykset, joilla on oma tuote, ei ulkoistaminen; ulkoistamisessa kaikki voi olla hyvin erilaista;
2) jos olet juniori, niin kaikki neuvot eivät päde, ja jos olisin sinä, keskittyisin ohjelmointiin toistaiseksi.

Hyvä kehittäjä: todellisuus

1: Keskimääräistä parempi koodi

Hyvä kehittäjä osaa luoda hienoa arkkitehtuuria, kirjoittaa siistiä koodia eikä tee liikaa virheitä; Yleensä hän pärjää keskimääräistä paremmin, mutta hän ei ole asiantuntijoiden kärjessä. Useimmat tuntemistani tyylikkäimmistä kehittäjistä eivät ole niin mahtavia koodaajia: he ovat loistavia siinä, mitä tekevät, mutta he eivät voi tehdä mitään poikkeuksellista.

2: Ratkaisee ongelmia sen sijaan, että luo niitä

Kuvitellaan, että meidän on integroitava ulkopuolinen palvelu projektiin. Saamme tekniset tiedot, katsomme dokumentaatiota, näemme, että siellä on jotain vanhentunutta, ymmärrämme, että meidän on siirrettävä lisäparametreja, tehtävä joitain säätöjä, yritettävä toteuttaa kaikki jotenkin ja saada jokin vino menetelmä toimimaan oikein, lopulta parin jälkeen päivien aikana ymmärrämme, että emme voi jatkaa näin. Kehittäjän vakiokäyttäytyminen tässä tilanteessa on palata liiketoimintaan ja sanoa: "Tein tämän ja tuon, tämä ei toimi niin ja tuo ei toimi ollenkaan, joten ota itse selvää. ” Yrityksellä on ongelma: sinun täytyy syventyä tapahtumiin, kommunikoida jonkun kanssa ja yrittää ratkaista se jotenkin. Rikkinäinen puhelin alkaa: "Sinä kerrot hänelle, minä lähetän hänelle tekstiviestin, katso mitä he vastasivat."

Hyvä kehittäjä, joutuessaan tällaiseen tilanteeseen, löytää itse kontakteja, ottaa häneen yhteyttä puhelimitse, keskustelee ongelmasta, ja jos mikään ei auta, hän kerää oikeat ihmiset, selittää kaiken ja tarjoaa vaihtoehtoja (todennäköisimmin on olemassa toinen ulkoinen palvelu paremmalla tuella). Tällainen kehittäjä näkee liiketoimintaongelman ja ratkaisee sen. Hänen tehtävänsä on suljettu, kun hän ratkaisee liiketoimintaongelman, eikä silloin, kun hän törmää johonkin.

3: Yrittää käyttää mahdollisimman vähän vaivaa maksimaalisen tuloksen saavuttamiseksi, vaikka se tarkoittaisi kainalosauvojen kirjoittamista

Tuoteyritysten ohjelmistokehitys on lähes aina suurin kuluerä: kehittäjät ovat kalliita. Ja hyvä kehittäjä ymmärtää, että yritys haluaa saada maksimaalisen rahasumman käyttämällä minimiin. Auttaakseen häntä hyvä kehittäjä haluaa käyttää mahdollisimman vähän kallista aikaansa saadakseen työnantajalle suurimman voiton.

Tässä on kaksi ääripäätä. Yksi on, että voit yleensä ratkaista kaikki ongelmat kainalosauvalla, vaivautumatta arkkitehtuuriin, ilman refaktorointia jne. Tiedämme kaikki, miten tämä yleensä päättyy: mikään ei toimi, kirjoitamme projektin uudelleen alusta. Toinen tapaus on, kun henkilö yrittää keksiä ihanteellisen arkkitehtuurin jokaiselle painikkeelle, viettäen tunnin tehtävään ja neljä tuntia uudelleenjärjestelyyn. Tällaisen työn tulos näyttää hyvältä, mutta ongelmana on, että liiketoiminnalla painikkeen täyttäminen vie kymmenen tuntia, sekä ensimmäisessä että toisessa tapauksessa, yksinkertaisesti eri syistä.

Hyvä kehittäjä osaa tasapainottaa näiden ääripäiden välillä. Hän ymmärtää kontekstin ja tekee optimaalisen päätöksen: tässä ongelmassa leikkaan kainalosauvan, koska tämä on koodi, jota kosketetaan kerran puolessa vuodessa. Mutta tässä vaivaudun ja teen kaiken mahdollisimman oikein, koska sata uutta ominaisuutta, joita ei ole vielä kehitetty, riippuu siitä, mitä onnistun.

4. Hänellä on oma liikkeenjohtojärjestelmä ja hän pystyy työskentelemään siinä missä tahansa monimutkaisissa projekteissa.

Työskentely periaatteiden mukaan Saada asiat tehtyä – Kun kirjoitat kaikki tehtäväsi johonkin tekstijärjestelmään, älä unohda sopimuksia, työnnä kaikkia, tule kaikkialle ajoissa, tiedä mikä on tärkeää ja mikä ei ole tällä hetkellä tärkeää, et koskaan menetä tehtäviä. Tällaisten ihmisten yleinen ominaisuus on, että kun olet samaa mieltä jostakin heidän kanssaan, et koskaan pelkää, että he unohtavat; ja tiedät myös, että he kirjoittavat kaiken ylös eivätkä kysy sitten tuhansia kysymyksiä, joihin on jo keskusteltu.

5. Kyselee ja selventää mahdollisia ehtoja ja esittelyjä

Tässäkin on kaksi ääripäätä. Toisaalta voit olla skeptinen kaiken johdantotiedon suhteen. Ihmiset ennen sinua keksivät joitain ratkaisuja, mutta luulet, että voit tehdä paremmin ja alkaa keskustella uudelleen kaikesta, mikä oli ennen sinua: suunnittelu, liiketoimintaratkaisut, arkkitehtuuri jne. Tämä tuhlaa paljon aikaa sekä kehittäjälle että hänen ympärillään oleville, ja sillä on negatiivinen vaikutus luottamukseen yrityksessä: muut ihmiset eivät halua tehdä päätöksiä, koska he tietävät, että kaveri tulee takaisin ja rikkoo kaiken. Toinen ääripää on, kun kehittäjä näkee johdannon, tekniset spesifikaatiot ja liiketoiveet kiveen hakattuna, ja vasta ratkaisemattoman ongelman edessä hän alkaa miettiä, tekeekö hän sitä mitä tekee. Hyvä kehittäjä löytää täältä myös keskitien: hän yrittää ymmärtää ennen tai ilman häntä tehdyt päätökset, ennen kuin tehtävä lähtee kehittämiseen. Mitä yritys haluaa? Ratkaisemmeko hänen ongelmansa? Tuotesuunnittelija keksi ratkaisun, mutta ymmärränkö miksi ratkaisu toimii? Miksi tiimin johtaja keksi juuri tämän arkkitehtuurin? Jos jokin on epäselvää, sinun on mentävä kysymään. Tämän selvennyksen aikana hyvä kehittäjä saattaa nähdä vaihtoehtoisen ratkaisun, joka ei yksinkertaisesti ole tullut kenellekään aiemmin mieleen.

6. Parantaa prosesseja ja ihmisiä ympärilläsi

Ympärillämme on meneillään monia prosesseja - päivittäisiä kokouksia, tapaamisia, scrumteja, teknisiä arvioita, koodiarvioita jne. Hyvä kehittäjä nousee seisomaan ja sanoo: katso, kokoonnumme yhteen ja keskustelemme samasta asiasta joka viikko, en ymmärrä miksi, voimme yhtä hyvin viettää tämän tunnin Contrassa. Tai: kolmantena peräkkäisenä tehtävänä en pääse koodiin, mikään ei ole selvää, arkkitehtuuri on täynnä reikiä; Ehkä arvostelukoodimme on ontuva ja meidän on heijastettava uudelleen, refaktoroidaan tapaaminen kahden viikon välein. Tai kooditarkistuksen aikana henkilö näkee, että joku hänen kollegoistaan ​​ei käytä tiettyä työkalua tarpeeksi tehokkaasti, mikä tarkoittaa, että hänen on tultava esiin myöhemmin ja annettava neuvoja. Hyvällä kehittäjällä on tämä vaisto, hän tekee sellaisia ​​asioita automaattisesti.

7. Erinomainen johtamaan muita, vaikka ei olisi esimies

Tämä taito sopii hyvin yhteen "ongelmien ratkaisemisen sijaan luomisen" -teeman kanssa. Usein hakemamme avoimen viran tekstissä ei kirjoiteta mitään johtamisesta, mutta silloin, kun kohtaat itsestäsi riippumattomia ongelmia, joudut silti johtamaan muita tavalla tai toisella, saavuttamaan heiltä jotain, jos unohdin - työnnä, varmista, että he ymmärsivät kaiken. Hyvä kehittäjä tietää, ketä kiinnostaa, voi soittaa näiden ihmisten kanssa tapaamiseen, kirjoittaa sopimukset muistiin, lähettää ne löysälle, muistuttaa oikeana päivänä, varmistaa, että kaikki on valmis, vaikka hän ei itse olisikaan suoraan vastuussa tämä tehtävä, mutta hänen tulos riippuu sen toteuttamisesta.

8. Ei pidä tietoaan dogmina, on jatkuvasti avoin kritiikille

Jokainen voi muistaa kollegan edellisestä työpaikasta, joka ei pysty tinkimään teknologiastaan ​​ja huutaa, että kaikki palavat helvettiin väärien mutaatioiden takia. Hyvä kehittäjä, jos hän työskentelee 5, 10, 20 vuotta alalla, ymmärtää, että puolet hänen tiedosta on mätä, ja loput puolet hän ei tiedä kymmenen kertaa enemmän kuin tietää. Ja aina kun joku on eri mieltä hänen kanssaan ja tarjoaa vaihtoehdon, se ei ole hyökkäys hänen egoaan vastaan, vaan mahdollisuus oppia jotain. Tämä antaa hänelle mahdollisuuden kasvaa paljon nopeammin kuin hänen ympärillään olevat.

Verrataan ideaani ideaalisesta kehittäjästä yleisesti hyväksyttyyn:

Tämä kuva näyttää kuinka monet yllä kuvatuista kohdista liittyvät koodiin ja kuinka monet eivät. Tuoteyrityksen kehittäminen on vain kolmasosa ohjelmointia, lopulla 2/3 on vain vähän tekemistä koodin kanssa. Ja vaikka kirjoitamme paljon koodia, tehokkuutemme riippuu suuresti näistä "epäolennaisista" kahdesta kolmasosasta.

Erikoistuminen, yleisyys ja 80-20 sääntö

Kun henkilö oppii ratkaisemaan joitain kapeita ongelmia, opiskelee pitkään ja ahkerasti, mutta sitten ratkaisee ne helposti ja yksinkertaisesti, mutta hänellä ei ole asiantuntemusta vastaavilta aloilta, tämä on erikoistumista. Yleisyys on sitä, että puolet koulutusajasta panostetaan omaan osaamisalueeseen ja puolet siihen liittyviin alueisiin. Vastaavasti ensimmäisessä tapauksessa teen yhden asian täydellisesti ja loput huonosti, ja toisessa teen kaiken enemmän tai vähemmän hyvin.

Sääntö 80-20 kertoo meille, että 80 % tuloksesta tulee 20 %:lla ponnistelusta. 80 % liikevaihdosta tulee 20 %:lta asiakkaista, 80 % voitosta 20 %:lta työntekijöistä ja niin edelleen. Opetuksessa tämä tarkoittaa, että 80 % tiedosta saamme ensimmäisen 20 %:n aikana.

Siinä on ajatus: koodaajien tulee vain koodata, suunnittelijoiden vain suunnitella, analyytikot analysoida ja johtajien vain hallita. Mielestäni tämä idea on myrkyllinen eikä toimi kovin hyvin. Tässä ei ole kyse siitä, että kaikkien on oltava universaaleja sotilaita, tässä on kyse resurssien säästämisestä. Jos kehittäjä ymmärtää vähintään vähän johtamista, suunnittelua ja analytiikkaa, hän pystyy ratkaisemaan monia ongelmia ilman muita ihmisiä. Jos sinun täytyy tehdä jonkinlainen ominaisuus ja sitten tarkistaa, kuinka käyttäjät työskentelevät sen kanssa tietyssä kontekstissa, mikä vaatii kaksi SQL-kyselyä, on hienoa, että pystyt olemaan häiritsemättä analyytikkoa tällä. Jos sinun on upotettava painike analogisesti olemassa olevien kanssa ja ymmärrät yleiset periaatteet, voit tehdä sen ilman suunnittelijaa, ja yritys kiittää sinua siitä.

Yhteensä: voit viettää 100 % ajasta taidon opiskeluun äärirajoille asti tai voit viettää saman ajan viidellä alueella ja saavuttaa 80 % kullakin alueella. Noudattamalla tätä naiivia matematiikkaa voimme saada neljä kertaa enemmän taitoja samassa ajassa. Tämä on liioittelua, mutta se havainnollistaa ajatusta.

Aiheeseen liittyviä taitoja ei voi kouluttaa 80 %, vaan 30-50 %. Vietettyäsi 10-20 tuntia parannat huomattavasti asiaan liittyvillä alueilla, ymmärrät paljon niissä tapahtuvia prosesseja ja tulet paljon itsenäisempään.

Nykypäivän IT-ekosysteemissä on parempi omistaa mahdollisimman paljon taitoja, eikä olla asiantuntija missään. Koska ensinnäkin kaikki nämä taidot haalistuvat nopeasti, varsinkin ohjelmoinnin suhteen, ja toiseksi, koska 99% ajasta käytämme paitsi perustaitoja, mutta ei todellakaan kaikkein kehittyneimpiä taitoja, ja tämä riittää jopa koodauksessa, jopa siistejä yrityksiä.

Ja lopuksi koulutus on investointi, ja hajautus on tärkeää investoinneissa.

Mitä opettaa

Mitä sitten opettaa ja miten? Tyypillinen kehittäjä vahvassa yrityksessä käyttää säännöllisesti:

• viestintä
• itseorganisaatio
• suunnittelu
• suunnittelu (yleensä koodi)
• ja joskus johtamista, johtamista, data-analyysiä, kirjoittamista, rekrytointia, mentorointia ja monia muita taitoja

Ja käytännössä mikään näistä taidoista ei leikkaa millään tavalla itse koodin kanssa. Ne on opetettava ja päivitettävä erikseen, ja jos tätä ei tehdä, ne jäävät erittäin alhaiselle tasolle, mikä ei salli niiden tehokasta käyttöä.

Millä aloilla kannattaa kehittää?

1. Pehmeät taidot ovat kaikkea, mikä ei koske editorin painikkeiden painamista. Näin kirjoitamme viestejä, miten toimimme kokouksissa, miten kommunikoimme kollegoiden kanssa. Nämä kaikki näyttävät ilmeisiltä asioilta, mutta usein ne aliarvioidaan.

2. Itseorganisaatiojärjestelmä. Minulle henkilökohtaisesti tästä on tullut erittäin tärkeä aihe viimeisen vuoden aikana. Kaikkien tuntemieni upeiden IT-työntekijöiden joukossa tämä on yksi kehittyneimmistä taidoista: he ovat erittäin organisoituja, tekevät aina mitä sanovat, he tietävät tarkalleen, mitä he tekevät huomenna, viikon tai kuukauden kuluttua. On välttämätöntä rakentaa itsesi ympärille järjestelmä, johon kaikki asiat ja kaikki kysymykset kirjataan; tämä helpottaa suuresti itse työtä ja auttaa suuresti vuorovaikutuksessa muiden ihmisten kanssa. Koen, että kehitys tähän suuntaan on viimeisen vuoden aikana parantanut minua paljon enemmän kuin teknisten taitojen parantaminen, aloin tehdä huomattavasti enemmän työtä aikayksikköä kohden.

3. Ennakoiva, ennakkoluuloton ja suunnitteleva. Aiheet ovat hyvin yleisiä ja elintärkeitä, eivät pelkästään IT:lle, ja jokaisen tulisi kehittää niitä. Ennakoiva toiminta tarkoittaa sitä, ettei odota signaalia toimiakseen. Olet tapahtumien lähde, et reaktioita niihin. Avarakatseisuus on kykyä käsitellä uutta tietoa objektiivisesti, arvioida tilannetta erillään omasta maailmankuvasta ja vanhoista tavoista. Suunnittelu on selkeä näkemys siitä, kuinka tämän päivän tehtävä ratkaisee viikon, kuukauden, vuoden ongelman. Jos näet tulevaisuuden tietyn tehtävän ulkopuolella, on paljon helpompaa tehdä mitä tarvitset, eikä pelätä ajan kuluttua huomata, että se meni hukkaan. Tämä taito on erityisen tärkeä uran kannalta: voit saavuttaa tuloksia menestyksekkäästi vuosia, mutta väärässä paikassa ja lopulta menettää kaikki kertyneet matkatavarat, kun käy selväksi, että olet menossa väärään suuntaan.

4. Kaikki asiaan liittyvät alat perustasolle. Jokaisella on omat erityisalueet, mutta on tärkeää ymmärtää, että kun käytät 10-20 tuntia aikaa jonkin "vieraan" taidon tasoittamiseen, voit löytää monia uusia mahdollisuuksia ja kosketuspisteitä päivittäisessä työssäsi, ja nämä tunnit saattavat riittää uran loppuun asti.

Mitä lukea

Itseorganisaatiosta on paljon kirjoja; se on kokonainen toimiala, jossa jotkut omituiset kaverit kirjoittavat neuvoja ja keräävät koulutusta. Samalla on epäselvää, mitä he itse ovat saavuttaneet elämässään. Siksi on tärkeää laittaa suodattimia tekijöihin, katsoa keitä he ovat ja mitä heillä on takanaan. Kehittymiseeni ja näkemykseeni vaikuttivat eniten neljä kirjaa, jotka kaikki liittyivät tavalla tai toisella yllä kuvattujen taitojen kehittämiseen.

1. Dale Carnegie "Kuinka voittaa ystäviä ja vaikuttaa ihmisiin". Kulttikirja pehmeistä taidoista, jos et tiedä mistä aloittaa, sen valitseminen on kaikille osapuolille hyödyllinen vaihtoehto. Se on rakennettu esimerkkien varaan, sitä on helppo lukea, luetun ymmärtäminen ei vaadi paljon vaivaa, ja hankittuja taitoja voidaan soveltaa välittömästi. Kaiken kaikkiaan kirja kattaa aiheen ihmisten kanssa kommunikoinnista.

2. Stephen R. Covey "Erittäin tehokkaiden ihmisten 7 tapaa". Sekoitus erilaisia ​​taitoja, proaktiivisuudesta pehmeisiin taitoihin, painopisteenä synergia, kun haluat tehdä pienestä tiimistä valtavan voiman. Se on myös helppo lukea.

3. Ray Dalio "Periaatteet". Paljastaa avarakatseisuuden ja proaktiivisuuden teemoja kirjailijan rakentaman yrityksen historian pohjalta, jota hän johti 40 vuotta. Monet kovalla työllä saavutetut esimerkit osoittavat, kuinka ennakkoluuloinen ja riippuvainen ihminen voi olla ja miten siitä pääsee eroon.

4. David Allen, "Getting Things Done". Pakollinen lukeminen itseorganisaation oppimiseen. Se ei ole niin helppolukuinen, mutta se tarjoaa kattavan työkaluvalikoiman elämän ja asioiden järjestämiseen, tarkastelee kaikkia näkökohtia yksityiskohtaisesti ja auttaa sinua päättämään, mitä tarkalleen tarvitset. Hänen avullaan rakensin oman järjestelmän, jonka avulla voin aina tehdä tärkeimmät asiat unohtamatta muuta.

Sinun täytyy ymmärtää, että pelkkä lukeminen ei riitä. Voit niellä vähintään kirjan viikossa, mutta vaikutus kestää useita päiviä, ja sitten kaikki palaa paikoilleen. Kirjoja tulee käyttää neuvojen lähteenä, joka testataan välittömästi käytännössä. Jos et tee tätä, he vain laajentavat näköalojasi.

Lähde: will.com