Hvordan man kan være en god juniorsoftwareingeniør

Tillykke! Du gjorde det! Du er blevet en Junior Software Engineer. For bare et kort år siden modtog jeg den samme ære, da jeg tiltrådte AdHawk, og det har været ret turen. I et forsøg på at videregive viden fra mine tidligere erfaringer har jeg samlet en liste med tip og råd om, hvordan du også kan være en stor Junior Software Engineer.

Mit team (jeg er til højre) Med vores produktchef Joe (Center) - AdHawk hovedkvarter 2018

Vær vokal!

Hvis og når du sidder fast under kodning, skal du ikke lade dig sidde for længe. Arbejd absolut for at skubbe dig selv, når du finder løsninger, men når du er uvirksom for længe, ​​skal du nå ud til en kollegaudvikler. Stil så mange spørgsmål, som du kommer til at tænke på, når du parrer med en kollega. Der er ingen dumme spørgsmål og at afklare ting for dig kommer begge parter til gode. At ikke være vokal kan resultere i at formindske din vækst og udviklingsproduktion.

Søg en mentor

Find en mentor, der er intern eller ekstern for dit specifikke team. Når du møder den mentor, skal du bringe SMART (specifikke, målbare, opnåelige, realistiske og rettidige) mål til disse check-ins og rapportere tilbage til din mentor med eventuelle resultater.

Forsøg også at bringe fejl i dine indtjekninger. Et af de stærkeste værktøjer til læring er introspektion. Diskuter eventuelle vanskeligheder, du har, og spørg din mentor, hvordan du kan vokse fra disse oplevelser.

Venture in the Unknown

Skub for at udføre opgaver, der måske føles uden for dit vidensomfang. Forpligtelse til udfordringer vil opbygge dit volumen af ​​oplevelser og uddybe din fortrolighed med nye og til tider almindelige problemer at løse.

Lær tilbage, hvad du lærer

Der er masser af forskellige måder at vende sig om og lære hvad du har lært. Du kan skrive dokumentation, lave en videoundervisning eller skrive et blogindlæg. Ligegyldigt hvad dit valg af medium, samler handlingen med at tilbagebetale din uddannelsesmæssige vækst. At skulle tydeligt formulere noget tvinger dig til at analysere et problem og udfylde eventuelle huller i din viden.

Opret en arbejdsplan

Der er masser af bevægelige stykker og ansvar, vi har som udviklere. På ethvert tidspunkt kan du skrive en ny funktion, rette en fejl, gennemgå en peer-kode, lære en ny teknologi, deltage i et møde eller et vilkårligt antal andre opgaver. Oprettelse af en tidsplan, der dikterer tid for hver type opgave i løbet af en bestemt arbejdsuge, garanterer, at du skrider fremad inden for hvert nyt ansvarsområde.

Min typiske dag

  1. Gennemgå anmodninger om træk (en halv time til en time)
  2. Arbejd med et udviklingskort (indtil standup, ca. 2-3 timer)
  3. Standup (halv time)
  4. Frokost (time)
  5. Fortsæt arbejdet med udviklingskort
  6. Tryk på en anmodning om igangværende pull og / eller gennemgå nye pull-anmodninger

Mødet vil komme op og blive klemt mellem alle disse opgaver.

Tving dig selv til testkørsel

TDD står for testdrevet udvikling. Kort sagt betyder TDD, at du først skriver test, der validerer funktionaliteten af ​​en aktuelt ikke-eksisterende funktion eller interaktion. Dette skaber en meget vigtig feedback-loop af information, der klart definerer målet og omfanget af din opgave. Et eksempel på en nylig test, jeg skrev, ville være:

Når du kører denne kode, er den første fejl, at stien variant_path ikke findes. Nu er din udviklingsfortælling indstillet. Som junior giver Test Driven Development mig muligheden for at sætte en vej mod en bestemt funktion. Denne vej leder mig derefter med en rute med fejlmeddelelser, der hjælper mig med at udfylde hullerne i enhver potentiel løsning.

Push For parring

Der er ingen hurtigere måde at vokse som junior på end parring med flere seniordevs. Det miljø, der er skabt, når et Senior- og Junior-par skal tjene til at styrke den opførsel, der er nødvendig for at få succes for alle involverede parter. Ældre bliver nødt til at kommunikere deres ideer og beslutninger på en mere generaliseret og kortfattet måde. Jeg tror, ​​at alle ingeniører lettere kan skrive kode, mens de er dybt i sammenhæng med at finde en løsning. Når de bliver bedt om at forklare eller validere deres beslutninger, begynder de imidlertid at forstå målet og potentialet for refactoring opstår.

Juniorer på den anden side vil kunne træffe beslutninger på højere niveau og almindelige interaktioner, der hurtigt trækkes ind i deres oplevelse. Dette gør det muligt for dem at springe over nogle af de ordsprægede springbræt, som at have et grundigt gennemgang af, hvordan man først bygger en test eller håndterer fejl på en mere passende måde. Dette skaber rette vaner og forbedrer ansøgningens sundhed på lang sigt.

Vigtigst af alt forbedrer udvikleroplevelsen for alle deltagere. Et gammelt ordsprog tænker på, ”Alene kan du gå hurtigt, men sammen kan vi gå langt”. Begrebet mental eller kognitiv træthed fra at blive “fast” forekommer næsten ikke så ofte.

At have et par til at afvise ideer fra eller muligvis skifte rolle fra “driver” til “navigator” (der skriver kontra hvem der taler uden at skrive) eller omvendt kan springe startkognitive blokke og faktisk øge udviklingshastigheden. Mens parring har en iboende omkostning (betalte timer), opvejer væksten, der forekommer og den returnerede værdi i udviklerens oplevelse, meget højere end den oprindelige investering.

Slip dine værktøjer

Længe før jeg vidste, at teknik var i horisonten, tog jeg en række klasser i gymnasiet om grafisk design. Den første test, vi tog for den klasse, var for tastaturgenveje. Hvorfor lærer vi ikke farve teori, eller hvordan man korrekt bruger maskeværktøjet? Det er fordi min instruktør vidste, at man ikke virkelig kan være kunstner uden først at lære at styre dine værktøjer. Denne lektion har været hos mig resten af ​​mit liv. Det var en enkel, men alligevel meget kraftfuld besked.

Som ingeniør er dit sind et af dine stærkeste værktøjer og vil fortsætte med at blive stærkere dagligt. Hvis dit udviklingsmiljø imidlertid ikke er konfigureret på en effektiv måde, kan du til sidst snuble gennem mappestrukturer, bruge din markør i stedet for almindelige genveje, og langsomme skrivehastigheder kan i høj grad hindre muligheden for at oversætte dine løsninger til kode.

En håndfuld værktøjer til din rådighed:

  • Lær dine IDE-genveje (VSCode-grundlæggende genveje)
  • Zsh - et unix-shell, der kan bruges til at optimere dine shell-interaktioner (autofuldførende kommandoer, kommandoaliasering osv.)
  • Installer en windows manager (Spectacle er min valgte app)

At være i stand til at få adgang til mine ressourcer har sparet mig utallige minutter (som tilføjer over tid). Dette har gjort det muligt for mig at bruge størstedelen af ​​min tid på at arbejde på at finde løsninger i stedet for at kæmpe med mit miljø.

Media Media Media

Mange af de mest succesrige individer i historien anbefaler planlægning af tid til at lære i hele din arbejdsuge. Elon Musk, Bill Gates og Oprah er blot et par af fortalerne for denne filosofi, 5-timers reglen. Reglen siger, at en person, der ønsker at øge deres samlede succes, skal bruge mindst 5 timer om ugen på at lære noget nyt.

Jeg har tillid til deres dom! Det er ingen hemmelighed, at der er en næsten uendelig mængde blogs, podcasts, artikler, konferencesamtaler, tutorials og mere, man kan forbruge for at styrke deres viden som en software-ingeniør. Under din rejse som junior vil du vade ind i et hav af ukendte udtryk og koncepter. Hold dig ikke væk fra denne oplevelse. Faktisk vil jeg foreslå at presse fremad.

Nogle få ressourcer, jeg har haft det sidste år:

  • Bike Shed Podcast - Softwareudviklingspodcast fra folkene på Thoughtbot (indhold på højt niveau, der kan synes over dit hoved, men vil være værdifuldt at høre i det lange løb)
  • Egghead.io - Fantastisk platform med meget kortfattede og velformaterede videotutorials
  • Exercism.io - TDD fokuseret platform til at undervise i mange populære sprog og rammer

At dedikere en håndfuld timer til at lære med disse og muligvis andre værktøjer vil optimere din vækst og presse dig til at blive den bedste udvikler, du kan være.

Gå frem og fremgang

Tillykke igen med den rejse, du skal tage. Det er en, der ikke er uden fare. Meget som software, vaner og succes bygges ikke natten over. Med disse tip og en generøs mængde hårdt arbejde er jeg overbevist om, at du bliver den bedste Junior Software Engineer, du kan være.