How Not to be Stressed as a Developer

There are three main sources of stress that affect developers:

The fear of losing control.
You get stressed because you are afraid of losing control over your code. Do you remember what each line of code does and the logic of your apps?
The fear that something will stop working.
You get stressed because you are afraid that your code will not work correctly. Will you be able to find the bug and fix it fast enough, without causing problems to your client?
The fear of not being able to do your job.
You get stressed because you are afraid that you are not up to the task at hand. Are you skilled enough to build your app? Can you meet the time deadlines?

There are other possible causes, but the great majority of stress comes from these three.
If you can address these sources of stress, then you will strongly reduce your stress too. Maybe even get rid of it completely.

So, let's see how to do that.

Fix #1:
Comment and document your code to remember what it does.

When you work on a project, it's easy to keep in mind its code structure and how it all works. But as soon as you switch to a new project, you will forget most of it.
It's not your fault. It's just how memory works. You are not supposed to remember all the code that you write, right?

But what happens when you need to get back to an old project?
If you only rely on your memory to remember how it works, you are bound to fail. You simply cannot remember everything.
This is one of the most common sources of stress, because you feel the pressure to remember how a project works to get back to it fast.

The solution is to use comments and documentation.

When working on a project, keep a project documentation log where you write down, in human language, what that project is about and its logic.
Just imagine having to explain your project to another developer who has never seen that project before.

Writing this file as you work it's not a big deal. It will not take you much time. Actually, it can even help you review and check your app's logic and speed your development time a little.
When you will get back to this project, reading this file will make you remember how it works in a matter of minutes.

Be sure to write down all the details. The more details you write, the easier it will be for your future self to get back to the project.

Comments, of course, are the specific, in-code hints that tell you what each function, argument, variable and class does.
Just like for the documentation file, writing comments as you code will not take much time, and they can actually help you code faster by reducing the number of bugs.

When you know that all your code is neatly commented, you avoid a lot of stress. You can be sure that, whatever piece of code you need to work on later, you can count on your own comments to see exactly what it does.

Fix #2:
Make your code super easy to fix.

You cannot eliminate bugs completely. It's impossible.
However, you can write code that is so easy to debug, that when a bug comes out you can fix it with little to no effort.

How?
The "trick" is to follow two rules when writing functions and methods:

Each function must perform only a single, specific task.
Function must actively report errors

Let's see a simple example:

function is_divisible(int $dividend, int $divisor): bool
{
if ($divisor == 0) {
throw new Exception('division by zero');
}
$divisible = ($dividend % $divisor) == 0;
return $divisible;
}

The above function does only one, specific thing: it tells whether two integer numbers are divisible by each other.
On top of that, it checks whether the divisor is zero (which is the only possible error condition) and, in that case, it throws an Exception.

If all your code is done this way, it becomes super easy to debug and to fix it.

Fix #3:
Adopt the "Top-Bottom" technique.

Do you remember the Top-Bottom technique? We talked about it in one of the last emails.
Basically, with this technique you begin the coding process from the most abstract and high-level functionalities, and then you move down to implement all the details.

So, what does it have to do with the last source of stress (the fear of not being able to do your work properly)?

Let's take an example.

Let's say that you are asked to build a REST API for a warehouse system. The API must implement commands to store new items, get the list of existing items, and so on.

If you adopt the Top-Bottom technique, you start by defining the higher-level methods such as addItem(), removeItem() and so on.
Even before writing the low-level implementation, you have a clear idea of the whole project, and you can estimate how much time it will take for you to finish the job.

The Top-Bottom technique also helps in code refactoring and updates, not just in the beginning.

By using this technique, you will get a clear idea of whether you can complete your job and also how much time you will need.