The other day I was interviewing a JavaScript developer who was applying for a senior position. A colleague, who was also present at the interview, asked the candidate to write a function that would make an HTTP request and, in case of failure, retry several times.
He wrote the code directly on the board, so it would be enough to depict something approximate. If he simply showed that he understood well what the essence of the matter was, we would be quite satisfied. But, unfortunately, he could not find a good solution. Then we, writing it off as excitement, decided to make the task a little easier and asked him to make a function built on promises from a function with callbacks.
But alas. Yes, it was obvious that he had seen similar code before. He knew in general terms how everything worked there. A sketch of the solution would be enough for us, which would demonstrate an understanding of the concept. However, the code the candidate wrote on the whiteboard was complete nonsense. He had a very vague idea of ββwhat promises are in JavaScript and could not really explain why they are needed. For a junior, this would still be forgivable, but the position of a senior was no longer drawn. How would this developer manage to fix the bugs in the complex promise chain and explain to the rest what exactly he did?
Developers consider finished code to be self-evident
During the development process, we constantly encounter reproducible materials. We move code snippets so that we don't have to rewrite them each time. Accordingly, by focusing all our attention on the key parts, we look at the finished code we work with as something self-evident - we simply assume that everything in it will work as it should.
And it usually does work, but when things get tricky, understanding its mechanics more than pays off.
For example, our senior developer candidate considered promises to be self-evident. He probably imagined how to deal with them when they occur somewhere in someone else's code, but he did not understand the general principle and could not repeat it himself at the interview. Perhaps he memorized the fragment - it's not that difficult:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});I've done it too - yes, we've probably all done it at some point. They simply memorized a piece of code so that they could later use it in their work, while only in general terms imagining how everything works there. But if the developer truly understood the concept, he would not have to remember anything - he would just know how it is done, and would easily reproduce everything necessary in the code.
Reach out to the origins
In 2012, before the dominance of front-end frameworks, the world of jQuery rules, and I was reading a book by John Resig, creator of jQuery.
The book teaches the reader how to create their own jQuery from scratch and provides a unique opportunity to get involved in the train of thought that led to the creation of the library. jQuery has fallen out of favor in recent years, but I still highly recommend the book. What struck me most about her was her insistent feeling that I could have thought of all this myself. The steps that the author described seemed so logical, so clear that it really began to seem to me that I could easily create jQuery if I just got down to business.
Of course, in reality, I would not have mastered anything like this - I would have decided that it was unbearably difficult. My own solutions would have seemed too simple and naive to me to work, and I would have given up. I would classify jQuery as a self-evident thing, in the correct operation of which you just need to blindly believe. Subsequently, I would hardly spend time delving into the mechanics of this library, but would simply use it as a kind of black box.
But reading this book made me a different person. I began to read the source code and found that the implementation of many solutions is actually very transparent, even obvious. No, of course, to think of something like this yourself is already from another opera. But it is the study of someone else's code and the reproduction of existing solutions that helps us come up with something of our own.
The inspiration you get and the patterns you start noticing will change you as a developer. You will find that the wonderful library you use all the time and think of as a magical artifact does not work on magic at all, but simply solves the problem concisely and resourcefully.
Sometimes you have to pore over the code, taking it apart step by step, but this is how, moving in small successive steps, you can repeat the author's path to the solution. This will allow you to dive deeper into the process of writing code and give you more confidence in finding your own solutions.
When I first started working with promises, I thought it was pure magic. Then I found out that they were based on the same callbacks, and my programming world turned upside down. That is, the pattern, the purpose of which is to save us from callbacks, is itself implemented using callbacks?!
This helped me look at the matter with different eyes and realize that in front of me there are not some abstruse pieces of code, transcendental complexity that I will never comprehend in my life. These are just patterns that can be easily understood with due curiosity and deep immersion. This is how people learn to code and grow as developers.
Reinvent this wheel
So feel free to reinvent the wheel: write your own code for data binding, create a homegrown promise, or even make your own state management solution.
It doesn't matter that no one will ever use all this - but now you know how. And if you have the opportunity to subsequently use such developments in your own projects, then this is generally great. You can develop them and learn something else.
The point here is not to send your code to production, but to learn something new. Writing your own implementation of an existing solution is a great way to learn from the best programmers and hone your skills.
Source: habr.com