Hvorfor bare å oppgradere kodingen din vil ikke gjøre deg til en bedre utvikler

Techlead Skyeng Kirill Rogovoy (flashhhh) holder en presentasjon på konferanser der han snakker om ferdighetene som enhver god utvikler bør utvikle for å bli best. Jeg ba ham dele denne historien med Habra-lesere, jeg gir ordet til Kirill.

Myten om en god utvikler er at han:

1. Skriver ren kode
2. Kan mange teknologier
3. Kode oppgaver raskere
4. Kjenner til en haug med algoritmer og designmønstre
5. Kan refaktorisere hvilken som helst kode ved å bruke Clean Code
6. Kaster ikke bort tid på ikke-programmeringsoppgaver
7. 100 % mester i favorittteknologien din

Slik ser HR ideelle kandidater, og ledige stillinger ser derfor også slik ut.

Men min erfaring sier at dette ikke er veldig sant.

Først to viktige ansvarsfraskrivelser:
1) min erfaring er produktteam, dvs. selskaper med eget produkt, ikke outsourcing; i outsourcing kan alt være veldig annerledes;
2) hvis du er junior, vil ikke alle råd være gjeldende, og hvis jeg var deg, ville jeg konsentrert meg om programmering foreløpig.

God utvikler: virkelighet

1: Bedre kode enn gjennomsnittet

En god utvikler vet hvordan man lager kul arkitektur, skriver kul kode og ikke lager for mange feil; Generelt gjør han det bedre enn gjennomsnittet, men han er ikke på topp 1% av spesialistene. De fleste av de kuleste utviklerne jeg kjenner er ikke så gode kodere: de er gode på det de gjør, men de kan ikke gjøre noe ekstraordinært.

2: Løser problemer i stedet for å skape dem

La oss tenke oss at vi må integrere en ekstern tjeneste i prosjektet. Vi mottar de tekniske spesifikasjonene, ser på dokumentasjonen, ser at noe er utdatert der, forstår at vi må sende flere parametere, gjøre noen justeringer, prøve å implementere alt på en eller annen måte og få en skjev metode til å fungere riktig, til slutt, etter et par av dager forstår vi at vi ikke kan fortsette slik. Standardoppførselen til en utvikler i denne situasjonen er å gå tilbake til virksomheten og si: «Jeg gjorde det og det, denne fungerer ikke slik, og den fungerer ikke i det hele tatt, så finn ut av det selv. ” En bedrift har et problem: du må fordype deg i det som skjedde, kommunisere med noen og prøve å løse det på en eller annen måte. Den ødelagte telefonen starter: «du forteller ham, jeg skal sende en melding til henne, se hva de svarte.»

En god utvikler, som står overfor en slik situasjon, vil finne kontakter selv, kontakte ham på telefon, diskutere problemet, og hvis ingenting løser seg, vil han samle de rette menneskene, forklare alt og tilby alternativer (mest sannsynlig er det en annen ekstern tjeneste med bedre støtte). En slik utvikler ser et forretningsproblem og løser det. Oppgaven hans er stengt når han løser et forretningsproblem, og ikke når han støter på noe.

3: Prøver å bruke minimal innsats for å få maksimale resultater, selv om det betyr skrivekrykker

Programvareutvikling i produktselskaper er nesten alltid den største utgiftsposten: utviklere er dyre. Og en god utvikler forstår at en bedrift ønsker å få maksimalt med penger ved å bruke minimum. For å hjelpe ham ønsker en god utvikler å bruke minst mulig av sin dyre tid for å oppnå maksimal fortjeneste for arbeidsgiveren.

Det er to ytterpunkter her. Den ene er at du generelt kan løse alle problemer med en krykke, uten å bry deg med arkitektur, uten refactoring osv. Vi vet alle hvordan dette vanligvis ender: ingenting fungerer, vi omskriver prosjektet fra bunnen av. En annen er når en person prøver å komme opp med en ideell arkitektur for hver knapp, bruker en time på oppgaven og fire på refaktorisering. Resultatet av et slikt arbeid ser bra ut, men problemet er at det på forretningssiden tar ti timer å fullføre en knapp, både i det første og det andre tilfellet, rett og slett av forskjellige årsaker.

En god utvikler vet hvordan man balanserer mellom disse ytterpunktene. Han forstår konteksten og tar den optimale avgjørelsen: i dette problemet vil jeg kutte en krykke, fordi dette er kode som berøres en gang hver sjette måned. Men i denne vil jeg bry meg og gjøre alt så riktig som mulig, fordi hundre nye funksjoner som ennå ikke er utviklet vil avhenge av hva jeg lykkes med.

4. Har sitt eget forretningsstyringssystem og er i stand til å jobbe med prosjekter av enhver kompleksitet i det.

Arbeider etter prinsipper Få ting gjort – når du skriver ned alle oppgavene dine i et slags tekstsystem, ikke glem noen avtaler, presser alle, møter opp overalt i tide, vet hva som er viktig og ikke viktig for øyeblikket, mister du aldri oppgaver. Det generelle kjennetegnet ved slike mennesker er at når du er enig om noe med dem, er du aldri bekymret for at de vil glemme; og du vet også at de skriver ned alt og vil ikke stille tusen spørsmål, svarene på disse er allerede diskutert.

5. Spørsmål og klargjør eventuelle forhold og innledninger

Også her er det to ytterpunkter. På den ene siden kan du være skeptisk til all introduksjonsinformasjon. Folk før deg kom opp med noen løsninger, men du tror at du kan gjøre det bedre og begynne å diskutere alt som kom før deg på nytt: design, forretningsløsninger, arkitektur osv. Dette kaster bort mye tid for både utvikleren og de rundt ham, og har en negativ innvirkning på tilliten i selskapet: andre mennesker vil ikke ta avgjørelser fordi de vet at den fyren vil komme tilbake og bryte alt. Den andre ytterligheten er når en utvikler oppfatter eventuelle innledende, tekniske spesifikasjoner og forretningsønsker som noe hugget i stein, og først når han står overfor et uløselig problem, begynner han å tenke på om han i det hele tatt gjør det han gjør. En god utvikler finner også en mellomting her: Han prøver å forstå beslutningene som er tatt før eller uten ham, før oppgaven går til utvikling. Hva ønsker næringslivet? Løser vi problemene hans? Produktdesigneren kom opp med en løsning, men forstår jeg hvorfor løsningen vil fungere? Hvorfor kom teamlederen opp med akkurat denne arkitekturen? Hvis noe ikke er klart, må du spørre. I prosessen med denne avklaringen kan en god utvikler se en alternativ løsning som rett og slett ikke hadde falt noen før.

6. Forbedrer prosesser og mennesker rundt deg

Det pågår mange prosesser rundt oss – daglige møter, meetups, scrums, tech reviews, code review, etc. En god utvikler vil reise seg og si: se, vi samles og diskuterer det samme hver uke, jeg forstår ikke hvorfor, vi kan like gjerne bruke denne timen på Contra. Eller: for den tredje oppgaven på rad kommer jeg ikke inn i koden, ingenting er klart, arkitekturen er full av hull; Kanskje vår anmeldelseskode er dårlig og vi må refaktorere, la oss refaktorisere treffet annenhver uke. Eller under en kodegjennomgang ser en person at en av kollegene hans ikke bruker et bestemt verktøy effektivt nok, noe som betyr at han må komme opp senere og gi noen råd. En god utvikler har dette instinktet; han gjør slike ting automatisk.

7. Utmerket til å administrere andre, selv om ikke en leder

Denne ferdigheten passer godt sammen med temaet "løsning i stedet for å skape problemer." Ofte, i teksten til den ledige stillingen vi søker på, er det ikke skrevet noe om ledelse, men når du står overfor et problem utenfor din kontroll, må du fortsatt styre andre på en eller annen måte, oppnå noe fra dem, hvis du glemte - trykk, sørg for at de forsto alt. En god utvikler vet hvem som er interessert i hva, kan innkalle til et møte med disse personene, skrive ned avtaler, sende dem til slakk, minne dem på rett dag, sørge for at alt er klart, selv om han ikke er personlig direkte ansvarlig for denne oppgaven, men resultatet avhenger av implementeringen.

8. Oppfatter ikke sin kunnskap som dogme, er konstant åpen for kritikk

Alle kan huske en kollega fra en tidligere jobb som ikke klarer å gå på akkord med teknologien sin og skriker at alle vil brenne i helvete for noen feil mutasjoner. En god utvikler, hvis han jobber i 5, 10, 20 år i bransjen, forstår at halvparten av kunnskapen hans er råtten, og i den resterende halvparten vet han ikke ti ganger mer enn han vet. Og hver gang noen er uenig med ham og tilbyr et alternativ, er det ikke et angrep på egoet hans, men en mulighet til å lære noe. Dette gjør at han kan vokse mye raskere enn de rundt ham.

La oss sammenligne ideen min om en ideell utvikler med den generelt aksepterte:

Dette bildet viser hvor mange av punktene beskrevet ovenfor som er relatert til koden, og hvor mange som ikke er det. Utvikling i et produktselskap er kun en tredjedel programmering, de resterende 2/3 har lite med kode å gjøre. Og selv om vi skriver mye kode, avhenger effektiviteten vår i stor grad av disse "irrelevante" to-tredjedelene.

Spesialisering, generalisme og 80-20-regelen

Når en person lærer å løse noen trange problemer, studerer lenge og hardt, men så løser dem enkelt og enkelt, men ikke har kompetanse på relaterte felt, er dette spesialisering. Generalisme er når halvparten av treningstiden investeres i området egen kompetanse, og en annen halvpart i relaterte områder. Følgelig, i det første tilfellet gjør jeg en ting perfekt og resten dårlig, og i det andre gjør jeg alt mer eller mindre bra.

80-20-regelen forteller oss at 80 % av resultatet kommer fra 20 % av innsatsen. 80 % av inntektene kommer fra 20 % av kundene, 80 % av overskuddet kommer fra 20 % av de ansatte, og så videre. I undervisningen betyr dette at 80 % av kunnskapen vi får i løpet av de første 20 % av tidsbruken.

Det er en idé: kodere skal bare kode, designere skal bare designe, analytikere skal analysere, og ledere skal bare administrere. Etter min mening er denne ideen giftig og fungerer ikke særlig bra. Dette handler ikke om at alle skal være universalsoldater, dette handler om å spare ressurser. Hvis en utvikler forstår i det minste litt om ledelse, design og analyse, vil han kunne løse mange problemer uten å involvere andre mennesker. Hvis du trenger å lage en slags funksjon og deretter sjekke hvordan brukere jobber med den i en bestemt kontekst, som vil kreve to SQL-spørringer, så er det flott å ikke kunne distrahere analytikeren med dette. Hvis du trenger å bygge inn en knapp analogt med eksisterende, og du forstår de generelle prinsippene, kan du gjøre det uten å involvere en designer, og selskapet vil takke deg for det.

Totalt: du kan bruke 100 % av tiden din på å studere en ferdighet til det ytterste, eller du kan bruke samme tid på fem områder, og nivåer opp til 80 % på hvert. Etter denne naive matematikken kan vi få fire ganger så mange ferdigheter på samme tid. Dette er en overdrivelse, men det illustrerer ideen.

Relaterte ferdigheter kan trenes ikke med 80%, men med 30-50%. Etter å ha brukt 10-20 timer, vil du merkbart forbedre deg på relaterte områder, få mye forståelse for prosessene som skjer i dem og bli mye mer autonom.

I dagens IT-økosystem er det bedre å ha så mange ferdigheter som mulig og ikke være ekspert på noen av dem. For det første falmer alle disse ferdighetene raskt, spesielt når det kommer til programmering, og for det andre fordi vi i 99% av tiden bruker ikke bare grunnleggende, men absolutt ikke de mest sofistikerte ferdighetene, og dette er nok selv i koding, selv i kule selskaper.

Og til slutt, trening er en investering, og diversifisering er viktig i investeringer.

Hva du skal lære

Så hva skal man lære og hvordan? En typisk utvikler i et sterkt selskap bruker regelmessig:

• kommunikasjon
• selvorganisering
• planlegging
• design (vanligvis kode)
• og noen ganger ledelse, ledelse, dataanalyse, skriving, rekruttering, veiledning og mange andre ferdigheter

Og praktisk talt ingen av disse ferdighetene krysser med selve koden. De må læres og oppgraderes separat, og hvis dette ikke gjøres, vil de forbli på et veldig lavt nivå, noe som ikke tillater at de kan brukes effektivt.

Hvilke områder er verdt å utvikle seg på?

1. Myke ferdigheter er alt som ikke gjelder å trykke på knapper i editoren. Det er slik vi skriver meldinger, hvordan vi oppfører oss i møter, hvordan vi kommuniserer med kollegaer. Alt dette ser ut til å være åpenbare ting, men veldig ofte blir de undervurdert.

2. Selvorganiseringssystem. For meg personlig har dette blitt et superviktig tema det siste året. Blant alle de kule IT-arbeiderne jeg kjenner, er dette en av de mest utviklede ferdighetene: de er superorganiserte, de gjør alltid det de sier, de vet nøyaktig hva de skal gjøre i morgen, om en uke, om en måned. Det er nødvendig å bygge et system rundt deg selv der alle saker og alle spørsmål er registrert; dette letter selve arbeidet i stor grad og bidrar i stor grad til å samhandle med andre mennesker. Jeg føler at det siste året har utvikling i denne retningen forbedret meg mye mer enn å forbedre mine tekniske ferdigheter; jeg begynte å gjøre betydelig mer arbeid per tidsenhet.

3. Proaktiv, åpen og planleggende. Temaene er veldig generelle og vitale, ikke unike for IT, og alle bør utvikle dem. Proaktivitet betyr ikke å vente på et signal om å iverksette tiltak. Du er kilden til hendelser, ikke reaksjoner på dem. Åpenhet er evnen til å behandle all ny informasjon objektivt, å vurdere situasjonen isolert fra ens eget verdensbilde og gamle vaner. Planlegging er en klar visjon om hvordan dagens oppgave løser problemet for uken, måneden, året. Hvis du ser fremtiden utover en spesifikk oppgave, er det mye lettere å gjøre det du trenger, og ikke være redd etter hvert for å innse at det var bortkastet. Denne ferdigheten er spesielt viktig for en karriere: du kan oppnå resultater i årevis, men på feil sted, og til slutt miste all den akkumulerte bagasjen når det blir klart at du beveget deg i feil retning.

4. Alle relaterte områder til grunnnivå. Alle har sine egne spesifikke områder, men det er viktig å forstå at ved å bruke 10-20 timer på å oppgradere noen "fremmede" ferdigheter, kan du oppdage mange nye muligheter og kontaktpunkter i ditt daglige arbeid, og disse timene kan være nok til slutten av karrieren.

Hva du skal lese

Det er veldig mange bøker om selvorganisering; det er en hel bransje der noen rare gutter skriver samlinger med råd og samler på opplæring. Samtidig er det uklart hva de selv har oppnådd i livet. Derfor er det viktig å sette filtre på forfatterne, se på hvem de er og hva de har bak seg. Min utvikling og syn var mest påvirket av fire bøker, alle på en eller annen måte relatert til å forbedre ferdighetene beskrevet ovenfor.

1. Dale Carnegie "Hvordan vinne venner og påvirke mennesker". En kultbok om myke ferdigheter, hvis du ikke vet hvor du skal begynne, er det et vinn-vinn-alternativ å velge det. Den er bygget på eksempler, er lett å lese, krever ikke mye innsats for å forstå det du leser, og de tilegnete ferdighetene kan tas i bruk umiddelbart. Samlet sett dekker boken temaet kommunikasjon med mennesker.

2. Stephen R. Covey «7 vaner til svært effektive mennesker». En blanding av ulike ferdigheter, fra proaktivitet til myke ferdigheter, med vekt på å oppnå synergi når du trenger å gjøre et lite team til en stor kraft. Den er også lett å lese.

3. Ray Dalio "Principles". Avslører temaer om åpenhet og proaktivitet, basert på historien til selskapet forfatteren bygde, som han ledet i 40 år. Mange hardt vunnede eksempler fra livet viser hvor fordomsfull og avhengig en person kan være, og hvordan man kan bli kvitt det.

4. David Allen, "Få ting gjort". Obligatorisk lesing for å lære selvorganisering. Den er ikke så lett å lese, men den gir et omfattende sett med verktøy for å organisere liv og anliggender, undersøker alle aspekter i detalj, og hjelper deg med å bestemme akkurat hva du trenger. Med hennes hjelp bygde jeg mitt eget system som gjør at jeg alltid kan gjøre de viktigste tingene uten å glemme resten.

Du må forstå at det ikke er nok å bare lese. Du kan svelge minst en bok i uken, men effekten vil vare i flere dager, og så vil alt gå tilbake til sin plass. Bøker bør brukes som en kilde til råd som umiddelbart testes i praksis. Hvis du ikke gjør dette, er alt de vil gi en utvidelse av horisonten din.

Kilde: www.habr.com