Sådan får du et udviklerjob på mindre end et år

Fremskynde din læring

Hvad er den sværeste del for en person, der beslutter at lære sig selv at kode? Det faktum, at de normalt ikke ved, hvad de skal lære - hvilket programmeringssprog de skal vælge, hvordan man nærmer sig læring, hvilke ressourcer der er bedst med hensyn til tidseffektivitet.

Det hele starter med Google-søgninger på disse emner, som uundgåeligt fører folk til en af ​​de mange ressourcer, der lærer folk at kode. Formatet på disse ressourcer varierer meget, og sund fornuft fortæller os, at vi skal prøve en masse forskellige ressourcer og vælge dem, der bedst passer til vores læringsstil. Selvstudier til nogle mennesker, screencasts til andre, artikler til endnu en gruppe osv. Synes det er ret logisk, ikke?

Altså nej. I dag vil jeg overbevise dig om, at et af disse læringsformater bringer dig dit sted, hvor du vil være hurtigere end nogen anden. Uden yderligere forsinkelse, lad mig fortælle dig, hvad det er, og hvorfor du skal fokusere al din indsats på det.

Byg projekter

Jeg vedder på, at du så den ene komme.

Lad mig først og fremmest få nogle af dine indvendinger ud af vejen. Jeg siger ikke, at du skal droppe alle de andre typer læringsressourcer helt.

Alle tutorials og screencasts har deres plads under solen, og det vil jeg uddybe yderligere i artiklen. For eksempel kan den mest effektive måde at blive introduceret til en ny teknologi eller en ramme undertiden være at læse en artikel eller gennemgå en tutorial.

Problemet er, at vi har tendens til at holde os (eller i det mindste jeg) til de ressourcer, der holder os i vores komfortzone, selv når det er tid til at gøre noget selv. Det er bare alt for praktisk, klar til forbrug. Det får os også altid til at føle os godt, for hej, her er vi ved at lære! Ret? Hvem kan sige, at vi spilder tid? Hvordan tør de? Vi udfylder hullerne i vores viden!

Det er farligt, at det kan synes for os, at disse ressourcer også er den mest effektive måde at lære på. Som mennesker kan vi retfærdiggøre stort set alt, hvad der holder os inden for vores komfortzone. Jeg har levet i den illusion i nogen tid.

Knock, Knock, Neo.

Opretter projekter ... hvad er nyt ved denne idé? Intet og dybt inde ved vi alle, at det ville være den bedste brug af vores tid og energi og ville få os til vores mål hurtigere. Så hvorfor gør vi det ikke? Modstand.

Jeg har talt om modstanden i min tidligere artikel (læs den, hvis du kæmper, eller hvis du føler dig fast), så lad mig forklare, hvorfor jeg er så overbevist om dette emne, og lad mig overbevise dig om at skifte fokus (medmindre det er allerede der) til bygning.

Ligesom Neo i Matrix, der får valget mellem den røde pille og den blå pille, kan vi vende tilbage til vores illusioner om, at de ressourcer, der holder vores hånd hele tiden, er den bedste måde at lære, eller vi kan tage den røde pille og omfavne den virkelighed, at vi kun bevæger os fremad og vokser, når vi er uden for vores komfortzone. (Hvis du ikke har set Matrixen, skal du sandsynligvis gøre det.)

Her er nogle af mine tanker om, hvordan man nærmer mig disse projekter, som kan være skræmmende at starte, samt nogle tip, jeg har hentet undervejs.

Det kan tage dig endnu mindre end et år (Hvad?)

Begrundelsen bag dette er, at jeg er baseret på min personlige erfaring, ved at tale med medlemmerne af vores Free Code Camp Toronto-gruppe og på at læse om medlemmernes rejser over hele verden.

Jeg finder ud af, at folk ofte er i stand til at finde et job, selv før de er færdige med Free Code Camp's Front End Development-certificering. De bygger de krævede projekter og begynder at ansøge. Snart nok får de et tilbud om at kode for penge.

Hvis du læser gennem Free Code Camp's subreddit, finder du, at der er mange historier som den.

Bemærk, at jobmarkederne varierer fra by til by. I Toronto er der for eksempel masser af job-åbninger i frontend-udviklere.

Free Code Camps officielle holdning er, at du skal gennemføre alle 2.080 timer i læseplanen. Du vil sandsynligvis være en meget stærkere kandidat (og have højere lønninger i mere udfordrende stillinger), hvis du gør det.

Lad os lave matematik:

Front End Webudviklingscertifikat med Free Code Camp tager cirka 478 timer. Der er mennesker, der fuldfører det hurtigere, men det varierer afhængigt af niveauet for personens forberedelse, så lad os beholde 478 som vores base.

Hvad er mindre end et år? Af hensyn til argumentet arbejder vi med 9 måneder. 9 måneder * 30 dage giver os 270 dage.

478 timer / 270 dage er cirka 1,8 timer om dagen. Det betyder, at vi kan kode mindre end i 2 timer om dagen, og om 9 måneder kan vi blive jobklare.

Jeg ved, at tidsplanen for nogle mennesker ikke tillader to ekstra timer om dagen, men for de fleste er det muligt at finde dem. For andre kan det tage lidt længere tid, men der er altid weekender og andre måder at finde (eller gøre) tiden på.

Hvis du leder efter råd om, hvordan du finder tid til at kode, tøv ikke med at kontakte mig på Twitter, så hjælper jeg gerne.

Jeg tog lidt længere tid end det - omkring et år og to måneder. Denne artikel er en analyse af grundene til, at det tog mig længere tid, end den skulle have. Jeg har lavet alle de fejl, som jeg taler om i artiklen. Når jeg giver dig råd, så husk at jeg også giver det råd til mig selv. Vi er i samme båd.

Jeg blev ansat inden jeg kunne færdiggøre Free Code Camp Front End-læseplanen, men jeg ved med sikkerhed, at det vil hjælpe mig med at vokse som udvikler til at komme tilbage og afslutte disse projekter. Her inde i artiklen har jeg placeret links til min Codepen-profil (jeg skammer mig lidt over det!), Og når du ser på det, vil du se, at jeg stadig har en lang vej at gå. Så jeg siger - lad os gøre det sammen! Jeg gør det til mit mål at afslutte alle Front End-projekterne og gøre dem til min prioritet frem for alt andet kodelateret, jeg lærer i den nærmeste fremtid.

Denne artikel er for mig og for dig - for at få os til at skubbe ubehaget igennem og optimere vores læring, så vi kan komme til, hvor vi vil være hurtigere!

Sørg for, at du har dækket dine grundlæggende

Jeg tror stærkt på, at du helt i starten af ​​din læring skal bruge tutorials og interaktive online ressourcer til at gøre dig bekendt med syntaksen for HTML, CSS, JavaScript, for at lære at tænke programmatisk og blive fortrolig med de væsentlige, grundlæggende ting.

Et forsøg på at bygge projekter med det samme uden denne viden ville være for frustrerende. Sørg for, at du ikke bruger for meget tid på dette stadium, da det er meget let at gøre.

Da jeg lærte HTML / CSS / JS, lærte jeg lignende emner fra forskellige ressourcer og tænkte, at det på en eller anden måde ville udfylde alle hullerne i min viden. Det udfyldte nogle huller, men på et tidspunkt indså jeg, at jeg brugte disse ressourcer som en krykke for at forhindre mig i at flytte til nye, mere spændende, men lidt mere skræmmende ting. Sæt dig ikke fast i endeløse sløjfer (sandsynligvis en stund-løkke?;) For at gennemgå og revidere de oplysninger, du allerede kender.

Giv ikke efter for rationalisering

Når du begynder at oprette projekter, vil du uundgåeligt sidde fast. Hvis du holder fast ved det, vil du efter et stykke tid overvinde barrieren, men snart derefter vil du ramme en anden. Det er ikke en mulighed, og det sker for alle.

I sådanne øjeblikke skriger hver del af vores krop - lad os gøre noget andet, lad os løbe herfra, det får mig til at føle mig ubehagelig, jeg kan tackle dette senere, når jeg ved mere, jeg kommer tilbage til det osv. Så vi tager en pause.

Vi er dog bange for, at vores pause vil strække sig, og vi vil bare fortsætte med at kode mindre og mindre og slippe det. For ikke at lade det ske, men alligevel beholde vores “beslutning” om ikke at arbejde på projektet, beslutter vi, at vi indtil videre vil arbejde igennem nogle tutorial eller et online kursus.

Det er meget let at rationalisere dig selv ud af at skabe. Ingen vil fortælle dig, at du ikke lærer at kode eller kritisere dig på nogen måde for at gøre det. Du er den eneste, der kan identificere, hvad der virkelig foregår (frygt, risikoaversion, modstand) og træffe en beslutning om at holde fast i arbejdet med projektet.

Stol på mig, alle væggene smuldrer, hvis du banker på dem længe nok. Tænk på de mennesker, der tilbage på dagen lærte fremmedsprog ved at have to eksemplarer af den samme bog på deres modersmål og målsprog. Hvordan gjorde de det? De holdt bare med det længe nok.

Start ikke med din STORE IDEE

Det er forbløffende, at du allerede har det, men der er nogle andre overvejelser, der kan spilles her, der kan ændre mening. Grunden til, at jeg bringer dette punkt op, er, at jeg hele tiden hører dette meget fra folk: ”Jeg vil oprette en online applikation, der lader folk oprette konti til deres kæledyr, uploade fotos, spore placeringer og mange andre ting. Jeg er for nylig begyndt at lære at kode, og jeg er allerede i færd med at opbygge min idé. ” Dette får mig til at ”Whoa whoa whoa”.

Hvad jeg let kan se, der sker i denne situation er, at en person bliver overforpligtet til ideen, de starter meget entusiastisk og langsomt bygger den op, men som tiden går, kan deres læring ikke følge med projektets krav, og det føles trækker, altid bagest i tankerne, ufærdige.

Det værste, der kan ske i denne situation er, at personen vil opgive projektet og dermed også give op med kodning.

Jeg anbefaler at starte med enkle projekter, og når du er færdig med hvert af dem, får du en følelse af gennemførelse og en bedre forståelse af, hvordan man strukturerer et større projekt.

Forestil dig, at du var forfatter, og du havde en idé til en større bog i dit liv, og du er begyndt at skrive den med det samme. Du bliver sandsynligvis nødt til at omskrive det hele 3-4 gange for at få det til et anstændigt kvalitetsniveau, mens du kan starte med at skrive små historier, få feedback, forbedre din skrivning og nærme dig din Moby Dick, når du virkelig er klar.

Hvor kan jeg få idéer til projekter

Det bedste sted, jeg kender, er Free Code Camp. Det var det, jeg brugte efter at have været helt fast. I begyndelsen af ​​min kodningsrejse ville jeg spørge alle de udviklere, jeg vidste (både offline og online), hvad mit første projekt skulle være. Jeg beder dig ikke, når jeg siger (overraskelse overraskelse), de sagde alle, at det skulle være en To-Do List-app. Jeg tror ærligt talt, at hvis vi fortsætter med at lave disse To-Do-liste-apps, vil de snart overfyldte hele Internettet.

Free Code Camp hjalp mig på en måde, at det gav en liste over spændende projekter, opstillet i en rækkefølge med stigende vanskeligheder. En anden god ting er, at hver af dem er specielt designet til at lære dig et specifikt emne, for eksempel: en hyldestside vil tage dine HTML / CSS-færdigheder på prøve, Vis det lokale vejr vil lære dig at arbejde med API'er, opbyg en JavaScript Lommeregner vil naturligvis forbedre dine JS-færdigheder osv.

Det er det stærkeste udgangspunkt, jeg ved for at få dig til at bygge. For alle de projekter, du er færdig med, kan du få feedback fra samfundet samt se, hvordan andre har kontaktet dem (efter at du har bygget din, ikke snyd!) For ekstra inspiration kan du altid Google “liste over seje kode projektideer ”Eller noget af denne slags.

Strukturér dit projekt først

Før du begynder at bygge, skal du skrive ud, hvad du vil have det til at gøre. Få specifikke brugerhistorier skrevet, for eksempel: "Brugere kan afspille lyd, når de klikker på lydafspiller-knappen", "Brugere kan logge ind ved hjælp af deres e-mail og adgangskode samt bare ved hjælp af Facebook".

Din kode skal også have en grundlæggende struktur, før du begynder at skrive den. Skriv i pseudokode - grundlæggende skal du bare forklare med ord, hvad hver del af applikationen eller projektkoden vil gøre.

Grundlæggende eksempel:

// Når brugeren åbner en side, skal du få fat i deres placering

// Send en anmodning til vejr-API-webstedet med placeringen

// Modtag data

// Vis graderne på siden

// Skift baggrundsbillede af siden for at afspejle det aktuelle vejr

Overdriv det ikke, det er ikke nødvendigt at skrive ud hver eneste lille ting, din kode vil gøre i pseudokode først, men har de vigtigste dele lagt ud.

Det bedste eksempel, jeg kan give dig, er: husk, da du skrev essays i skolen, du var nødt til at strukturere dem først, for eksempel en introduktion med din mening om emnet, 3 hovedpunkter til støtte for din mening og en konklusion .

Dette hjælper dig med at foregribe potentielle problemer og forbedre kvaliteten af ​​din kode.

Det er okay at sidde fast

Som jeg nævnte før, er det okay at sidde fast. Det betyder ikke, at vi er dumme, det betyder bare, at vi ikke ved det endnu. Du vil altid opleve øjeblikke med at sidde fast: ikke kun når du lærer, men også på arbejde.

Jo hurtigere du bliver fortrolig med at være ubehagelig, jo bedre. Det vil gøre dine fremskridt meget hurtigere. Programmering i sig selv er kreativ problemløsning. Hvis der ikke er problemer, der er svære at løse, betyder det, at du spiller det sikkert. Stop med at træde i det lave vand og tag et dyk!

Mest af alt, og jeg vil gentage dette igen, skal du ikke tænke på dig selv som dum. Jeg ved, det er let at gøre i disse øjeblikke. Jeg taler ofte med folk, der let har gennemgået HTML / CSS / JS-delen af ​​Free Code Camp og slår 30-40 varer ud om dagen, og så kommer de til grundlæggende og mellemliggende algoritmer og finder ud af, at de kun kan gøre 1– 5 om dagen, så de kommer til en konklusion, at de sidder fast, og at de er dumme, ikke gode nok eller ikke ment som udvikler.

Jeg var også på samme måde, jeg følte, at der sandsynligvis er mennesker, der bare flyver gennem dette afsnit, og jeg følte mig dårlig om mig selv og mine fremskridt. Nu ved jeg bedre.

Hvad jeg prøver at sige her er, at du bør lære at:

Vær over dit hoved

Du er nødt til at finde det niveau af projektvanskeligheder, der holder dig lige midt mellem de "ting, der er lette" og de "ting, der stadig er for hårde."

Jeg har talt meget om grundene til, at det er farligt at fortsætte med at gennemgå og genlære det samme materiale (de lette ting), så lad os tale om den modsatte side af ligningen: de vanskelige ting.

Din generelle regel, når du nærmer dig noget vanskeligt - noget du tror du måske ikke er i stand til - burde være at prøve at gøre det først.

Start fra den grundlæggende struktur, og prøv at kode den. Hvis du sidder fast i den samme ting i mere end tre dage med at fokusere på det, skal du slippe det et stykke tid og finde lignende - men lidt lettere - ting at gøre.

Hvad jeg finder ud af er, at efter at jeg har gjort det, er mit underbevidsthed stadig fokuseret på at løse det problem, jeg sidder fast i. Jeg får disse tilfældige ideer til, hvordan jeg kan løse det, når jeg laver enkle ting - som at tage et bad eller vaske op - det rammer mig pludselig!

Nogle gange fungerer det nøjagtigt på den måde. Nogle gange gør det ikke. Men det vigtigste råd her er - vælg altid noget, der gør dig lidt ubehagelig . Alt andet er ikke din tid værd.

Modstandsdygtighed

Jeg vil dele med dig et af mine absolutte yndlingsord:

Modstandsdygtighed - et systems evne til at tolerere forstyrrelser uden at kollapse, til at modstå stød, til at genopbygge sig selv, når det er nødvendigt, og til at forbedre sig selv, når det er muligt.

Dette er en fantastisk kvalitet, som du som programmør (og som en person, der ønsker at få succes i livet), skal arbejde på at udvikle dig selv. Forbered dig på alle problemer, alle udfordringer, al kritik af dit arbejde, af dit design, af dine løsninger og alt andet, du måtte gøre, selv før de sker.

Er du bange for at være på scenen? Tilmeld dig for at lære folk i dit lokale samfund det grundlæggende i webudvikling, eller tilmeld dig for at tale ved en konference / tech-begivenhed.

Er du skuffet over, hvordan dit interview gik - og at du ikke blev ansat bagefter? Er du bange for, at det er for sent at begynde at lære at kode? Er du ikke tilfreds med det projekt, du lige har afsluttet?

Omram alt dette : hvad kan du lære af oplevelsen for at gøre det bedre næste gang? Hvordan kan du gøre dine svagheder til styrker?

For eksempel kan du bekymre dig om, at du kommer til kodning for sent efter at have været på en anden karrierevej i X antal år. Omformere det i dit sind ved at tænke over et andet perspektiv og modenhed, du vil bringe ind i branchen, der desperat har brug for mere modne mennesker (psykologisk) og mere forskelligartede baggrunde? Du gør den tekniske industri rigere ved selve beslutningen om at komme ind i den!

Hvis du hører en stemme indeni dig sige 'du kan ikke male', så males på alle måder, og den stemme vil blive tavs. - Vincent Van Gogh

Hvad jeg kan anbefale for at øge din modstandsdygtighed er disse tre bøger:

  1. “Letters From a Stoic” af Seneca
  2. “Hindringen er vejen” af Ryan Holiday
  3. “Turning Pro” af Steven Pressfield

Sæt et dagligt tidsbegrænset mål

For at komme hurtigere skal du arbejde på dine projekter hver dag. Denne del er bare sund fornuft. Der er dog nogle yderligere overvejelser, som du skal huske på.

I stedet for at indstille et resultatmål ("Jeg vil afslutte denne funktion eller den del i dag"), skal du indstille en bestemt tidsperiode, som du vil bruge kodning hver dag. Gør det ikke mere end 30 minutter eller en time om dagen.

Jeg ved, at du vil forpligte dig til at kode i 3 timer om dagen og prøve at holde fast ved det. Dette fungerer, men kun så længe, ​​indtil livet kommer i spil. Med en rimelig tidsbegrænsning - som 30 minutter om dagen - vil du altid vide, at det kan gøres, og at du altid har en halv time om dagen til kodning, især hvis dit hovedmål er at lære at kode. Du vil endda finde dig selv at kode mere på bestemte dage, og det vil føles godt, fordi du allerede har opfyldt din kvote for den dag.

Denne tidsbegrænsning er mere et psykologisk trick, der fungerer på grund af den måde, hvorpå vores hjerner er forbundet. Husk den gang, du havde et stort projekt, som du havde brug for at starte, men du blev ved med at forsinke og forsinke, indtil du lige havde tid nok til at afslutte det inden deadline? Du gjorde det OK, men du var stresset hele tiden før det. Derefter tilføjes dette, at der ikke er nogen, der sætter dig en frist for at blive udvikler. Det er ingen andre end dig.

Hvad der sker, når vi sætter et resultatmål, er at vi ikke kan estimere den tid, det tager at afslutte den eller denne funktion. Og oftere end ikke ender vi ikke med at udføre det, vi har planlagt at gøre for dagen. Det får os til at føle os forfærdelige og mindsker ønsket om at sidde ned og kode den næste dag.

Med et tidsbegrænset dagligt mål vil du gøre fremskridt hver dag. Hvem er ligeglad med, hvis du ikke er færdig med den specifikke funktion, du ønskede at afslutte i dag? Du har gjort fremskridt! Du dukkede op. Det er det, der får dig foran.

En anden god bonus er, når du sidder ned og begynder at kode, ideer og løsninger begynder at strømme, som om de er ud af ingenting (svarer til at skrive en artikel, hva? :). Det vil være meget lettere at få dig til at sætte dig ned og kode, når du først får urealistiske forventninger og frygt.

Kopiering af kode spilder tid

Under processen med at opbygge et projekt, enten helt i starten - når du ikke ved, hvor du skal starte fra, eller på et senere tidspunkt, når du rammer et problem, du ikke let kan løse - vil du opleve et stærkt ønske om at se ved kildekoden til projektet for at se, hvordan det gøres. Du vil rationalisere, at det får dig til straks at forstå koden, og det betyder, at du har lært og assimileret den. Langt fra.

Kopier ikke hele projekter og tilpas dem. Tag ikke dele af koden. Tag ikke engang stykker af det.

Med projekter - se ikke på koden i første omgang. Med de ting, du så op på Stack Overflow og sådan, skal du se på det, analysere, forstå, men derefter kode det selv fra bunden. Du vil se, at det er svært at skrive det selv, selv efter at du lige har set det hele.

Dette er, hvordan bevidst praksis er forskellig fra almindelig praksis (gentagelse). 10.000-regelens vigtigste fangst er, at fremgangsmåden skal være bevidst. Følgende skabeloner og færdige løsninger fører dig ikke nogen steder. Nogen vil sandsynligvis være i stand til at skrive et Python-script, der vil erstatte dig, uanset hvad du laver, hvis du går den vej. Vær opmærksom på, hvad der synes svært for dig.

En anden idé uden for emnet er, at hvis du kæmper med et bestemt emne, skal du prøve at lære det til andre eller bare forklare det for dem, som du forstår det. Resultaterne følger for både dig og de studerende.

Kopiering af kode frarøver dig muligheden for at lære at gøre det selv, og det er på ingen måde bedre end at gennemgå en tutorial. Ja, løsningen er lige der. Ja, du kan tage det, hvis du vil. Men hvad er pointen? Forsøger du at imponere nogen med den hastighed, hvormed du har bygget projektet? Eller prøver du at undgå de hårde problemer, der vil tage lidt tid at løse?

Uanset hvad din årsag måtte være - det er bare en anden vej tilbage i den varme komfort, hvorfra vi forsøger at flygte fra. Gør det modsatte. Kør mod ubehaget.

Den eneste gang det er OK at kigge ind i andres kode, er når du er færdig med projektet. Se derefter så meget du vil, analyser det og lær af det.

Hvert vanskeligt problem, du løser, får dig til at vokse med spring.

Spred ikke din indsats rundt

Jeg er meget skyldig i dette, og det er faktisk et råd, jeg skriver mere for mig selv end for nogen anden (undskyld!). Når du begynder at arbejde på et projekt og rammer de vægge, som jeg nævnte, vil du blive fristet til at sætte det projekt på hold og starte et nyt.

Det føles altid godt i starten, indtil du rammer en mur med det andet projekt. Så vil du have to ufærdige projekter på hånden. Dette gentages igen og igen, hvis du lader det.

Løsningen her er at begrænse dig til 2 projekter ad gangen. Når du sidder fast på en, skal du bruge lidt tid på at finde ud af det. Men hvis det ser ud til at være uhåndterligt i øjeblikket, skal du bare gå til det andet projekt, du har. Det vigtigste er ikke at starte en tredje, fordi det er en glat skråning derfra.

Du bør altid forsøge at gøre alt muligt for at få dig til at holde dig på læringsstien. Hvis du føler dig træt, eller bare keder dig med det, du i øjeblikket laver, skal du tage en lille pause, justere og komme tilbage til det. Giv ikke op med kodning helt.

Derfor anbefaler jeg altid at have et lille wiggle-rum, det være sig en midlertidig distraktion i form af en anden læringsressource (begrænset til en uge), eller i dette tilfælde to projekter i stedet for et.

Din portefølje er, hvad der får dig til at ansættes

Det er meget svært for en ansættelsesleder eller for en ingeniør at vurdere dine færdigheder udelukkende på baggrund af det, du har skrevet i dit CV. “Jeg kender JavaScript! (og har 4 års erfaring). ” "Vis mig!" (Jeg må virkelig stoppe med Matrix-referencerne).

Alle de projekter, du bygger og lægger online, omfatter dit ultimative live CV. Enhver kan se på det og være overbevist om, at du faktisk ved, hvad du laver.

Bliv dog ikke bange, det betyder ikke, at din kode skal være ideel for dem at overveje dig selv. Disse projekter hjælper den, der har til opgave at interviewe dig, til korrekt at vurdere dit færdighedsniveau.

Du behøver ikke opleve interviews langt over dit niveau, fordi nogle HR-personer har fundet et bestemt sæt nøgleord i dit CV. Din arbejdsgivers forventninger vil være mere på niveau med dine faktiske evner.

De positive fordele ved at have dit arbejde online inkluderer:

  • arbejdsgivere ser, at du ved, hvad du laver
  • de ser, at du konstant arbejder på at forbedre dine færdigheder
  • de ser, at du faktisk er en udvikler, og at du er modig nok til at sætte dit arbejde online, så alle kan se.

Fra min personlige erfaring og fra det, jeg stadig hører fra folkene i vores Toronto Free Code Camp-gruppe, er, at den vigtigste faktor i at finde et kodende job har været deres portefølje af projekter.

Du vil gøre det bedre ved interviews

Ved interviews får du sandsynligvis en lille webapp til det virkelige liv eller en side at opbygge eller får et problem at løse.

Ofte med disse problemer søger den person, der udfører ansættelsen, at se, hvordan du tænker gennem at løse et problem. De vil ikke altid have dig til at producere den ideelle løsning. Nogle gange giver de problemer, der ikke kan løses bare for at se, hvad du vil gøre. Du får en masse øvelse af den slags med projekter: hver af dem vil blive fyldt med disse mini-problemer.

Med hensyn til de virkelige ting, som du kan få til at bygge, kan det og vil variere. Her er noget, jeg måtte bygge under interviewet til min nuværende position. Jeg ved, at koden ikke er så god, men dette skal give dig en idé om, hvad du kan forvente. Den eneste grund til, at jeg var i stand til at afslutte det på min interviewdag, var fordi jeg tidligere havde erfaring med at bygge ting som en vejr-app og en lommeregner gennem Free Code Camp.

Du vil identificere de reelle huller i din viden

Her er hvor tutorials og lignende spiller et trick for dig. De får dig til at føle, at når du er færdig med dem, har du dækket alt, hvad du har brug for at vide om emnet. Men i det øjeblik du prøver at bygge noget alene, vil du straks sidde fast - ofte på meget enkle ting.

Hvorfor det? Fordi de små stykker information, der blev givet til dig i en tutorial, blev valgt af nogen, der oprettede den ved hjælp af deres egen forståelse af, hvad folk måske ledte efter. Og fordi det simpelthen er umuligt at dække alt i en tutorial.

Den eneste måde at virkelig se, hvilken viden du mangler, er at fortsætte med at opdage hullerne i den, mens du går. Du ved ikke, hvad du ikke ved. Så processen er: gå, slå en mur, arbejd igennem problemet, fortsæt og så videre.

Hvert nyt projekt skræmmer dig. Hvad skal man gøre?

Jeg ved ikke om dig, men med mig sker det hele tiden. Jeg afslutter et projekt og har det godt med mig selv og mine evner. Så i det øjeblik jeg læser brugerhistorierne til mit næste projekt, bliver jeg lammet af frygt.

Jeg tænker - hvordan kan jeg endda starte? Hvad skal jeg gøre først? Hvordan kunne jeg afslutte den forrige? Jeg ved ingenting! * Skift fuld paniktilstand *

Der er et par teknikker, som jeg bruger, når jeg kommer i den situation:

Først og fremmest skal du kigge på alle de tidligere projekter, du har bygget. De var også enormt skræmmende. På en eller anden måde fandt du en måde at løse problemerne på og bygge disse projekter ud.

At se tilbage på dine tidligere succeser, når du er i et lavt selvtillid, er en stærk metode til at trække dig sammen igen og gøre dig klar til en ny udfordring.

Nøglen er at se på projektet som et bundt af små problemer at løse. Vi bliver kun bange, fordi vi ser hele isbjerget i sin helhed, og det kommer mod os. Men hvis du bruger en teknik, vi talte om før - at nedbryde projektet til en grundlæggende struktur - vil det være meget let at komme i gang.

Glem perfektionisme

Du gør ikke dette for at skabe en slags et ideelt, fantastisk projekt med koden så smuk, at det får erfarne udviklere til at græde.

Målet er at gøre, hvad der er nødvendigt: Opfyld de brugerhistorier, du har fået (eller har oprettet til dig selv), så du kan lære mekanikken i, hvordan en bestemt kodningsteknik / sprogfunktion / ramme fungerer, det være sig API'er, funktioner, løfter , etc.

Gør så så meget som muligt for at forbedre projektet - både design, funktionalitet og kvaliteten af ​​koden.

Men tillad dig selv på et tidspunkt at stoppe. Det er ikke en international kunstkonkurrence. Det er dig og emnet, du vil lære. Lad ikke emnet skræmme dig så meget, at du ikke engang kan starte.

Mennesker, der har et ekstremt behov for at gøre alt perfekt, er normalt de mennesker, der absolut ikke får gjort noget.

Jeg kunne for eksempel ikke starte med denne artikel, hvis jeg brugte for meget tid på at bekymre mig om, om det ville være godt eller dårligt, endsige perfekt. Jeg vidste, at dette var et vigtigt emne, som mange mennesker er interesserede i, og at jeg havde brug for at skrive om det, jeg hidtil har opdaget, i håb om, at det ville hjælpe nogen og gøre deres koderejse let.

Hvis alt skulle være perfekt, ville der være noget sted at tegne i kunsten? Ufuldkommenheder er trods alt det, der gør dem unikke.

Lad din kreativitet flyde!

Føler ikke, at du skal gøre dit projekt nøjagtigt det samme som du ser på siden, hvis du arbejder ud fra en beskrivelse og et eksempel, du fandt online. Programmering er lige så meget kunst som videnskab.

Tag dette punkt endnu mere alvorligt, hvis du gør frontend.

Hvis du laver en tilfældig tilbudsmaskine, så lad citaterne komme fra din yndlingskarakter. Hvis du laver et spil, så lad lydene og designet være, hvad du vil have dem til at være!

Vær underlig. Slip alle de særheder og unikke forskelle i din personlighed ud. Slip dit sande selv løs.

Fokuser på at opfylde alle brugerhistorierne, men alt andet er helt op til dig.

Her er Zen Calculator, som jeg har bygget, som et eksempel på, hvad jeg taler om. Selvfølgelig kan du blive meget mere kreativ. Originalen er her, selvom den allerede er opdateret. Den version, jeg har arbejdet fra, mindede mere om en iPhone-regnemaskine-app.

Internettet - og programmering generelt - tillader os den frihed. Hold dig aldrig tilbage. Vær den, du vil være, gør hvad du vil, og lad det spildes til alle dele af dit liv, inklusive kodning.

Her er noget til inspiration og til at illustrere, hvad jeg mener:

Ting får kun deres smag, når du tilføjer dem personlighed! Sammenlign hyperrealistiske malere og Picasso. Kunne du skelne hyperrealistiske malere fra hinanden bare ved at se på deres arbejde? Jeg tvivler meget på det. Alligevel kender du et Picasso-maleri med det samme. Får dig til at tænke.

Giv efter for en distraktion - en gang imellem

Nogle gange er det okay at tage en lille pause fra projekterne, men for det skal du have nogle regler.

Ideelt set skal din distraktion tage mindre end en uge , det være sig et kursus eller en tutorial eller noget andet. Det skal være et specifikt emne, du vil lære, helst forbundet med noget, du har brug for at vide for at fortsætte med at forfine dit projekt.

Ellers er det helt fint for mig, hvis du læser programmeringsbøger eller ser kodende videoer under din pendling eller mens du venter et sted uden adgang til internettet.

Bare sørg for at når du er tilbage ved dit skrivebord (eller hvilket sted du koder fra - kan være en seng eller en sofa, ikke?), Er du tilbage til de rigtige ting. Det er din praksis .

Få feedback på dine projekter

Ud over at hjælpe dig med at udfylde hullerne i din viden, giver projekter dig også en artefakt, som du kan dele med verdenen og søge konstruktiv feedback.

Vær forsigtig med hvem du deler dine projekter med. Lad ikke de overkritiske mennesker komme ind. Prøv at finde rigtige udviklere eller mennesker, der også stadig lærer, men som allerede er lidt mere avancerede end du er. Bed dem om at gennemgå din kode og give deres feedback. Hvad kan du forbedre? Hvad fungerer der? Hvad gør det ikke?

Dette fremskynder din læring yderligere, fordi disse venlige mennesker hjælper dig med at afdække indsigt, som du ellers ikke havde fundet dig selv.

Jeg håber, jeg har overbevist dig nu, at opbygning af levende projekter er den mest effektive måde at lære at kode på.

Jeg har personligt bemærket, at de perioder, hvor jeg bygger - i modsætning til at se, læse eller gennemgå online kurser - er de perioder, hvor jeg lærer mest. Jeg håber, at din oplevelse vil være den samme som min.

Held og lykke! Du er velkommen til at tilføje dine råd i kommentarerne til denne artikel, og del også dine projekter her.

Tilfældig note: Jeg skrev denne artikel, mens jeg lyttede til Tron: Legacy Soundtrack.

Hvis du kunne lide denne artikel, skal du klikke på ❤ for at anbefale den her på Medium. Det ville betyde verden for mig! :)