Open source is one of the most fascinating things I’ve ever encountered in our industry. It is a movement that essentially groups people together to work on a product because they want to. They usually do it for free, especially during the first stages of the project, and then — get this — they maintain it so that others can use it. Also for free.

I tend to think that if more industries were to adopt open source as we do in software development, things would be a lot easier. Then again, that’s not why we’re here. …

The dream of being your own boss is one that almost everyone goes through at some point during their career. For some strange reason, we tend to believe we can do away with concepts such as “boss,” “9 to 5,” or “team meetings” and just sit down, put our head down, and work on what we love. Like that would solve all our problems.

In some cases, this notion becomes more than just a dream; some people actually succeed at freelance. More often than not, it either remains a dream or quickly becomes a nightmare. …

There is no substitute for good documentation. The more you document the happier your users will be. There is a point, however, where you start getting diminishing returns. In other words, once you pass a threshold the more you keep documenting the less happy your users will be.

What?

Yeah, you have to find a sweet spot, just enough to explain your project but not too much to overwhelm your user. And when it comes to documenting Node.js modules, then the easiest way to do it is to create a comprehensible Readme file.

The structure of a good ReadMe file

The Readme file is normally the first…

Being stressed out because you have pending code to write or not being able to stare at your IDE for longer than 10 minutes without tabbing out and browsing the Web — are both symptoms of developer burnout. In other words, you’ve spent so much of your energy coding that you no longer can stand it.

This happens to all of us senior and junior devs alike. It’s the problem of having a job that sometimes is also a hobby. …

The fact that multiple teams live under the umbrella of the same company doesn’t automatically mean they’ll be easy to coordinate. From a software development PoV multiple issues can (and normally do) happen when standards aren’t enforced.

Problems such as lack of a common development environment or real understanding of the entire toolset used by all teams. These issues can cause havoc ranging from increased development time to problems during the dev workflow.

The normal way to solve these types of problems would be to enforce a standard toolset for the entire company and then train everyone around them. But…

When we think about measuring the performance of our applications we tend to drift towards the backend environment. We picture metrics such as resource utilization, disk I/O operations, memory leak detection, response times, and more. However, given the complexity of today’s web interactions it’s not that crazy to think that we also need to understand how to focus our performance measuring efforts on the UI.

But how can we do that? Browsers don’t really perform I/O operations on the client disk, can we somehow measure memory utilization? What else can we analyze?

While it is true that if you want…

After working for a while with Node.js I’ve come to the conclusion that there is no better tool to use when writing microservices. Of course, that is my opinion, completely biased by my preference for JavaScript as a language. But hey, even without me pushing my own opinion into your eyes, I bet you can’t say Node.js isn’t a great tool for building microservices.

It provides very fast development times, lots of pre-existing frameworks and the async I/O allows for fantastic performance when dealing with a multitude of simultaneous requests.

And while Node.js by itself is a great tool, it’s…

When you’re working with a team of multiple developers on the same project, one of the main things you want to do is to standardize their development environment. This ensures everyone is using the same tools, the same configurations and thus goes through the same process when working.

The problem is that achieving a standard dev environment is not easy due to the number of tools we tend to use. For instance, take the workflow of a team working on a Node.js project writing their code with TypeScript. You’ll need:

• A standard tsconfig.json file.
• A standard linter file.
• A standard…