Hvordan kan man være en stor udvikler? (Det handler ikke kun om god kode)

Tillad mig dristigheden ved at skrive om at være stor på mit arbejdsområde. Er jeg egnet til at skrive om det? Nå, jeg skriver om, hvordan jeg prøver at være en stor udvikler hver dag.

Vi vil alle være bedre til, hvad vi gør for at leve, enten af ​​økonomiske grunde, selvtillid, skridt op i vores karriere eller anden gyldig grund.

En softwareingeniør er ikke anderledes end at tilhøre en branche, der konstant ændrer sig og udvikler sig. Softwareteknikfeltet har forskellige karakteristika, såsom:

  • at have mange forskellige tilgange til at løse en udfordring;
  • den rigtige løsning kan hurtigt blive en dårlig løsning, når konteksten ændres;
  • og det faktum, at vores arbejde oftest analyseres af ikke-eksperter, der træffer beslutninger baseret på en opfattelse af, hvordan alt passer. For eksempel et websted eller en app, der er oprettet af et helt team versus den kodenhed, der er oprettet af udvikleren.

I denne artikel giver jeg mit synspunkt og hvilken tilgang jeg tager for at forbedre mig som udvikler.

For øvrig er det let. Vi behøver ikke at have en kirurgs håndpræcision, heller ikke den fysiske styrke hos en bygningsarbejder. Vi er nødt til at bruge vores hjerne for rigtigt.

Hvad er en god udvikler?

Jeg antager, at du er kandidat eller har lært det grundlæggende i programmering.

Udviklerens ansvar:

Jeg mener, at en god udvikler skal være i stand til at udføre mindst halvdelen af ​​disse opgaver:

  • kode (kaptajn er åbenlyst er her!);
  • forstå det projekt, han / hun er integreret i;
  • finde løsninger til problemer;
  • følge holdene og projektmålene;
  • genkender mulighederne for at forbedre sig selv, teamet og virksomheden.

I de første år af din karriere

Ha modet til at stille spørgsmål

Se ikke kun efter penge, når du vælger et firma. De første interviews er svære, vi ved ikke, hvad vi skal spørge, så vi lytter til intervieweren, der snakker om projektet, virksomhedens forventninger og den løn de tilbyder, og hvordan det passer godt til vores karriere.

Prøv at forstå, hvordan virksomheden og mere præcist, hvordan teamet fungerer. Stil nogle spørgsmål som:

  • Indeholder din udviklingsproces kodevurdering? (vi kommer til dette senere)
  • Arbejder du med opdaterede værktøjer og softwaresprog? Og har disse trækkraft?
  • Hvordan er projektgruppen organiseret?

De første projekter, du deltager, vil påvirke resten af ​​din karriere. Tro mig! Enten lærer du efter metodik, softwaresprog eller teknologier og bliver til sidst ekspert.

Jeg valgte min praktik på universitetet og den første kontrakt baseret på penge. Jeg var heldig, for selv om det ikke var et perfekt firma, havde det nogle gode udviklere, som jeg har lært et par ting fra. I øvrigt var det Java og Adobe Flex 3 (det havde trækkraft dengang, ikke nu takket være Apple for at have dræbt Flash), og 12 år senere, her koder jeg (stadig) Java.

Jeg har været i en masse interviews, hvor rekruttereren netop fortalte mig, hvor godt virksomheden behandlede sine ansatte og hvor godt de tjente. Ingen detaljer blev givet om projekterne, ansvaret eller forventningerne til mit arbejde.

En dag kom jeg ud af et interview og tænkte: ”Hvis jeg accepterer, foruden min løn, hvad ved jeg hvad jeg vil opleve i dette firma?”. Fra da af tvang jeg mig selv til ikke at forlade nogen anden samtale uden svarene på disse spørgsmål:

“Hvor mange mennesker er der på holdet?”;

“Hvordan er det struktureret?”;

"Hvad er teknologier og versioner?";

”Hvor tæt på den endelige levering er projektet / produktet?”

I løbet af din karriere

Har nogen at lære af

Når vi arbejder i et team, har vi konstante incitamenter til at forbedre os. Den grundlæggende er at have mindst en mentor villig til at dele. Det kan være din chef eller kollega. Se på, hvordan han overvinder sine udfordringer. Lær, studerer og endda kopierer fra sit arbejde. Hvis du er i de tidlige stadier af din karriere, og når du ser dig rundt, synes du, du er den bedste, skal du enten være mere beskeden eller for at se efter en ny udfordring.

Omfavn kritik

En anden større bonus er kodevurderingspolitikken. Se ikke på kodevurderingen som "dit arbejde bliver bedømt" af dine holdkammerater; se på det som den ultimative genvej for at forbedre dine tekniske færdigheder. Du får gratis personlige klasser med eksempler fra den virkelige verden!

Tænk og tænk igen

Så du har fundet en hurtig løsning til en fejl? Har du tænkt på det 2, 3 gange? ”Det er bare en ny tilstand i en komponent, og det fungerer,” siger du. Sørg for, at din kode ikke påvirker nogle andre funktionaliteter, og at den er i overensstemmelse med det grundlæggende i programmering. Du ønsker ikke at blive for sprængt i kodevurderingen.

Kan du huske, da jeg talte om mit første job? Der var ikke sådan noget som en kodeanmeldelse! Jeg havde en god teamleder, som jeg har lært om tekniske aspekter og kommunikation, men han forlod virksomheden og lige efter et år. Jeg havde en følelse af at være forældet. På grund af det besluttede jeg at gå til et andet firma, hvor jeg troede, jeg ville lære mere. Når jeg ser tilbage, og som et lille råd til dig (hvor modig er jeg at skrive om at være god og give dig råd), skal du ikke skynde dig på grund af en kort periode uden "nye ting at gøre", men vent ikke for meget, når du er "ikke lærer af nogen".

Vil du udmærke dig?

Hvis du er smart og dedikeret nok og følger de tidligere tip, vil du være en pålidelig udvikler for det mindste.

Vær disciplin, fokuseret og nysgerrig

En typisk udviklerdag har 8 timers arbejde, som ikke er 100% dedikeret til vores nuværende opgaver. Udover de regelmæssige pauser, så din hjerne kan trække vejret, hvis du af en eller anden grund ikke får tildelt nogen opgave i et par timer, har du en fremragende mulighed for at lære noget relateret til dit arbejde.

Vær opmærksom på den dybe, mørke verden af ​​flyvende katte på internettet. De får 1 time til at ligne 5 minutter.

https://www.freepik.com/free-vector/hand-drawn-ufo-abduction-concept_2934541.htm

Forstå projektet, du arbejder i

Kender du det grundlæggende i det projekt, du arbejder i?

  • Hvordan integreres dit arbejde med resten?
  • Retter du kun fejl? Hvad er de fejl, der forhindrer brugerne i at udføre?
  • Bygger du noget REST API? Hvordan og til hvad skal de bruges til?
  • Opretter du en ny UI-komponent? Hvor vil det blive brugt, og hvorfor har projektet brug for det?

Husk, at du højst har et par timer, vær så pragmatisk som du kan. Forstå de direkte omgivelser i dit arbejde og ikke hele projektet på én gang.

Invester dig selv

Vi vil udmærke os. Lad os gøre det. Hvis du er som de fleste af os, bliver du nødt til at gå længere og tage noget af din fritid for at lære mere. Du kan hvile, hvis du vil, og du har brug for det, men hvis du bliver en stor udvikler, er der ingen magisk pille, du bliver nødt til at investere. Tro mig: penge er billigere end tiden. Tag noget af din fritid, og kig efter nye tilgange til kodning, læse eksempler, lær af akkrediterede blogs, eventuelt køb nogle bøger med fokus på teknologien, du arbejder i, eller vil arbejde.

Stadig om min rejse ... Efter at jeg havde skiftet firma, mødte jeg en person, der tog Java-certificeringer (jeg vidste ikke, at sådan noget eksisterede). Det fik mig til at tro, at for at være bedre, bliver jeg nødt til at investere mere i mig selv. Så jeg begyndte at studere på fritiden. De to første bøger, jeg læste, var "Spring in Action" og "EJB 3". Mere end at lære om disse rammer lærer jeg meget om kodestruktur og bedste praksis.

Jeg anbefaler også den store rene kode fra Robert C. Martin.

Det er ok at fejle

Som bonustip: Accepter fiasko. Selv hvis du har udviklet noget grundigt, fejler du nogle gange, og det er ok, så længe du lærer af det. Dette er noget, der kaldes oplevelse. Erfaring er ikke opsummeringen af ​​arbejdsår; oplevelsen er en opsummering af konfronterede situationer og erfaringer

Én gang var jeg i et meget ambitiøst projekt, der var beregnet til at optimere ressourcetildelingen fra et privat hospital, uanset om der var senge, børnehave, operationer osv. Dette var et projekt med flere indbyrdes afhængige teams. Input til mit team var et andet holds output, og et tredje-team havde brug for vores data som input. Alt arbejde blev koordineret gennem ”acceptkriterier” (AC) og en “checkliste”. Jeg fik alt i alt, bortset fra at udvikleren fra det tredje hold ikke fortolker en særlig AC som jeg var. Dette havde ingen indflydelse på test eller forproduktionsdata, men en søndag i august modtog jeg et opkald fra min chef, og klienten kunne ikke bruge værktøjet. Problemet kunne have været undgået, hvis jeg havde et skype-opkald på 30 minutter til en sidste kontrol med den anden udvikler.

Jeg hader at mislykkes, men alle mine fejl var store lektioner. Enten i en lille opgave eller i et projekt skal du være så omhyggelig som du kan. Accepter og lær af resultatet af det.

Er dette nok til at være en stor udvikler?

Efter et stykke tid, der har udviklet sig som udvikler og blevet teamleder hos Xpand IT, er dette de vigtigste ting, som jeg værdsætter, mens jeg bliver en god udvikler.

Vi ved, at ikke alle mennesker har den samme kapacitet. Nogle lærer hurtigere, andre tænker hurtigere, andre er meget teoretiske og andre meget pragmatiske. Accepter din måde at gøre ting på, fix det, du laver forkert, og følg den vej, du vil have for din karriere.

At være en god professionel er den primære nøgle til at være en stor udvikler, ligesom for andre job, bortset fra at vores har en mørk verden fuld af flyvende katte, der venter på at blive frigjort.