Varför bara uppgradera din kodning kommer inte att göra dig till en bättre utvecklare

Techlead Skyeng Kirill Rogovoy (flashhhh) håller en presentation på konferenser där han berättar om de färdigheter som varje bra utvecklare bör utveckla för att bli bäst. Jag bad honom dela den här historien med Habras läsare, jag ger ordet till Kirill.

Myten om en bra utvecklare är att han:

1. Skriver ren kod
2. Kan många tekniker
3. Kodningsuppgifter snabbare
4. Kan en massa algoritmer och designmönster
5. Kan refaktorisera vilken kod som helst med Clean Code
6. Slösar inte tid på icke-programmeringsuppgifter
7. 100 % mästare på din favoritteknik

Det är så HR ser på idealiska kandidater, och lediga tjänster ser därför också ut så här.

Men min erfarenhet säger att detta inte är särskilt sant.

Först två viktiga ansvarsfriskrivningar:
1) min erfarenhet är produktteam, d.v.s. företag med sin egen produkt, inte outsourcing; vid outsourcing kan allt vara väldigt annorlunda;
2) om du är junior så kommer inte alla råd att vara tillämpliga, och om jag var du skulle jag koncentrera mig på programmering för tillfället.

Bra utvecklare: verklighet

1: Bättre kod än genomsnittet

En bra utvecklare vet hur man skapar cool arkitektur, skriver cool kod och inte gör för många buggar; I allmänhet gör han det bättre än genomsnittet, men han är inte i topp 1% av specialister. De flesta av de coolaste utvecklarna jag känner är inte så bra kodare: de är bra på vad de gör, men de kan inte göra något superextraordinärt.

2: Löser problem snarare än att skapa dem

Låt oss föreställa oss att vi behöver integrera en extern tjänst i projektet. Vi tar emot de tekniska specifikationerna, tittar på dokumentationen, ser att något är föråldrat där, förstår att vi måste skicka ytterligare parametrar, göra några justeringar, försöka implementera allt på något sätt och få någon sned metod att fungera korrekt, äntligen, efter ett par dagar vi förstår att vi inte kan fortsätta så här. Standardbeteendet för en utvecklare i den här situationen är att återgå till verksamheten och säga: "Jag gjorde det och det, den här fungerar inte på det sättet och den fungerar inte alls, så ta reda på det själv. ” Ett företag har ett problem: du måste fördjupa dig i vad som hände, kommunicera med någon och försöka lösa det på något sätt. Den trasiga telefonen börjar: "säg till honom, jag skickar ett sms till henne, se vad de svarade."

En bra utvecklare, som står inför en sådan situation, kommer själv att hitta kontakter, kontakta honom på telefon, diskutera problemet, och om inget löser sig kommer han att samla rätt personer, förklara allt och erbjuda alternativ (sannolikt finns det en annan) extern service med bättre support). En sådan utvecklare ser ett affärsproblem och löser det. Hans uppgift är stängd när han löser ett affärsproblem, och inte när han stöter på något.

3: Försöker lägga ner minimal ansträngning för att få maximala resultat, även om det innebär att skriva kryckor

Mjukvaruutveckling i produktföretag är nästan alltid den största utgiftsposten: utvecklare är dyra. Och en bra utvecklare förstår att ett företag vill få maximalt med pengar genom att spendera det minsta. För att hjälpa honom vill en bra utvecklare spendera minsta möjliga av sin dyra tid för att få maximal vinst för arbetsgivaren.

Det finns två ytterligheter här. Den ena är att man generellt sett kan lösa alla problem med en krycka, utan att krångla till arkitektur, utan att refaktorera osv. Vi vet alla hur det här brukar sluta: ingenting fungerar, vi skriver om projektet från grunden. En annan är när en person försöker komma på en idealisk arkitektur för varje knapp, spenderar en timme på uppgiften och fyra på att omfaktorisera. Resultatet av ett sådant arbete ser bra ut, men problemet är att det på affärssidan tar tio timmar att slutföra en knapp, i både det första och andra fallet, helt enkelt av olika anledningar.

En bra utvecklare vet hur man balanserar mellan dessa ytterligheter. Han förstår sammanhanget och fattar det optimala beslutet: i det här problemet kommer jag att skära en krycka, eftersom det här är kod som berörs en gång var sjätte månad. Men i den här kommer jag att bry mig och göra allt så korrekt som möjligt, eftersom hundra nya funktioner som ännu inte har utvecklats kommer att bero på vad jag lyckas med.

4. Har ett eget företagsledningssystem och kan arbeta med projekt av vilken komplexitet som helst i det.

Arbetar efter principer Getting Things Done – när du skriver ner alla dina uppgifter i något slags textsystem, glöm inte några avtal, pushar alla, dyker upp överallt i tid, vet vad som är viktigt och vad som inte är viktigt för tillfället, förlorar du aldrig uppgifter. Det allmänna kännetecknet för sådana människor är att när man kommer överens om något med dem, oroar man sig aldrig för att de ska glömma; och du vet också att de skriver ner allt och kommer då inte att ställa tusen frågor, vars svar redan har diskuterats.

5. Ifrågasätter och klargör eventuella villkor och inledningar

Även här finns det två ytterligheter. Å ena sidan kan du vara skeptisk till all inledande information. Folk före dig kom på några lösningar, men du tror att du kan bli bättre och börja omdiskutera allt som kom före dig: design, affärslösningar, arkitektur osv. Detta slösar mycket tid för både utvecklaren och omgivningen, och har en negativ inverkan på förtroendet inom företaget: andra människor vill inte fatta beslut eftersom de vet att den killen kommer tillbaka och bryter allt. Den andra ytterligheten är när en utvecklare uppfattar eventuella inledande, tekniska specifikationer och affärsönskemål som något hugget i sten, och först när han står inför ett olösligt problem börjar han fundera på om han överhuvudtaget gör det han gör. En bra utvecklare hittar också en mellanväg här: han försöker förstå de beslut som fattas före eller utan honom, innan uppgiften går in i utvecklingen. Vad vill näringslivet? Löser vi hans problem? Produktdesignern kom på en lösning, men förstår jag varför lösningen kommer att fungera? Varför kom teamledaren på just den här arkitekturen? Om något inte är klart måste du gå och fråga. I processen med detta förtydligande kan en bra utvecklare se en alternativ lösning som helt enkelt inte hade hänt någon tidigare.

6. Förbättrar processer och människor omkring dig

Det pågår många processer runt omkring oss - dagliga möten, meetups, scrums, tekniska recensioner, kodrecensioner, etc. En bra utvecklare kommer att stå upp och säga: titta, vi träffas och diskuterar samma sak varje vecka, jag förstår inte varför, vi kan lika gärna spendera den här timmen på Contra. Eller: för den tredje uppgiften i rad kan jag inte komma in i koden, ingenting är klart, arkitekturen är full av hål; Kanske är vår recensionskod halt och vi måste refaktorera, låt oss refaktorera mötet varannan vecka. Eller under en kodgranskning ser en person att en av hans kollegor inte använder ett visst verktyg tillräckligt effektivt, vilket innebär att han måste komma upp senare och ge några råd. En bra utvecklare har denna instinkt, han gör sådana saker automatiskt.

7. Utmärkt på att hantera andra, även om inte en chef

Denna färdighet stämmer väl överens med temat "att lösa snarare än att skapa problem." Ofta, i texten till den lediga tjänst som vi söker, skrivs ingenting om ledning, men då, när du ställs inför ett problem utanför din kontroll, måste du ändå hantera andra på ett eller annat sätt, uppnå något av dem, om du glömde - tryck, se till att de förstod allt. En bra utvecklare vet vem som är intresserad av vad, kan kalla till möte med dessa personer, skriva ner avtal, skicka dem till slack, påminna dem på rätt dag, se till att allt är klart, även om han inte är personligt direkt ansvarig för denna uppgift, men hans resultat beror på dess genomförande.

8. Uppfattar inte sin kunskap som dogm, är ständigt öppen för kritik

Alla kan minnas en kollega från ett tidigare jobb som inte kan kompromissa med sin teknik och skriker att alla kommer att brinna i helvetet för några felaktiga mutationer. En bra utvecklare, om han arbetar i 5, 10, 20 år i branschen, förstår att hälften av hans kunskap är ruttet, och i den återstående hälften vet han inte tio gånger mer än han vet. Och varje gång någon inte håller med honom och erbjuder ett alternativ är det inte en attack på hans ego, utan en möjlighet att lära sig något. Detta gör att han kan växa mycket snabbare än de runt omkring honom.

Låt oss jämföra min idé om en idealisk utvecklare med den allmänt accepterade:

Den här bilden visar hur många av punkterna som beskrivs ovan som är relaterade till koden och hur många som inte är det. Utveckling i ett produktbolag är bara en tredjedel programmering, resterande 2/3 har lite med kod att göra. Och även om vi skriver mycket kod beror vår effektivitet mycket på dessa "irrelevanta" två tredjedelar.

Specialisering, generalism och 80-20-regeln

När en person lär sig att lösa vissa smala problem, studerar länge och hårt, men sedan löser dem enkelt och enkelt, men inte har expertis inom närliggande områden, är detta specialisering. Generalism är när hälften av utbildningstiden satsas på den egna kompetensen och en annan hälften på närliggande områden. Följaktligen, i det första fallet gör jag en sak perfekt och resten dåligt, och i det andra gör jag allt mer eller mindre bra.

80-20-regeln säger att 80 % av resultatet kommer från 20 % av ansträngningen. 80 % av intäkterna kommer från 20 % av kunderna, 80 % av vinsten kommer från 20 % av de anställda, och så vidare. I undervisningen innebär det att 80 % av kunskapen vi får under de första 20 % av tiden.

Det finns en idé: kodare ska bara koda, designers ska bara designa, analytiker ska analysera och chefer ska bara hantera. Enligt min åsikt är denna idé giftig och fungerar inte särskilt bra. Det handlar inte om att alla ska vara universalsoldater, det handlar om att spara resurser. Om en utvecklare förstår åtminstone lite om management, design och analys kommer han att kunna lösa många problem utan att involvera andra människor. Om du behöver göra någon form av funktion och sedan kontrollera hur användare arbetar med den i ett visst sammanhang, vilket kommer att kräva två SQL-frågor, så är det bra att inte kunna distrahera analytikern med detta. Om du behöver bädda in en knapp analogt med befintliga, och du förstår de allmänna principerna, kan du göra det utan att involvera en designer, och företaget kommer att tacka dig för det.

Totalt: du kan spendera 100 % av din tid på att studera en färdighet till det yttersta, eller så kan du spendera samma tid på fem områden, med upp till 80 % i varje. Efter denna naiva matematik kan vi få fyra gånger så många färdigheter på samma tid. Detta är en överdrift, men det illustrerar idén.

Relaterade färdigheter kan tränas inte med 80%, utan med 30-50%. Efter att ha spenderat 10-20 timmar kommer du att märkbart förbättra dig inom relaterade områden, få mycket förståelse för de processer som sker i dem och bli mycket mer autonom.

I dagens IT-ekosystem är det bättre att ha så många kompetenser som möjligt och inte vara expert på någon av dem. För för det första bleknar alla dessa färdigheter snabbt, särskilt när det kommer till programmering, och för det andra för att 99% av tiden använder vi inte bara grundläggande, utan absolut inte de mest sofistikerade färdigheterna, och det räcker även i kodning, även i coola företag.

Och slutligen, utbildning är en investering, och diversifiering är viktigt i investeringar.

Vad man ska lära ut

Så vad ska man lära ut och hur? En typisk utvecklare i ett starkt företag använder regelbundet:

• kommunikation
• självorganisering
• planering
• design (vanligtvis kod)
• och ibland ledning, ledarskap, dataanalys, skrivande, rekrytering, mentorskap och många andra färdigheter

Och praktiskt taget ingen av dessa färdigheter korsar själva koden. De behöver läras ut och uppgraderas separat, och om detta inte görs kommer de att förbli på en mycket låg nivå, vilket inte gör att de kan användas effektivt.

Vilka områden är värda att utvecklas inom?

1. Soft skills är allt som inte handlar om att trycka på knappar i editorn. Så här skriver vi meddelanden, hur vi beter oss i möten, hur vi kommunicerar med kollegor. Allt detta verkar vara självklara saker, men väldigt ofta underskattas de.

2. Självorganiseringssystem. För mig personligen har detta blivit ett superviktigt ämne under det senaste året. Bland alla coola IT-arbetare jag känner är detta en av de mest utvecklade färdigheterna: de är superorganiserade, de gör alltid som de säger, de vet exakt vad de kommer att göra i morgon, om en vecka, om en månad. Det är nödvändigt att bygga ett system runt sig själv där alla frågor och alla frågor registreras, detta underlättar avsevärt själva arbetet och hjälper till att interagera med andra människor. Jag känner att utvecklingen i denna riktning under det senaste året har förbättrat mig mycket mer än att förbättra tekniska färdigheter, jag började göra betydligt mer arbete per tidsenhet.

3. Proaktiv, öppen och planerande. Ämnena är mycket generella och viktiga, inte unika för IT, och alla borde utveckla dem. Proaktivitet innebär att inte vänta på en signal för att vidta åtgärder. Du är källan till händelser, inte reaktioner på dem. Öppenhet är förmågan att behandla all ny information objektivt, att utvärdera situationen isolerad från sin egen världsbild och gamla vanor. Planering är en tydlig vision av hur dagens uppgift löser problemet för veckan, månaden, året. Om du ser framtiden bortom en specifik uppgift är det mycket lättare att göra det du behöver, och inte vara rädd efter tiden att inse att det var bortkastat. Denna färdighet är särskilt viktig för en karriär: du kan framgångsrikt uppnå resultat i flera år, men på fel plats, och så småningom förlora allt ackumulerat bagage när det står klart att du rörde dig i fel riktning.

4. Alla relaterade områden till grundnivån. Alla har sina egna specifika områden, men det är viktigt att förstå att genom att lägga 10-20 timmar på att utveckla någon "främmande" kompetens kan du upptäcka många nya möjligheter och kontaktpunkter i ditt dagliga arbete, och dessa timmar kan räcka till slutet av karriären.

Vad ska man läsa

Det finns väldigt många böcker om självorganisering; det är en hel bransch där några konstiga killar skriver råd och samlar på utbildningar. Samtidigt är det oklart vad de själva har åstadkommit i livet. Därför är det viktigt att sätta filter på författarna, titta på vilka de är och vad de har bakom sig. Min utveckling och synsätt påverkades mest av fyra böcker, alla på ett eller annat sätt relaterade till att förbättra de färdigheter som beskrivs ovan.

1. Dale Carnegie "Hur man vinner vänner och påverkar människor". En kultbok om mjuka färdigheter, om du inte vet var du ska börja är det ett vinn-vinn-alternativ att välja det. Den bygger på exempel, är lätt att läsa, kräver inte mycket ansträngning för att förstå det du läser, och de förvärvade färdigheterna kan tillämpas omedelbart. Sammantaget tar boken upp ämnet att kommunicera med människor.

2. Stephen R. Covey "7 vanor hos mycket effektiva människor". En blandning av olika färdigheter, från proaktivitet till mjuka färdigheter, med tonvikt på att uppnå synergi när du behöver förvandla ett litet team till en enorm kraft. Det är också lätt att läsa.

3. Ray Dalio "Principer". Avslöjar teman om öppenhet och proaktivitet, baserat på historien om företaget som författaren byggde, som han förvaltade i 40 år. Många svårvunna exempel från livet visar hur fördomsfull och beroende en person kan vara, och hur man blir av med det.

4. David Allen, "Få saker gjorda". Obligatorisk läsning för att lära sig självorganisering. Det är inte så lätt att läsa, men det ger en omfattande uppsättning verktyg för att organisera livet och angelägenheterna, undersöker alla aspekter i detalj och hjälper dig att bestämma exakt vad du behöver. Med hennes hjälp byggde jag upp ett eget system som gör att jag alltid kan göra det viktigaste utan att glömma resten.

Du måste förstå att det inte räcker att bara läsa. Du kan svälja minst en bok i veckan, men effekten kommer att vara i flera dagar, och sedan kommer allt att återgå till sin plats. Böcker bör användas som en källa till råd som omedelbart prövas i praktiken. Om du inte gör detta, då är allt de kommer att ge en breddning av dina horisonter.

Källa: will.com