Articles

How to take a good break

Published on:

When I wrote about my [productive routine](/blog/becoming-more-productive-while-working-less/ 'Becoming more productive while working less') in a previous article, I said I'd work for 1.5 hours and take a break 30 minutes. And I'll repeat this sequence four times a day.

In my experiments, I reduced my work hours to 4.5 hours (3 x 1.5-hour slots) and managed to get 40% more work done.

The key to this routine isn't simply sitting at my desk for 1.5 hours each sprint.

The key is 30-minute break.

If I don't rest properly, I'll waste the next 1.5 hours of work because I'm not focused. When I'm not focused, I can't get work done.

So today, I want to share how I take a proper break.

How to review and edit a pull request

Published on:

When you submit a pull request, a collaborator will have the right to review your pull request. They'll decide whether to accept your pull request. If they accept your pull request, your code will be merged into the branch you requested for.

You're going to learn how a review process will look like from both points of view:

  1. The person who's reviewing the process
  2. The person who's submitting the review

Getting out of a productivity funk

Published on:

It's ironic. I became unproductive after releasing an article about [increasing productivity while working less][1].

I got thrown into a situation where I couldn't find space and time to work for about a month.

I want to share with you what happened, how I handled the situation, and the lessons I learned. This article will help if you found yourself in a productivity funk.

How to submit a pull request

Published on:

Let's say you wrote some code on the develop branch. You're done with what you were working on, and you want to merge it to the master branch.

But you don't know whether the code you've written is good enough. You want someone to review your code before you merge it into the master branch.

You can do that with a pull request

Creating a simple form with CSS Grid

Published on:

You learned to create a simple form with Flexbox in the [previous article][1]. Today, you'll understand how to create the same thing with CSS Grid.

Here's what we're building:

<Image src="/assets/2018/simple-form-css-grid/form.png" alt="The simple form we're building consists of one email input and one submit button" />

How to use Git stashes as a temporary storage

Published on:

Let's say you're coding on your development branch. And you get a notice that there's a bug on the production branch.

You want to check for the bug, but you don't want to lose the work you've created on the development branch. You also don't want to commit what you've written because they're not done yet.

What do you do? You can't commit and you can't switch branches. If you switch branches, things that aren't committed will flow over to the branch you switched to.

What you want to do is save the changes somewhere temporary while you switch over to another branch. **A Git stash is that temporary storage. **

Creating a simple form with Flexbox

Published on:

The simplest form on the web contains an email field and a submit button. Sometimes, the email field and the submit button is placed on the same row, like this:

<Image src="/assets/2018/simple-form-flexbox/form.png" caption="Email and submit button on the same row" />

This UI looks simple! But it can be difficult to build if you're using older methods like inline-block. The hard part is getting the email field and button to align visually.

The great news is: CSS Grid or Flexbox can help you build this form easily.

How I remember CSS Grid properties

Published on:

The syntax for CSS Grid is foreign and hard to remember. But if you can't remember CSS Grid's syntax, you won't be confident when you use CSS Grid.

To wield CSS Grid effectively, you need to remember its properties and values.

I want to share how I remember the most common CSS Grid properties today. This will help you use CSS Grid without googling like a maniac.

Semantic Versioning

Published on:

We created numbers like 1.0.0 and 1.0.1 for releases and hotfixes when we worked on Git Flow. What do these numbers represent, and why do we use them?

These numbers represent the version number of the product we put out in the world. We use them because we're following a best practice called Semantic Versioning.

When we use Semantic Versioning, developers will know whether a change will break their code. The numbers give a clue to the kind of changes that have occurred.

Many popular projects use Semantic Versioning. Examples are React and Vue.

Becoming more productive while working less

Published on:

I don't have time to learn.

Many people say that to themselves. I say that to myself too.

I haven't learned much this year because I was on a tight schedule to create content. I had to create one article and one video every week for the blog. I also had to create as many Learn JavaScript lessons as I can.

And I was almost burned out. I was unhappy and depressed.

Learning is important to me. When I don't learn, I start to feel guilty.

One day, I decided enough was enough. I had to change up my schedule to allow time for learning. I did some experiments over the next few weeks and found a way where I could give myself 1.5 hours to learn every day. The best part is, I created even more content than I did before!

I want to share with you my experiment and how I tweaked my schedule to allow time for learning. I hope it'll help you find some time to learn as well.

Managing your Git branches with Git Flow

Published on:

How do you manage your git branches if you have many of them? For this, we have a well-known method called the Git flow.

It contains five types of branches:

  1. The production branch
  2. The develop branch
  3. Feature branches
  4. Release branches
  5. Hotfix branches

We'll go into what each type of branches do and how to create them in this lesson.

When will Learn JavaScript be completed?

Published on:

The most common question I get about Learn JavaScript is: "When will Learn JavaScript be complete?"

If you don't know, Learn JavaScript is my flagship JavaScript course. [You can find out more about the course here](https://learnjavascript.today 'Learn JavaScript with Zell').

The best answer I could come up with was: "I don't know".

I hated myself for saying that.

I've been writing Learn JavaScript since last August. I promised myself a certain deadline twice. And I failed to hit the deadline twice. I feel ashamed for creating content so slowly.

I came to a point where I'm scared to promise a deadline. I don't want to disappoint my students. I don't want to disappoint myself either.

But I realize that I can't say "I don't know" to students who already bought the course. They have a right to know. So today, I'm going to overcome my fear and provide you with a proper estimate.

What is a branch in Git?

Published on:

Note: This the seventh video in the Git for beginners series. Watch the first video here.

Imagine there are parallel worlds. We have:

  1. A world where I have created this video, and you're watching it.
  2. A world where I have created this video, but you're not watching it.
  3. A world where I did not create this video.

In this parallel world concept, a Git branch is a parallel world.

You can have a branch that stays the same in one world. Then, you branch off into a different world. Once you finish your code, you can complete the initial world by merging the changes into it.

Changing my refund policy

Published on:

When I launched Learn JavaScript in July 2018, I used a refund policy that says:

> "I’m happy to refund your money if you don’t manage to learn JavaScript through this course. Send me an email within 60 days, show me you did your homework and I’ll send your money back."

I want to let you know that I'm changing to a new refund policy. I want to tell you about the new policy, and why I'm changing it.

Resolving Git conflicts

Published on:

Note: This the sixth video in the Git for beginners series. Watch the first video here.

Let's say a friend of made a change to your repository and pushed the changes to the Git remote. At the same time, you also made a change to the same line of code.

When you pull their changes into your local repository, you'll notice that there is a conflict.

This happens because Git no idea whether their version is the updated version or your version is the updated version.

This is what we call a Git conflict.

You'll learn how to resolve a Git conflict today.

How to use the :empty selector and the :blank selector

Published on:

I made a terrible mistake when I tweeted about :empty and :blank a month ago. I said that :empty wasn't useful, and :blank is much more useful than :empty.

<Image src="/assets/2018/empty-and-blank/tweet.png" alt="Blank is not supported by any browser" />

I was wrong!

:empty is actually good enough. We don't even need :blank!

Cloning a Git repository

Published on:

Note: This the fifth video in the Git for beginners series. [Watch the first video here][1].

Let's say you want to work on a project together with a friend. The two of you will be creating commits on the same project.

Let's also say your friend has created the project. They initialized a repository on Github.

What you need to do next is to copy the project from the remote to your computer.

In Git, you can do this through a Git Clone.

What makes a good frontend developer?

Published on:

The frontend development industry is getting confusing nowadays. More people think that frontend developers are people with great JavaScript skills.

But there's more to frontend development than JavaScript.

And as professional frontend developers, we need to understand what our jobs are.

Pulling from a Git remote

Published on:

Note: This the fourth video in the Git for beginners series. [Watch the first video here][1].

When you make a change to a local repository, you can push a change to a Git remote. Likewise, when the remote gets changed, you can pull the changes back to your local repository.

Today, you'll learn how to do the pull from the remote back to your repository.

Stop using big words and industry jargons (and what to do instead)

Published on:

Let's say you want to teach a person something. Why does the person not understand what you're saying?

One of the main reasons is because we like to use big words and industry jargons. These jargons may mean something to us, but they mean nothing to the people we're trying to teach.

The next time you try to teach programming, watch out for the words you use.