Hitchhiker’s Guide to the programming

Hi there! Firstly,

and carry a towel, as the towel is a very functional item.

Not so long ago I started to learn JavaScript, and that was a lot of pain for me because all that I have learned, I learned by myself, with the guidance of my friends and internet. I want to tell you about the problems I faced whole along this journey.

Why? Because ‘scars’ are still fresh! As time passes it makes harder to remember the struggling you’ve been through. So the first suggestion, try to find someone who is still fresh, who just ‘broke the wall’ because they know exactly what bricks you need to push. It is much harder for a senior developer to understand newcomer’s problems, although that doesn’t mean that you must ignore the guidance and help of seniors.

I will try to keep this article more general to keep it also actual in the future.

Note: This article is not JS learning guideline, it is rather the things I wanted to know when I just started.

Let’s go!

You wrote your program, but it doesn’t work properly, and you can’t see the reason, you can’t see even what data was passed, or changed!
This one is pretty easy, although I know a lot of people who didn’t know about console.log() when they just started**.**

Remember when I say seniors don’t really feel your pain? For them, this is such a simple and natural, it’s strange that you don’t know about it.

console.log(‘message’) outputs a message to the web console, you can pass an argument instead of string and see it’s value.

Note: As we talked about console.log, it is good to know about DevTools. You can access it with right-click on the webpage and choose ‘Inspect’.

Single Responsibility Principle (or SRP).

The main idea of this concept is: all pieces of software must have only a single responsibility. Your function should solve one task. For example, if you need to create a calculator, you can write one function, that accepts arguments, and action, or you can write 4 functions that will accept arguments, and depending on the function name, return an action. Example

function calculator( x, y, action ) {
  if ( action === 'plus' || action === '+' ) {
    return x + y
  } else if ( action === 'minus' || action === '-' ) {
    return x - y
  } else if ( action === 'divide' || action === '/' ) {
    return x / y
  } else if ( action === 'multiply' || action === '*' ) {
    return x * y
  } else {
    return "This is simple calculator, we don't have much"
  }
}

Now in SRP way

function plus( x,y ){
  return x + y
}
function minus( x,y ){
  return x - y
}
function divide( x,y ){
  return x/y
}
function multiply( x,y ){
  return x * y
}

Now let’s add ES6 and a little ❤️.

const plus = (x,y) =>  x + y
const minus = (x,y) =>  x - y
const divide = (x,y) =>  x / y
const multiply = (x,y) =>  x * y

Admit that the last example is much, much cleaner, and readable. Also, you don’t need additional checks.

In JavaScript functions always return values.

Not always we need a value, sometimes you just need to make a change, and there is no return statement in your function. Although you will get a value, equal to undefined. It is important to know.

Learn ES6

Know the difference between var, let, const. Learn about ES6 features.

Choose good names.

When your program becomes complex, or old, you will forget the functionality of functions, and the purpose of files and folders. There is only one good way to overcome this problem. Choose good names, I know, it’s hard at the beginning, but eventually, it will help you in future, and with more experience, it will become easier.

Comments

Some say you need to comment your code. Well, that is not an insane thing to say. In the beginning, it may save you from hours of struggle.

Although, I personally think that you should write a program using good (even long) names, good coding style, and good structure, so anyone could understand your code ( even yourself from the future!), without any comments. In any case, I believe this statement is true:

“Documentation is a love letter that you write to your future self.” — Damian Conway

So, you should find a balance.

Object-oriented(OOP) VS functional programming(FP).

I personally prefer FP, but I started with OOP, so should you. Both have pros and cons, but before choosing what is best for you, you need to know why another is bad. Here is a playlist from Mattias Petter Johansson, about FP in JavaScript. I learned a lot from his sho, not only about functional programming but also about ̶f̶l̶u̶f̶f̶y̶k̶i̶n̶s̶ programmers daily life. And in the darkest hour, he consistently kept me inspired and excited to keep learning, and I blame him for my job, that I have today. SO if you want to learn JS, and become the really good developer, I highly encourage you to subscribe to his channel.

Asynchronous programming

Dive deep into asynchronous programming, understand What the heck is the event loop. Also, as I mentioned, you can find great examples at MPJ’s channel about callbacks, promises, async/await

Version control

Learn what is version control, and how it works. You need to differ git from Github, it is important to understand how git works, and what patters are there. I think in the beginning, you use version control as a backup for your projects, nut later you’ll use it for syncing with other team members.

When you’ll start to work with git, review yourself before merging, git diff is a pretty great command for this.

Terminal

It is good to know what are the terminal commands, and how to use them.

Get familiar with the function scope

It is a very common mistake, when starters, and even sometimes experienced developers, being confused with this. Although it is pretty simple.

In JS there are two types of scope:

• Local scope
• Global scope

Variables defined inside a function are not accessible (visible) from outside the function.

Scope determines the accessibility of variables, objects, and functions from different parts of the code.

Coding style.

This is something people ignore, as you are ‘just learning’. I think this is wrong. You need to watch over your coding style from the very first line of code. Your code must be as clean and easy to read as possible, and sooner you start, sooner you learn the art of programming.

Yes, good style is a subjective matter and is difficult to define.

However, there are several elements common to a large number of programming styles. The issues usually considered as part of programming style include the layout of the source code, including indentation; the use of white space around operators and keywords; the capitalization or otherwise of keywords and variable names; the style and spelling of user-defined identifiers, such as function, procedure and variable names; and the use and style of comments.

Breaks

“Sometimes it pays to stay in bed on Monday, rather than spending the rest of the week debugging Monday’s code.” — Christopher Thompson

This one is one of the most important things, learn when to take breaks. It is hard to stop when you’re doing things you love. But you get tired, and sometimes you will be stuck, and your brain will need to rest. It’s very individual, but working 8 hours without stopping, is definitely a very bad idea.

Questions

Another one from the same opera, learn when to ask. When you stuck, and can’t solve a problem, it is okay to ask someone to help you, although it is not okay not to ask for help. When you start working, give yourself some time, depending on task complexity, from 20 minutes to an hour or two. If you couldn’t finish your task, you ask someone for help, without any shame. It is possible that you’ll be a little bit unlucky l̶i̶k̶e̶ ̶m̶e̶, and your ‘senior’ developer wouldn’t answer your questions and try to get rid of you. Don’t feel bad about that, if your mentor refuses to answer your questions, that means you don’t have a mentor. Keep in mind you are learning, and it is required from you to ask questions.

Feedback.

The issue you may face is the lack of feedback. This can be very frustrating. Great way to deal with it, is code reviews. If you are lucky, you will get them anyways, in another case you need to ask for that.

And in the end.

Do not start with learning frameworks. I suggest you to start learning (If we are talking about JS) with ES5, not ES6.

‘But you said I need to learn ES6!?’

Yes, you should, but before that, you should be familiar with ES5. The reason is pretty obvious. It is useless for you to learn technologies that solve problems that you never had. So, you should start having problems! And only after that learn about the solutions.

Career :
First, when I started my career, I was looking for a job. After my first job experience, I start looking for a company to work for.

Keep in mind that you need to work in a place when people, and the atmosphere will encourage you to learn, and move forward.

Thank you for reading this far, I wasn’t expecting to write this long. I will be happy to discuss them with you. I really hope that this article will help someone.

If any questions or suggestions. You can follow me on Twitter, and if you liked this article, I would be very happy to receive a couple of 👏.

Here are some stuff(mainly about JavaScript ):
All the answers you need: 42, JS
Links: Fun FunFunction, What the heck is the event loop, ES6 features, Git, terminal commands, avoid hell, Event bubbling, Mostly Adequate Book.

Online playgrounds: Codesandbox, Repl.it, CodePen.

Also, I want to mention Dan Abramov, as his tweet about this, was one of the inspiration points for me to write this up, and there is a lot of good comments there!