How I Became 10X More Productive As A JavaScript Developer

How I Became 10X More Productive As A JavaScript Developer

Or the importance of quality and automation

From the moment I started React as an Engineering student to the present day, a lot changed, especially my productivity. For the same result, my time spent on coding, delivering and fixing bugs has greatly decreased.

There is a common misconception about how much time is really spent on a task in code-related jobs. A feature is finished when it’s in production and bug-free (and often more), not when it looks finished on a developer local environment.

That’s how you can increase your productivity, of course on time spent writing code but even more by increasing the speed of deployment and reducing time spent on bug correction.

Writing code

Yes, with practice you’ll get better at understanding and using your libraries, frameworks and environment. That means, better and faster at taking technical choices and writing code, but you’ll quickly hit a ceiling. That’s when some new practices might interest you.

Reading code

Funny enough, your productivity in writing code is heavily linked to reading it. I can’t say how much I LOVE this sentence from Clean Code: A Handbook of Agile Software Craftsmanship: “Indeed, the ratio of time spent reading vs. writing is well over 10:1.”.

So how to spend less time writing? Start by spending less time reading. In my opinion (and by experience), some practices should be mandatory :

  • Typed JavaScript: at a glance, typed code will give you much more information on what you are actually doing.

  • Linter: lots of poor practices can make your code less readable, any well-configured linter would give you a boost in productivity

  • Code formatting: as useful as a linter, will keep you from writing code you will regret later on.

Also, with experience you might enter a virtuous circle: writing good code makes it more readable, allowing you to write even better code, etc.

Inside your IDE

The time spent on learning how to use your IDE will be worth it. A well-configured IDE will make your life easier, if you cannot start working instantly after starting your favorite IDE, maybe there is something wrong.

Basics features anyone should master are: shortcuts, handling different files and projects, GIT, search (and replace), debugging and plugins.

We talked previously about types, linter and formatter. There is almost always a plugin to make use of those functionalities.

A more advanced feature can be code snippets. A lot of plugins can add some for you but I 100% recommend you to add the ones you need yourself.

Clear structure

Spending time looking for a file is a no-go, that is one of the difficulties I experienced as a React developer: how to structure your app, files and directory-wise.

A good start would be to respect separation of concerns³ (SoC), i.e. keep apart components from requests, translations, etc.

Regarding React, there is a lot of discussion about it, but no perfect solution, as well for Redux.

Another good practice I use regarding files is to avoid more than 7 files and directories in the same directory.


Sometimes, we’ll be talking about boilerplate. Do you feel like doing the same thing, again and again, when starting a new project?

Then, maybe looking for a serious starter project or creating your own could save you a lot of time.

Reinvent the wheel

In the same way, we have access to a huge amount of open-source packages. Did you ever need lodash⁶ or react-hook-form? Maybe deepmerge?

We, developers, love writing code. Sometimes maybe too much, a good knowledge of useful packages is valuable.

Don’t reinvent the wheel.

Bug correction

Our aim is not only to quickly correct unwanted behaviors but to prevent them in the first place.


A practice that will definitely helps in preventing unwanted behaviors is Test Driven Development (TDD).

TDD alone is a whole and complex subject. As we are here discussing productivity, I’ll say the following :

Your productivity will decrease, you heard me right. When you’ll discover the wonders of Test Driven Development for the first time, you’ll go insane and spend more time writing tests than it would take to fix bugs.

But, good news, that’ll only be the beginning. Once you have a certain level of mastery regarding unit/integration testing and TDD, you might spend less time writing tests and coding than you were just writing code before.

And I’m not even talking about the stakes of an app in production yet. How valuable is this? Not only increasing productivity but avoiding errors in production as well as any regression.

What’s important is not only testing but good testing politics. After TDD and unit/integration testing, you’ll discover functional, e2e, contract, and a lot more testing practices. You’ll learn about coverage and mutation testing.

Can you test everything? What do you test? Those questions will need an answer.


  • If something bad happens, are you aware of it?

  • If you are aware of it, do you know why it happened?

Or do you spend hours looking for a badly spelled property? That’s when monitoring comes in handy.

Every time you write “console.log”, someone deletes a production database by mistake.

There is plenty of monitoring tools out there. Among them, sentry, datadog, dynatrace or splunk. In my experience, was enough but you might need something else depending on your needs.

Process & Deployment

I’ll consider that, in today’s age, you are using GIT.

First, a well-defined process/structure is a must. You should be able to easily work as a team and deploy without any hassle. I’ve been using GitFlow for a few years now and I never left it.

Earlier, we discussed using linters, formatter and tests. Those will help you verify your app can be deployed using two tools: GIT Hooks and pipelines.

GIT Hooks

I use git hooks to run quick and cheap scripts. This shouldn’t bother developers (and make them want to bypass it).

Running at least eslint and prettier before committing or pushing is a great way to not waste time later on.

Code review

Depending on the project, code reviews are set up as part of GitFlow. We aren’t gaining time by doing code reviews, we avoid losing more!

Feedback given by those reviews is valuable, as a new eye can quickly help identify new problems. They are also a great place to pass on knowledge.

Pipeline & Quality

Pipelines are also a complex subject. The main ones are GitLab CI/CD, CircleCI and Travis CI.

I’ve been using GitLab for a long time and absolutely love it! This pipeline is a big part of my strategy :

  • As part of GitFlow, branches are created for every task. Unit/integration tests are run with eslint and prettier

  • Once merged on my develop branch, those tests are re-run on the new version, with e2e tests.

  • Once merged on release, depending on the project, those tests are run on a replicate of the production environment.

  • They are then merged on master and tagged.

Automated Release

Who is responsible for creating a tag from master? How do you decide if it’s worth creating, and what name do you give this tag?

Tags can be accompanied by a release. In the same way, who is responsible for creating it and its content?

Well, out there are tools such as semantic-release and standard-version that can handle it for you. My favorite is semantic-release, which automates your whole release process.

semantic-release automates the whole package release workflow including: determining the next version number, generating the release notes and publishing the package.


Not only are tests run on my pipeline but once successful, my app is deployed differently :

  • On develop, the app is deployed on a cheap development environment.

  • On release, the app is deployed on a close-to-production environment.

  • Finally, once tagged, the app is deployed to production.


This process allows me and my team to develop/deploy quality applications while avoiding mistakes and time loss.

In the end, all those practices are linked to each other. Increased readability decreases not only writing time but also bugs (which means less deployment).

Not only will those practices help you be productive but will make you even more valuable, as they will help avoid expensive unwanted behaviors.

Cover photo by krisna iv on Unsplash