Как да получите работа за програмист за по-малко от година

Ускорете обучението си

Коя е най-трудната част за някой, който реши да се научи да кодира? Фактът, че те обикновено не знаят какво да учат - какъв език за програмиране да изберат, как да подходят към ученето, кои ресурси са най-добри по отношение на ефективността на времето.

Всичко започва с търсенията в Google по тези теми, които неизбежно водят хората до един от многото ресурси, които учат хората да кодират. Форматът на тези ресурси варира значително и здравият разум ни подсказва, че трябва да опитаме куп различни ресурси и да изберем тези, които най-добре отговарят на нашия стил на обучение. Уроци за някои хора, екранни предавания за други, статии за още една група и т.н. Изглежда доста логично, нали?

Ами ... не. Днес искам да ви убедя, че един от тези формати на обучение ще ви отведе там, където искате да бъдете по-бързи от всеки друг. Без допълнително забавяне, позволете ми да ви кажа какво е и защо трябва да съсредоточите всичките си усилия върху него.

Изграждане на проекти

Обзалагам се, че видяхте това да идва.

Първо, позволете ми да премахна някои от вашите възражения. Не казвам, че трябва да изоставите всички останали видове учебни ресурси.

Всички уроци и екранни предавания имат своето място под слънцето и ще разгледам това по-нататък в статията. Например, понякога най-ефективният начин да се запознаете с нова технология или рамка може да бъде четене на статия или преминаване през урок.

Проблемът е, че сме склонни да се придържаме (или поне аз) към ресурсите, които ни държат в зоната ни на комфорт, дори когато е време да направим нещо свое. Просто е прекалено удобен, готов за консумация. Освен това винаги ни кара да се чувстваме страхотно, защото хей, ето ни, учим се! Нали? Кой може да каже, че губим време? Как смеят? Попълваме пропуските в нашите знания!

Опасно е, че може да ни се струва, че тези ресурси са и най-ефективният начин за учене. Като хора можем да оправдаем почти всичко, което ни държи в зоната ни на комфорт. Живея в тази илюзия от доста време.

Почукай, Почукай, Нео.

Създаване на проекти ... какво ново има тази идея? Нищо, а дълбоко в себе си всички знаем, че това би било най-доброто използване на нашето време и енергия и ще ни отведе по-бързо до целите ни. И така, защо не го направим? Съпротива.

Говорих за съпротивата в предишната ми статия (прочетете я, ако се борите или се чувствате заседнал), така че позволете ми да обясня защо съм толкова категоричен по тази тема и нека ви убедя да изместите фокуса си (освен ако не е вече там) към сградата.

Подобно на Нео в Матрицата, на когото е даден избор между червеното хапче и синьото хапче, ние можем да се върнем към нашите илюзии, че ресурсите, които през цялото време ни държат за ръка, са най-добрият начин да научим, или можем да вземем червеното хапче и прегърнете реалността, че ние се движим напред и растеме само когато сме извън зоната си на комфорт. (Ако не сте гледали Матрицата, вероятно трябва да го направите.)

Ето някои от мислите ми за това как да подходим към тези проекти, които могат да бъдат смущаващи за започване, както и някои съвети, които съм събрал по пътя си.

Може да ви отнеме дори по-малко от година (Какво?)

Мотивите зад това се основават на личния ми опит, на разговора с членовете на нашата група за свободен кодекс в Торонто и на четенето за пътуванията на членовете по целия свят.

Откривам, че най-често хората успяват да си намерят работа дори преди да завършат сертифицирането за разработка на Front Code Camp. Те изграждат необходимите проекти и започват да кандидатстват. Скоро те получават предложение да кодират пари.

Ако прочетете subreddit на Free Code Camp, ще откриете, че има много подобни истории.

Имайте предвид, че пазарите на работа варират в различните градове. Например в Торонто има много работни места за разработчици от предния край.

Официалната позиция на Free Code Camp е, че трябва да попълните всички 2080 часа от учебната програма. Вероятно ще бъдете много по-силен кандидат (и ще командвате по-високи заплати на по-предизвикателни позиции), ако го направите.

Нека направим малко математика:

Сертификатът за уеб разработка на Front End с Free Code Camp отнема около 478 часа. Има хора, които го изпълняват по-бързо, но то варира в зависимост от нивото на подготовка на човека, така че нека запазим 478 като наша база.

Какво е по-малко от година? За аргумента ще работим с 9 месеца. 9 месеца * 30 дни ни дават 270 дни.

478 часа / 270 дни е приблизително 1,8 часа на ден. Това означава, че можем да кодираме по-малко от 2 часа на ден и след 9 месеца можем да станем готови за работа.

Знам, че за някои хора графикът не позволява два свободни часа на ден, но за повечето е възможно да ги намерят. За други може да отнеме малко повече време, но винаги има почивни дни и други начини да намерите (или да отделите) времето.

Ако търсите съвет как да намерите време за кодиране, не се колебайте да се свържете с мен в Twitter и ще се радвам да помогна.

Отне ми малко повече време - около една година и два месеца. Тази статия е анализ на причините, поради които ми отне повече време, отколкото би трябвало. Направих всички грешки, за които говоря в статията. Когато ви давам съвет, не забравяйте, че давам този съвет и на себе си. Ние сме в една лодка.

Наех се, преди да успея да завърша учебната програма на Free Code Camp Front End, но със сигурност знам, че това ще ми помогне да израсна като разработчик, за да се върна и да завърша тези проекти. Тук там в статията съм поставил връзки към моя профил в Codepen (малко ме е срам от него!) И когато го погледнете, ще видите, че все още ми предстои дълъг път. Затова казвам - нека го направим заедно! Целта ми е да завърша всички проекти на Front End и да ги направя мой приоритет пред всичко друго, свързано с кода, което науча в близко бъдеще.

Тази статия е за мен и за вас - за да ни накара да преодолеем дискомфорта и да оптимизираме обучението си, за да можем да стигнем там, където искаме да бъдем по-бързи!

Уверете се, че сте покрили основите си

Силно вярвам, че в самото начало на обучението си определено трябва да използвате уроци и интерактивни онлайн ресурси, за да се запознаете със синтаксиса на HTML, CSS, JavaScript, да се научите да мислите програмно и да се чувствате комфортно с основните, основни неща.

Опитът за изграждане на проекти веднага без тези знания би бил твърде разочароващ. Уверете се, че не прекарвате твърде много време на този етап, тъй като е много лесно да се направи.

Когато изучавах HTML / CSS / JS, щях да изучавам подобни теми от различни ресурси, мислейки, че по някакъв начин това ще запълни всички пропуски в моите знания. Наистина запълни някои пропуски, но в даден момент бях осъзнал, че използвам тези ресурси като патерица, за да не ми позволи да премина към нови, по-вълнуващи, но малко по-страшни неща. Не се забивайте в безкрайни цикли (вероятно за известно време?) При преглед и преразглеждане на информацията, която вече знаете.

Не се поддавайте на рационализацията

Когато започнете да създавате проекти, неизбежно ще закъсате. Ако се придържате към него, след известно време ще преодолеете бариерата, но скоро след това ще ударите друга. Това не е опция и се случва на всеки.

В такива моменти всяка част от тялото ни крещи - нека направим нещо друго, да бягаме оттук, това ме кара да се чувствам неудобно, мога да се справя с това по-късно, когато знам повече, ще се върна към него и т.н. Така че правим пауза.

Страхуваме се обаче, че нашата пауза ще се разтегне и ние просто ще продължим да кодираме все по-малко и да го пуснем. За да не позволим това да се случи, но все пак запазвайки нашето „решение“ да не работим по проекта, решаваме, че засега ще работим чрез някакъв урок или онлайн курс.

Много е лесно да се рационализирате от създаването. Никой няма да ви каже, че не се научавате да кодирате или да ви критикува по какъвто и да е начин за това. Вие сте единственият, който може да идентифицира какво всъщност се случва (страх, отвращение към риска, съпротива) и да вземе решение да се придържа към работата по проекта.

Повярвайте ми, всички стени ще се срутят, ако ударите по тях достатъчно дълго. Помислете за хората, които по онова време са учили чужди езици, като са имали два екземпляра от една и съща книга на техния роден и целеви езици. Как го направиха? Те просто останаха с него достатъчно дълго.

Не започвайте с вашата ГОЛЯМА ИДЕЯ

Удивително е, че вече го имате, но тук има някои други съображения, които могат да ви променят мнението. Причината, поради която изтъквам това, е, че продължавам да чувам това много от хората: „Искам да създам онлайн приложение, което да позволява на хората да създават акаунти за своите домашни любимци, да качват снимки, да проследяват местоположенията и много други неща. Наскоро започнах да се уча да програмирам и вече съм в процес на изграждане на идеята си. " Това ме кара да отида „Уау, уау“.

Това, което лесно мога да видя да се случва в тази ситуация, е, че човек е прекалено отдаден на идеята, започва много ентусиазирано и бавно я изгражда, но с течение на времето обучението им не може да се справи с изискванията на проекта и се чувства влачене, винаги в края на съзнанието им, недовършено.

Най-лошото, което може да се случи в тази ситуация е, че човекът ще се откаже от проекта и заедно с това ще се откаже и от кодирането.

Препоръчвам да започнете с прости проекти и като завършите всеки от тях, ще получите усещане за постигнатост и по-добро разбиране за това как да структурирате по-голям проект.

Представете си, че сте писател и имате идея за една голяма книга от живота си и веднага сте започнали да я пишете. Вероятно ще трябва да пренапишете всичко това 3-4 пъти, за да стигнете до прилично ниво на качество, докато можете да започнете с писането на малки истории, да получите обратна връзка, да подобрите писането си и да се обърнете към вашия Moby Dick, когато сте наистина готови.

Откъде да вземем идеи за проекти

Най-доброто място, което познавам, е Free Code Camp. Това използвах, след като бях напълно заседнал. В началото на кодирането си бих попитал всички разработчици, които познавах (както офлайн, така и онлайн) какъв трябва да бъде първият ми проект. Не те шегувам, когато казвам (изненада изненада), всички те казаха, че това трябва да е приложение за списък със задачи. Честно мисля, че ако продължим да правим тези приложения със списък със задачи, те скоро ще претрупат целия Интернет.

Free Code Camp ми помогна в смисъл, че предостави списък с вълнуващи проекти, подредени в последователност от нарастваща трудност. Друго чудесно нещо е, че всеки от тях е специално създаден, за да ви научи на определена тема, например: Tribute Page ще вземе вашите HTML / CSS умения на тест, Покажете Local Weather ще ви научи да работите с API, изграждане на JavaScript Калкулаторът очевидно ще подобри вашите JS умения и т.н.

Това е най-силната отправна точка, която знам, за да ви накарам да изградите. За всички проекти, които приключвате, можете да получите обратна връзка от общността, както и да видите как другите са се обърнали към тях (след като сте изградили своя, без измама!) За допълнително вдъхновение винаги можете да потърсите в Google „списък с идеи за страхотни кодови проекти Или нещо подобно.

Първо структурирайте проекта си

Преди да започнете да изграждате, напишете какво искате да прави. Напишете конкретни потребителски истории, например: „Потребителите могат да възпроизвеждат звук, когато кликнат върху бутона на аудио плейъра“, „Потребителите могат да влязат в системата, използвайки своя имейл и парола, както и само с Facebook“.

Вашият код също трябва да има основна структура, преди да започнете да го пишете. Пишете с псевдокод - основно просто обяснете с думи какво ще прави всяка част от приложението или кода на проекта.

Основен пример:

// Когато потребителят отвори страница, вземете местоположението му

// Изпратете заявка до сайта на API за времето с местоположението

// Получаване на данни

// Показване на градусите на страницата

// Променете фоновото изображение на страницата, за да отразява текущото време

Не прекалявайте, не е необходимо първо да изписвате всяко малко нещо, което вашият код ще прави в псевдокод, но има изложени основните части.

Най-добрият пример, който мога да ви дам, е: не забравяйте, че когато пишете есета в училище, първо трябваше да ги структурирате, например, въведение с вашето мнение по темата, 3 основни точки в подкрепа на вашето мнение и заключение .

Това ще ви помогне да предвидите потенциални проблеми и да подобрите качеството на вашия код.

Добре е да заседнеш

Както вече споменах, добре е да се забиете. Това не означава, че сме глупави, а просто означава, че още не знаем. Винаги ще изживеете моментите на закъснение: не само когато учите, но и на работа.

Колкото по-рано се почувствате неудобно, толкова по-добре. Това ще направи напредъка ви много по-бърз. Самото програмиране е творческо решаване на проблеми. Ако няма проблеми, които да ви е трудно да разрешите, това означава, че играете на сигурно. Спрете да стъпвате в плитката вода и се гмуркайте!

И най-вече, и ще повторя това отново, не се смятайте за глупав. Знам, че е лесно да се направи в тези моменти. Често говоря с хора, които са преминали през HTML / CSS / JS частта на Free Code Camp с лекота, нокаутирайки 30–40 елемента на ден и след това стигат до основни и междинни алгоритми и установяват, че могат да направят само 1– 5 на ден, така че те стигат до заключението, че са закъсали и че са глупави, недостатъчно добри или не са предназначени да бъдат разработчици.

И аз бях по същия начин, чувствах, че вероятно има хора, които просто летят през този раздел и се чувствах зле за себе си и за напредъка си. Сега вече знам по-добре.

Това, което се опитвам да кажа тук, е, че трябва да се научите да:

Бъдете над главата си

Трябва да откриете онова ниво на трудност на проекта, което да ви държи точно в средата между „нещата, които са лесни“ и „нещата, които все още са твърде трудни“.

Говорих много за причините, поради които е опасно да продължавам да преглеждам и преучавам един и същ материал (лесните неща), така че нека да поговорим за обратната страна на уравнението: трудните неща.

Общото ви правило, когато подхождате към нещо трудно - нещо, което смятате, че може да не сте в състояние да направите, - трябва да опитате да го направите първо.

Започнете от основната структура и се опитайте да я кодирате. Ако сте останали на едно и също нещо повече от три дни, фокусирайки се върху него, пуснете го за малко и намерете подобни - но малко по-лесни - неща, които трябва да направите.

Това, което откривам е, че след като го направя, подсъзнанието ми все още е фокусирано върху решаването на проблема, в който съм се заклещил. Получавам тези произволни идеи как мога да го реша, когато правя прости неща - като да взема душ или да мия чиниите - това изведнъж ме връхлита!

Понякога работи точно по този начин. Понякога не става. Но основният съвет тук е - винаги избирайте нещо, което ви прави малко неудобно . Всичко друго не си струва времето.

Устойчивост

Искам да споделя с вас една от най-любимите ми думи:

Устойчивост - способността на системата да толерира смущения, без да се срутва, да издържа на удари, да се възстановява, когато е необходимо, и да се подобрява, когато е възможно.

Това е невероятно качество, върху което вие като програмист (и като човек, който иска да успеете в живота) трябва да работите върху развитието си в себе си. Подгответе се за всички проблеми, всички предизвикателства, всички критики към вашата работа, към вашите проекти, към вашите решения и всичко друго, което бихте могли да направите дори преди те да се случат.

Страхувате ли се да не сте на сцената? Регистрирайте се, за да научите хората от вашата местна общност на основите на уеб разработката, или се регистрирайте, за да говорите на конференция / техническо събитие.

Разочаровани ли сте от протичането на вашето интервю - и че след това не сте наети Страхувате ли се, че е твърде късно да започнете да се научавате да кодирате? Не сте доволни от току-що завършения проект?

Преформулирайте всичко това : какво можете да научите от опита, за да го направите по-добър следващия път? Как можете да превърнете своите слабости в силни страни?

Например, може да се притеснявате, че сте стигнали до кодирането твърде късно, след като сте били в друга кариера в продължение на X брой години. Представете си, че в ума си, като мислите за различна перспектива и зрялост, ще въведете в индустрията, която отчаяно се нуждае от по-зрели хора (психологически) и по-разнообразен произход? Вие правите технологичната индустрия по-богата от самото решение да влезете в нея!

Ако чуете глас в себе си, който казва „не можете да рисувате“, тогава непременно рисувайте и този глас ще бъде заглушен. - Винсент ван Гог

Това, което мога да препоръчам за повишаване на вашата устойчивост, са тези три книги:

  1. „Писма от стоик“ от Сенека
  2. „Препятствието е пътят“ от Райън Холидей
  3. “Turning Pro” от Стивън Пресфийлд

Поставете дневна цел, ограничена във времето

За да напредвате по-бързо, трябва да работите по проектите си всеки ден. Тази част е просто здрав разум. Има обаче някои допълнителни съображения, които трябва да имате предвид.

Вместо да задавате цел на резултата („Ще завърша тази функция или онази част днес“), задайте определен период от време, който ще отделяте за кодиране всеки ден. Не правете повече от 30 минути или час на ден.

Знам, че искате да поемете ангажимент за кодиране в продължение на 3 часа на ден и да се опитате да се придържате към него. Това работи, но само толкова дълго, докато животът влезе в игра. С разумен срок - например 30 минути на ден - винаги ще знаете, че това може да се направи и че винаги ще имате половин час на ден, за да отделите кодиране, особено ако основната ви цел е да се научите да кодирате. Дори ще откриете, че кодирате повече в определени дни и това ще се почувства страхотно, защото вече сте изпълнили квотата си за този ден.

Този срок е по-скоро психологически трик, който работи поради начина, по който мозъците ни са свързани. Не забравяйте, че когато сте имали голям проект, който е трябвало да започнете, но сте продължили да се бавите и да се бавите, докато просто не сте имали достатъчно време да го завършите преди крайния срок? Направихте добре, но бяхте стресирани през цялото време преди това. След това добавете към това факта, че няма кой да ви определи краен срок да станете разработчик. Тоест никой, освен теб.

Това, което се случва, когато си поставим цел за резултат, е, че не можем да изчислим времето, което ще е необходимо, за да завършим тази или тази функция. И по-често в крайна сметка не постигаме това, което сме си поставили за деня. Това ни кара да се чувстваме ужасно и намалява желанието да седнем и да кодираме на следващия ден.

С ограничена във времето дневна цел ще напредвате всеки ден. На кого му пука, ако не сте завършили конкретната функция, която искате да приключите днес? Постигнахте напредък! Ти се появи. Това ви кара да напредвате.

Друг чудесен бонус е, щом седнете и започнете да кодирате, идеи и решения ще започнат да текат, сякаш от нищото (подобно на писането на статия, а? :). Ще бъде много по-лесно да се накарате да седнете и да кодирате, след като отстраните нереалистичните очаквания и страхове.

Копирането на код губи време

По време на процеса на изграждане на проект, или в самото начало - когато не знаете откъде да започнете, или на по-късен етап, когато ударите проблем, който не можете лесно да разрешите - ще изпитвате силно желание да търсите в изходния код на проекта, за да видите как се прави. Ще рационализирате, че това ще ви накара незабавно да разберете кода, а това означава, че сте го научили и усвоили. Далеч от това.

Не копирайте цели проекти и ги персонализирайте. Не вземайте части от кода. Дори не вземайте парчета от него.

С проекти - не гледайте кода на първо място. С нещата, които сте потърсили в Stack Overflow и подобни, погледнете ги, анализирайте, разберете, но след това го кодирайте сами от нулата. Ще видите, че е трудно да го напишете сами дори след като току-що видяхте цялата работа.

По този начин умишлената практика се различава от редовната практика (повторение). Основният улов на правилото от 10 000 е, че практиката трябва да бъде преднамерена. Следването на шаблони и готови решения няма да ви отведе никъде. Някой вероятно би могъл да напише скрипт на Python, който ще ви замести във всичко, което правите, ако тръгнете по този начин. Обърнете внимание на това, което изглежда трудно за вас.

Друга идея извън темата е, че ако се борите с определена тема, опитайте да я научите на други или просто да им я обясните по начина, по който я разбирате. Резултатите ще последват както за вас, така и за учащите.

Копирането на код ще ви лиши от възможността да се научите да го правите сами и това по никакъв начин не е по-добре от преминаването през урок. Да, решението е точно там. Да, можете да го вземете, ако искате. Но какъв е смисълът? Опитвате ли се да впечатлите някого със скоростта, с която сте изградили проекта? Или се опитвате да избегнете трудните проблеми, които ще отнемат известно време?

Каквато и да е причината ви - това е просто още един път обратно към топлия комфорт, от който се опитваме да избягаме. Направете обратното. Бягайте към дискомфорта.

Единственият път, когато е добре да надникнете в кода на други хора, е след като приключите проекта. След това гледайте колкото искате, анализирайте го и се поучете от него.

Всеки труден проблем, който решавате, ви кара да растете със скокове.

Не разпръсквайте усилията си наоколо

Много съм виновен за това и всъщност това е съвет, който пиша повече за себе си, отколкото за никой друг (извинете!). Когато започнете да работите по проект и ударите стените, за които споменах, ще се изкушите да го задържите и да започнете нов.

Винаги се чувства страхотно в началото, докато не ударите стена с втория проект. Тогава ще имате на разположение два недовършени проекта. Това ще се повтаря отново и отново, ако го оставите.

Решението тук е да се ограничите до 2 проекта наведнъж. След като се забиете в един, прекарайте известно време, за да го разберете. Но ако в момента изглежда невъзможно, просто преминете към другия проект, който имате. Ключовото е да не започвате трети, защото от там е хлъзгав склон.

Винаги трябва да се опитвате да направите всичко възможно, за да останете на пътя на обучението. Ако ви е писнало или просто ви е омръзнало това, което правите в момента, направете малко почивка, нагласете се и се върнете към него. Не се отказвайте изцяло от кодирането.

Ето защо винаги препоръчвам да имате малка стая за размахване, било то временно отвличане на вниманието под формата на различен учебен ресурс (ограничен до една седмица) или, в този случай, два проекта вместо един.

Вашето портфолио е това, което ще ви наеме

Много е трудно за наемащ мениджър или за инженер да оцени вашите умения само въз основа на написаното от вас в автобиографията си. „Знам JavaScript! (и имат 4 години опит). " "Покажи ми!" (Наистина трябва да спра с справките на Matrix).

Всички проекти, които изграждате и пускате онлайн, включват вашето крайно резюме на живо. Всеки може да го погледне и да бъде убеден, че всъщност знаете какво правите.

Не се страхувайте обаче, това не означава, че вашият код трябва да е идеален, за да могат дори да ви обмислят. Тези проекти ще помогнат на всеки, който има задача да ви интервюира, да оцени правилно нивото ви на умения.

Няма да ви се налага да преживявате интервюта далеч над нивото си, защото някой HR човек е намерил определен набор от ключови думи във вашето автобиография. Очакванията на вашия работодател ще бъдат по-равни на действителните ви възможности.

Положителните ползи от работата ви онлайн са:

  • работодателите виждат, че вие ​​знаете какво правите
  • те виждат, че непрекъснато работите за подобряване на уменията си
  • те виждат, че вие ​​всъщност сте разработчик и че сте достатъчно смели, за да пуснете работата си онлайн, за да я видят всички.

От моя личен опит и от това, което продължавам да чувам от хората в нашата група за безплатни кодове в Торонто, е, че най-важният фактор за намиране на работа за кодиране е тяхното портфолио от проекти.

Ще се справите по-добре на интервюта

На интервюта най-вероятно ще получите малко уеб приложение или страница за изграждане в реалния живот или ще ви бъде даден проблем за решаване.

Често при тези проблеми човекът, който извършва наемането, търси да види как мислите чрез решаване на проблем. Те не винаги искат да създадете идеалното решение. Понякога те дават проблеми, които не могат да бъдат решени, само за да видите какво ще правите. Ще получите много практика от този тип с проекти: всеки от тях ще бъде изпълнен с тези мини-проблеми.

Що се отнася до нещата от реалния живот, които можете да получите за изграждане, те могат и ще варират. Ето нещо, което трябваше да изградя по време на интервюто за настоящата си позиция. Знам, че кодът не е толкова страхотен, но това трябва да ви даде представа какво да очаквате. Единствената причина, поради която успях да го завърша в деня на интервюто, беше, че имах предишен опит да изграждам неща като приложение за времето и калкулатор чрез Free Code Camp.

Ще идентифицирате реалните пропуски във вашите знания

Тук уроците и други подобни ви играят на трик. Те ви карат да чувствате, че когато сте ги приключили, сте покрили всичко, което трябва да знаете по темата. Но в момента, в който се опитате да изградите нещо сами, незабавно ще се забиете - често на много прости неща.

Защо така? Тъй като битовете и информацията, дадени ви в урок, са избрани от някой, който го е създал, използвайки собственото си разбиране за това, което хората може да търсят. И тъй като е просто невъзможно да се обхване всичко в урок.

Единственият начин наистина да разберете какви знания ви липсват е да продължите да откривате пропуските в него, докато вървите. Не знаете какво не знаете. Така че процесът е: отидете, ударете стена, преодолейте проблема, продължете и т.н.

Всеки нов проект ви плаши. Какво да правя?

Не знам за вас, но при мен това се случва постоянно. Завършвам проект и се чувствам чудесно за себе си и уменията си. Тогава в минутата, в която чета потребителските истории за следващия си проект, ставам парализиран от страх.

Замислям се как мисля - как мога изобщо да започна? Какво трябва да направя първо? Как успях да завърша предишния? Нищо не знам! * Превключване на режим на пълна паника *

Има няколко техники, които използвам, когато попадна в тази ситуация:

На първо място, разгледайте всички предишни проекти, които сте изградили. Те също бяха изключително плашещи. По някакъв начин намерихте начин да разрешите проблемите и да изградите тези проекти.

Поглеждането към миналите ви успехи, когато сте в момент на ниско самочувствие, е мощен метод да се съберете отново и да се подготвите за ново предизвикателство.

Ключът е да се разглежда проектът като пакет от малки проблеми за решаване. Страхуваме се само защото виждаме целия айсберг в неговата цялост и той идва към нас. Ако обаче използвате техника, за която говорихме преди - разбиване на проекта до основна структура - ще бъде много лесно да започнете.

Забравете перфекционизма

Не правите това, за да създадете някакъв идеален, невероятен проект с толкова красив код, че ще накара опитни разработчици да плачат.

Целта е да направите необходимото: изпълнете потребителските истории, които са ви били дадени (или сте създали за себе си), за да можете да научите механиката на това как работи определена техника на кодиране / езикова функция / рамка, било то API, функции, обещания и т.н.

След това направете колкото можете, за да подобрите проекта - както дизайн, функционалност, така и качество на кода.

Но в даден момент си позволете да спрете. Това не е международен конкурс за изкуство. Това сте вие ​​и предметът, който искате да научите. Не позволявайте на обекта да ви плаши толкова много, че дори не можете да започнете.

Хората, които имат крайна нужда да правят всичко перфектно, обикновено са хората, които не правят абсолютно нищо.

Не бих могъл да започна тази статия, например, ако прекарах твърде много време в притеснения дали ще бъде добро или лошо, камо ли перфектно. Знаех, че това е важна тема, от която се интересуват много хора, и че трябва да пиша за това, което съм открил досега, с надеждата, че това ще помогне на някого и ще улесни пътуването му с кодирането.

Ако всичко трябваше да е идеално, щеше ли да има място за скици в изкуството? В крайна сметка несъвършенствата са това, което ги прави уникални.

Оставете вашата креативност да тече!

Не се чувствайте така, сякаш трябва да направите проекта си по същия начин, както виждате на страницата, ако работите от описание и пример, който сте намерили онлайн. Програмирането е колкото изкуство, толкова и наука.

Приемете тази точка още по-сериозно, ако правите преден край.

Ако правите машина за произволни кавички, нека кавичките са от вашия любим герой. Ако правите игра, нека звуците и дизайна да бъдат каквито искате!

Бъди странен. Оставете всички странности и уникални различия на вашата личност. Освободете истинското си аз.

Съсредоточете се върху изпълнението на всички потребителски истории, но всичко останало зависи изцяло от вас.

Тук е Zen Calculator, който съм изградил, като пример за това, за което говоря. Разбира се, можете да станете много по-креативни. Оригиналът е тук, въпреки че вече е актуализиран. Версията, от която съм работил, напомня повече за приложение за калкулатор за iPhone.

Мрежата - и програмирането като цяло - ни позволяват тази свобода. Никога не се сдържайте. Бъдете какъвто искате да бъдете, правете каквото искате и оставете това да се разлее във всяка част от живота ви, включително кодирането.

Ето нещо за вдъхновение и за онагледяване на това, което имам предвид:

Нещата придобиват своя вкус само когато им добавите индивидуалност! Сравнете хиперреалистичните художници и Пикасо. Бихте ли разделили хиперреалистичните художници, само като разгледате работата им? Силно се съмнявам. И все пак бихте познали картината на Пикасо веднага. Кара ви да мислите.

Поддайте се на разсейване - от време на време

Понякога е добре да си починете малко от проектите, но за това трябва да имате някои правила.

В идеалния случай разсейването ви трябва да отнеме по-малко от седмица , било то курс, урок или нещо друго. Това трябва да е конкретна тема, която искате да научите, за предпочитане свързана с нещо, което трябва да знаете, за да продължите да усъвършенствате проекта си.

В противен случай е напълно добре с мен, ако четете книги за програмиране или гледате кодиращи видеоклипове по време на пътуването си до работа или докато чакате някъде без достъп до интернет.

Просто се уверете, че когато се върнете на бюрото си (или от което и място да кодирате - може да е легло или диван, нали?), Отново сте към истинските неща. Това е вашата практика .

Получете обратна връзка за вашите проекти

Освен че ви помагат да запълните пропуските във вашите знания, проектите ви дават и артефакт, който можете да споделите със света, търсейки конструктивна обратна връзка.

Внимавайте с кого споделяте проектите си. Не допускайте свръхкритичните хора. Опитайте се да намерите истински разработчици или хора, които също все още учат, но вече са малко по-напреднали от вас. Помолете ги да прегледат кода ви и да предоставят отзивите си. Какво можете да подобрите? Какво работи? Какво не?

Това допълнително ще ускори обучението ви, защото тези любезни хора ще ви помогнат да разкриете прозрения, които иначе не бихте открили.

Надявам се, че вече ви убедих, че изграждането на проекти на живо е най-ефективният начин да се научите да кодирате.

Лично забелязах, че периодите, в които изграждам - ​​вместо да гледам, чета или преминавам онлайн курсове - са периодите, в които научавам най-много. Надявам се вашият опит да бъде същият като моя.

Късмет! Чувствайте се свободни да добавите вашите съвети в коментарите към тази статия и да споделите вашите проекти и тук.

Случайна бележка: Написах тази статия, докато слушах саундтрака на Tron: Legacy.

Ако тази статия ви е харесала, моля, щракнете върху ❤, за да я препоръчате тук на Medium. Това би означавало света за мен! :)