9 tips that made me speed up my workflow as a front-end developer

If you save 5 seconds on a task that you repeat at least 12 times per day, that means that you save one minute per day, after three months that’s almost an hour. If you can do the same with 9 other tasks, at the end of the year you will have saved 40 hours, which is an entire week of work.

In this post I will share some tips I use to save those few seconds that make the difference. I will go from the most minimalist things (installing some plugins in your code editor) to more complex changes that will require you to modify your habits.

Use Emmet

Writing HTML code is much faster with Emmet

If you have to write a lot of HTML and you don’t know Emmet yet, I am pretty sure this will change your life. Emmet allows you to write HTML code as if it was CSS selectors. So:

nav#navigation-menu.menu>ul.menu-list>li.menu-list-item-$*6>a.menu-link

Will generate this:

<nav id="navigation-menu" class="menu">
  <ul class="menu-list">
    <li class="menu-list-item-1"><a href="" class="menu-link"></a></li>
    <li class="menu-list-item-2"><a href="" class="menu-link"></a></li>
    <li class="menu-list-item-3"><a href="" class="menu-link"></a></li>
    <li class="menu-list-item-4"><a href="" class="menu-link"></a></li>
    <li class="menu-list-item-5"><a href="" class="menu-link"></a></li>
    <li class="menu-list-item-6"><a href="" class="menu-link"></a></li>
  </ul>
</nav>

Cool right? Imagine now how much time you could have saved thanks to this.

Emmet also works with CSS files, so:

.menu {
  mt: 5px;
}

Will become:

.menu {
  margin-top: 5px;
}

Make sure to install it in your code editor and check the documentation and cheatsheet.

Spammy note: if you hadn’t read it yet, take a look at my previous article “8 CSS selectors DO’s and DON’Ts” to help you write correct CSS selectors.

Use a multi-cursor code editor

When I used a code editor with multi-cursor for the first time I thought “ok, I can do the same with copy-&-paste or with search and replace”. But since I’m a curious guy, I forced myself to use the multi-cursor for some days instead of the other options.

Now, I feel it’s much faster than the previous solutions I was using and I even feel uncomfortable if I have to use a code editor with no multi-cursor.

Create git aliases

git ucm and git st are faster to write than git reset HEAD~ and git status

Create aliases for the git instructions you use the most. You can get them from one of the many lists available on Internet or create your own. That has the advantage that you can choose what aliases you create and keep updating it as your git habits change.

These are the commands I run after installing git to create all the aliases I need:

git config --global alias.st status
git config --global alias.co checkout
git config --global alias.cm "commit -m"
git config --global alias.ucm "reset HEAD~"
git config --global alias.d diff
git config --global alias.dc "diff --cached"

Learn the shortcuts of the programs you use

You don’t have to remember the entire list of shortcuts of all the programs you use, just learn the ones you will use more.

I can’t stress enough how important this is. You can save a lot of time controlling your programs with the keyboard instead of the mouse. Pressing keys is much faster than moving the mouse up and down and pressing tiny buttons.

Most programs include a list of shortcuts in their docs. Go check it on their website or in the settings panel of the application and learn one every day for the tasks you repeat the most.

Sooner than later you will realize you barely touch the mouse during all day.

Make your programs work the same way, so you can reuse your muscle memory between them

The programs I use all the time when programming are Atom and Firefox. If I’m not wrong, by default they switch tabs (with Ctrl+Tab) in a different way: Firefox goes from left to right and Atom moves to the previous active one.

I feel Firefox’s behavior is more predictable, so the first thing I do after installing Atom is to change that setting.

Use the terminal when possible

During my life I met many people who are afraid of the command line and try to get GUIs for every tool they use, some others use (or pretend to use) vim and emacs every day. I believe the best option is somewhere in the middle: having a user interface is great, but if you can use the console you will probably be faster.

Force yourself to use the console for some days, once you get practice, decide which one is better.

Set linting rules as the first thing when starting a project

If you had set up a linting process in a project that never had one, you will know how painful it is to fix dozens, hundreds or even thousands of errors that could be fixed at the moment of writing the code.

Most linting tools nowadays include an autofix setting, which is awesome, but it usually doesn’t support all rules so the problem is still there.

If you set your strict linting rules in the beginning, you will force yourself to learn to code following those rules. If some day you regret about a rule, it’s easier to make it more permissive than more restrictive.

Teach yourself about the technologies you’re using

Usually you learn more directly reading the code than searching on StackOverflow

Right, it’s fun opening your code editor, checking a couple of code examples and start programming without knowing more or less what you are doing. Indeed, that’s how most of us learned to code in the beginning, that’s not the driving license where you have to study a book and pass an exam before you can take a car, here you can write your own program and execute it without almost any risk.

However, as time goes on, it’s better to spend some time reading documentation and exploring the code of the libraries you use.

You want to do something with that library and don’t know how? Right, you can go to StackOverflow but it’s even better if you can find the same answer in the documentation. It will include a detailed explanation of what it does and any advice you need to know before using that tool or function.

There is an npm package that doesn’t work as you expected? Go and search it in GitHub, download it and experiment with the code. You might have found a bug or it might be you who didn’t understand how it was supposed to be used.

If you learn how to do something, you would have solved your problem now. If you learn why you have to do something that way, you will have solved many future problems.

Use TDD

Start your project with TDD in mind or it will be too late in the future

Any Front-End developer that writes JavaScript with a minimum level of complexity should be using Test Driven Development (TDD).

It consists on writing code that will test your code at the same time you write your code.

It might feel tedious in the beginning and you might think you are slower, indeed you probably are in the short term. But having tests will make you faster in the long term.

You will be able to make changes in your codebase with confidence that you don’t break something else (even though it can still happen). Writing tests also makes you read your code a couple of times before publishing it, which might prevent some silly errors or typos you might have missed.


Those are only some examples that came to my mind while writing this, but for sure there are many more things we can do to improve our routines as front-end developers.

Feel free to share if you know one!

Leave a Reply