DEV Community: Denis Veleaev

Why do you abandon your personal projects?

Denis Veleaev — Thu, 05 Nov 2020 15:28:08 +0000

Hi. 👋
I'm Denis. I'm going to give a talk at my company and I need your help with my small investigation.

So, why do you abandon your personal projects?

Thanks a lot for your answers in advance!

Personal projects. Do you work on them? Have you finished one?

Denis Veleaev — Thu, 05 Nov 2020 12:08:28 +0000

Hi. 👋

I'm Denis. I've recently completed a mega workshop called 30 projects in 30 days.

I want to give a talk in my company about the lessons I've learned from it. But I'd like to know who can be interested in it and what problems related to my topic developers experience.

If you have a spare minute, may I ask you several questions on that? It will help me a lot!

Please please please answer these questions:

Do (or did you) you work on personal projects? Why?
Are they small or medium/large?
How many years of experience in development do you have?
Do you tend to start and abandon these projects? Why?
Have you completed at least one personal project? Was it successful?
What's your process? Do you start with coding or any investigation?

Thanks a lot in advance!

5 SOLID principles with JavaScript. How to make your code SOLID

Denis Veleaev — Sat, 19 Sep 2020 12:51:23 +0000

Hi 👋! I'm Denis.

SOLID principles are strictly related to design patterns. It's important to know design patterns because it's a hot topic for an interview. If you know them, you'll easily understand more sophisticated programming paradigms, architectural patterns, and language features such as reactive programming, flux architecture (Redux), generators in JavaScript, etc.

What are SOLID principles?

SOLID stands for

S — Single responsibility principle
O — Open closed principle
L — Liskov substitution principle
I — Interface segregation principle
D — Dependency Inversion principle

These 5 principles will guide you on how to write better code. Though they come from object-oriented programming. I know it's very daring to call JavaScript an object-oriented language :) Regardless, I promise that if you understand these principles, then when you design your next solutions, you will definitely ask yourself "Hey, am I violating the Single-responsibility principle?".

So, let's begin

S — Single responsibility principle

It's probably the easiest principle, and at the same time, the most misunderstood one.

A module should be responsible for only one actor. As a consequence, it has only one reason to change

Example

Let's take a look at the following code:

class TodoList {
  constructor() {
    this.items = []
  }

  addItem(text) {
    this.items.push(text)
  }

  removeItem(index) {
    this.items = items.splice(index, 1)
  }

  toString() {
    return this.items.toString()
  }

  save(filename) {
    fs.writeFileSync(filename, this.toString())
  }

  load(filename) {
    // Some implementation
  }
}

Ooops. Even though from first glance, this class seems to be fine, it violates the Single responsibility principle. We added second responsibility to our TodoList class which is the management of our database.

Let's fix the code so that it complies with the "S" principle.

class TodoList {
  constructor() {
    this.items = []
  }

  addItem(text) {
    this.items.push(text)
  }

  removeItem(index) {
    this.items = items.splice(index, 1)
  }

  toString() {
    return this.items.toString()
  }
}

class DatabaseManager {
  saveToFile(data, filename) {
    fs.writeFileSync(filename, data.toString())
  }

  loadFromFile(filename) {
    // Some implementation
  }
}

Thus our code has become more scalable. Of course, it's not so obvious when we're looking at small solutions. When applied to a complex architecture, this principle takes on much more meaning.

O — Open closed principle

Modules should be open for extension but closed for modification

That means that if you want to extend a module's behavior, you won't need to modify the existing code of that module.

Example

class Coder {
  constructor(fullName, language, hobby, education, workplace, position) {
    this.fullName = fullName
    this.language = language
    this.hobby = hobby
    this.education = education
    this.workplace = workplace
    this.position = position
  }
}

class CoderFilter {
  filterByName(coders, fullName) {
    return coders.filter(coder => coder.fullName === fullName)
  }

  filterBySize(coders, language) {
    return coders.filter(coder => coder.language === language)
  }

  filterByHobby(coders, hobby) {
    return coders.filter(coder => coder.hobby === hobby)
  }
}

The problem with CoderFilter is that if we want to filter by any other new property we have to change CodeFilter's code. Let's solve this problem by creating a filterByProp function.

const filterByProp = (array, propName, value) =>
  array.filter(element => element[propName] === value)

L — Liskov substitution principle

A principle with the most confusing name. What does it mean?

If you have a function, that works for a base type, it should work for a derived type

Let's go with a classic example

Example

class Rectangle {
  constructor(width, height) {
    this._width = width
    this._height = height
  }

  get width() {
    return this._width
  }
  get height() {
    return this._height
  }

  set width(value) {
    this._width = value
  }
  set height(value) {
    this._height = value
  }

  getArea() {
    return this._width * this._height
  }
}

class Square extends Rectangle {
  constructor(size) {
    super(size, size)
  }
}

const square = new Square(2)
square.width = 3
console.log(square.getArea())

Guess what will be printed to the console. If your answer is 6, you are right. Of course, the desired answer is 9. Here we can see a classic violation of the Liskov substitution principle.

By the way, to fix the issue you can define Square this way:

class Square extends Rectangle {
  constructor(size) {
    super(size, size)
  }

  set width(value) {
    this._width = this._height = value
  }

  set height(value) {
    this._width = this._height = value
  }
}

I — Interface segregation principle

Clients should not be forced to depend upon interfaces that they do not use

There are no interfaces in JavaScript. There is a way to mimic their behavior, but I don't think there's much sense. Let's better adapt the principle to the js world.

Example

Let's define an "abstract" Phone class which will play role of the interface in our case:

class Phone {
  constructor() {
    if (this.constructor.name === 'Phone')
      throw new Error('Phone class is absctract')
  }

  call(number) {}

  takePhoto() {}

  connectToWifi() {}
}

Can we use it to define an iPhone?

class IPhone extends Phone {
  call(number) {
    // Implementation
  }

  takePhoto() {
    // Implementation
  }

  connectToWifi() {
    // Implementation
  }
}

Okay, but for an old Nokia 3310 this interface will violate the "I" principle

class Nokia3310 extends Phone {
  call(number) {
    // Implementation
  }

  takePhoto() {
    // Argh, I don't have a camera
  }

  connectToWifi() {
    // Argh, I don't know what wifi is
  }
}

D — Dependency Inversion principle

High-level modules should not depend on low-level modules

Let's take a look at the following example:

Example

class FileSystem {
  writeToFile(data) {
    // Implementation
  }
}

class ExternalDB {
  writeToDatabase(data) {
    // Implementation
  }
}

class LocalPersistance {
  push(data) {
    // Implementation
  }
}

class PersistanceManager {
  saveData(db, data) {
    if (db instanceof FileSystem) {
      db.writeToFile(data)
    }

    if (db instanceof ExternalDB) {
      db.writeToDatabase(data)
    }

    if (db instanceof LocalPersistance) {
      db.push(data)
    }
  }
}

In this case, a high-level module PersistanceManager depends on the low-level modules, which are FileSystem, ExternalDB, and LocalPersistance.

To avoid the issue in this simple case we should probably do something like this:

class FileSystem {
  save(data) {
    // Implementation
  }
}

class ExternalDB {
  save(data) {
    // Implementation
  }
}

class LocalPersistance {
  save(data) {
    // Implementation
  }
}

class PersistanceManager {
  saveData(db, data) {
    db.save(data)
  }
}

Of course, this is an oversimplified example, but you've got the point.

Conclusion

The value of SOLID principles is not obvious. But if you ask yourself "Am I violating SOLID principles" when you design your architecture, I promise that the quality and scalability of your code will be much better.

Thanks a lot for reading!
Feel free to follow me here on DEV.to and also on Twitter (@DenisVeleaev)

Peace!

6 simple rules to fully understand "this" keyword in JavaScript

Denis Veleaev — Wed, 09 Sep 2020 05:50:22 +0000

Hey! 👋
I'm Denis.

One of the most popular topics for a JavaScript interview is the this keyword. Even though this concept is fundamental, there are a lot of developers who don't really know the rules of this keyword.

Actually there is nothing complicated. I want to share with you 6 simple rules that will help you to stand out among the other interviewees.

Rules

1. `new` keyword

The first and the most important rule is that if the new keyword is used when we calling a function, inside this function this refers to a new object that is created and returned by the constructor function. This rule is also applicable when we use ES6 classes

Example

function Person() {
  console.log(this)
  this.age = 23
  console.log(this)
}
const p = new Person()

/* Output */
// {}
// { age: 23 }

2. `apply` / `call` / `bind`

The rule that we all probably know is that when we can force a function call to use a particular object as this using one of these 3 methods: apply / call / bind

function myFunction() {
  console.log(this)
}

const  thisObject = {
  someValue: 23
}

myFunction.call(thisObject)   // { someValue: 23 }
myFunction.apply(thisObject)  // { someValue: 23 }

const myBoundFunction = myFunction.bind(thisObject )
myBoundFunction()             // { someValue: 23 }

3. Function as a method

This one is quite popular for interviews. The rule is simple. When the function is called as a method (i.e., the function is called by a preceding dot), this is the object that the function is a property of (this is the object before that dot).

const thisObject = {
  someValue: 23,
  itsMethod: function() {
    console.log(this)
  }
}

thisObject.itsMethod('John') // { someValue: 23, itsMethod: ƒ }

4. The simplest case

This is the simplest one, but a lot of people forget (or don't know) it. The rule says: if the function is called without any of the conditions above, this is the global object (window) for browser.

function f() {
  console.log(this)
}

f() // Window (global object)

5. The order

If multiple rules can be applied simultaneously, the rule that is higher in the list will determine the this value.

6. Arrow functions

Arrow functions are the most favorite for interviews. Everyone knows that there's something special with this and arrow functions, but the minority really can tell the rule.

So, the rule is that arrow function ignores all the rules and takes the this value of its surrounding scope at the time it’s created.

It's that simple! We can determine an arrow function's this value by finding the line where it was created and looking at what the value of this is there.

Test yourself!

Let's test if you understand the rules 🙂.

const obj = {
  value: 'abc',
  createFn: function() {
    return function() {
      console.log(this)
    }
  },
}
const fn = obj.createFn()
fn()

So, can you tell me what's going to be printed as this in this case? Can you clearly tell why?

To test it you can simply run this code in chrome console.

But can you answer how to "fix" this code?

If the answer is "Yes", congratulations! 🎉 You're one step closer to passing JavaScript interview!

Conclusion

The rules of this are really simple, but knowing them you can definitely show understanding of the fundamentals to the interviewer.

Thanks a lot for reading my article. Feel free to subscribe to me on DEV and Twitter @DenisVeleaev.

Peace!

How to be mentally healthy and what you should pursue in your career

Denis Veleaev — Sun, 06 Sep 2020 09:59:04 +0000

Hey! 👋

I'm Denis - I am a Web Developer and an IT mentor at CoderDojo. And I want to ask you a very important question

Are you happy with your job? Do you understand why?

I believe that understanding what makes you happy is probably one of the most important drivers for your career. And this question is much more complex than it seems to be. It requires a lot of self-awareness and experimentations.

I'd like to share with you my absolute truths that I've found out working on different positions with different teams and of different projects. This article is inspired by Monica Lent's great story "7 absolute truths I unlearned as junior developer"

1. The team is the most important factor

I'd like to start with a kind of obvious topic, but extremely important. The people around you influence your mental health more than anything else even in current conditions. This is true both in positive and negative directions. Being in a toxic environment is awful and if you are in such one, you should definitely find a way to change it. There is a popular opinion that you have to stay in one workplace no matter what to avoid having a resume full of short stints. The truth is that in a toxic environment you won't have the motivation to grow and share, and you'll end up a less valuable and employable specialist. So, there's nothing more important than your mental health.

I'm happy I've never been in a toxic environment though.

2. You are the arithmetic mean of the people around you

Once our team had got a junior developer who was full of energy, constantly learning something new and sharing this with others, it literally changed the spirit of the team. This growing mindset spread among the people. Btw he has become one of the best young web devs I know in person now.

You are the arithmetic mean of the people around you. Try to surround yourself with people who grow fast, and, on the other hand, be the one who shares his/her energy with others. It pays back. I promise.

3. Understand the most suitable role for you

At the beginning of my career path, I thought that as a developer you can simply be a working bee or the leader or manager-dev. Now I understand that it's not that simple. The development process is very complex, and to be a developer does not only mean to write code. Try to analyze what makes you feel happy in terms of non-coding responsibilities. Some questions I'd suggest to ask yourself:

Do you like to have an influence on the product?
Are you the kind of person who wants to "just do their job" and be involved in any meetings as less as possible?
What pace of development is the most comfortable for you?
Do you like to interact with other team members a lot?
Do you like to teach people?
Do you like to be taught by other people?
Do you like to be involved in the client's business processes?
Do you like trying new things?

There are no right or wrong answers. Thinking about these things you can find out what role in the team suites you. I believe that you cannot find an ideal workplace. But you can create it, knowing your needs.

What I've found out thinking about my role:

I'm a teacher by nature. At my workplace, I help a lot to my colleagues, teaching them new things. I mentor the interns and do the lectures for them to end other colleagues. I'm also a volunteer IT mentor for children at CodeDojo.
It's important for me to be involved in shaping the product I build. I really like to interact with other team members. I like startup-like pushing super-fast pace of development. I'm into trying a lot of new things.

If some of these needs are not satisfied in my workplace I find another way to do it. For example, I participate in Hackathons (and suggest you try too. It's magical).

The ideal team for me is the one who can literally break the walls to overcome the problems. And I'm extremely happy to be surrounded by such people.

4. All the people are different

I must confess. Early in my career, I silently blamed the people for the fact that they don't want to grow fast, like the comfortable process of delivery, spend too much time on polishing things more than it's needed, don't like to communicate with others much. The truth is that we all are different and it's absolutely normal, that other people are driven by different things than you.

5. Balance is crucial

It's super important to find work-life balance. Find time not only for learning and work but also for building healthy relationships with your friends and family, and for your hobby. If you neglect any of these, the others will be ruined soon.

By the way, I'm interested in what your hobbies are. Please share it with us in the comment session! I'm a fire-show artist and volunteer IT mentor for children. I also like board games and conduct board games events for children and adults.

6. Don't burn out

Despite everything I've said, you are not your job. You don't have to stay at work more than you are paid for. But I believe that you should strive to find or create a place where you want to stay longer. Anyway, really important, listen to yourself and take a pause if needed. And never try to escape other life problems via working more. It's very unhealthy.

Don't blame yourself for being unproductive today. It's normal! :)

7. FOMO is your enemy

This is extremely important for developers. The wold around is changing constantly and the fact that you cannot be on top of all the new technologies generates a lot of FOMO (Fear Of Missing Out). Trust me, even the most senior people feel it. Just learn to live with it. Think of the gap in your knowledge as a growth opportunity!

Conclusion

It's not easy to find out what's important for you. But it's the key to find (or more precisely to create) the best workplace for you. Invest in your self-awareness. It really pays back.

Thank you for reading my article. Peace!

The complete learning path for Front-End developer (Online courses)

Denis Veleaev — Fri, 21 Aug 2020 07:10:14 +0000

Hey! 👋

I'm a Front-End (React) Developer and an IT mentor at CoderDojo. People often ask me how to become a developer, what resources I would recommend, what is the correct order for learning these technologies. As a person who constantly watches courses online and learned A LOT from them, I think I've got a pretty decent answer.

So, let me share with you the courses that had a great influence on my career. And BTW I want to say special thanks to the authors of these courses because without them I'd probably become a vegetable seller. This is not an advertisement, although I would like it to be...

First things first: HTML + CSS

Since this is the very first topic you should touch, there's quite a lot of information on HTML and the basics of CSS on the Internet. But there is one resource that I've found very decent. I like Jonas Schmedtmann's course not only because it's very comprehensive. Jonas is a great designer and walking through this course you'll build the web pages that look amazing! We all know how hard it is to maintain the motivation at the beginning of your learning journey, but I promise that the web-artworks that you'll create with this course will provide you instant gratification. You'll be proud of what you're doing, trust me :)

Build Responsive Real World Websites with HTML5 and CSS3 by Jonas Schmedtmann

Second things second: Advanced CSS

Try to ask a Back-End Developer "Why didn't you choose Front-End?". Chances are good that you will receive something like "I hate CSS. I just can't do it". For some unclear reason, a lot of people think that the ability to use CSS is God's gift. News flash — it isn't 😊. The delusion is probably caused by the fact that it is easy to start working with CSS, but it requires a lot of time to master it. And again, I think that the best option to start with it is another course by Jonas Schmedtmann. The author dives deep into important topics like Flexbox, CSS-Grid, preprocessors, project structure, BEM methodology, etc. I really do recommend it!

Advanced CSS and Sass: Flexbox, Grid, Animations and More! by Jonas Schmedtmann

The heat is getting higher: JavaScript

JavaScript is without hesitation the most important skill for you as a Front-End Developer. I am a supporter of the not very popular opinion that the fastest and most effective way to master it is as follows:

Learn the basics of JavaScript
Learn React (or another framework/library)
Understand that you don't know the basics of JavaScript
Truly learn JavaScript

Don't try to learn every little JavaScript detail from the beginning. It will be much easier for you to understand and prioritize many things if you already have some practical experience. But don't be fooled by a too superficial understanding of the basics.

At the beginning of your JavaScript journey I'd recommend one of these tho courses:

The Complete JavaScript Course: Build Real Projects! by Jonas Schmedtmann

JavaScript - The Complete Guide(Beginner + Advanced) by Maximilian Schwarzmüller

Time to choose your destiny: React, Angular, Vue

Now you're ready to learn how to handle real power. There's no need to learn all of them. At least for the start, you'd better pick one of the frameworks/libraries. I'm really into React but I don't want to start a holy war about what technology is better (although React is the best 😊). I tried them all and can confidently say that Academind (Maximilian Schwarzmüller) has excellent courses about all three:

React - The Complete Guide (incl Hooks, React Router, Redux) by Maximilian Schwarzmüller

Angular - The Complete Guide (2020 Edition) by Maximilian Schwarzmüller

Vue JS - The Complete Guide (incl. Vue Router & Vuex) by Maximilian Schwarzmüller

The "T-word": Unit Testing

I know that you hate it. I hate it too. But we have to live with what we've got. The process of testing is especially painful when you try to come up with weird hacks because of a lack of knowledge. And probably the best way to gain this knowledge is an awesome course on unit testing by Kent C. Dodds. Everybody in the community knows him. He truly deserves trust. After all, he gave us the react-testing-library. Definitely the best resource on unit (and not only unit) testing I've seen:

Learn the smart, efficient way to test any JavaScript application by Kent C. Dodds

JavaScript on steroids: TypeScript

Another great Maximilian Schwarzmüller's course. If you truly master TypeScript, you'll insanely improve the quality of your code! There're a lot of people with a superficial understanding of TypeScript... Please, don't become one of them. This course (and a lot of practice) will help you to become a Master Yoda of TypeScript.

Understanding TypeScript by Maximilian Schwarzmüller

Think out of the box: Node.js

What? Isn't it for the Back-End?! Technically it's not only for BE but I do want to talk about the Back-End part. At some point in your career, you'll most probably want (need?) to try the Back-End part or even become a full-stack developer. I've taken a few courses on this topic and the one I like the most is created by Andrew Mead:

The Complete Node.js Developer Course by Andrew Mead

There ain't no REST for you: GraphQL

Even though GraphQL is not that new technology (in Front-End development world things are changing so fast that there will likely be released a fancy new framework by the end of this article), REST is still much much more popular. But I'm sure you'll want (or need) to give it a try. After all, as a good person once said "No sane person would choose REST instead of GraphQL". It's hard to find the course on this topic that is not out of date. For today I think this one is quite decent:

The Modern GraphQL Bootcamp (with Node.js and Apollo) by Andrew Mead

What? JavaScript again?: The Hard Parts

As I previously said, the vast majority of us (devs) at some point have to realize that "we know nothing". I love Will Sentance's course from the bottom of my heart because he dives deep in very important topics that you probably missed during your first cycle of learning of the basics. The author uses only the whiteboard to explain the concepts. I like it so much that I even give such lectures for the interns in the company where I work. It helps a lot in preparation for an interview.

JavaScript: The Hard Parts by Will Sentance

Conclusion

If you watched all the mentioned courses, I'm sure you are a decent specialist. One thing I wanted to mention before the end is a trap for Front-End Developers. Our JS world is probably one of the most fast-changing in the industry. It's almost impossible to be on top of all new technologies. You can probably feel the same "fear of missing out" because of that as I do. I've recently come across a wonderful Kitze's Talk on how to "Navigate the Hype-Driven Frontend Development World Without Going Insane". Please, enjoy what you're doing and live a balanced life.

Peace.

Thanks again to all the authors of these amazing courses, and also thank you, the readers. Feel free to follow me on Twitter @DenisVeleaev. I'm at the beginning of my blogging path. Hope you will like it.

Also, I would like to see your recommendations.

Honorable mentions

What I've learned during the year teaching IT to children as a volunteer.

Denis Veleaev — Mon, 06 Jul 2020 14:22:02 +0000

Hi! For last year I’ve been teaching children IT disciplines as a volunteer in Coder Dojo (The community of 2272 free, open and local programming clubs for young people in 100+ countries). Well, I’d say “teach” is the wrong word. In our Dojo we apply so-called “Project-based learning”. Me and 2 other outstanding people have been helping children with everything they want in the field of IT (game development, web development, graphic design, SMM, AR effects for Instagram, etc.)

Initially, I thought I’ll teach these children. In fact, I think I’ve learned from them much more. So, today I want to tell you why I think you should definitely try IT volunteering.

Here’re conclusions that I’ve made this year:

We’re extremely lazy

Sorry for that, but for the vast majority of us, it’s true. As a volunteer, I visited several IT events and competitions for young people. I met a lot of talented children and, to be honest, it was a challenge for my ego. These outstanding children and teens create serious projects in domains such as Machine Learning, IoT, robotics, game dev, etc. I’m pretty sure that some of them could probably replace some of your colleagues right now. And that’s not because they are so talented. They are not geniuses. They simply work hard! And this drives me to work harder.

It’s normal to try and fail

In fact, it’s the only way to grow. You should fail a lot! I know that might sound corny, but we forget about this simple truth so often. We’re so afraid of failing that we don’t even try. The children, on the contrary, try and fail a lot. And that’s how they find their interests, their strengths, and weaknesses. And, guess what, nobody cares about your failure, so, please, don’t be afraid! (To be honest, I’m afraid to publish this article :))

Internal motivation is far more powerful than external

What drives you as a professional? What was your motivation when you started learning IT disciplines? I’m pretty sure that the majority of us didn’t start learning because of money. And I really hope you managed to keep this spark inside you because after hard work that’s the main driver of growth. Internal motivation not only helps you to grow faster, it really makes you happier. And that’s the distinguishing feature of the most talented children (and grown-up colleagues as well). So, if you don’t feel this fire, you should probably do something with it.

All the limitations are only in your head

As I said, I’ve met a lot of teenagers who already can replace some of your colleagues. The secrets are hard work and passion. And nothing else matters.

It’s normal to be a generalist

Even more, it’s cool! As a developer, I often heard something like “You should know everything about ”. And that’s okay unless it’s not for you. Some people are generalists, and despite their narrow niche they want to have at least superficial knowledge of other fields. And that’s what helped me a lot with mentoring children.

Grown-ups are simply big children

Well, what I wanted to say is that this experience of working with children helped me when at my workplace I got my first junior assistant and had to help her get onboarded fast in a quite complex project. So, If you want to become a better leader or mentor, I definitely recommend you to try volunteer teaching.

It really extends your network

I wish I knew it earlier that volunteering gives you the possibility to enormously extend your network with amazing people. It’s hard to explain how it influences you, but it’s easy to understand the benefits of being familiar with the most “significant” people in the IT domain in your location.

In conclusion

I want to say I found what makes me happy. I will not exchange for anything the look of the burning eyes of people who give their whole soul to their beloved work. And I am very glad that I have the opportunity to help them with this. I hope my experience was useful to you. I really want this community to continue to grow.

DEV Community: Denis Veleaev

Why do you abandon your personal projects?

Personal projects. Do you work on them? Have you finished one?

Hi. 👋

Please please please answer these questions:

5 SOLID principles with JavaScript. How to make your code SOLID

Hi 👋! I'm Denis.

What are SOLID principles?

S — Single responsibility principle

Example

O — Open closed principle

Example

L — Liskov substitution principle

Example

I — Interface segregation principle

Example

D — Dependency Inversion principle

Example

Conclusion

6 simple rules to fully understand "this" keyword in JavaScript

Rules

1. new keyword

Example

2. apply / call / bind

3. Function as a method

4. The simplest case

5. The order

6. Arrow functions

Test yourself!

Conclusion

How to be mentally healthy and what you should pursue in your career

Hey! 👋

Are you happy with your job? Do you understand why?

1. The team is the most important factor

2. You are the arithmetic mean of the people around you

3. Understand the most suitable role for you

What I've found out thinking about my role:

4. All the people are different

5. Balance is crucial

6. Don't burn out

7. FOMO is your enemy

Conclusion

The complete learning path for Front-End developer (Online courses)

Hey! 👋

First things first: HTML + CSS

Build Responsive Real World Websites with HTML5 and CSS3 by Jonas Schmedtmann

Second things second: Advanced CSS

Advanced CSS and Sass: Flexbox, Grid, Animations and More! by Jonas Schmedtmann

The heat is getting higher: JavaScript

The Complete JavaScript Course: Build Real Projects! by Jonas Schmedtmann

JavaScript - The Complete Guide(Beginner + Advanced) by Maximilian Schwarzmüller

Time to choose your destiny: React, Angular, Vue

React - The Complete Guide (incl Hooks, React Router, Redux) by Maximilian Schwarzmüller

Angular - The Complete Guide (2020 Edition) by Maximilian Schwarzmüller

Vue JS - The Complete Guide (incl. Vue Router & Vuex) by Maximilian Schwarzmüller

The "T-word": Unit Testing

Learn the smart, efficient way to test any JavaScript application by Kent C. Dodds

JavaScript on steroids: TypeScript

Understanding TypeScript by Maximilian Schwarzmüller

Think out of the box: Node.js

The Complete Node.js Developer Course by Andrew Mead

There ain't no REST for you: GraphQL

The Modern GraphQL Bootcamp (with Node.js and Apollo) by Andrew Mead

What? JavaScript again?: The Hard Parts

JavaScript: The Hard Parts by Will Sentance

Conclusion

Honorable mentions

What I've learned during the year teaching IT to children as a volunteer.

Here’re conclusions that I’ve made this year:

We’re extremely lazy

It’s normal to try and fail

Internal motivation is far more powerful than external

All the limitations are only in your head

It’s normal to be a generalist

Grown-ups are simply big children

It really extends your network

In conclusion

1. `new` keyword

2. `apply` / `call` / `bind`