How to learn GraphQL, React and Node.js faster

Learning GraphQL, React, Node.js, and engineering in general is not easy for most people. In this article we will go through some of the top cognitive biases that you need to be aware of to accelerate your learning rate, to decide when to switch technologies, and to refactor your code or avoid mistakes that could lead to technical debt and inefficiently spent time. You will avoid going in circles and find that you learn each lesson more quickly.

Introduction

Learning programming and engineering, especially JavaScript, can be tricky. The Node.js ecosystem is changing at a fast pace, leaving your current knowledge outdated. In this fast-paced environment you need to be aware of how you can accelerate your learning and cut out unnecessary time. As the technology progresses, the important thing is not only to have some specific knowledge about the technology, but to adapt thinking patterns to the frequent changes. Thinking patterns and architecture patterns will stay similar and can be applied to different environments and languages. In this article, we will go through the top cognitive biases that are affecting our decisions when we need to refactor or change our tech stack. We will discuss how to avoid bad decisions that keep us from learning faster, and suggest tips that will help you increase your learning rate. A lot of these things are also applicable to different domains.

Resistance to changes

I see myself and others to be really attached to their code. A lot of people are working hard on preparing certain architecture, code base or solutions to the problem to only find that the architecture is not modular enough, too error-prone or just does not scale very well. Completely changing or refactoring the architecture is often quite time-consuming and means that a lot of your code will be removed. This is the point where most people will get resistant to change and start rationalizing and finding ways to justify their solution even though logical reasoning wouldn’t support the old solution. In this problem we are dealing with a number of cognitive biases that affect our decisions. The main biases are:

• Commitment bias
• Confirmation bias
• Post-purchase rationalization

I see that people start new projects with an already predefined technology stack in their head. Their technology stack will match a lot with their current skills. While this is natural, it can lead to accumulating technical debt and to using technology which is not the best fit for the current modern stack. In addition, badly designed architecture leads to dissatisfaction in your team, frustration, and inefficiency. The GraphQL ecosystem is really fast-paced and is still changing a lot. Before each project you need to re-evaluate and adjust your tech stack to reflect the best and most current solutions. This is much harder for projects already in progress. You invest much more time and it becomes more difficult to transition to a more suitable technology. People still tend to go with the old architecture, however, even though in the long term it means that you will choose less modern and efficient solutions and you will spend more time writing state updates, etc. A lot of people resist switching to new technologies even if that new technology would solve many problems in their application as well as saving development time. This is understandable if your codebase is too big to switch, but you should think about gradually refactoring your stack to be up to date with current modern engineering.

Without a doubt you should not adapt new technologies blindly; you need to evaluate each technology separately. Instead of focusing on the time invested in the old code, I would recommend learning from your experience implementing the technology, and recognizing the advantages of adapting different thinking patterns. With these lessons you will learn how to quickly and efficiently adopt new technologies in the future.

We need to be especially aware about commitment bias as it can lead to the so-called Escalation of commitment. Escalation of commitment is human behaviour pattern where the individual or group will continue the same behaviour rather than alter course, even that decisions are clearly wrong. In certain cases, it can lead to disasters in peoples live as they are proceeding in the same bad decisions and completely ignore the negative signals. They attached a lot of ego and work to it and the willpower needed to change the decision is is increasing with the time. Once you are aware of commitment bias and other similar biases you will make better decisions when it comes to choosing your tech stack. And also that you will also be able to better estimate the right time for significant refactoring and changes to your app. We also need to take into account a number of other biases. The decision to migrate a technology stack is affected by the post-purchase rationalization. This means we place much higher value on past choices and try to justify these.

Confirmation bias affects these decisions as well. This bias results in people tending to believe things that confirm their beliefs. This can be really dangerous if your beliefs lead to bad decision-making. You will then focus solely on facts that reinforce your beliefs. Let’s take the example of staying with technology that is gradually becoming outdated. You know that you need to switch to new technology or significantly refactor your code base. But you will stick to finding facts and information that confirm your beliefs and actions. All these biases affect you in a similar way. You are resistant to changing your decisions and being flexible with technologies, and you avoid refactoring and incorporating new things into your codebase.

Focus not only on your strengths but also on those areas you find less enjoyable and more difficult.

You have that bug, that warning in your console that you know that you should have resolved for weeks now. You still prefer to work on new features, things that you know how to resolve, or on a nice frontend feature with great effects that will add a feeling to your website. But the important things that will enable you to grow as developer also include focusing on those tasks you do not find enjoyable at the moment, but that may bring rewards in the long run. When you resolve that warning, you will get much more insight into how things work at a deeper level. You usually know your libraries just superficially through prepared APIs, but by going after vital but less attractive tasks you will often need to dive into the library codebase. You will learn how other engineers work and what their coding style involves.

Listen to others & get a mentor

Being on a team of people who listen to each other will increase your learning so dramatically that it is invaluable and irreplaceable. You will not just learn the skills of engineering, but also important social skills. If you are a complete beginner it may be difficult to start coding from scratch. You just do not know what you do not know. You will probably make many mistakes in focusing on things that do not matter that much, and it will cost you a lot of time. I would recommend that you join a team with more senior developers so you can ask for help, code reviews, etc. The most common problems in a team environment is that we often encounter a cognitive bias called the IKEA effect that can cause disputes between team members, especially if there are senior developers who have their egos attached to their code. The IKEA effect causes each member to not approach the solution to a problem objectively, and to overvalue their own solution and undervalue those of others. Once you are aware of this issue you can be more logical when you are discussing the best solution for the project with other team members.

Mitigating biases

This is just a small subset of biases good to be aware of when learning programming. The best way to start mitigating the effect biases have on you and your decisions is to be aware of them and start to retrospectively see how they have affected your decisions and behaviour. I would recommend you look at your past behaviour and try to identify some cases in which you were in some sense biased. Try to remember the emotions that you were feeling, be aware of it and start calculating further decisions with that emotion. The key to reducing how much a bias affects you is to disassociate yourself from the feeling itself. Look at the feeling as an external object and evaluate the decisions you made based on real facts. If possible, rely on mathematics and calculating an expected value for each decision. Feelings are a good indicator in some cases, but are not entirely accurate. By injecting logic into your learning and work in general you will get much better results and you will be able to focus on key areas and avoid pitfalls

• especially mistakes that lead you to continue working with old legacy tech stacks.

Summary

These are some of the cognitive biases and human tendencies in programming that may hold you back in your progress as an engineer. I would say that it is most important to be flexible in adopting new technologies and not resistant to change while also prioritizing your tasks for long-term success. This will help you to adopt technologies faster, learn more lessons and, indirectly, will also help you increase your learning rate. By adopting new technologies more frequently you will see more codebases and you will “learn to learn” much more effectively. I believe that the ability to learn quickly is the most important skill for success, especially in engineering, as the amount of new technology and complexity of our systems is continually increasing.