DEV Community

Cover image for One of the most important rules I learned after a year of learning frontend
Anwar
Anwar

Posted on • Updated on

One of the most important rules I learned after a year of learning frontend

Most of the time when I was writing code, I was subconsciously working according to one concept "If it works, don't touch it" which was really time wasting and a lot of the time frustrating. Now I try to code according to another concept "Think before you code". In this article I'm gonna talk about this concept and why it's really important.

If it works, don't touch it

When you write code as a beginner this is probably how you solve a problem:
"write some stuff then run it , doesn't work ? write more stuff then run it again, maybe copy some snippets from stackoverflow and so on until it works."
Even with css, you probably try different properties on the element and keep trying until you get the desirable result.
I have been there but I discovered that this is not a right way of writing code because most of the time you're not really understanding what your code does, another problem is that you're probably have some lines of code that either redundant or repetitive.

Think before you code

A better approach is by planning things out before writing any code, There two magical tools that'll help you make a good plan these tools are: a pen and a paper.
Say you wanna build a website, spend some time away from your code editor and start ask yourself some questions : "What colors or fonts do I wanna use ?" , "how do I want it to look on desktops? what about mobile ?" , "Do I want to repeat some style ?".
Think deeply about each question and write the answers, draw a basic shape of your layout, believe me this'll save you from repeating yourself and from wasting a lot of the time trying things out waiting for your code to work. Kevin powell has an amazing article about that topic(Creating a website - getting over the anxiety of starting with a blank file)

Applying it to javascript

Take you time understanding the problem and the relation between the input and the output, think about things you need in order to solve the problem, the data type you're dealing with and whether you need an auxiliary data type or not , write some pseudo code.

What if things didn't work after planning?

At this point, start searching to understand why your code isn't working and by searching I mean looking for articles/videos that talk about the topic that's confusing you, take your time searching until you figure out what's wrong this searching process will help you develop your skills and understanding of the language you're learning, and please never copy snippets of code without understanding them.

Top comments (3)

Collapse
 
ecyrbe profile image
ecyrbe

In the future you'll learn that it's all about coding workflow.

You can't plan everything and you can't make good design emerge from scratch.

One workflow i like (you are welcome to disagree) is TDD (Test Driven Development). Indeed 20 years ago, computer industry invented TDD. A coding workflow driven by writing small features with test first approach and then refactoring your code.

The refactoring part is important. you can't get your code right and clean from first try (whoever you are). So you always need to refactor your code once your tests are green, so you can be confident your refactoring is not breaking anything.

But you can't do everything with just TDD, because good architecture is hard to setup with just TDD.

So what we do is designing architecture first (it's better to design with whole team and not alone) then once architecture is designed develop features with TDD.

Collapse
 
danakin40 profile image
Danakin40

I do agree however having a pre-planned layout helps alot most time if not every time

Collapse
 
patarapolw profile image
Pacharapol Withayasakpunt • Edited

Well tested both as a part and as whole. CI if possible. I use that for backend.