avatr of Ibrahim

Published 28th Apr 2022

Lessons I learnt while learning frontend development

6 min read

In this blog I will highlight some key learning points of my self-taught journey into web development - how I tackled learning new things and what helped me learn quicker. Hopefully by the end of the article you would have picked one or two points to help you with your journey.

Don’t skim read

As tempting as it may seem - to skim read an entire page on an official document, don’t. I learnt this the hard way.

I used to skim read, go practise this new JS array method, fail, come back to the doc and read again. It was time wasting. It took me a while until I stopped this habit. Furthermore, the more documents I read the more cautiously-paced I had to be as every document is written differently. Some documents are excellent at displaying information particularly if there are ‘exceptions’ to certain rules whilst other documents hide ‘exceptions’ in their lengthy code blocks which is a nightmare.

However skim reading to get to the right section of the page or the correct sub heading is fine - as long as you don’t skim read chunks of text. Read it once, read it all, go apply.

Repeat, repeat, repeat.

Repetition is one of the most under-rated learning aids. It reinforces memory, speed, confidence and accuracy.

Ok - but how much repetition does one need?

How ever much is required. My rule of thumb is to repeat until you feel confident. Let’s say you’ve been following a tutorial on how to make a navbar. Good - now make it again without the tutorial. Now make it once more and add a new feature to it. And one last time - but make the bar stick to the top of the viewport so it never slides out of view when scrolling.

With each repeat you are using a few skills - recalling, applying, creating and consolidating. This way you are recalling what you have learnt, not being bored doing the same thing over and over, and at the same time consolidating what you have learnt in the previous problem.

The Boiling Frog

‘The Boiling Frog’ is a concept that I first came across during my teacher training year. One of the best mentors I worked with introduced me to this apologue.

Essentially if you throw a frog into hot water, the frog will jump out instantly. However if you put a frog into water at room temperature and slowly heat it, the frog will not notice the temperature change and will eventually be sitting in a pot of boiling water… if it’s still alive by then.

I used this concept throughout my teaching career. I would present the same maths problem to my students but add one extra step in the middle and before they knew it I took them from a grade 5 to a grade 7 difficulty (C to A grade).

How has this helped me in coding? I tackle one problem at a time. One challenge at a time.

One of the first mistakes I did was when I started on FreeCodeCamp. I used to look a few units ahead to see what sort of things I will be learning e.g. looking up algorithm scripting in the JavaScript unit whilst still working on the HTML course. Was that encouraging? No. Did I feel intimidated? Yes.

I learnt to stop the habit of looking forward because it would simply overwhelm my little brain trying to comprehend this new universe of web technologies. Instead, I would focus on the current task. Complete it and move on to the next one. A few weeks later I would look back, see how much I’ve progressed and decide whether I need to practise more or transition to the next learning objective.

Use more than one resource

I’ve learnt not to rely on one source of information - in the beginning it was FreeCodeCamp and FreeCodeCamp only. I then realised that when I mix up the learning style I get exposed to more new information and different ways of doing things.

I guess every teaching medium has their own teaching strategy. One medium might emphasise on a particular topic more than others e.g. a five minute video might not go into greater depth than a book. Or you could a read a book but you can’t practise if you don’t have a code editor - so this is where online platforms have their advantages.

So I ended up bookmarking 3-4 resources that I will instantly go to if I needed more explanation on a particular topic. So what resources do I usually use?

  • The official documentation of that particular framework or library.
  • W3Schools
  • A well-respected popular community driven blog site e.g. CSS-Tricks. I would ‘Google’ the problem I’m trying to solve followed by CSS Tricks
  • Two or three popular YouTube tutors for that traditional human-to-human teaching.

Of course, not forgetting StackOverFlow and FreeCodeCamp

Get it running first

I can recall my first few times using VS Code to set up the environment - usually consisting of only one html page and one styling sheet. But even with that simple setup I often used to spend considerable time writing lines of HTML and CSS without even seeing it in the browser.

Then I would wonder why it’s not showing in the browser. I remember spending 15-20 minutes trying to figure out why it’s not showing only to find that I did not link my stylesheet in the HTML file!

This is why you should test things out, make sure it’s running smooth before adding greater depth to your projects.

As I began to learn more web technologies including React JS and started building more complex apps I often found myself going off tangents and spending more time on the design and aesthetics of the app. So much so that on occasions I would spend an hour or two on researching about a particular animation or hover effect. Or I would go down a rabbit hole of debates on StackOverFlow about using spans vs divs or anchors vs buttons.

In the end I would get frustrated, time has passed and I did not make progress.

To overcome this issue I promised myself that I would focus on getting the backbones of the project running first before applying any styling or adding extra features.

For example when I was working on my Meme Generator app where I had to make a GET request, take user input and POST it to an API, I made a simple JSX component first. I added input fields, coded the logic behind it and tested out the GET and POST requests. Once it was successful I spent the next day or two adding routing, styling and any other features I wanted.

This increased my development speed tremendously. The reason for this is because design and styling is arbitrary and even little things such as picking theme colours can get in the way. However by focussing on the core functionality of the app, styling and design can take as long, or as short, as I want it to be.

Do not take notes

I remember my first day embarking on this journey. I got myself a pack of A4 printing paper a few coloured ballpoint pens - black, blue, red and green. I took notes with the black pen, blue for remarks, red for circling or emphasising points, and green for comments.

I logged on to FreeCodeCamp and hit the first lesson. I copied the <h1> tags onto paper, passed the test and moved on to the next challenge. Copied some of the information, passed the test and moved on to the next challenge. Copied important bits, passed the test and moved on. You get it - copying almost every point mentioned in the course.

Few hours in and I have 5 pages of notes already. I check the FCC curriculum and I see ‘thousands of hours’ worth of learning. At this rate I was going to end up with hundreds of pages worth of notes.

Is this the right approach? Maybe? My clever side thought ‘ok I can cut down on notes and only write down what’s really important’. I managed to condense my notes to ten pages in total for the HTML course. I still saw that as a problem and felt I needed to change the way I learn.

After getting to JavaScript I found myself still taking notes - however that soon changed. It became inconceivable to copy almost everything from the MDN docs onto paper. It was useless. After all, I noticed that I rarely used my notes as a point of reference - I almost always Googled when I had a question.

Where are my notes now? Only God knows.

There are benefits to not taking notes - it strengthens your memory. There have been studies shown that note taking kills your memory. It’s similar to how everyone used to memorise their family’s and friends’ phone numbers in the 90s.

Closing thoughts

These are some of the useful lessons I learnt while navigating my way in the web. It may not work for everyone, but it worked for me. Ultimately we all have our unique way of learning. You do what is best for you. If your skim reading skills are heavenly then by all means skim read. If taking notes helps to reinforce your memory then take as much notes as you want.

Thank you for reading. Let's connect!

Feel free to connect on Twitter or LinkedIn

© Ibrahim Al-Quraishi 2024