Як отримати роботу розробника менше ніж за рік

Прискоріть своє навчання

Що найскладніше для того, хто вирішив навчити себе кодувати? Справа в тому, що вони зазвичай не знають, чому вчитися - яку мову програмування вибрати, як підійти до навчання, які ресурси найкращі з точки зору ефективності часу.

Все починається з пошуку в Google на ці теми, що неминуче призводить людей до одного з багатьох ресурсів, які вчать людей кодувати. Формат цих ресурсів дуже різниться, і здоровий глузд підказує нам, що нам слід спробувати купу різних ресурсів і вибрати ті, які найкраще відповідають нашому стилю навчання. Підручники для одних людей, екранні трансляції для інших, статті для ще однієї групи тощо. Здається цілком логічним, чи не так?

Ну ... ні. Сьогодні я хочу переконати вас, що один із таких форматів навчання приведе вас туди, де ви хочете бути швидшим за будь-який інший. Без подальших затримок, дозвольте мені сказати вам, що це таке, і чому ви повинні зосередити на цьому всі свої зусилля.

Створення проектів

Б'юся об заклад, ви бачили, що такий прийде.

Перш за все, дозвольте мені уникнути деяких ваших заперечень. Я не кажу, що вам слід взагалі відмовитись від усіх інших видів навчальних ресурсів.

Усі навчальні посібники та екранні трансляції мають своє місце під сонцем, і я детальніше про це розповім далі в статті. Наприклад, іноді найефективнішим способом ознайомитись з новою технологією чи фреймворком може бути читання статті або перегляд підручника.

Проблема полягає в тому, що ми схильні дотримуватися (або, принаймні, я) до ресурсів, які утримують нас у зоні комфорту, навіть коли настав час зробити щось своє. Це просто надто зручно, готово до вживання. Це також завжди змушує нас почуватись чудово, адже привіт, ось ми тут вчимось! Правда? Хто може сказати, що ми витрачаємо час даремно? Як вони сміють? Ми заповнюємо прогалини в наших знаннях!

Небезпечно, що нам може здатися, що ці ресурси також є найефективнішим способом навчання. Як люди, ми можемо виправдати майже все, що тримає нас у зоні комфорту. Я вже давно живу в цій ілюзії.

Стук, стук, Нео.

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

Я говорив про Опір у своїй попередній статті (прочитайте його, якщо ви боретеся або відчуваєте застряг), тож дозвольте мені пояснити, чому я так непохитний у цій темі, і дозвольте мені переконати вас змінити фокус (якщо це не так вже там) до будівлі.

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

Ось кілька моїх думок про те, як підходити до цих проектів, які можуть бути лякаючими для початку, а також кілька порад, які я взяв у дорозі.

Це може зайняти у вас навіть менше року (Що?)

Аргументація цього полягає в тому, що на основі мого особистого досвіду, розмови з членами нашої групи Free Code Camp Toronto та читання про подорожі членів по всьому світу.

Я виявляю, що найчастіше люди можуть знайти роботу навіть до того, як закінчать сертифікацію Front Code Development Free Code Camp. Вони будують необхідні проекти та починають подавати заявки. Незабаром вони отримують пропозицію кодувати гроші.

Якщо ви прочитаєте підредагування 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, я ходив і вивчав подібні теми з різних ресурсів, думаючи, що якимось чином це заповнить усі прогалини в моїх знаннях. Це справді заповнило деякі прогалини, але в якийсь момент я зрозумів, що використовую ці ресурси як милицю, щоб уникнути переходу до нових, більш захоплюючих, але трохи страшніших речей. Не застрягайте в нескінченних циклах (можливо, циклі while?;) Перегляду та перегляду відомостей, які ви вже знаєте.

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

Почавши створювати проекти, ви неминуче застрягнете. Якщо ви дотримаєтеся цього, через деякий час ви подолаєте бар'єр, але незабаром після цього ви вдаритесь про інший. Це не варіант, і це трапляється з усіма.

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

Однак ми боїмося, що наша пауза буде розтягуватися, і ми будемо продовжувати кодувати все менше і менше і скидати її. Щоб цього не допустити, але все ж дотримуючись нашого "рішення" не працювати над проектом, ми вирішили, що наразі ми будемо працювати за допомогою якогось навчального посібника чи онлайн-курсу.

Дуже легко раціоналізувати себе, не створюючи. Ніхто не скаже, що ви не навчитеся кодувати або будь-яким чином критикуєте вас за це. Ви єдиний, хто може визначити, що насправді відбувається (страх, неприязнь до ризику, опір) і прийняти рішення дотримуватися роботи над проектом.

Повірте мені, всі стіни обрушаться, якщо ви вдарите по них досить довго. Подумайте про людей, котрі в той час вивчали іноземні мови, маючи два примірники однієї і тієї ж книги рідною та цільовою мовами. Як вони це зробили? Вони просто затрималися з цим досить довго.

Не починайте зі своєї ВЕЛИКОЇ ІДЕЇ

Дивно, що у вас це вже є, але тут є деякі інші міркування, які можуть передумати. Причиною цього я є те, що я постійно чую це від людей: «Я хочу створити онлайн-додаток, яке дозволяє людям створювати облікові записи для своїх домашніх тварин, завантажувати фотографії, відстежувати місця та багато іншого. Нещодавно я почав вчитися кодувати, і я вже будую свою ідею ". Це змушує мене йти “Уууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууууу?

Що я легко бачу, що відбувається в цій ситуації, так це те, що людина стає надто відданою ідеї, вона починає дуже захоплено і повільно її вибудовувати, але з часом їх навчання не встигає за вимогами проекту, і вона відчуває тягнуть, завжди в глубині думки, незавершені.

Найгірше, що може статися в цій ситуації, це те, що людина відмовиться від проекту, а разом з ним відмовиться і від кодування.

Я рекомендую починати з простих проектів, і, закінчуючи кожен із них, ви відчуєте досягнення і краще зрозумієте, як структурувати більший проект.

Уявіть, що ви були письменником, і у вас була ідея для однієї великої книги у вашому житті, і ви почали писати її відразу. Ймовірно, вам доведеться переписати все це 3-4 рази, щоб досягти гідного рівня якості, тоді як ви можете почати з написання невеликих історій, отримати відгуки, покращити своє написання та підійти до свого Мобі Діка, коли будете по-справжньому готові.

Де взяти ідеї для проектів

Найкраще місце, яке я знаю, - Free Code Camp. Це те, що я використовував після того, як повністю застряг. На початку мого шляху кодування я запитав усіх розробників, яких я знав (як офлайн, так і онлайн), яким повинен бути мій перший проект. Я жартую вас не тоді, коли я кажу (несподіваний сюрприз), вони всі сказали, що це має бути додаток зі списком справ. Я чесно думаю, що якщо ми продовжимо створювати ці програми зі списком справ, вони незабаром перевантажать весь Інтернет.

Free Code Camp мені допоміг у тому сенсі, що він надав перелік захоплюючих проектів, вибудованих у послідовність зростаючих труднощів. Ще одна чудова річ полягає в тому, що кожен з них спеціально розроблений, щоб навчити вас певній темі, наприклад: Tribute Page проведе ваші тести HTML / CSS на тест, Show the Local Weather навчить вас працювати з API, побудувати JavaScript Калькулятор, очевидно, покращить ваші навички JS тощо.

Це найсильніша відправна точка, яку я знаю, щоб змусити вас будувати. Для всіх проектів, які ви закінчуєте, ви можете отримати відгук від спільноти, а також побачити, як інші звертаються до них (після того, як ви створили свій, без обману!). ”Або щось подібне.

Спершу структуруйте свій проект

Перш ніж розпочати будівництво, напишіть, що ви хочете зробити. Напишіть конкретні історії користувачів, наприклад: «Користувачі можуть відтворювати аудіо, коли вони натискають кнопку аудіоплеєра», «Користувачі можуть входити, використовуючи свою електронну адресу та пароль, а також просто використовуючи Facebook».

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

Основний приклад:

// Коли користувач відкриває сторінку, захопіть їх місцезнаходження

// Надішліть запит на сайт API погоди з місцезнаходженням

// Отримання даних

// Відображення градусів на сторінці

// Змінити фонове зображення сторінки з урахуванням поточної погоди

Не перестарайтеся, немає необхідності виписувати кожну дрібницю, яку ваш код буде робити, спершу в псевдокоді, але викладені основні частини.

Найкращий приклад, який я можу вам навести: пам’ятайте, коли ви писали есе в школі, вам спочатку потрібно було їх структурувати, наприклад, вступ зі своєю думкою на цю тему, 3 основні моменти на підтримку вашої думки та висновок .

Це допоможе вам передбачити потенційні проблеми та покращити якість вашого коду.

Це нормально застрягти

Як я вже згадував раніше, нормально застрягти. Це не означає, що ми дурні, це просто означає, що ми ще не знаємо. Ви завжди будете переживати моменти застрягання: не лише під час навчання, але й на роботі.

Чим швидше ви почуватиметесь незручно, тим краще. Це зробить ваш прогрес набагато швидшим. Саме програмування - це творче вирішення проблем. Якщо проблем, які вам важко вирішити, немає, це означає, що ви граєте в безпеці. Припиніть топтатись на мілководді та пірнайте!

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

Я теж був таким самим, я відчував, що є люди, напевно, які просто пролітають цей розділ, і мені було погано від себе та свого прогресу. Тепер я знаю краще.

Тут я хочу сказати, що ви повинні навчитися:

Будь над головою

Ви повинні знайти той рівень складності проекту, який утримує вас посередині між «простими речами» і «речами, які все ще занадто важкі».

Я вже багато говорив про причини, чому небезпечно продовжувати переглядати та перевчати той самий матеріал (прості речі), тож давайте поговоримо про протилежну сторону рівняння: важкі речі.

Вашим загальним правилом, коли підходите до чогось складного - до того, що, на вашу думку, може бути неможливим, - слід спробувати зробити це спочатку.

Почніть з основної структури та спробуйте кодувати її. Якщо ви затримуєтеся на одній і тій же речі більше трьох днів, коли зосереджуєтесь на ній, киньте її на деякий час і знайдіть подібні, але трохи простіші речі.

Я виявляю, що після цього моя підсвідомість все ще зосереджується на вирішенні проблеми, в якій я застряг. Я отримую ці випадкові ідеї щодо того, як я можу це вирішити, коли я роблю прості речі - наприклад, приймаю душ або мию посуд - це раптом мене вражає!

Іноді це працює саме так. Іноді це не так. Але головна порада тут - завжди вибирайте те, що робить вас трохи незручним . Все інше не варто вашого часу.

Стійкість

Я хочу поділитися з вами одним із моїх найулюбленіших слів:

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

Це дивовижна якість, над якою ви як програміст (і як людина, яка прагне досягти успіху в житті) повинні розвиватися в собі. Підготуйтеся до всіх проблем, усіх викликів, усієї критики вашої роботи, вашого дизайну, ваших рішень і всього іншого, що ви можете зробити ще до того, як вони трапляться.

Ви боїтесь бути на сцені? Зареєструйтесь, щоб навчити людей у ​​вашій місцевій громаді основам веб-розробки, або зареєструйтесь, щоб виступити на конференції / технічному заході.

Are you disappointed in how your interview went — and that you didn’t get hired afterwards? Are you afraid that it’s too late to start learning to code? Aren’t happy with the project you just finished?

Reframe all of this: what can you learn from the experience to make it better next time? How can you turn your weaknesses into strengths?

For example, you might worry that you are coming to coding too late after having been on another career path for X number of years. Reframe that in your mind by thinking about a different perspective and maturity you will be bringing into the industry that desperately needs more mature people (psychologically) and more diverse backgrounds? You are making the tech industry richer by the very decision to get into it!

Якщо ви почуєте в собі голос, який говорить "ви не можете малювати", то неодмінно малюйте, і цей голос буде замовкнути. - Вінсент Ван Гог

Що я можу порекомендувати для підвищення вашої стійкості - це ці три книги:

  1. “Листи від стоїка” Сенеки
  2. “Перешкода - це шлях” Райана Холідей
  3. “Turning Pro” Стівена Прессфілда

Встановіть щоденну мету, обмежену часом

Щоб швидше прогресувати, вам слід щодня працювати над своїми проектами. Ця частина - це просто здоровий глузд. Однак є кілька додаткових міркувань, про які слід пам’ятати.

Замість того, щоб встановлювати ціль результату («Я закінчу цю функцію або ту частину сьогодні»), встановіть певний проміжок часу, який ви будете витрачати на кодування щодня. Не робіть це більше 30 хвилин або години на день.

I know you want to make a commitment of coding for 3 hours a day and try to stick to it. This works, but only for so long, until life comes into play. With a reasonable time limit — like 30 minutes a day — you will always know that it can be done, and that you will always have half an hour a day to spare on coding, especially if your main goal is to learn to code. You will even find yourself coding more on certain days, and that will feel great, because you will already have fulfilled your quota for that day.

This time limit is more of a psychological trick that works because of the way our brains are wired. Remember that time you had a big project that you needed to start, but you kept delaying and delaying until you just had enough time to finish it before the deadline? You did OK, but you were stressed out all the time prior to that. Then add to this the fact that there is no one to set you a deadline on becoming a developer. That is, no one, but you.

What happens when we set an outcome goal is that we can’t estimate the time it’s going to take to finish that or this feature. And more often than not, we end up not accomplishing what we’ve set out to do for the day. That makes us feel terrible, and decreases the desire to sit down and code the next day.

With a time-limited daily goal, you will make progress every day. Who cares if you haven’t finished that specific feature you wanted to wrap up today? You’ve made progress! You showed up. That’s what gets you ahead.

Another great bonus is once you sit down and start coding, ideas and solutions will start flowing, as if out of nowhere (similar to writing an article, huh? :). It will be much easier to get yourself to sit down and code once you get unrealistic expectations and fears out of the way.

Copying code is wasting time

During the process of building a project, either at the very beginning — when you don’t know where to start from, or at a later stage when you hit a problem you can’t easily solve — you will experience a strong desire to look at the source code of the project to see how it is done. You will rationalize that it will make you instantly understand the code, and that means you’ve learnt and assimilated it. Far from it.

Don’t copy whole projects and customize them. Don’t take parts of the code. Don’t even take pieces of it.

With projects — don’t look at the code in the first place. With the stuff that you looked up on Stack Overflow and such, look at it, analyze, understand, but then code it yourself from scratch. You will see that it’s difficult to write it yourself even after you just saw the whole thing.

This is how deliberate practice is different from regular practice (repetition). The 10,000 rule’s main catch is that the practice has to be deliberate. Following templates and ready-made solutions will not take you anywhere. Someone probably would be able to write a Python script that will replace you in whatever it is you are doing, if you go that way. Pay attention to what seems difficult for you.

Another off-topic idea is that if you struggle with a particular topic, try teaching it to others, or just even explaining it to them the way you understand it. Results will follow for both you and the learners.

Copying code will rob you of the opportunity to learn to do it yourself, and it is in no way better than going through a tutorial. Yes, the solution is right there. Yes, you can take it if you want to. But what’s the point? Are you trying to impress someone with the speed with which you’ve built the project? Or are you trying to avoid the hard problems that will take some time to solve?

Whatever your reason might be — it is just another way back into the warm comfort from which we are trying to escape from. Do the opposite. Run toward the discomfort.

The only time it’s OK to peek into other people’s code is after you’ve finished the project. Then look as much as you want, analyze it, and learn from it.

Every difficult problem you solve makes you grow by leaps and bounds.

Don’t spread your efforts around

I am very guilty of this, and that’s actually a piece of advice I am writing more for myself than for anybody else (sorry!). When you start working on a project and hit the walls that I mentioned, you will be tempted to put that project on hold and start a new one.

It always feels great in the beginning, until you hit a wall with the second project. Then you will have two unfinished projects on your hands. This will repeat again and again, if you let it.

The solution here is to limit yourself to 2 projects at a time. Once you get stuck on one, spend some time figuring it out. But if it seems uncrackable at the moment, just move to the other project you’ve got. The key thing is not to start a third one, because it’s a slippery slope from there.

You should always try to do anything possible to make yourself stay on the path of learning. If you feel fed up, or are just bored with what you’re currently doing, take a little break, adjust, and get back to it. Don’t give up on coding altogether.

This is why I always recommend having a little wiggle room, be it a temporary distraction in a form of a different learning resource (limited to a week), or, in this case, two projects instead of one.

Your portfolio is what will get you hired

It’s very difficult for a hiring manager or for an engineer to assess your skills based solely on what you’ve written in your resume. “I know JavaScript! (and have 4 years of experience).” “Show me!” (I’ve really got to stop with the Matrix references).

All of the projects you build and put online comprise your ultimate live resume. Anyone can look at it and be convinced that you actually know what you are doing.

Don’t get scared though, it doesn’t mean your code should be ideal for them to even consider you. These projects will help whoever is tasked with interviewing you to properly assess your skill level.

You won’t have to experience interviews way above your level because some HR person have found a particular set of keywords on your resume. Your employer’s expectations will be more on-par with your actual abilities.

The positive benefits of having your work online include:

  • employers see that you know what you are doing
  • they see that you are constantly working on improving your skills
  • they see that you are, in fact, a developer, and that you are brave enough to put your work online for everyone to see.

From my personal experience, and from what I keep hearing from the people at our Toronto Free Code Camp group is that the most important factor in finding a coding job has been their portfolio of projects.

You will do better at interviews

At interviews, you are likely to get a real life little web app or a page to build, or to be given a problem to solve.

Often with these problems, the person who is doing the hiring is looking to see how you think through solving a problem. They don’t always want you to produce the ideal solution. Sometimes they give problems that can’t be solved just to see what you will do. You will get a lot of practice of that kind with projects: each of them will be filled with these mini-problems.

As for the real-life stuff that you can be given to build, it can and will vary. Here is something I had to build during the interview for my current position. I know the code isn’t that great, but this should give you an idea of what to expect. The only reason I was able to finish it on my interview day was because I had previous experience building things like a weather app and a calculator through Free Code Camp.

You will identify the real gaps in your knowledge

Here is where the tutorials and the like play a trick on you. They make you feel that when you’ve finished them, you’ve covered everything you need to know about the subject. But the moment you try to build something on your own, you’ll instantly get stuck — often on very simple stuff.

Why is that? Because the bits and pieces of information given to you in a tutorial were chosen by someone who created it using their own understanding of what people might be looking for. And because it is simply impossible to cover everything in a tutorial.

The only way to truly see what knowledge you are lacking is to keep discovering the gaps in it as you go. You don’t know what you don’t know. So the process is: go, hit a wall, work through the problem, keep going, and so on.

Every new project scares you. What to do?

I don’t know about you, but with me it happens all the time. I finish a project and feel great about myself and my skills. Then the minute I read the user stories for my next project, I become paralyzed by fear.

I find myself thinking — how can I even start? What should I do first? How was I able to finish the previous one? I know nothing! *Toggle Full Panic Mode*

There are a couple of techniques that I use when I get into that situation:

First of all, take a look at all the previous projects you’ve built. They were also hugely intimidating. Somehow, you found a way to solve the problems and build these projects out.

Looking back on your past successes when you’re in a low self-confidence moment is a powerful method to pull yourself back together, and to get ready for a new challenge.

The key is to look at the project as a bundle of tiny problems to solve. We only get scared because we see the whole iceberg in its entirety, and it’s coming towards us. However, if you use a technique we talked about before — breaking the project down to a basic structure — it will be very easy to get started.

Forget perfectionism

You are not doing this to create some sort of an ideal, amazing project with the code so beautiful it will make experienced developers cry.

The goal is to do what’s necessary: fulfill the user stories that you have been given (or have created for yourself) so you can learn the mechanics of how a certain coding technique/language feature/framework works, be it APIs, functions, promises, etc.

Then do as much as you can to improve the project — both design, functionality and the quality of code.

But at some point, allow yourself to stop. It’s not an international art competition. It’s you and the subject you want to learn. Don’t let the subject scare you so much you can’t even start.

People who have an extreme need to do everything perfectly are usually the people who get absolutely nothing done.

I wouldn’t be able to start on this article, for example, if I spent too much time worrying of whether it would be good or bad, let alone perfect. I knew this was an important topic that a lot of people are interested in, and that I needed to write about what I’ve discovered so far, in hopes that it would help someone and make their coding journey easy.

If everything had to be perfect, would there be any place for sketches in art? Imperfections are what makes them unique, after all.

Let your creativity flow!

Don’t feel like you have to make your project exactly the same as you see on the page, if you are working from a description and an example you found online. Programming is as much art as it is science.

Take this point even more seriously if you are doing front end.

If you are making a Random Quote Machine, let the quotes be from your favorite character. If you are making a game, let the sounds and design be whatever you want them to be!

Be weird. Let all of the quirks and unique differences of your personality out. Unleash your true self.

Focus on fulfilling all the user stories, but everything else is completely up to you.

Here is the Zen Calculator that I’ve built, as an example of what I am talking about. Of course, you can get much more creative. The original is here, though it’s already been updated. The version I’ve worked from reminded more of an iPhone calculator app.

The web — and programming in general — allow us that freedom. Never hold yourself back. Be whoever you want to be, do whatever you want to do, and let that spill to every part of your life, including coding.

Here is something for inspiration, and to illustrate what I mean:

Things only get their flavor when you add personality to them! Compare hyper-realistic painters and Picasso. Could you tell hyper-realistic painters apart just by looking at their work? I highly doubt it. Yet you would know a Picasso painting right away. Makes you think.

Give in to a distraction — once in a while

Sometimes it’s okay to take a little break from the projects, but for that you have to have some rules.

Ideally, your distraction has to take less than a week, be it a course or a tutorial, or anything else. It should be a specific subject you want to learn, preferably connected to something you need to know to continue refining your project.

Otherwise, it’s completely fine with me if you are reading programming books or watching coding videos during your commute, or while waiting somewhere with no access to the internet.

Just make sure that when you are back at your desk (or whichever place you code from — could be a bed or a couch, right?), you are back to the real stuff. It’s your Practice.

Get feedback on your projects

In addition to helping you fill the gaps in your knowledge, projects also give you an artifact which you can share with the world, soliciting constructive feedback.

Be careful whom you share your projects with. Don’t let the over-critical people in. Try to find real developers, or people who are also still learning, but are already a little more advanced than you are. Ask them to review your code and provide their feedback. What you can improve? What works? What doesn’t?

This will further accelerate your learning, because these kind people will help you uncover insights you wouldn’t have otherwise found yourself.

I hope I’ve convinced you by now that building live projects is the most effective way to go about learning to code.

I’ve personally noticed that the periods when I build — as opposed to watch, read, or go through online courses — are the periods when I learn the most. I hope your experience will be the same as mine.

Good luck! Feel free to add your advice in the comments to this article, and share your projects here as well.

Random note: I wrote this article while listening to the Tron: Legacy Soundtrack.

If you liked this article, please click the ❤ to recommend it here on Medium. It would mean the world to me! :)