My key learnings as a developer

Some key learning has changed everything for me as a developer. Knowledge that has been decisive for my professional life. Things I would have liked to have known earlier. Sometimes technical, sometimes pragmatic. Always indispensable.

Occult practices

I remember the first times I used Javascript. I absolutely hated it. I felt like I was working with a schizophrenic who had a personal grudge against me.

The context (this) was completely unpredictable. The variables copied their values on each other in a supernatural way. Sometimes variables were available before I declared them. Race conditions were legion and very often the app would suddenly, for no reason, freeze. Black magic!

And like most young developers, my only goal was to get my app working. As soon as possible. I didn’t care about anything else.

No need to make the effort to understand everything, it already works without!

My only strategy was to get inspiration from code I already had. Whether it’s internal or on the internet. And let’s face it, most of the time, it worked very well like that.

It gave me the illusion of being effective.

And that’s when I started the occult practices. Copy and paste stack overflow responses on top of each other. Hopefully, it will work out in the end. Have you ever done this before?

Conjuration

One morning, on the advice of a senior, I decided to stop struggling with this Javascript application. I was going to devote the morning to really understand the inner workings of Javascript.

I started with Hoisting, primitive and complex variables, and their occult relationship with values passed in copy or reference.

Then I learned once and for all the nuances and quirks of “this”. From its behavior in the prototyping chain, through the related functions (bind, apply) to how it works in event handlers.

Finally, I ended up with the inner workings of Javascript. Really understanding the blocking and non-blocking behaviors of the language was crucial.

That very afternoon, I fixed my problem which I had been blocking for several days in a few minutes.

I even remember thinking that the solution is “obvious”. It’s obvious when you really understand what you’re doing.

My effectiveness as a developer skyrocketed when I decided to fully understand the context of a problem before solving it.

Study the terrain before you hit the ground running. It seems obvious, it’s not. Especially when you have to go fast. You want to go fast? Waste time first by deeply learning your subject, you’ll optimize your speed after.

Apply this to everything you need, I promise you incredible results.

In fact, a few years later, I would come across the book Secrets of the Javascript Ninja. I already told you about it quickly and I’ll tell you about this one again.

I thought I already knew a lot of things. And then I invested some time in this book. It has been so important in my understanding of the language that I will dedicate an entire article to it in 2021. I highly suggest you try it before !

Prestidigitator

For a long time, I practiced my incantations in one and only one way. I was doing object-oriented and synchronous programming in PHP. I was good at it.

When I had to do something in another language, I did it the same way I did it with PHP.

The first time I went into NodeJS with that mindset, it was a disaster.

This asynchronous and highly concurrent execution environment challenged my way of thinking. Challenging my way of seeing things. Redefining in my brain the possibilities to solve a problem.

Your openness to new programming paradigms is as painful as it is necessary. You can’t stay in the same school of thinking indefinitely. You will lock yourself up. Only one way of thinking ? A curse that will prevent you from evolving as a developer.

Before learning new paradigms, I only saw programming through the prism of PHP. Limited and above all incompatible solutions to specific needs.

After practicing new paradigms, for the first time, I began to have thoughts on how best to solve a problem in a general way. Not the best way to solve a problem with PHP. And that changes everything.

And I’m not telling you to become a specialist everywhere. No, that’s impossible.

But only to understand the problem solving philosophy of other paradigms. The advantages and disadvantages of these. How can you use them to your advantage?

This hindsight, this technical open-mindedness, will give you a global vision of the profession. Each problem will suddenly have an optimized way of being solved. And being able to identify it is absolutely decisive as a developer.

Prototyping

As a developer, you don’t compromise with the quality of your application. This sentence is present in all good grimoires for developers. And it is true. But in my opinion, a precision is missing to this sentence.

As a developer, you do not compromise with the quality of your application in production.

Everything that is used by a customer must have a respectable level of quality. So it doesn’t concern the problem-solving phase. The problem-solving phase is when you don’t know how to solve the problem with your application yet.

Entering this phase with a perfect quality mindset will trigger what is called analysis paralysis.

You want to do so well, so badly right now, that you don’t do anything anymore.

So what to do? It’s simple, you have to prototype until you find a solution. Iterate very quickly to first solve the problem. Reach a solution that works.

Then, starting from this viable solution, focus on quality. At the end of the story, you have the same quality in production, it’s just that you’re faster.

This way of doing things is absolutely dreadful. Using this way of dealing with unknown problems is decisive in my speed of problem solving.

Bewitchment

I’ve been working on this bug for two hours. It’s driving me crazy. The stack trace of the error is all garbage. Very quickly, I started to use my problem solving techniques (next article!) to get to the bottom of it.

But nothing to do. It’s not a bug, it’s a real curse that prevents me from moving forward. Before getting angry, and wasting even more time, I decide to use a joker.

I summon a colleague and hope that with a wave of her magic wand she will get me out of this situation.

I then explain to her the chaos I am in. In the middle of the explanation, she cuts me off and says:

• Your array doesn’t exist.
• What ? Why do you say that?
• The error message says it, your array doesn’t exist!

I start reading the error and I discover with horror that she is right. I’m assigning the wrong array in my loop. Above the huge stack trace, the error is clear, obvious, here from the beginning.

How could I have missed it?

With a cocktail of willingness to go fast, panic and bad habits I read that error very quickly. Focusing only on the code, I was blind to the obvious answers. Answers that were right under my nose.

This advice is simple, obvious and not respected by most developers. Take the time to really stop and read what is available to you. You don’t realize how decisive it is.

And I’m only taking the example of error messages, but it’s valid for everything.

Take the time to REALLY read the documentation when something doesn’t work properly. Don’t just glance at it ! It could save you a lot of time.

Read the READMEs of the repository you are using. Some of the ways the library works might surprise you. That’s often where you’ll find the little option that changes everything.

Developers hate reading documentation. And it plays tricks on them that can be expensive.

They hate writing it even more. I talk about it in an another article. If they do, it’s usually because it’s really necessary. And those who take the time to really read have a decisive advantage over the rest.

Epilogue

Honestly, I have plenty of other advice for you. But the article is already long and the time you have to devote to me is limited. By implementing these tips, I promise you radical changes. Count on me to follow up on this subject in another article in the future.