How I Became 10X More Productive As A JavaScript Developer
By: Teddy Morin
Tags: Development, JavaScript, Productivity, Programming, DevOps

How I Became 10X More Productive As A JavaScript Developer

Or the importance of quality and automation

Photo by krisna iv on Unsplash

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 choice 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 : lot of poor practices can make your code less readable, any well configured linter would give you a boost in productivity

Code formatter : 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), debug 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 difficulty 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 request, 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.

Template

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 times.

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.

Testing

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 test 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 test 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 a 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 question will need an answer.

Monitoring

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 delete a production database by mistake.

There is plenty of monitoring tools out-there. Among them, sentry¹¹, datadog¹², dynatrace¹³ or splunk¹⁴. In my experience, sentry.io 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 linter, 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 in order 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 review are setup as part of GitFlow. We aren’t really gaining time by doing code reviews, we avoid losing more !

Feedback given by those reviews are 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 being 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, branch 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, who automate 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.

Deploy

No 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.

Conclusion

This process allow 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 decrease 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.