Techlead Skyeng Kirill Rogovoy () geeft een presentatie op conferenties waarin hij vertelt over de vaardigheden die iedere goede ontwikkelaar moet ontwikkelen om de beste te worden. Ik vroeg hem om dit verhaal te delen met de Habra-lezers, ik geef het woord aan Kirill.
De mythe over een goede ontwikkelaar is dat hij:
- Schrijft schone code
- Kent veel technologieën
- Codeer taken sneller
- Kent een aantal algoritmen en ontwerppatronen
- Kan elke code refactoren met behulp van Clean Code
- Verspilt geen tijd aan niet-programmeertaken
- 100% meester van uw favoriete technologie
Zo ziet HR de ideale kandidaten, en vacatures zien er dus ook zo uit.
Maar mijn ervaring zegt dat dit niet helemaal waar is.
Allereerst twee belangrijke disclaimers:
1) mijn ervaring is productteams, d.w.z. bedrijven met een eigen product, niet uitbesteden; bij outsourcing kan alles heel anders zijn;
2) als je junior bent, zijn niet alle adviezen van toepassing, en als ik jou was, zou ik me voorlopig concentreren op programmeren.
Goede ontwikkelaar: realiteit
1: Beter dan gemiddelde code
Een goede ontwikkelaar weet hoe hij coole architectuur moet creëren, coole code moet schrijven en niet te veel bugs moet maken; Over het algemeen doet hij het beter dan gemiddeld, maar hij behoort niet tot de top 1% van de specialisten. De meeste van de coolste ontwikkelaars die ik ken, zijn niet zulke geweldige programmeurs: ze zijn geweldig in wat ze doen, maar ze kunnen niets superbuitengewoons doen.
2: Lost problemen op in plaats van ze te creëren
Laten we ons voorstellen dat we een externe dienst in het project moeten integreren. We ontvangen de technische specificaties, bekijken de documentatie, zien dat daar iets verouderd is, begrijpen dat we aanvullende parameters moeten doorgeven, enkele aanpassingen moeten maken, proberen het allemaal op de een of andere manier te implementeren en een of andere kromme methode correct te laten werken, eindelijk, na een paar van dagen begrijpen we dat we zo niet verder kunnen. Het standaardgedrag van een ontwikkelaar in deze situatie is om weer aan de slag te gaan en te zeggen: “Ik heb dit en dat gedaan, deze werkt niet zo, en die werkt helemaal niet, dus zoek het zelf maar uit. ” Een bedrijf heeft een probleem: je moet je verdiepen in wat er is gebeurd, met iemand communiceren en proberen het op de een of andere manier op te lossen. De kapotte telefoon begint: "Vertel het hem maar, ik sms haar, kijk wat ze hebben geantwoord."
Een goede ontwikkelaar die met een dergelijke situatie wordt geconfronteerd, zal zelf contacten zoeken, telefonisch contact met hem opnemen, het probleem bespreken, en als niets lukt, zal hij de juiste mensen verzamelen, alles uitleggen en alternatieven aanbieden (hoogstwaarschijnlijk is er nog een andere externe dienst met betere ondersteuning). Zo’n ontwikkelaar ziet een zakelijk probleem en lost dat op. Zijn taak is afgerond als hij een zakelijk probleem oplost, en niet als hij ergens tegenaan loopt.
3: Probeert minimale moeite te doen om maximale resultaten te behalen, zelfs als dat betekent dat je op krukken moet schrijven
Softwareontwikkeling bij productbedrijven is vrijwel altijd de grootste kostenpost: ontwikkelaars zijn duur. En een goede ontwikkelaar begrijpt dat een bedrijf het maximale geldbedrag wil binnenhalen door het minimale uit te geven. Om hem te helpen wil een goede ontwikkelaar zo min mogelijk kostbare tijd besteden aan het behalen van de maximale winst voor de werkgever.
Er zijn hier twee uitersten. Eén daarvan is dat je over het algemeen alle problemen met een kruk kunt oplossen, zonder je druk te maken over architectuur, zonder refactoring, enzovoort. We weten allemaal hoe dit meestal afloopt: niets werkt, we herschrijven het project helemaal opnieuw. Een andere is wanneer iemand voor elke knop een ideale architectuur probeert te bedenken, waarbij hij een uur aan de taak besteedt en vier aan refactoring. Het resultaat van dergelijk werk ziet er geweldig uit, maar het probleem is dat het aan de zakelijke kant tien uur duurt om een knop te voltooien, zowel in het eerste als in het tweede geval, simpelweg om verschillende redenen.
Een goede ontwikkelaar weet de balans tussen deze uitersten te vinden. Hij begrijpt de context en neemt de optimale beslissing: bij dit probleem zal ik een kruk doorsnijden, omdat dit code is die eens in de zes maanden wordt aangeraakt. Maar in deze zal ik mijn best doen en alles zo correct mogelijk doen, want honderd nieuwe functies die nog ontwikkeld moeten worden, zullen afhangen van wat mij lukt.
4. Heeft een eigen bedrijfsbeheersysteem en kan daarin aan projecten van elke complexiteit werken.
Werken aan principes – als je al je taken in een soort tekstsysteem opschrijft, afspraken niet vergeet, iedereen pusht, overal op tijd komt, weet wat op dit moment belangrijk is en wat niet, dan raak je nooit taken kwijt. Het algemene kenmerk van zulke mensen is dat als je het met hen eens bent, je nooit bang hoeft te zijn dat ze het zullen vergeten; en je weet ook dat ze alles opschrijven en dan geen duizend vragen stellen waarvan de antwoorden al besproken zijn.
5. Stelt vragen en verduidelijkt eventuele voorwaarden en introducties
Ook hier zijn er twee uitersten. Aan de ene kant kun je sceptisch zijn over alle inleidende informatie. Mensen vóór u hebben een aantal oplossingen bedacht, maar u denkt dat u het beter kunt doen en begint alles wat vóór u kwam opnieuw te bespreken: ontwerp, bedrijfsoplossingen, architectuur, enz. Dit verspilt veel tijd voor zowel de ontwikkelaar als de mensen om hem heen, en heeft een negatieve invloed op het vertrouwen binnen het bedrijf: andere mensen willen geen beslissingen nemen omdat ze weten dat die man terug zal komen en alles kapot zal maken. Het andere uiterste is wanneer een ontwikkelaar inleidende, technische specificaties en zakelijke wensen als iets in steen gehouwen beschouwt, en pas wanneer hij met een onoplosbaar probleem wordt geconfronteerd, begint hij na te denken of hij überhaupt wel doet wat hij doet. Een goede ontwikkelaar vindt hier ook een middenweg: hij probeert de beslissingen te begrijpen die vóór of zonder hem zijn genomen, voordat de taak in ontwikkeling gaat. Wat wil het bedrijfsleven? Zijn wij zijn problemen aan het oplossen? De productontwerper heeft een oplossing bedacht, maar begrijp ik waarom de oplossing gaat werken? Waarom heeft de teamleider deze specifieke architectuur bedacht? Als iets niet duidelijk is, moet je het vragen. Tijdens het proces van deze verduidelijking kan een goede ontwikkelaar een alternatieve oplossing tegenkomen die nog nooit eerder bij iemand was opgekomen.
6. Verbetert processen en mensen om je heen
Er zijn veel processen om ons heen gaande: dagelijkse vergaderingen, meetups, scrums, technische beoordelingen, codebeoordelingen, enz. Een goede ontwikkelaar zal opstaan en zeggen: kijk, we komen samen en bespreken elke week hetzelfde, ik begrijp niet waarom, we kunnen dit uur net zo goed aan Contra besteden. Of: voor de derde taak op rij kom ik niet in de code, niets is duidelijk, de architectuur zit vol gaten; Misschien is onze beoordelingscode zwak en moeten we herstructureren, laten we de bijeenkomst elke twee weken herstructureren. Of iemand ziet tijdens een code review dat een van zijn collega’s een bepaalde tool niet effectief genoeg gebruikt, waardoor hij later naar voren moet komen en advies moet geven. Een goede ontwikkelaar heeft dit instinct; hij doet zulke dingen automatisch.
7. Uitstekend in het managen van anderen, zelfs als je geen manager bent
Deze vaardigheid sluit goed aan bij het thema ‘problemen oplossen in plaats van creëren’. Vaak staat er in de tekst van de vacature waarvoor wij solliciteren niets over management, maar als je dan met een probleem wordt geconfronteerd waar je geen invloed op hebt, moet je toch op de een of andere manier anderen aansturen, iets uit hen halen, als je vergeten - duwen, zorg ervoor dat ze alles begrepen. Een goede ontwikkelaar weet wie waarvoor geïnteresseerd is, kan met deze mensen een afspraak beleggen, afspraken opschrijven, opsturen, op de juiste dag herinneren, zorgen dat alles klaar staat, ook al is hij daar niet persoonlijk direct verantwoordelijk voor deze taak, maar zijn resultaat hangt af van de uitvoering ervan.
8. Ziet zijn kennis niet als dogma, staat voortdurend open voor kritiek
Iedereen kent wel een collega uit een vorige baan die geen concessies kan doen aan zijn technologie en schreeuwt dat iedereen in de hel zal branden vanwege een aantal verkeerde mutaties. Een goede ontwikkelaar begrijpt, als hij 5, 10, 20 jaar in de industrie werkt, dat de helft van zijn kennis verrot is, en dat hij van de overige helft niet tien keer meer weet dan hij weet. En elke keer dat iemand het niet met hem eens is en een alternatief aanbiedt, is dat geen aanval op zijn ego, maar een kans om iets te leren. Hierdoor kan hij veel sneller groeien dan de mensen om hem heen.
Laten we mijn idee van een ideale ontwikkelaar vergelijken met het algemeen aanvaarde idee:
Deze afbeelding laat zien hoeveel van de hierboven beschreven punten verband houden met de code, en hoeveel niet. Ontwikkeling in een productbedrijf bestaat slechts voor een derde uit programmeren, de overige 2/3 heeft weinig met code te maken. En hoewel we veel code schrijven, hangt onze effectiviteit in grote mate af van deze “irrelevante” tweederde.
Specialisatie, generalisme en de 80-20 regel
Wanneer iemand leert een aantal beperkte problemen op te lossen, lang en hard studeert, maar ze vervolgens gemakkelijk en eenvoudig oplost, maar geen expertise heeft op aanverwante gebieden, is dit specialisatie. Van generalisme is sprake als de helft van de opleidingstijd wordt geïnvesteerd op het gebied van de eigen competentie, en de andere helft op aanverwante gebieden. Dienovereenkomstig doe ik in het eerste geval één ding perfect en de rest slecht, en in het tweede geval doe ik alles min of meer goed.
De 80-20-regel vertelt ons dat 80% van het resultaat voortkomt uit 20% van de inspanning. 80% van de omzet komt van 20% van de klanten, 80% van de winst komt van 20% van de werknemers, enzovoort. In het lesgeven betekent dit dat we 80% van de kennis opdoen in de eerste 20% van de tijd die we besteden.
Er is een idee: programmeurs moeten alleen coderen, ontwerpers moeten alleen ontwerpen, analisten moeten analyseren en managers moeten alleen beheren. Naar mijn mening is dit idee giftig en werkt het niet erg goed. Het gaat er niet om dat iedereen een universele soldaat moet zijn, maar om het besparen van hulpbronnen. Als een ontwikkelaar op zijn minst een beetje begrijpt van management, ontwerp en analyse, zal hij veel problemen kunnen oplossen zonder er andere mensen bij te betrekken. Als je een functie moet maken en vervolgens wilt controleren hoe gebruikers ermee werken in een bepaalde context, waarvoor twee SQL-query's nodig zijn, dan is het geweldig om de analist hiermee niet af te leiden. Als u een knop moet insluiten naar analogie met bestaande, en u begrijpt de algemene principes, dan kunt u dit doen zonder een ontwerper erbij te betrekken, en het bedrijf zal u daarvoor bedanken.
Totaal: je kunt 100% van je tijd besteden aan het tot het uiterste bestuderen van een vaardigheid, of je kunt dezelfde tijd aan vijf gebieden besteden, waarbij je in elk gebied tot 80% kunt nivelleren. Als we deze naïeve wiskunde volgen, kunnen we in dezelfde tijd vier keer zoveel vaardigheden verwerven. Dit is overdreven, maar het illustreert het idee.
Gerelateerde vaardigheden kunnen niet voor 80% worden getraind, maar voor 30-50%. Na 10-20 uur zul je merkbaar verbeteren op aanverwante gebieden, veel inzicht krijgen in de processen die daarin plaatsvinden en veel autonomer worden.
In het huidige IT-ecosysteem is het beter om over zoveel mogelijk vaardigheden te beschikken en in geen van deze vaardigheden een expert te zijn. Omdat, ten eerste, al deze vaardigheden snel vervagen, vooral als het gaat om programmeren, en ten tweede omdat we 99% van de tijd niet alleen basisvaardigheden gebruiken, maar zeker niet de meest geavanceerde vaardigheden, en dit is zelfs voldoende bij het coderen, zelfs bij het programmeren. toffe bedrijven.
En ten slotte is opleiding een investering, en diversificatie is belangrijk bij investeringen.
Wat te leren
Dus wat moet je leren en hoe? Een typische ontwikkelaar in een sterk bedrijf gebruikt regelmatig:
- communicatie
- zelforganisatie
- planning
- ontwerp (meestal code)
- en soms management, leiderschap, data-analyse, schrijven, rekruteren, mentorschap en vele andere vaardigheden
En vrijwel geen van deze vaardigheden kruist de code zelf. Ze moeten afzonderlijk worden onderwezen en verbeterd, en als dit niet gebeurt, zullen ze op een zeer laag niveau blijven, waardoor ze niet effectief kunnen worden gebruikt.
Op welke gebieden is het de moeite waard om zich te ontwikkelen?
-
Soft skills zijn alles wat niet te maken heeft met het indrukken van knoppen in de editor. Dit is hoe we berichten schrijven, hoe we ons gedragen in vergaderingen, hoe we communiceren met collega's. Het lijken allemaal voor de hand liggende zaken, maar vaak worden ze onderschat.
-
Zelforganisatiesysteem. Voor mij persoonlijk is dit het afgelopen jaar een superbelangrijk onderwerp geworden. Van alle coole IT-medewerkers die ik ken, is dit een van de meest ontwikkelde vaardigheden: ze zijn supergeorganiseerd, ze doen altijd wat ze zeggen, ze weten precies wat ze morgen, over een week, over een maand gaan doen. Het is noodzakelijk om een systeem om jezelf heen te bouwen waarin alle zaken en alle vragen worden vastgelegd; dit vergemakkelijkt het werk zelf enorm en helpt enorm bij de interactie met andere mensen. Ik heb het gevoel dat de ontwikkeling in deze richting mij het afgelopen jaar veel meer heeft verbeterd dan het verbeteren van mijn technische vaardigheden; ik begon aanzienlijk meer werk per tijdseenheid te doen.
-
Proactief, open-minded en planmatig. De onderwerpen zijn zeer algemeen en essentieel, niet uniek voor IT, en iedereen zou ze moeten ontwikkelen. Proactiviteit betekent dat je niet wacht op een signaal om actie te ondernemen. Jij bent de bron van gebeurtenissen, niet de reacties daarop. Openheid van geest is het vermogen om nieuwe informatie objectief te behandelen, om de situatie los van het eigen wereldbeeld en oude gewoonten te beoordelen. Planning is een duidelijke visie op hoe de taak van vandaag het probleem voor de week, maand, jaar oplost. Als je de toekomst verder ziet dan een specifieke taak, is het veel gemakkelijker om te doen wat je nodig hebt, en niet bang te zijn om na verloop van tijd te beseffen dat het verspild was. Deze vaardigheid is vooral belangrijk voor een carrière: je kunt jarenlang met succes resultaten behalen, maar op de verkeerde plek, en uiteindelijk alle opgebouwde bagage verliezen als duidelijk wordt dat je de verkeerde kant op gaat.
-
Alle gerelateerde gebieden tot het basisniveau. Iedereen heeft zijn eigen specifieke gebieden, maar het is belangrijk om te begrijpen dat door 10 tot 20 uur te besteden aan het verbeteren van bepaalde “buitenlandse” vaardigheden, je veel nieuwe kansen en contactpunten in je dagelijkse werk kunt ontdekken. voldoende zijn tot het einde van de carrière.
Wat te lezen?
Er zijn heel veel boeken over zelforganisatie; het is een hele industrie waar een paar vreemde jongens verzamelingen advies schrijven en trainingen verzamelen. Tegelijkertijd is het onduidelijk wat ze zelf in het leven hebben bereikt. Daarom is het belangrijk om filters op de auteurs te zetten, te kijken wie ze zijn en wat ze achter zich hebben. Mijn ontwikkeling en visie werden het meest beïnvloed door vier boeken, die allemaal op de een of andere manier verband hielden met het verbeteren van de hierboven beschreven vaardigheden.
1. Dale Carnegie “Hoe je vrienden kunt winnen en mensen kunt beïnvloeden”. Een cultboek over soft skills, als je niet weet waar je moet beginnen, is het kiezen ervan een win-winoptie. Het is gebaseerd op voorbeelden, is gemakkelijk te lezen, vereist niet veel moeite om te begrijpen wat je leest en de verworven vaardigheden kunnen onmiddellijk worden toegepast. Over het geheel genomen behandelt het boek het onderwerp communicatie met mensen.
2. Stephen R. Covey ‘Zeven eigenschappen van zeer effectieve mensen’. Een mix van verschillende vaardigheden, van proactiviteit tot soft skills, met de nadruk op het bereiken van synergie wanneer je van een klein team een grote kracht moet maken. Het is ook gemakkelijk te lezen.
3. Ray Dalio ‘Principes’. Onthult thema's als ruimdenkendheid en proactiviteit, gebaseerd op de geschiedenis van het bedrijf dat de auteur heeft opgebouwd en dat hij 40 jaar lang heeft geleid. Veel zwaarbevochten voorbeelden uit het leven laten zien hoe bevooroordeeld en afhankelijk iemand kan zijn, en hoe je daar vanaf kunt komen.
4. David Allen, ‘Dingen gedaan krijgen’. Verplichte lectuur om zelforganisatie te leren. Het is niet zo gemakkelijk te lezen, maar het biedt een uitgebreide set hulpmiddelen voor het organiseren van het leven en de zaken, onderzoekt alle aspecten in detail en helpt u beslissen wat u precies nodig heeft. Met haar hulp heb ik mijn eigen systeem gebouwd waarmee ik altijd de belangrijkste dingen kan doen zonder de rest te vergeten.
Je moet begrijpen dat alleen lezen niet genoeg is. Je kunt minstens een boek per week doorslikken, maar het effect houdt enkele dagen aan en dan keert alles terug naar zijn plaats. Boeken moeten gebruikt worden als bron van advies, dat meteen in de praktijk wordt getoetst. Als je dit niet doet, is het enige wat ze je opleveren een verbreding van je horizon.
Bron: www.habr.com