Hogyan juthatunk fejlesztői munkához kevesebb, mint egy év alatt

Gyorsítsa fel a tanulást

Mi a legnehezebb annak, aki úgy dönt, hogy megtanítja magát kódolni? Az a tény, hogy általában nem tudják, mit kell megtanulni - milyen programozási nyelvet válasszon, hogyan közelítse meg a tanulást, mely erőforrások a legjobbak az időhatékonyság szempontjából.

Az egész a Google keresésével kezdődik ezeken a témákon, amelyek elkerülhetetlenül eljutnak az emberekhez a sok forrás egyikéhez, amely megtanítja az embereket a kódolásra. Ezeknek az erőforrásoknak a formátuma nagymértékben változik, és a józan ész azt mondja nekünk, hogy ki kell próbálnunk egy csomó különböző forrást, és ki kell választanunk azokat, amelyek a legjobban megfelelnek a tanulási stílusunknak. Oktatóanyagok egyes emberek számára, képernyőképernyők mások számára, cikkek egy másik csoport számára stb. Elég logikusnak tűnik, nem?

Hát nem. Ma meg akarlak győzni arról, hogy a tanulás egyik ilyen formája eljut oda, ahová gyorsabban akarsz lépni, mint bármely más. További késedelem nélkül hadd mondjam el, mi ez, és miért kell minden erőfeszítést erre összpontosítania.

Projektek építése

Fogadok, hogy látta, hogy jön.

Először is hadd tegyem el az útból néhány kifogását. Nem azt mondom, hogy az összes többi típusú tananyagot teljesen el kellene dobnia.

Minden oktatóanyagnak és képernyőkészüléknek megvan a maga helye a nap alatt, és ezt a cikkben tovább részletezem. Például néha a leghatékonyabb módja annak, hogy megismerkedjünk egy új technológiával vagy keretrendszerrel, ha elolvassunk egy cikket, vagy áttekintünk egy oktatóanyagot.

A probléma az, hogy hajlamosak vagyunk ragaszkodni (vagy legalábbis én teszem) azokhoz az erőforrásokhoz, amelyek a kényelmi zónánkban tartanak minket, még akkor is, ha ideje lenne valami saját cselekedetre. Túl kényelmes, fogyasztásra kész. Ez mindig nagyszerű érzéssel tölt el minket is, mert hé, itt vagyunk, tanulunk! Jobb? Ki mondhatja, hogy időt pazarolunk? Hogy merik? Kitöltjük ismereteink hiányosságait!

Veszélyes, hogy számunkra úgy tűnhet, hogy ezek az erőforrások a leghatékonyabb módszerek a tanulásra is. Emberként nagyjából mindent igazolhatunk, ami a komfortzónánkon belül tart. Már jó ideje ebben az illúzióban élek.

Kopog, kopog, Neo.

Projektek készítése ... mi újság van ebben az ötletben? Semmi, és mélyen belül mindannyian tudjuk, hogy ez időnk és energiánk legjobb felhasználása lenne, és gyorsabban elérnénk céljainkat. Akkor miért nem tesszük? Ellenállás.

Korábbi cikkemben beszéltem az Ellenállásról (olvassa el, ha nehezen küzd, vagy ha elakadt) már ott van) építésig.

Akárcsak a Mátrixban szereplő Neo, akinek választási lehetősége van a vörös és a kék tabletta között, visszatérhetünk illúzióinkhoz, miszerint az erőforrások, amelyek folyamatosan a kezünket fogják, a legjobb módja a tanulásnak, vagy a vörös pirulát, és fogadja be azt a valóságot, hogy csak akkor haladunk előre és növekedünk, ha kívül vagyunk a komfortzónánkon. (Ha még nem nézte a Mátrixot, akkor valószínűleg meg kell tennie.)

Íme néhány gondolatom arról, hogyan lehet megközelíteni ezeket a projekteket, amelyek félelmetesek lehetnek az induláshoz, valamint néhány tippet, amelyeket útközben felvettem.

Még kevesebb, mint egy évbe is telhet (mi?)

Ennek hátterében az áll, hogy személyes tapasztalataim alapján, a Free Code Camp Toronto csoportunk tagjaival folytatott beszélgetéseken és a tagok útjainak olvasásán a világ minden tájáról.

Úgy látom, hogy az emberek leggyakrabban képesek munkát találni, még mielőtt befejezik a Free Code Camp Front End Development tanúsítványát. Megépítik a szükséges projekteket, és elkezdik pályázni. Elég hamar kapnak egy ajánlatot a pénz kódolására.

Ha végigolvassa a Free Code Camp subbreddit-jét, rengeteg ilyen történet létezik.

Ne feledje, hogy a munkaerőpiacok városonként változnak. Például Torontóban rengeteg front end fejlesztői állásajánlat nyílik.

A Free Code Camp hivatalos álláspontja az, hogy teljesítse a tananyag 2080 óráját. Valószínűleg sokkal erősebb jelölt leszel (és magasabb fizetést fogsz parancsolni kihívást jelentőbb pozíciókban), ha így teszel.

Vegyünk egy kis matekot:

A Front Code Web Development tanúsítvány a Free Code Camp segítségével körülbelül 478 órát vesz igénybe. Van, aki gyorsabban teljesíti, de az ember felkészültségének szintjétől függően változik, ezért tartsuk meg a 478-at bázisként.

Mi kevesebb, mint egy év? Az érvelés érdekében 9 hónappal dolgozunk. 9 hónap * 30 nap 270 napot ad.

478 óra / 270 nap nagyjából napi 1,8 óra. Ez azt jelenti, hogy kevesebb, mint napi 2 órára tudunk kódolni, és 9 hónap alatt készen állunk a munkára.

Tudom, hogy néhány ember számára a menetrend nem tesz lehetővé napi két szabad órát, de a legtöbb számára lehetséges megtalálni őket. Másoknak ez egy kicsit tovább tarthat, de mindig vannak hétvégék és más módszerek az idő megtalálásához (vagy eléréséhez).

Ha tanácsot keres, hogyan lehet időt találni a kódolásra, forduljon hozzám bizalommal a Twitteren, és örömmel segítek.

Ennél valamivel tovább tartottam - körülbelül egy év és két hónap. Ez a cikk azoknak az okoknak az elemzése, amelyek miatt tovább tartott, mint kellett volna. Mindazokat a hibákat elkövettem, amelyekről a cikkben beszélek. Amikor tanácsot adok neked, ne feledd, hogy magamnak is adom ezt a tanácsot. Egy csónakban vagyunk.

Azelőtt vettem fel, hogy befejezhettem volna a Free Code Camp Front End tantervét, de pontosan tudom, hogy ez segít fejlesztőként növekedni abban, hogy visszatérhessek és befejezhessem ezeket a projekteket. Itt, a cikkben elhelyeztem linkeket a Codepen profilomra (kissé szégyellem magam!), És amikor ránézel, látni fogod, hogy még hosszú utam van. Szóval azt mondom - csináljuk együtt! Célomnak tartom, hogy befejezzem az összes Front End projektet, és prioritássá tegyem őket minden más, a közeljövőben megtanult kóddal kapcsolatos dologgal szemben.

Ez a cikk nekem és neked szól - hogy átvészeljük a kellemetlenségeket és optimalizáljuk a tanulásunkat, hogy gyorsabban eljussunk oda, ahol szeretnénk lenni!

Győződjön meg róla, hogy áttekintette az alapokat

Határozottan hiszem, hogy a tanulás legelején feltétlenül oktatóanyagokat és interaktív online forrásokat kell használnia, hogy megismerkedjen a HTML, CSS, JavaScript szintaxisával, megtanuljon programozottan gondolkodni, és kényelmessé váljon az alapvető, alapvető dolgokban.

Az a kísérlet, hogy ezeket az ismeretek nélkül azonnal felépítsék a projekteket, túl frusztráló lenne. Ügyeljen arra, hogy ne töltsön túl sok időt ebben a szakaszban, mivel ezt nagyon könnyű megtenni.

Amikor HTML / CSS / JS-t tanultam, hasonló témákat tanultam különböző forrásokból, és arra gondoltam, hogy valahogy ez kitölti a tudásom összes hiányosságát. Valóban hiányosságokat pótolt, de valamikor rájöttem, hogy mankóként használtam ezeket az erőforrásokat, hogy megakadályozzam, hogy új, izgalmasabb, de kissé ijesztőbb dolgokra térjek át. Ne ragadjon bele a végtelen ciklusokba (valószínűleg egy ideig?;) A már ismert információk áttekintése és felülvizsgálata.

Ne engedjen a racionalizálásnak

Amikor elkezd projekteket létrehozni, elkerülhetetlenül elakad. Ha ragaszkodsz hozzá, egy idő után legyőzöd a korlátot, de nem sokkal később megüt egy másikat. Ez nem lehetőség, és mindenkivel előfordul.

Ilyen pillanatokban testünk minden része sikoltozik - tegyünk valami mást, meneküljünk innen, ettől kényelmetlenül érzem magam, ezt később kezelhetem, ha többet tudok, visszatérek rá, és így tovább. Tehát szünetet tartunk.

Attól tartunk azonban, hogy a szünetünk megnyúlik, és továbbra is egyre kevesebbet kódolunk és dobunk. Annak érdekében, hogy ez ne történjen meg, de továbbra is megtartjuk a „döntésünket”, miszerint nem fogunk dolgozni a projekten, úgy döntünk, hogy egyelőre valamilyen oktatóanyagot vagy online tanfolyamot dolgozunk majd fel.

Nagyon könnyű racionalizálni magad a teremtésből. Senki nem fogja megmondani, hogy nem tanulsz meg kódolni vagy bármilyen módon kritizálni. Csak te tudod felismerni, mi történik valójában (félelem, kockázatkerülés, ellenállás), és dönthetsz úgy, hogy ragaszkodsz a projekt munkájához.

Higgye el, az összes fal összeomlik, ha elég hosszú ideig robbantja őket. Gondoljon azokra az emberekre, akik a nap folyamán úgy tanultak idegen nyelveket, hogy ugyanazon könyvből két példányban készültek anyanyelvükön és célnyelven. Hogy csinálták? Elég sokáig ragaszkodtak hozzá.

Ne kezdje a BIG IDEA-val

Elképesztő, hogy már megvan, de van itt még néhány olyan szempont, amely meggondolhatja magát. Azért hozom fel ezt a pontot, mert folyamatosan hallom ezt az emberektől: „Szeretnék létrehozni egy online alkalmazást, amely lehetővé teszi az emberek számára, hogy fiókokat hozzanak létre háziállataik számára, feltölthessenek fényképeket, nyomon kövessék a helyüket és még sok minden mást. Nemrég kezdtem el megtanulni a kódolást, és már dolgozom az ötletem kidolgozásán. ” Ez arra késztet, hogy “Whoa whoa whoa” váljak.

Könnyen látom, hogy ebben a helyzetben történik, hogy az embert túlságosan lekötik az ötlet, nagyon lelkesen kezdik és lassan építik fel, de az idő múlásával a tanulás nem képes lépést tartani a projekt követelményeivel, és úgy érzi húzva, mindig az eszük végén, befejezetlen.

A legrosszabb, ami ebben a helyzetben történhet, az, hogy az ember feladja a projektet, és ezzel együtt lemond a kódolásról is.

Azt javaslom, hogy kezdjen egyszerű projektekkel, és amikor mindegyiket befejezi, a teljesítmény érzését kapja, és jobban megérti, hogyan lehet egy nagyobb projektet felépíteni.

Képzelje el, hogy író volt, és volt egy ötlete életének egyik fő könyvéhez, és azonnal elkezdte írni. Valószínűleg 3-4-szer át kellene írnia az egészet, hogy megfelelő minőségű színvonalat érjen el, miközben kezdheti apró történetek írásával, visszajelzéseket kaphat, javíthatja az írást, és akkor fordulhat Moby Dickjéhez, amikor valóban készen áll.

Hol lehet ötleteket meríteni a projektekhez

A legjobb hely, amit ismerek, a Free Code Camp. Ezt használtam, miután teljesen beragadtam. A kódolási utam elején megkérdeztem az összes ismert fejlesztőt (offline és online egyaránt), hogy mi legyen az első projektem. Nem kölyök, amikor azt mondom (meglepetés meglepetés), mind azt mondták, hogy tennivalóknak kell lennie. Őszintén azt gondolom, hogy ha folyamatosan elkészítjük ezeket a tennivalók listájával készült alkalmazásokat, hamarosan túlzsúfolják az egész internetet.

A Free Code Camp bizonyos értelemben segített nekem abban, hogy felajánlotta az izgalmas projektek listáját, egyre növekvő nehézségekkel sorakozva. Egy másik nagyszerű dolog, hogy mindegyiket kifejezetten egy adott téma megtanítására tervezték, például: A Tribute oldal tesztre viszi a HTML / CSS készségeit, a Helyi idő megjelenítése megmutatja az API-kkal való munkát, a JavaScript felépítését A számológép nyilvánvalóan javítja a JS készségeit stb.

Ez a legerősebb kiindulópont, amellyel építkezni tudok. Az összes befejezett projekt kapcsán visszajelzést kaphat a közösségtől, valamint megnézheti, hogy mások hogyan fordultak hozzájuk (miután megépítetted a sajátodat, ne csalj!) ”Vagy valami ilyesmi.

Először strukturálja a projektjét

Mielőtt elkezdené építkezni, írja le, mit szeretne csinálni. Írjon konkrét felhasználói történeteket, például: „A felhasználók hangot játszhatnak, amikor rákattintanak az audiolejátszó gombra”, „A felhasználók bejelentkezhetnek e-mailjükkel és jelszavukkal, valamint csak a Facebook segítségével”.

A kódnak alapszerkezettel is kell rendelkeznie, mielőtt elkezdené írni. Írjon pszeudokódban - alapvetően csak szavakkal magyarázza el, hogy az alkalmazás egyes részei vagy a projektkód mit fog tenni.

Alap példa:

// Amikor a felhasználó megnyit egy oldalt, ragadja meg a helyét

// Küldjön egy kérést az időjárás API webhelyének a helyével

// Adatok fogadása

// A fokozatok megjelenítése az oldalon

// Az oldal háttérképének módosítása az aktuális időjárás tükrözése érdekében

Ne vigyük túlzásba, nem kell minden apró dolgot először pszeudokódban írni, de a fő részeket el kell helyezni.

A legjobb példa, amellyel tudok szolgálni: emlékszem, amikor esszét írt az iskolában, először fel kellett strukturálnia őket, például egy intro a véleményével a témában, 3 fő pont a véleményed alátámasztására és egy következtetés .

Ez segít előrejelezni a lehetséges problémákat és javítja a kód minőségét.

Nem baj, ha elakad

Mint már korábban említettem, rendben van, hogy elakad. Ez nem azt jelenti, hogy hülyék vagyunk, hanem azt, hogy még nem tudjuk. Mindig megtapasztalhatja az elakadás pillanatait: nemcsak akkor, amikor tanul, hanem a munkahelyén is.

Minél hamarabb kényelmesen érzi magát, annál jobb. Sokkal gyorsabb lesz a fejlődésed. Maga a programozás kreatív problémamegoldás. Ha nincs olyan probléma, amelyet nehezen tudna megoldani, az azt jelenti, hogy biztonságosan játszik. Ne lépkedjen tovább a sekély vízben, és merüljön el!

Legfőképpen, és még egyszer megismétlem, ne gondolja magát hülyének. Tudom, hogy ezekben a pillanatokban könnyű megtenni. Gyakran beszélek olyan emberekkel, akik könnyedén átélték a Free Code Camp HTML / CSS / JS részét, napi 30–40 elemet kiütöttek, majd eljutnak az alapvető és a köztes algoritmusokhoz, és megtudják, hogy csak 1– Napi 5, ezért arra a következtetésre jutnak, hogy elakadtak, és hogy hülyék, nem elég jók, vagy nem fejlesztőknek szánják őket.

Én is ugyanígy voltam, úgy éreztem, hogy vannak olyan emberek, akik valószínűleg csak repülnek ezen a szakaszon, és rosszul éreztem magam és a fejlődésemet. Most már jobban tudom.

Amit itt akarok mondani, meg kell tanulnia:

Legyen a feje fölött

Meg kell találnia azt a projekt nehézségi szintet, amely a közepén tart a „könnyű dolgok” és a „még mindig túl nehéz dolgok” között.

Sokat beszéltem azokról az okokról, amelyek miatt veszélyes ugyanazon anyag folyamatos felülvizsgálata és újratanulása (a könnyű dolgok), szóval beszéljünk az egyenlet ellentétes oldaláról: a nehéz dolgokról.

Az az általános szabály, amikor valami nehéz dologhoz közeledsz - amihez úgy gondolod, hogy nem tudsz megtenni - először az kell, hogy megpróbáld megtenni.

Indítsa el az alapstruktúrából, és próbálja meg kódolni. Ha több mint három napig ragaszkodik ugyanarra a dologra, akkor koncentráljon rá, hagyja el egy ideig, és találjon hasonló - de kissé könnyebb - tennivalókat.

Azt tapasztalom, hogy miután ezt megtettem, a tudatalattim továbbra is a probléma megoldására összpontosít, amin elakadtam. Ezeket a véletlenszerű ötleteket kapom arról, hogyan oldhatnám meg, amikor egyszerű dolgokat csinálok - például zuhanyozom vagy mosogatok -, hirtelen eltalál!

Néha pontosan így működik. Néha nem. De a legfontosabb tanács itt az: mindig válasszon valamit, ami kissé kényelmetlen lesz . Bármi más nem éri meg az idejét.

ellenálló képesség

Szeretném megosztani veletek az egyik kedvenc szavamat:

Rugalmasság - a rendszer azon képessége, hogy elviselje a zavarokat összeomlás nélkül, ellenálljon a sokkoknak, szükség esetén újjáépítse magát, és ha lehetséges, fejlessze önmagát.

Ez egy csodálatos tulajdonság, amelyet Önnek programozóként (és az életben sikerre vágyóként) fejlesztenie kell magában. Készüljön fel minden problémára, minden kihívásra, minden kritikára a munkájával, a terveivel, a megoldásaival és bármi mással kapcsolatban, amit még azelőtt megtehetne.

Félsz a színpadon állástól? Iratkozzon fel, hogy megtanítsa a helyi közösség tagjainak a webfejlesztés alapjait, vagy regisztráljon beszédre egy konferencián / technikai eseményen.

Csalódott abban, hogy hogyan sikerült az interjúja - és hogy nem vettek fel utána? Attól félsz, hogy késő elkezdeni megtanulni a kódolást? Nem elégedett a most befejezett projekttel?

Átfogalmazza mindezt : mit tanulhat a tapasztalatból, hogy legközelebb jobb legyen? Hogyan lehet gyengeségeit erősséggé alakítani?

Például aggódhat, hogy túl későn érkezik a kódolás, miután X évek óta más karrier utat választott. Átfogalmazza, hogy gondolatában más perspektíván és érettségen gondolkodva be fogja hozni azt az iparágat, amelynek nagy szüksége van érettebb (pszichológiailag) és sokszínűbb háttérrel rendelkező emberekre? Gazdagabbá teszi a technológiai ipart azzal a döntéssel, hogy belemegy!

Ha hallasz egy hangot benned, amely azt mondja: „nem festhetsz”, akkor mindenképpen fest, és ez a hang elnémul. - Vincent Van Gogh

Amit a rugalmasságának növelése érdekében tudok ajánlani, az a három könyv:

  1. Seneca „Levelei egy sztoikusból”
  2. Ryan Holiday „Az akadály az út”
  3. Steven Pressfield “Turning Pro”

Napi időhöz kötött cél kitűzése

A gyorsabb előrehaladás érdekében minden nap dolgozni kell a projektjein. Ez a rész csak józan ész. Van azonban néhány további szempont, amelyet érdemes szem előtt tartania.

Ahelyett, hogy kitűzne egy kimeneti célt („Ma befejezem ezt a funkciót vagy azt a részt”), állítson be egy meghatározott időszakot, amelyet minden nap kódolással tölt. Ne csináljon napi 30 percnél vagy egy óránál többet.

Tudom, hogy el akarod vállalni a kódolást napi 3 órában, és megpróbálsz betartani. Ez működik, de csak olyan sokáig, amíg az élet játékba nem lép. Ésszerű határidővel - például napi 30 percig - mindig tudni fogja, hogy ez megtehető, és hogy napi fél órája van tartalékára a kódolásnak, különösen, ha a fő célja a kódolás megtanulása. Sőt, azon kapja magát, hogy bizonyos napokon többet kódol, és ez nagyszerű érzés lesz, mert aznapi kvótáját már teljesítette.

Ez az időkorlát inkább pszichológiai trükk, amely az agyunk bekötésének módja miatt működik. Emlékszel arra az időre, amikor volt egy nagy projekted, amelyet el kellett kezdened, de folyamatosan halogattad és halogattad, amíg csak elegendő időd volt arra, hogy a határidő lejárta előtt befejezd? Jól tetted, de előtte mindig stresszes volt. Ezután tegye hozzá azt a tényt, hogy senki sem szab határidőt a fejlesztővé váláshoz. Vagyis senki, csak te.

Mi történik, ha kitűzünk egy kimeneti célt, az az, hogy nem tudjuk megbecsülni, mennyi időbe telik ennek vagy ennek a funkciónak a befejezése. És gyakran előfordul, hogy végül nem teljesítjük azt, amit aznapra kitűztünk. Ettől rettenetesen érezzük magunkat, és csökken a vágy, hogy másnap leüljünk és kódoljunk.

Időben korlátozott napi céllal minden nap előrelépést fog elérni. Kit érdekel, ha még nem fejezte be azt a speciális funkciót, amelyet ma be akart szerelni? Haladtál! Te megjelentél. Ez vezet előre.

Egy másik nagyszerű bónusz, ha leülsz és elkezdesz kódolni, az ötletek és a megoldások mintha a semmiből fakadnának (hasonlóan, mint egy cikkhez, mi? :). Sokkal könnyebb lesz rávenni magát arra, hogy üljön le és kódoljon, ha irreális elvárásokat és félelmeket kap az útból.

A kód másolása időt pazarol

A projekt építése során, akár a legelején - amikor nem tudja, honnan induljon, vagy egy későbbi szakaszban, amikor olyan problémába ütközik, amelyet nem tud könnyen megoldani -, erős vágyat fog átélni a projekt forráskódjánál, hogy lássa, hogyan történik. Ésszerűbbé teszi, hogy ez azonnal megérteni fogja a kódot, és ez azt jelenti, hogy megtanulta és beolvasztotta. Messze van tőle.

Ne másoljon egész projekteket, és ne szabja testre őket. Ne vegye be a kód egy részét. Ne is vegyen belőle darabokat.

Projekteknél - elsősorban ne nézd meg a kódot. Azokkal a dolgokkal, amelyeket utánanéztél a Stack Overflow-nak, meg ilyeneket, nézd meg, elemezd, értsd meg, de aztán kódold magad a semmiből. Látni fogja, hogy nehéz maga írni, még akkor is, ha csak meglátta az egészet.

Így különbözik a szándékos gyakorlat a szokásos gyakorlattól (ismétlés). A 10 000 szabály fő fogása az, hogy a gyakorlatnak szándékosnak kell lennie. A sablonok és a kész megoldások követése nem vezet sehová. Valaki valószínűleg képes megírni egy Python-szkriptet, amely helyettesít téged abban, amit csinálsz, ha így jársz. Figyeljen arra, ami nehéznek tűnik számodra.

Egy másik témán kívüli ötlet az, hogy ha egy adott témával küzdesz, próbáld meg tanítani másoknak, vagy csak elmagyarázni nekik, ahogyan érted. Az eredmények következnek mind Ön, mind a tanulók számára.

A kód másolása elrabolja a lehetőséget, hogy megtanulja saját maga megcsinálni, és ez semmiképpen sem jobb, mint egy oktatóanyag elvégzése. Igen, ott van a megoldás. Igen, elviheti, ha akarja. De mi értelme van? Szeretne valakit lenyűgözni a projekt felépítésének sebességével? Vagy megpróbálja elkerülni azokat a nehéz problémákat, amelyek megoldása némi időt vesz igénybe?

Bármi is legyen az oka - ez csak egy újabb út a meleg kényelem felé, ahonnan megpróbálunk elmenekülni. Tegye az ellenkezőjét. Fuss a kellemetlenség felé.

Az egyetlen alkalom, hogy belenézel mások kódjába, miután befejezted a projektet. Akkor nézz, amennyit csak akarsz, elemezd és tanulj belőle.

Minden nehéz probléma, amit megold, ugrásszerűen növekszik.

Ne terjessze erőfeszítéseit

Nagyon bűnös vagyok ebben, és ez valójában egy tanács, amelyet inkább magamnak írok, mint bárki másnak (sajnálom!). Amikor elkezd dolgozni egy projekten, és az általam említett falakra ütközik, akkor kísértésbe esik, hogy ezt a projektet visszatartja, és újat kezdjen.

Az elején mindig nagyszerű érzés, amíg a falnak nem ütközik a második projekttel. Akkor két befejezetlen projekt lesz a kezedben. Ez megismétlődik újra és újra, ha engedi.

A megoldás itt az, hogy egyszerre 2 projektre szorítkozik. Ha egyszer elakad, töltsön egy kis időt a kitalálásával. De ha pillanatnyilag feltörhetetlennek tűnik, akkor lépjen a másik projektre. A legfontosabb, hogy ne kezdjünk el harmadikat, mert onnan csúszós lejtő.

Mindig próbáljon meg mindent megtenni annak érdekében, hogy a tanulás útján maradjon. Ha eleged érzed magad, vagy csak unod, amit éppen csinálsz, tarts egy kis szünetet, igazodj és térj vissza ehhez. Ne mondjon le teljesen a kódolásról.

Ezért mindig azt javaslom, hogy legyen egy kis csónakázó helyiség, legyen az ideiglenes figyelemelterelés egy másik tanulási erőforrás formájában (egy hétre korlátozva), vagy ebben az esetben két projekt egy helyett.

A portfólió az, ami felveszi

Nagyon nehéz egy felvételi menedzsernek vagy egy mérnöknek értékelnie a készségeit kizárólag az önéletrajzában leírtak alapján. „Ismerem a JavaScript-et! (és 4 éves tapasztalattal rendelkezik). ” "Mutasd meg nekem!" (Nagyon le kell állnom a Mátrix hivatkozásokkal).

Az összes projekt, amelyet felépít és online tesz közzé, az Ön végleges önéletrajzát tartalmazza. Bárki megnézheti és meggyőződhet arról, hogy valóban tudja, mit csinál.

Ne ijedj meg, de ez nem jelenti azt, hogy a kódodnak ideálisnak kell lennie ahhoz, hogy akár téged is figyelembe vegyenek. Ezek a projektek segítenek annak, akinek az a feladata, hogy interjút készítsen Önnel, hogy felmérje a készség szintjét.

Nem kell tapasztalatokat készítenie az Ön szintjénél sokkal magasabb szintű interjúkról, mert néhány HR-es személy egy bizonyos kulcsszót talált az önéletrajzában. Munkáltatójának elvárásai jobban megfelelnek a tényleges képességeinek.

Az online munka pozitív előnyei:

  • a munkaadók látják, hogy tudod, mit csinálsz
  • látják, hogy Ön folyamatosan dolgozik a képességeinek fejlesztésén
  • látják, hogy valójában fejlesztő vagy, és elég bátor vagy ahhoz, hogy a munkádat mindenki online láthassa.

Személyes tapasztalataim alapján, és amit a torontói Free Code Camp csoport tagjaitól hallok, az az, hogy a kódolási munka megtalálásában a legfontosabb tényező a projektek portfóliója volt.

Az interjúkon jobban jársz

Az interjúk során valószínűleg kap egy valós életben használható webalkalmazást vagy oldalt, amelyet fel kell építenie, vagy megoldandó problémát kap.

Gyakran ezeknél a problémáknál az a személy, aki felveszi a munkát, azt szeretné megtudni, hogyan gondolkodik egy probléma megoldásán keresztül. Nem mindig akarják, hogy az ideális megoldást hozza létre. Néha olyan problémákat adnak, amelyeket nem lehet megoldani, csak hogy lássák, mit fognak tenni. Nagyon sok ilyen gyakorlatot fog kapni a projektekkel: mindegyik meg lesz töltve ezekkel a mini problémákkal.

Ami a valós dolgokat illeti, amelyeket fel lehet adni az elkészítéséhez, azok változhatnak és változhatnak. Itt van valami, amit az interjú során fel kellett építenem jelenlegi pozíciómra. Tudom, hogy a kód nem olyan nagy, de ennek képet kell adnia arról, hogy mire számíthat. Az interjú napján csak azért tudtam befejezni, mert korábban volt tapasztalatom olyan dolgok felépítéséhez, mint egy időjárás-alkalmazás és egy számológép a Free Code Camp segítségével.

Meg fogja ismerni a tudás valódi hiányosságait

Itt trükkökkel játszanak az oktatóanyagok és hasonlók. Úgy érzik, hogy amikor befejezte őket, mindent áttekintett, amit tudnia kell a témáról. De abban a pillanatban, amikor megpróbál saját maga építeni valamit, azonnal elakad - gyakran nagyon egyszerű dolgokon.

Miert van az? Mivel az oktatóanyagban kapott információ darabjait és darabjait olyan személy választotta, aki saját ismerete alapján hozta létre, hogy mit kereshetnek az emberek. És mivel egyszerűen lehetetlen mindent bemutatni egy oktatóanyagban.

Az egyetlen módja annak, hogy valóban lássa, milyen ismeretek hiányoznak, az az, hogy menet közben folyamatosan fedezze fel benne a hiányosságokat. Nem tudod, amit nem tudsz. Tehát a folyamat: menj, ütközz falnak, dolgozd át a problémát, folytasd stb.

Minden új projekt megijeszt. Mit kell tenni?

Nem tudok rólad, de velem ez mindig előfordul. Befejezek egy projektet, és remekül érzem magam és a képességeim. Aztán abban a percben, amikor elolvastam a következő projektem felhasználói történeteit, megbénul a félelem.

Gondolom magam - hogyan is kezdhetném? Mit tegyek először? Hogyan tudtam befejezni az előzőt? Semmit sem tudok! * Teljes pánik mód váltása *

Van néhány technika, amelyet használok, amikor ebbe a helyzetbe kerülök:

Először vessen egy pillantást az összes korábbi projektre, amelyet épített. Hatalmasan megfélemlítettek is. Valahogy megtalálta a módját a problémák megoldására és a projektek kiépítésére.

Visszatekintés korábbi sikereire, amikor önbizalomhiányban van, hatékony módszer arra, hogy visszahúzza magát, és felkészülhessen egy új kihívásra.

A legfontosabb az, hogy a projektre úgy gondoljunk, mint egy apró megoldandó problémára. Csak attól félünk, hogy az egész jéghegyet teljes egészében látjuk, és felénk jön. Azonban, ha olyan technikát használ, amelyről korábban beszéltünk - a projekt lebontása alapvető struktúrára -, akkor nagyon könnyű lesz elkezdeni.

Felejtsd el a perfekcionizmust

Ezt nem azért csinálja, hogy valamilyen ideális, csodálatos projektet hozzon létre, amelynek kódja olyan szép, hogy a tapasztalt fejlesztőket sírásra készteti.

A cél az, hogy megtegyük a szükségeseket: teljesítsük azokat a felhasználói történeteket, amelyeket kaptál (vagy magad készítettél), így megtanulhatod egy bizonyos kódolási technika / nyelvi funkció / keretrendszer működésének mechanikáját, legyen szó API-ról, funkcióról, ígéretről stb.

Ezután tegyen meg mindent a projekt fejlesztése érdekében - mind a tervezés, mind a funkcionalitás, mind a kód minősége szempontjából.

De valamikor hagyd, hogy megállj. Ez nem egy nemzetközi művészeti verseny. Te vagy az a téma, amelyet meg akarsz tanulni. Ne hagyja, hogy a téma annyira megijesszen, hogy el sem tudja kezdeni.

Azok az emberek, akiknek rendkívüli szükségük van mindenre tökéletesen, általában azok, akik semmit sem csinálnak.

Nem tudnám elindítani például ezt a cikket, ha túl sok időt töltenék azzal, hogy aggódjak-e azon, hogy jó vagy rossz lesz-e, nemhogy tökéletes. Tudtam, hogy ez egy fontos téma, amelyet sok ember érdekel, és hogy írnom kell arról, amit eddig felfedeztem, abban a reményben, hogy ez segít valakinek és megkönnyíti a kódolási útját.

Ha mindennek tökéletesnek kell lennie, lenne-e helye a művészet vázlatainak? A tökéletlenség az, ami végül is egyedivé teszi őket.

Hagyja, hogy a kreativitás folyjon!

Ne érezze úgy, hogy pontosan ugyanolyan projektet kell készítenie, mint amit az oldalon lát, ha az interneten talált leírás és példa alapján dolgozik. A programozás ugyanolyan művészet, mint tudomány.

Vegyük ezt a pontot még komolyabban, ha elöljárót csinálunk.

Ha véletlenszerű idézőgépet készít, akkor az idézetek a kedvenc karakteréből származzanak. Ha játékot készít, akkor legyenek a hangok és a dizájn olyanok, amilyeneket csak akarnak!

Légy furcsa. Engedje ki személyiségének minden furcsaságát és egyedi különbségét. Engedje szabadjára valódi önmagát.

Összpontosítson az összes felhasználói történet teljesítésére, de minden más teljesen rajtad múlik.

Itt van a Zen kalkulátor, amelyet építettem, példaként arra, amiről beszélek. Természetesen sokkal kreatívabb lehet. Az eredeti itt van, bár már frissítették. Az a verzió, amelyen dolgoztam, inkább egy iPhone számológép-alkalmazásra emlékeztetett.

Az internet - és általában a programozás - lehetővé teszi számunkra ezt a szabadságot. Soha ne fogd vissza magad. Legyen bárki, aki akarsz, tedd, amit csak akarsz, és hagyd, hogy ez életed minden részébe átáramoljon, beleértve a kódolást is.

Itt van valami inspiráció és annak illusztrálása, amire gondolok:

A dolgok csak akkor kapják meg az ízüket, ha személyiséget adnak hozzájuk! Hasonlítsa össze a hiperrealisztikus festőket és Picasso-t. Meg tudná különböztetni a hiperrealisztikus festőket, csupán a munkájuk megnézésével? Erősen kétlem. Mégis tudna egy Picasso-festményt azonnal. Gondolkodásra készteti.

Engedjen egy figyelemelterelésnek - egyszer-egyszer

Néha rendben van egy kis szünet a projektekben, de ehhez meg kell szabni néhány szabályt.

Ideális esetben a figyelemelterelésnek kevesebb, mint egy hétig kell tartania, legyen szó tanfolyamról vagy bemutatóról, vagy bármi másról. Ennek egy meghatározott tantárgynak kell lennie, amelyet meg akar tanulni, lehetőleg kapcsolódjon valamihez, amelyet tudnia kell a projekt finomításának folytatásához.

Egyébként velem teljesen rendben van, ha programozási könyveket olvas vagy kódoló videókat néz az ingázás közben, vagy ha valahol vár, ahol nincs internet-hozzáférés.

Csak győződjön meg arról, hogy amikor visszatért az íróasztalához (vagy bármelyik helyre, ahonnan kódolt - lehet ágy vagy kanapé, igaz?), Akkor visszatér az igazi dolgokhoz. Ez a te gyakorlatod .

Kérjen visszajelzést a projektjeiről

Amellett, hogy segítenek kitölteni ismeretei hiányosságait, a projektek egy olyan tárgyat is adnak, amelyet megoszthat a világgal, és konstruktív visszajelzést kér.

Legyen óvatos, kivel osztja meg projektjeit. Ne engedje be a túlkritikus embereket. Próbáljon meg valódi fejlesztőket vagy olyan embereket találni, akik szintén tanulnak, de már valamivel előrébb vannak, mint Ön. Kérje meg őket, hogy nézzék át a kódot, és adják meg visszajelzésüket. Mit javíthat? Mi működik? Mi nem?

Ez tovább fogja gyorsítani a tanulást, mert ezek a kedves emberek segítenek olyan felismerések felfedezésében, amelyeket egyébként nem talált volna magának.

Remélem, mára meggyőztelek benneteket arról, hogy az élő projektek építése a leghatékonyabb módszer a kódolás megtanulásához.

Személyesen vettem észre, hogy azok az időszakok, amikor építek - szemben az online tanfolyamok nézésével, olvasásával vagy azokon való részvételével - azok az időszakok, amikor a legtöbbet tanulom. Remélem, hogy a tapasztalata megegyezik az enyémmel.

Sok szerencsét! Adja meg bátran tanácsát a cikk megjegyzésében, és itt is ossza meg projektjeit.

Véletlen megjegyzés: Ezt a cikket a Tron: Legacy Soundtrack hallgatása közben írtam.

Ha tetszett ez a cikk, kattintson agombra , hogy itt ajánlhassa a közepes oldalon. Számomra a világot jelentené! :)