DEV Community: Mauro López

Nothing is like it seems: Asynchronous in JavaScript

Mauro López — Sat, 24 Jul 2021 17:24:46 +0000

In the following, you will understand what means asynchronous in JavaScript and why it is important, using as an example a song from the Ramones

JavaScript it’s a useful and amazing language. You can write tons of applications in different environments: backend, frontend, desktop, mobile... and all with the same language!! It all is possible because of its characteristics and asynchronous is part of the reasons.

Asynchronous as a concept brings us a lot of pros, however it can be kind of tricky at the beginning, basically because sequences are different from what we could expect. What did I mean? Let's see the following code

function hey() {
  console.log("hey");
}

function ho() {
  setTimeout(() => {
    console.log("ho");
  }, 0);
}

function lets() {
  console.log("lets");
}

function go() {
  setTimeout(() => {
    console.log("go");
  }, 0);
}

function song() {
  hey();
  ho();
  lets();
  go();
}

song();

Explanation of code

In the past code, we had 4 methods, all prints something in the console. 2 of them have a timeout function inside of them but both wait 0 milliseconds, so it gives us the idea that they shouldn't stop any time

We should expect an output like this:

// hey 
// ho
// lets 
// go

But we got this:

// hey 
// lets 
// ho
// go

weird, right? let's try to find answers to that mystery

What happened

Well, it’s important to know that JavaScript supports synchronous and asynchronous code. Synchronous code is executed just after being read and asynchronous is executed “later”, but in this case, later does not mean after now, it means at one point in the future that we don’t necessarily know when it will be.

As we could suppose, in the past example we got both types of instructions. Synchronous in methods hey and lets and asynchronous in methods ho and go.

// call order:
function song() {
  hey();    // synchronous
  ho();    // asynchronous
  lets(); // synchronous
  go();  // asynchronous
}

// execution order:
// hey 
// lets  
// ho
// go

Regarding that, it can be explained how a method (ho method for example) can be called before another one (lets method) but the last method to be called (lets) shows the results first anyway.

Why is asynchronous important

The short answer is because JavaScript is single-thread.

A more detailed answer should start with what is behind the fact of being "single-thread", which means that JavaScript has just one call stack and that at the same time can be understood as that it only can do “one thing at the time”.

Single-thread -> one call stack -> one thing at the time

In simple terms, we just can do one thing at a time and If the call stack is busy, our application will be busy. So, we want our call stack to be as less over busy as we can, but sometimes there are tasks that no matter what we want, will take their time to be executed (request to an external API for example) and that inevitably will block the stack until the task ends the execution.

How does JavaScript solve that problem? There is a famous catchphrase that recommends “think outside the box” and in this case, JavaScript does it LITERALLY because it takes off the "slow" tasks from the stack and executes them in another place.

So using asynchronous code JavaScript is able to avoid the overload of the call stack, thus by the execution of "slow" tasks out of the stack somewhere we can do more than one thing at a time.

For example, the I/O operations in Node.js are offloads to the system kernel whenever possible, taking advantage that modern operating systems’ kernels are multi-threaded.

Nothing is like it seems...

Nothing is like it seems, that’s right, but now we know that the execution order is different from what we expect because there are some methods that execute asynchronously. And they executed this way in order to keep the call stack the freest possible because there is only one and if it is busy, the performance of our app will be affected.

On other hand, it's important to know that asynchronous code in JavaScript can be present in form of promises and callbacks, and once they are resolved, they come back to the call stack pushed by the event loop.

This is just a very small introduction to very important concepts from JavaScript. Understanding the functionality of the concepts helps us to face in a better way many situations we can have while developing JavaScript code. You can keep learning about those in the following links:

https://youtu.be/8aGhZQkoFbQ

https://youtu.be/SrNQS8J67zc

I got 99 problems, but that’s better than one

Mauro López — Tue, 13 Jul 2021 23:07:40 +0000

This is a small collection of some lessons learned facing up different situations in my daily life as a software engineer.

In my opinion, work as a software engineer is nothing but the continuous implementation of solutions to different situations, some of them are technical and others no-technical. No matter the type of situation, each one can teach you many things, even things you thought you knew.

This article pretends to be a support for any dev but especially for those who are starting on this great road

We work with computers, but humans are our principal customer

When I talk about a “customer” I’m not only talking about the final user of the app or the product owner, I’m talking about our co-workers too because, in the end, we are giving a service, the service of build software! And real software is building in teams.

So, to be gentle, kind, and empathetic is very important. Virtuality or the fast pace from routine makes it easy to forget that on the other side of the screen/table, there is a human too. Small actions such as showing genuine interest in others or small talks with your teammates can make the different. Every person is different and great on their own.

You can be a leader, no matter where you are

You don't need to wait until you are in a leadership position in order to perform your leadership. No matter your position you always be able to make suggestions, provide solutions, discuss scenarios, spread a good attitude to the team… and by doing that, you will build relations that will allow you to increase your influence zone every day more.

Visibility is the key

Usually, we have an inner voice that tells us we're lost even before we realize we truly are. In that case, the best approach is to raise our hand as soon as we hear it in order to give visibility to the situation and plan different scenarios.

You don't have to send a red flag to the team at the first time you hear the voice I just mentioned, it’s only to communicate that probably that ticket will require more time than you expected or you’re having troubles with X or Y thing and because of that you will need to add new subtask or increase the remaining time of the task. When the situation progress, you can give updates and in case you require help, the situation will be easier to manage because you gave visibility with time

Documentation is like a hug to yourself (or someone else) in the future

Do you remember the reason why you and your friends went to that new cafe and not to the usual one 4 months ago? Well, basically the same here! Sometimes we make small decisions that make a lot of sense at the moment, but we can forget in the future, and in case that you need to look back and understand the reason for the things, you can save a lot of time if you can find context easily. So, document!! Document your methods, document your tickets, document your pull request, document with clear messages your git commitments… document.

Documentation requires time, but trust me, is a good investment. Also, you can add a subtask in your ticket only to document all the stuff you did there.

Conclusions:

We work with computers, but humans are our principal customer
You can be a leader, no matter where you are
Visibility is the key
Documentation is like a hug to yourself (or someone else) in the future

Postdata:

This article is based on this other written by Avy Faingezicht (even has the same title, but kind of different focus). I decided to write my own version because I feel identified with many situations exposed there and it was very helpful in order to give me a guide for solving some of my situations as a software engineer. For that reason, I would love to share my experience in case it could help others. Also, I recommended you to take a look into Avy Faingezicht’s blog, which has many other interesting articles and cool photos !

Explained: Definition of done

Mauro López — Sat, 10 Jul 2021 22:24:15 +0000

As engineers, our responsibilities don't lie only in writing the code but also to develop a solution that meets standards of quality. To guarantee that quality it is recommended to define what we can expect from a ticket that is done, this is called “definition of done”.

Normally, each team has its own definition of done. For sure, it can change between teams and commonly the responsibilities for developers are:

Make sure to cover ticket accepts criteria
Create Unit test to methods created and updated
Make a pull request and attend requested changes if there is any
Make sure Pull Request is closed before continues process
Make smoke testing of ticket on controlled environment

There are sometimes due to any external situation where your work related to code is done but still the ticket does not satisfy what “done” means to the project, so even when it feels like it is done, the ticket is not yet!!!

It’s very important to know that there exist mechanisms to manage this type of situation. All of them resume on raising your hand, but there are different ways you can raise the hand.

Meeting
Official communication channel
Ticket comments
Email

If daily meetings as stand up take place on your project, you must use them to mention the current situation and also, request the actions to remove the blocker. However, there is a phrase that says “words are gone with the wind”, so if you don't see any movement on your blocked ticket, you should use the official communication channel, as Slack for example, to remember the actions needed. If that doesn't solve the issue you can proceed to write a comment on the ticket and also flag it. If after all this, the situation persists, you can use the email to communicate and explain the context.

Conclusions:

Always have present what “done” mean for your team and make sure your tickets meet those standards
Is totally normal that a random situation appears and blocks your intention to make your ticket accomplish the definition of done, but raising your hand as soon as possible you can mitigate risks.