You may be thinking: school alone is plenty of work! And it often is. But if you set your mind to it, like I did, you'll be amazed at what you can do.

In this story, I’ll share my journey of working through and receiving 15 freeCodeCamp certifications in just four months.

What I'll Cover:

• My Beginning with the Digital World

• Starting My Journey with freeCodeCamp

• Benefits of freeCodeCamp's Methodology

• freeCodeCamp Learning Paths

• 1- Responsive Web Design Certification.

• 2- JavaScript Algorithms and Data Structures

• 3- Scientific Computing with Python

• 4- Data Visualization

• 5- Backend End Development and APIs

• 6- Front End Development Libraries

• 7- Data Analysis with Python

• 8- Machine Learning with Python

• 9- Quality Assurance

• 10- Information Security

• 11- Legacy Certifications

• Personal recommendations

My Beginning with the Digital World

I grew up in a family that really believed in life-long learning.

At an early age – around 10 – my father bought me my first laptop.

From there, learning became part of our daily routine. My father approached it with structure and intention. He designed a complete detailed learning plan for me.

Looking back, it was quite ambitious for someone my age. But my father always believed in high standards and expectations.

Still, we didn’t start with programming right away.

At first, we explored different areas and domains. I focused on trying to find something I though was interesting.

But it didn’t take long before we realized how important programming was becoming and how powerful it could be to start early.

So, we decided that I should start learning programming.

I began with HTML, building my very first web page. I was able to build a complete web page using different elements and tags on my own.

It was simple but it worked. That moment felt like a win.

Then I moved on to CSS. I was able to style and arrange the elements on the web page the way I liked. I grasped many CSS techniques and commands that help control the layout and arragement of elements so I could make them look the way I wanted.

After that came JavaScript. That’s when I was able to make things more alive. I started adding movement, interaction, and behavior to my web pages.

And I didn’t stop there.

I stepped into backend development with PHP, beginning to understand how things worked behind the scenes. Alongside that, I started learning SQL to handle databases – an essential part of building real, functional web applications.

Step by step, the picture was becoming clearer.

Before learning about these languages, the web sound like a black box. But after I finished learning them, I started looking at websites from a different angle, and I started recognizing how web pages are made.

All this learning came through a mix of YouTube lessons and structured courses my father invested in for me, like a 50-hour PHP course on Udemy.

I was absorbing a lot, moving from one concept to another, and building small pieces along the way.

But at some point, something clicked: I realized that watching tutorials – even long, detailed ones – wasn’t enough on its own. There was a gap between understanding concepts and building something real. So I decided I needed to dive deeper.

Starting My Journey with freeCodeCamp

I needed to move beyond lessons into building structured, meaningful web applications. Projects that weren’t just exercises, but had real purpose.

Projects with expectations, constraints, and even real stakeholders.

The kind of work that forces you to think, to make decisions, and to take ownership.

Because there’s a big difference between following along with a video… and sitting alone in front of a blank screen, figuring things out step by step.

That shift helped me avoid what many learners fall into: the endless loop of tutorials without real progress (Tutorial Hell).

And for the first time, I started to feel what it really means to build.

That’s when I made a clear decision to switch to freeCodeCamp. What drew me in was simple: it wasn’t just lessons. It was practice building real, structured, hands-on projects.

Benefits of freeCodeCamp's Methodology

After completing 15 certifications on freeCodeCamp, I was able to build and launch a full platform called Programming Ocean Academy, focused on Data Science and Artificial Intelligence.

It pushed me to think, to solve problems on my own, and to act like an engineer – not just a learner following instructions.

This wasn’t a small project. It included:

• A fully functional frontend and backend system

• More than 25 databases

• Over 150 pages

• Integrated training platforms

But what mattered more than the scale… was what came next.

Because of the strong logical and programming foundation I had built, transitioning into Data Science and AI felt natural and not overwhelming.

I moved into Python and its ecosystem with confidence. From there, I worked with powerful libraries like scikit-learn, TensorFlow, and PyTorch.

The solid foundation I'd built enabled me to deliver multiple training programs in collaboration with Arab universities, and I've helped train more than 5,000 learners.

Looking back, that shift from consuming content to building real systems and delivering courses was the turning point.

freeCodeCamp Learning Paths

Today, I’m happy to share this journey with you and to emphasize something I’ve come to believe deeply: the programs and learning paths offered by freeCodeCamp aren't just courses. They're a structured bridge that'll help take you from being someone who watches tutorials and writes code to someone who builds real applications and creates products that serve people.

Now, you have the context you need to understand the rest of the story.

So let’s begin.

This is where the journey with freeCodeCamp really starts. A journey I would confidently recommend to anyone who wants to enter the world of programming and technology with clarity and direction.

How did it start? And how did I choose my path?

At the beginning, I didn’t approach freeCodeCamp randomly.

I knew that if I wanted real progress, I needed structure.

So instead of jumping between topics, I followed a clear order – one that builds understanding step by step, just like constructing a solid foundation before raising a building.

I asked myself a simple question: What do I need to master first, so everything that comes after becomes easier not harder?

That question influenced everything that followed.

So instead of creating my own path from scratch, I decided to fully trust the methodology of freeCodeCamp, following its order of certifications, lessons, and progression exactly as designed.

That decision made everything simpler.

I started from the very beginning and moved step by step.

My journey began with:

1: Responsive Web Design Certification.

At that time, I was studying for around 8 hours a day on most days, balancing it with my school responsibilities. It wasn’t always easy, but the structure kept me focused.

During this first phase, I built a strong foundation.

I explored HTML in depth:

• Understanding almost all HTML tags

• Knowing the purpose of each element

• Learning which attributes belong to which elements

• When to use each tag properly

• Writing clean, semantic code that follows best practices

Then came CSS. This is where things evolved visually.

I started understanding more deeply how to:

• Style and structure pages

• Create modern, clean layouts

• Build responsive designs that adapt across devices

But the real test wasn’t the lessons.

To earn the certification, I had to complete five full projects, each one requiring me to apply everything I had learned, solve problems independently, and choose the best possible approach rather than just making things “work.”

That’s where the real learning happened.

2: JavaScript Algorithms and Data Structures

For the second certification, JavaScript, things took a different turn.

This is where the web stopped being static.

I learned how to make pages interactive and alive. I learned how to control behavior, respond to user actions, and build logic that does something. But more importantly, I spent time learning how to think logically.

JavaScript pushed me into algorithmic thinking:

• Breaking problems into smaller steps

• Writing logic in a structured, methodical way

• Building solutions that are not just correct but clean and scalable

And after that phase, I didn’t stop at just using freeCodeCamp's curriculum.

I wanted to go deeper.

So I started solving programming challenges on platforms like Codewars and Edabit. Those challenges sharpened my thinking even more. They forced me to face unfamiliar problems and figure things out without guidance.

3: Scientific Computing with Python

Then came the third stage of the journey.

This phase was different. Python had its own elegance, its own logic, and a strong connection to mathematics and data.

It opened a completely new way of thinking.

Through hands-on projects, I learned how to work with data using powerful tools like NumPy, pandas, and Matplotlib. And I didn’t just learn how to use these tools. I got familiar with what they enable.

I practiced:

• Analyzing data

• Exploring patterns

• Visualizing insights

• Thinking statistically

• Moving from raw data to meaningful conclusions

I began to understand how data can be transformed into real insights That’s when my skills started to become more powerful.

My first real encounter with Python and data analysis was through freeCodeCamp.

Unlike web development – which I had explored earlier through different resources – this was my first entry point into the world of data.

And for that, I honestly give freeCodeCamp a lot of credit. It didn’t just introduce me to new tools. It introduced me to a completely new way of thinking.

4: Data Visualization

This phase added a new dimension. It wasn’t just about working with data anymore – it was about communicating it's meaning.

I learned how to transform raw numbers into clear, meaningful visualizations. I explored how to create graphs that don’t just look good but help you understand what’s going on beneath the surface.

That experience was incredibly valuable

It built a foundation that later made my transition from web development into data science and AI much smoother.

And once again, I must acknowledge the role of freeCodeCamp. Because during this phase working with tools like Python, Matplotlib, and pandas, I began to truly understand the importance of data visualization and analysis.

I started to carry this mindset back into the world of web development:

• Into databases

• Into SQL tables

• Into how data is structured, queried, and interpreted

I realized that data isn't just something you store. Its value comes from how well you can understand it, analyze it, and use it.

And for stakeholders, this is just as critical as storage, security, and privacy because without insight, data alone means very little.

This distinction is incredibly important for every developer to understand.

In the world of web development, the focus is often on storing data, securing it, and making sure it’s accessible. But in the world of data analysis, scientific computing, and statistical modeling, the focus shifts completely.

It becomes about studying the data itself transforming it from something silent… into something that speaks. Something that guides decisions. Something that helps you improve systems, refine products, and make smarter long-term choices.

That shift in perspective changed the way I handled everything.

5: Backend End Development and APIs

This was a new world.

Even though I had previous experience with PHP and SQL from Udemy, this path introduced me to a different ecosystem which is modern, fast, and widely used in real-world applications.

Of course, the beginning wasn’t easy. I had no prior experience with tools like Node.js or MongoDB. It felt unfamiliar at first, and there was a learning curve.

But this is where freeCodeCamp stood out again.

They didn’t just throw you alone into the deep end. They supported the journey.

I found dedicated courses on their YouTube channel like a full Node.js course (around 8 hours) and a MongoDB course (around 4 hours).

I went through both of them completely. Step by step, things started to make sense. I built a solid foundation, returned to the certification path, and this time I was ready.

I completed all the challenges and projects successfully, from the first attempt.

And that experience taught me something important: sometimes the path forward isn’t about pushing harder, it’s about stepping back, strengthening your foundations, and then coming back stronger.

One of the most interesting parts of this stage was discovering the difference between how data is handled in SQL versus MongoDB.

It wasn’t just a technical difference, but a shift in mindset.

With SQL, everything is structured, relational, and predefined. With MongoDB, things are more flexible, document-based, and dynamic.

Learning to work with both gave me a broader perspective on how to design and manage data depending on the problem at hand.

6: Front End Development Libraries

This was one of the most enjoyable phases. It felt creative, fast, and powerful.

I explored frameworks and libraries like:

• jQuery

• React

• Vue.js

To strengthen my understanding, I followed additional courses on the freeCodeCamp YouTube channel, making sure I had the right foundations before tackling the projects and passing the certification requirements.

What stood out to me the most during this phase was something new: for the first time, I truly learned how to control HTML and CSS through JavaScript in a structured and scalable way.

This wasn’t just about styling anymore, but it was about building dynamic interfaces, managing state, and creating responsive user experiences.

And honestly, this was the first time I grasped this concept deeply.

7: Data Analysis with Python

Here, things became more precise.

I explored how to:

• Choose the right type of visualization depending on the data

• Analyze datasets using tools like Excel, NumPy, and pandas

• Create advanced visualizations using libraries like D3.js

I was learning how to think with data, how to read it, question it, and turn it into something meaningful.

8: Machine Learning with Python

This new learning path was deeper, more abstract. Sometimes even unfamiliar compared to everything I had learned before.

For the first time, I wasn’t just writing code to build applications. I was building models that learn from data.

Working with tools like TensorFlow, I began to understand how data, mathematics, and algorithms come together to create intelligent systems.

Everything I had learned through freeCodeCamp started to reflect beyond programming itself.

I noticed the impact in school:

• In mathematics, logic became clearer

• In digital technology, concepts felt more intuitive

• Even in subjects like physics and chemistry, problem-solving became easier

Because at its core, my way of thinking had changed. My logical reasoning had become stronger. Working with algorithms and mathematical expressions no longer felt difficult. Instead it felt natural.

One of the most meaningful outcomes of this journey came during high school. A teacher trusted me with a responsibility I didn’t expect: To explain programming lessons to my classmates.

And I did.

Not just by repeating information but by simplifying it, structuring it, and making it understandable. That moment I discovered that learning deeply allows you to teach clearly.

And then came a new and powerful phase: building the engineering mindset.

At this stage, everything started to come together. It was about thinking differently.

An engineering mindset built on:

• Strong logical foundations

• Real project experience

• Understanding how systems behave, not just how code runs

And this introduced me to the upcoming certifications.

9: Quality Assurance

I spent time learning how to write code that's not only functional but reliable, maintainable, and scalable.

Using tools, and practices like Chai.js, I began to:

• Test applications properly

• Catch errors early

• Ensure systems run smoothly under different conditions

And this is where the real transformation started happening. I started moving from being someone who writes code to someone who builds systems.

10: Information Security

Through the cybersecurity path on freeCodeCamp, I was introduced to a completely new dimension of software development: thinking about protecting systems, not only building them blindly.

I picked up essential concepts and practical skills using tools like:

• Helmet.js to secure web applications

• Python for penetration testing and security analysis

• Socket.IO for handling real-time interactions securely

As part of this path, I worked on building five projects including a password cracker. It wasn’t just a technical exercise – it was a way to develop a real security mindset. To understand vulnerabilities, risks, and how attackers think so you can build systems that are stronger and safer.

Then I got into the legacy learning courses:

11: Legacy Certifications

Front End:

Back End:

Data Visualization:

Full Stack:

Legacy Cybersecurity & Quality Assurance:

This phase was incredibly valuable.

It felt like a consolidation of everything I had learned, a chance to revisit key concepts with more maturity and deeper understanding. These certifications focused more on what truly matters in each path, with diverse and practical projects that strengthened both my skills and confidence.

If I had to summarize this entire journey in one idea, it would be this: learning by building changes everything.

This core methodology of freeCodeCamp enabled me to:

• Solve real problems

• Build actual products

• Connect learning with real-world impact

It moved me beyond theory into practice.

Personal Recommendations

Based on my experience, I strongly recommend freeCodeCamp to anyone who wants to:

• Develop programming skills

• Strengthen logical thinking

• Improve problem-solving ability

• Build real-world applications

Because when learning is built on the right methodology, the results are not just visible they are transformative.

Here are resources about freeCodeCamp programs and certifications that structured my learning journey.

Contact Me:

GitHub

Linkedin

X

This absence of direction makes the journey significantly harder. Faced with an overwhelming abundance of online resources, many beginners become confused about where to start and often attempt to learn everything at once.

This is where the struggle with knowledge retention begins.

Not because they lack intelligence or effort, but because they're learning in a way that contradicts how the human brain actually works.

They dive into tutorials and courses without understanding the mechanism of the brain – that is, how the brain processes, stores, and retrieves information. As a result, much of what they learn simply doesn’t stick.

How the Brain Processes Information

So what's the connection between the brain and learning how to code, you might ponder?

The connection is direct and unavoidable.

Coding isn't learned through willpower or motivation — though both matter — or by spending countless hours watching tutorials.

It's learned through the brain’s ability to process, store, and retrieve information.

Every variable, function, data structure, or debugging pattern must pass through the brain’s cognitive systems before it becomes usable knowledge.

If your learning process doesn't align with how the brain naturally acquires and organises information, your retention will collapse, no matter how determined you are.

Now imagine you’re trying to fill a bucket with water. You keep pouring and pouring, but the bucket has tiny holes at the bottom. No matter how much effort you put in, the water keeps leaking out. You might blame yourself for not pouring fast enough, or you might try switching to a bigger jug, but the real problem isn’t your effort — it’s the bucket.

The water is the information you’re trying to learn.

The bucket is your brain’s memory system.

The holes in the bucket are the natural forgetting mechanisms of the brain: cognitive overload, limited working memory, and other constraints that make retention difficult.

If you don’t understand these mechanisms, you can pour in as much information as you want, but most of it will leak out.

Not because you’re incapable, but because you’re learning in a way that contradicts how the brain actually retains knowledge.

The Role of Academic Learning Theories

Since learning ultimately takes place in the brain, an important question is: How does the human brain acquire, organize, and apply knowledge and why does the typical self‑taught learning process clash with these principles?

This is where academic learning theories become indispensable. These frameworks explain how the brain actually acquires, retains, and applies complex information and they offer a scientific roadmap for learning more effectively. Without understanding these principles, self‑taught developers unintentionally work against the brain’s natural architecture.

The purpose of this article is to unpack these essential learning theories and apply them directly to the beginner self‑taught developer’s journey.

By understanding how the brain processes information, beginners can structure their learning more intentionally, retain knowledge more reliably, and move toward becoming competent developers with far greater confidence and clarity.

Table of Contents

• Cognitive Load Theory (CLT)

  • Working Memory

  • Miller's Law

  • Chunking

  • Long-term memory

  • Schema

  • Intrinsic Load: The Natural Difficulty of the Task

  • Extraneous Load: The Mental Noise

  • Germane Load: The Construction Work

• Ebbinghaus Forgetting Curve.

• How the Theory of Spaced Repetition Works

• Theory of Deliberate Practice

• What is Bloom's Taxonomy?

  • Focused Mode vs Diffuse Mode

• Conclusion

• References

Cognitive Load Theory (CLT)

Learning a new concept often requires mental effort by the brain to process newly acquired information. This effort exerted by the brain is known as cognitive load, a term coined by Australian educational psychologist John Sweller in 1988 during his study on how the brain acquires and retains information (Sweller, 1988).

Since then, his work has been expanded upon by other researchers. Notably, Dylan Wiliam famously tweeted in 2017 that Cognitive Load Theory (CLT) is "the single most important thing for teachers to know" (Dylan William, 2017).

You might wonder again: What does this have to do with me? As a beginner self‑taught developer, the answer is simple: you're both the teacher and the student.

So this is the most important theory you should know. In this self-tutoring journey, you're tasked with designing your own curriculum, choosing your own resources, pace your own learning, and evaluating your own progress.

Without understanding how cognitive load affects your ability to absorb and retain information, you may unintentionally overload your brain and sabotage your own learning.

Before we get into the nitty-gritty of CLT, there are important concepts masterminded by David Geary that you'll need to grasp to sufficiently understand this concept : “that which can be learnt” (biologically primary knowledge), “that which can be taught”(biologically secondary knowledge) (Geary, 2007, 2008).

According Geary (2007, 2008), "biologically primary knowledge" consists of "instinctual" skills that the brain is evolved to pick up naturally without formal schooling.

Examples include learning a first language, recognizing faces, or basic social navigation.

"Biologically secondary knowledge", on the other hand, consists of cultural and technical skills, like reading and writing, that are necessary for society but don't come naturally to the brain.

This is because we aren't "wired" to pick these up automatically. Instead, they require formal instruction and schools to pass them down.

Therefore, coding is a prime example of biologically secondary knowledge. The human brain is remarkably plastic, but it didn't evolve to interpret syntax, manage memory allocation, or debug logical loops.

These are cultural inventions, not natural instincts. Unlike learning to walk or speak your native language (which are biologically primary skills) you can't learn to code simply by “being around” computers.

Recognising that the human brain is not instinctively prepared for coding allows you to change your strategy. Once you accept that coding concepts are not “natural,” you can finally approach them with the structured, deliberate effort they require.

The second set of concepts beginner self-taught developers should know and understand are working memory, Miller's Laws, chunking, long-term memory, and schemas.

Working Memory

Working memory is where thinking happens. It's the active mental workspace where you hold information while you process it. When you encounter concepts like syntax, loops, functions, or an if/elseif statement for the first time, all of that information sits inside your working memory. The problem is that working memory is extremely limited and fragile.

When you first learn to code, your working memory functions like a small mental desk where only a few items can be placed at once.

Imagine trying to assemble a piece of IKEA furniture on a tiny coffee table. If you spread out the instruction manual, the screws, the wooden panels, and the tools all at the same time, the table becomes cluttered instantly. You start losing track of which part goes where, not because you’re incapable, but because the surface you’re working on is too small to hold everything at once.

Working memory behaves the same way. When you’re learning new concepts – like arrays, loops, functions, or error handling – each idea takes up space on that mental desk. If you then overload it, the desk becomes overcrowded.

Once it exceeds its capacity, things begin to fall off, and your ability to retain collapses.

It’s not a lack of intelligence. It’s simply the natural limit of working memory.

Now this collapse happens because you went against the threshold your working memory can hold. This is backed up by research that shows that working memory can typically process only 5–9 pieces of information at any given time (Miller, 1956). This is known as Miller’s Law.

Miller's Law

In 1956, George Miller found that the average human can hold about seven items (plus or minus two) in working memory at once, even some recent research has stated the number is even lower about four item (Nelson Cowan, 2001).

So imagine you encounter a tutorial that introduces the following concepts all at the same time: a Route, a Controller, a Model, a Migration, a View, a Request, Helper files, Jobs and Queues, Middleware, Roles and Permissions, and a Service Provider. If you attempt to hold all of these in your mind simultaneously, you'll inevitably hit Miller’s Wall, as your working memory becomes overloaded, and you'll likely forget the first concept long before you reach the last.

So how do you handle complex tasks if the brain can only juggle 4–9 items at once?

You use chunking — the process of grouping small pieces of information into a single, meaningful unit.

Chunking

Chunking is the brain’s strategy for compressing complexity. Instead of forcing working memory to hold a dozen unrelated items, you reorganise them into a few coherent structures. This reduces cognitive load, prevents overload, and allows you to work with far more information than your raw working‑memory limits would normally allow.

Let's consider an example:

A beginner learning Laravel might see Route, Controller, Model, Migration, and View as five separate, overwhelming items. To a beginner, each one feels like a distinct cognitive burden. But an experienced developer doesn't treat them as isolated concepts. Instead, they're understood as a single meaningful unit: the MVC pattern. Instead of holding five items in working memory, the expert holds one.

This raises an important question: how does a beginner know that these five elements belong together when they have only just encountered them?

It's crucial to emphasise that chunking isn't automatic. It depends on recognising meaningful relationships between concepts, and beginners typically lack the prior knowledge needed to perceive those relationships early on.

But as learners repeatedly encounter the same sequence during the learning process, they begin to notice consistent patterns. Over time, the brain’s natural tendency to seek structure enables them to identify which components reliably operate together, allowing these elements to gradually fuse into a single, meaningful chunk.

For example, when I first followed a Laravel e-commerce tutorial, I noticed that for every new resource the tutor created – Payment, Cart, KYC, and Contact – the same pattern was repeated: a Controller, a Model, and a View were always created together.

After encountering this sequence several times, it became clear that these components consistently belonged together as a set. Over time, I began to perceive the Controller, Model, and View not as separate elements, but as a single, integrated unit.

So beginners may not be able to chunk effectively on day one because they lack the prior knowledge needed to recognise what belongs together. But with time, and repeated encounters across different contexts, these individual pieces fuse into stable mental units stored in long‑term memory.

What feels overwhelming at first eventually becomes effortless, not because the task became simpler, but because your internal representation became more organised.

This is the power of chunking: it transforms scattered pieces of information into organised units that fit comfortably within the limits of working memory.

Without chunking, beginners drown in details. With chunking, they gain the cognitive space needed to understand, retain, and apply what they learn.

Long-term memory

Unlike working memory, long‑term memory has virtually infinite capacity. The goal of all study is to move information from the cramped working memory into the vast long‑term memory.

Here is the real secret: you don’t learn in working memory – you only process there.

True learning is the permanent change that happens in long‑term memory.

Schema

Once stored in long-term memory, information becomes part of a schema — a mental map or filing system that organizes related ideas.

For example, when you finally learn that Laravel is an MVC framework, you aren’t just memorizing three letters. You're building a schema that tells your brain: Models handle data, Views handle presentation, and Controllers handle logic.

Once a schema is built, it can be pulled into working memory as a single chunk, effectively bypassing Miller’s Law.

This is how experts think effortlessly while beginners feel overwhelmed.

And this is why Garnett (2020) argues that "being competent or lacking competence in something depends entirely on how secure the retrieval of knowledge held in the schema is".

Now that the foundations of working memory, long‑term memory, schemas, and chunking are clear, we can turn to another set of concepts every self‑taught developer must understand: intrinsic load, extraneous load, and germane load. These three components make up the full structure of Cognitive Load Theory, and they determine whether learning feels manageable or overwhelming.

Intrinsic Load: The Natural Difficulty of the Task

Intrinsic load refers to the inherent complexity of the material itself. Some concepts are simply harder than others because they contain more interacting elements that must be processed at the same time.

In Laravel, understanding a simple Route has low intrinsic load.

But concepts like Dependency Injection or Polymorphic Relationships have high intrinsic load because they involve multiple layers of abstraction and interdependent ideas.

You can't change the intrinsic load of a concept, but you can manage it by breaking the idea into smaller, more digestible sub‑tasks. This is why good teaching — and good self‑teaching — always begins with simplification and sequencing.

Simplification means stripping a concept down to its essential parts so the learner isn't overwhelmed by unnecessary detail.

Sequencing means introducing parts in a logical order, where each step builds on the previous one. This helps reduce unnecessary cognitive load and allows learners to devote more mental effort (germane load) to building schemas.

It’s like meeting someone new, and they tell you their name and it happens to be your mother’s name. Instantly, your brain forms a connection. You associate this new person’s name with the strong, deeply stored memory of your mother.

Because that schema already exists in your long-term memory, the new information “attaches” to it. Later, when you try to recall the name, you don’t struggle, you simply think of your mother, and the name comes back easily.

While many believe self‑taught developers struggle because they lack immediate, reliable, personal guidance, there's actually a hidden advantage in this predicament. When a teacher explains a concept, even if they try their best to “chunk” the information, they can't truly know the student’s internal limits — how much intrinsic load the learner can handle, how quickly they can process new ideas, or how much prior knowledge they can activate.

This is where self‑taught developer quietly shines. Because you are both the teacher and the student, you know your own cognitive limits better than anyone else. You can slow down when something feels heavy, pause when working memory is overloaded, and chunk information in a way that perfectly matches your personal capacity.

You can simplify a concept to its bare essentials and sequence it at a pace that aligns with your own understanding.

Extraneous Load: The Mental Noise

Extraneous load is the enemy of the self‑taught developer. It's the mental effort wasted on tasks that don't contribute to actual learning. This is where a self-taught developer's strength must truly shine.

A teacher in a classroom is responsible for removing any distractions that might derail a child or slow down their assimilation of knowledge. As a self-taught developer, that responsibility falls entirely on you. You must identify these distractions and eliminate them.

As a self-taught developer myself, I use specific strategies to ensure I stay focused. Before starting any course, I spend time reading the comment section to see what others have experienced. If I see complaints about low audio quality, unclear explanations, or tutorials that move too fast, I immediately abandon that course and look for one with better reviews.

Anything that might derail my progress must be removed. If you spend half of your mental energy trying to figure out all of these, you only have the remaining half available for understanding the logic of the code. And remember: when learning new concepts, we use working memory, which is fragile.

As your own “inner teacher,” you must eliminate this noise so your limited working memory can focus entirely on the material that matters.

Germane Load: The Construction Work

Germane load is the productive mental effort used to build and refine schemas — the mental structures that make future learning easier.

This is the “Aha!” moment when new information connects meaningfully to what you already know.

For example, germane load appears when you realise that a Database Migration is essentially a version‑control system for your table structure.

That insight is schema construction in action.

Teachers are often advised to help manage a child's germane load. One way they do this is by connecting the new idea being taught to an existing concept.

By doing this, they help the student build schemas: mental frameworks that organise and interpret information.

For a self-taught developer, this means instead of memorizing a new syntax in isolation, you look for a 'hook' in something you already understand.

For example, if you already know how a physical filing cabinet works, understanding Arrays or Objects in code becomes much easier.

You aren't learning from scratch – you're simply "plugging" new data into an old socket. This reduces the mental strain and makes the new knowledge stick permanently.

But this can only happen when intrinsic load is properly managed and extraneous load is removed.

It's important to note that, unlike intrinsic and extraneous load, germane load isn't an independent type of cognitive load.

Instead, it represents the portion of your working memory that remains available to handle the element interactivity associated with intrinsic load.

In other words, germane load is the mental energy you have left for learning once the unnecessary noise is stripped away.

Understanding cognitive load explains why learning can feel overwhelming in the moment, but it doesn't explain why knowledge fades after the moment has passed. For that, we turn to another foundational principle in learning science: the Ebbinghaus Forgetting Curve.

Ebbinghaus Forgetting Curve

If you remember the bucket analogy, this curve represents one of the holes at the bottom — the brain’s natural tendency to let information leak away unless it's reinforced.

In the late 19th century, Hermann Ebbinghaus discovered that human memory follows a predictable pattern of decline. After learning something new, we forget most of it astonishingly quickly — often within hours — unless the information is revisited. The forgetting curve shows that memory retention drops sharply at first and then continues to decline more slowly over time.

Studies based on Ebbinghaus’ forgetting curve found that without a conscious effort to retain newly acquired information, we lose approximately 50% of new information within 24 hours, and up to 90% within a week (Clearwater, 2024).

In other words, the brain is designed to discard information that isn't reinforced.

For self‑taught developers, this has profound implications.

You may understand a Laravel controller today, spatial roles and permission concepts, and so on – but if you don't revisit it, practice it, or apply it within the next few hours, your brain will naturally let it fade.

This is not a sign of weakness or lack of talent. It's simply how human brain works.

The forgetting curve also explains why tutorials feel deceptively easy the moment you're going through them.

While watching, everything seems clear — but a week later, the same concepts feel unfamiliar.

The knowledge never made it into long‑term memory because you didn't revisit, practice, or connect it to existing schemas.

Since the human brain is designed to forget anything that isn't repeated, repetition becomes the signal that tells the brain, “This matters — keep it.”

This is why, when you meet someone for the first time and they tell you their name, you'll almost certainly forget it unless you consciously repeat it to yourself several times. If you don’t reinforce it, you end up asking — often with embarrassment — “Sorry, what was your name again?”

The same principle applies to learning code: without deliberate repetition, the brain simply lets the information fade. However, with a technique called spaced repetition, retention is significantly improved .

How the Theory of Spaced Repetition Works

Spaced repetition is a learning technique grounded in cognitive psychology that involves reviewing information at increasingly spaced intervals to strengthen long‑term memory retention.

It's based on the principle that memory decays predictably over time — as demonstrated by the Ebbinghaus Forgetting Curve — and that strategically timed reviews or repetition interrupt this decay, making the memory more durable with each repetition.

This idea is what gave birth to Anki-Flash cards.

Imagine you're trying to memorise the time complexity of different algorithms.

This is a classic "dry" academic topic that's easy to forget.

To understand why spaced repetition is so powerful, consider a familiar scenario. You spend Sunday night staring at a chart of Big‑O complexities for four hours. By Monday’s review, you can recall most of them. By Friday, only a few remain. Two weeks later, the entire chart has vanished from memory.

Spaced repetition reverses this process by reviewing information at the precise moment it's about to be forgotten. Instead of cramming Big‑O notation in a single session, you revisit it across expanding intervals:

1. Day 1 (Initial Learning): You study the Big‑O chart and understand each complexity class.

2. Day 2 (First Review): You test yourself. If you recall an item correctly, you schedule the next review three days later. If you miss it, you review it again the following day.

3. Day 5 (Second Review): You encounter the material again. Because you still remember it, the interval expands to ten days.

4. Day 15 (Third Review): Your memory has begun to fade, but the moment you see the prompt, the concept resurfaces. This slight struggle to retrieve the information is precisely what strengthens long‑term retention.

5. Day 45 (Fourth Review): By now, the memory is deeply consolidated. Concepts like O(log⁡n) feel as natural and accessible as your own phone number.

Through this process, spaced repetition transforms fragile, short‑term awareness into durable, long‑term knowledge. Each review interrupts the forgetting curve, reinforces the schema, and reduces the cognitive load required to recall the concept in the future.

For self-taught developers, spaced repetition can take many forms. You might rewrite code from memory, re‑implement a feature days later, build small variations of the same concept, or return to the concept after working on different tasks.

Every review strengthens the schema and reduces the cognitive load required to recall it. Over time, what once felt complex becomes automatic — not because the concept changed, but because your brain reorganised it into a stable, efficient structure.

As you can see, learning isn't a single event but a cycle of exposure, forgetting, and reinforcement.

Mastery comes not from seeing something once, but from returning to it until it becomes part of your cognitive architecture.

But we must be careful with repetition. Doing the same thing over and over again doesn't guarantee improvement. In fact, mindless repetition can trap you at the same level indefinitely.

This is where the theory of deliberate practice becomes essential, as it emphasises increasing the level of challenge, focusing on specific weaknesses, and actively seeking feedback so that each repetition leads to measurable improvement rather than just familiarity.

Theory of Deliberate Practice

Developed by psychologist K. Anders Ericsson, it argues that expertise is not the result of talent but of high‑quality, intentional practice (Ericsson, 1993). This type of practice is fundamentally different from simply doing something repeatedly.

He coined the term "deliberate practice" while researching how people become experts. Studying experts from several different fields, he dismantled the myth that expert performers have unusual innate talents.

Instead, he discovered that experts attain their high performance through how they practice: it's a deliberate effort to become an expert. This effort is characterized by breaking down required skills into smaller parts and practicing these parts repeatedly.

According to Anders Ericsson, Deliberate Practice requires:

1. Clear goals

2. Immediate feedback

3. Tasks that stretch your ability just beyond your comfort zone

4. Full concentration and effort

The main tenet of Deliberate Practice is that tasks must stretch your ability just beyond your comfort zone. This is paramount to the advancement of learning.

Imagine a child being taught 1+1 every day. That child will never grow beyond basic arithmetic. Anders Ericsson calls this "Arrested Development" (Ericsson, Nandagopal and Roring, 2005). For that child to grow to become a mathematician, their knowledge must be stretched.

The takeaway for developers is a play on the DRY principle (Don’t Repeat Yourself): If you are only repeating what you already know without stretching yourself, you aren't growing. This "stretch" is the extra edge that Deliberate Practice adds to Spaced Repetition.

Building a simple to-do list, a calculator, or a weather app over and over again won't take you anywhere. You already know how to do those.

To truly grow, you must stretch yourself. Instead, try a project that integrates new ideas, like building a mini-app where the weather data affects your to-do list. For example, if the API shows it's raining, the app automatically hides outdoor tasks and calculates the time you'll save or the indoor tasks you should prioritize instead.

This forces you to handle complex logic and state management, moving you beyond simple repetition into true mastery.

This ability to create brings me to the last theory: Bloom's Taxonomy.

What is Bloom's Taxonomy?

Bloom’s Taxonomy provides a hierarchy of cognitive skills that learners move through as they develop mastery. It begins with the simplest tasks and progresses toward the most complex:

1. Remember – recalling facts or syntax

2. Understand – explaining concepts in your own words

3. Apply – using knowledge in real situations

4. Analyze – breaking problems into parts

5. Evaluate – judging solutions or comparing approaches

6. Create – building original systems or applications

Most self‑taught developers get stuck in the first two levels. They memorize syntax and understand examples, but they struggle to apply, analyze, or create.

This isn't because they lack ability. Rather, it's because they haven't been taught that learning must progress through these stages.

Bloom’s Taxonomy gives structure to the learning journey.

It reminds self-taught developers that mastery isn't achieved by watching tutorials but by climbing the ladder from remembering → understanding → applying → analyzing → evaluating → creating (with an emphasis on Creation).

Creation is one of the most difficult yet most transformative experiences in your journey as a developer. It forces you to think abstractly, confront ambiguity, and notice dimensions of a problem that tutorials rarely reveal.

When you build something real, the neatness of the theory in your head collapses, and you begin to see its true complexity. You must then devise strategies to navigate these challenges, and through this process, you learn.

And as with anything worthwhile, the process isn't smooth. You'll encounter bugs — not just one or two, but hundreds. Yet this is precisely how real knowledge is built. Every bug you solve becomes a permanent entry in your long‑term memory.

The next time you see that error, you won’t panic. Instead, you’ll recognise it instantly and know exactly where it’s coming from and how to fix it.

Some self‑taught developers encounter a few bugs and never return to their projects again, concluding that “coding isn’t for me.”

After trying several fixes and seeing no progress, they abandon the work and look for something else. But this is the wrong conclusion. The problem is rarely a lack of talent — it's a misunderstanding of how the brain behaves under cognitive strain.

Focused Mode vs Diffuse Mode

When you spend a long time wrestling with a bug, you may be experiencing mental fixation or functional fixedness.

This is when your brain becomes locked into a single line of reasoning, repeating the same logic path over and over because it feels like the right direction. The longer you stare at the problem, the deeper the cognitive rut becomes. You develop tunnel vision, making it almost impossible to see alternative solutions.

This is where understanding how the brain operates becomes essential.

According to Oakley (2014), the brain works in two primary modes:

1. Focused Mode: Ideal for executing a known formula or following a clear procedure, terrible for discovering a new approach or breaking out of a mental rut.

2. Diffuse Mode: This is activated when you step away — walking, showering, relaxing, or sleeping.

In this second mode, the brain enters a “big‑picture” state where neural connections stretch across different regions.

The background processes continue working on the problem without the restrictive tunnel vision of conscious focus.

This phenomenon is known as incubation.

This is why solutions often appear when you’re not actively thinking about the problem. You step away, and suddenly the answer emerges, not because you stopped working, but because a different part of your brain started working for you.

The reality is that many developers never allow for incubation. While you step away from the problem, your brain performs subconscious synthesis: it clears out the noise (Extraneous Load) and lets the core logic (Germane Load) settle. When you return, the “wrong” paths you were obsessing over have faded, and the correct path which was there all along often finally becomes visible.

This is why developers must deliberately allow for incubation. We can take some lessons from great minds of the past:

Henri Poincaré famously struggled with Fuchsian functions for weeks. It was only during a geological excursion when he had completely forgotten about the mathematics that the solution appeared with “perfect certainty” the moment he stepped onto an omnibus. His breakthrough did not come from more effort, but from stepping away long enough for diffuse mode to take over.

Friedrich August Kekulé experienced something similar after years of wondering why benzene’s carbon atoms didn't fit a linear structure.

If some of the greatest minds in history stepped away from their problems and found solutions in diffuse mode, why should developers treat themselves any differently?

Now that you're familiar with some key learning strategies – Cognitive Load Theory, Spaced Repetition, and Bloom's Taxonomy – creating or building a project from the ground up should be your next task. It will help you curate, retrieve, organise, and seal in all that diverse knowledge you've gathered as a self-taught developer.

Conclusion

In this article, we explored why the human brain isn't instinctively wired to understand programming. Coding is a biologically secondary skill, which means it doesn't develop naturally through immersion but requires explicit instruction, structure, and patience.

We also talked about the limits of working memory, the importance of chunking, and the need to manage cognitive load so that learning remains possible rather than overwhelming.

We then analyzed the three components of Cognitive Load Theory – intrinsic, extraneous, and germane load – and discussed how each influences the learning process. Reducing extraneous load is especially crucial for self‑taught developers, as it frees up mental resources for meaningful understanding.

From there, we turned to the Ebbinghaus Forgetting Curve, which demonstrates how quickly newly learned information fades without reinforcement.

To counter this natural forgetting, we introduced Spaced Repetition, a method that strengthens memory by reviewing material at expanding intervals. We also examined Deliberate Practice, which pushes learners just beyond their comfort zone to promote genuine skill development, and Bloom’s Taxonomy, which outlines the stages of cognitive growth from remembering to creating.

Finally, we emphasized the importance of knowing when to step back. The brain operates in both focused and diffuse modes, and effective learning requires movement between the two. Breaks are not signs of weakness but essential components of consolidation and insight.

Together, these theories form a comprehensive framework for learning to code with scientific precision. When self‑taught developers understand how their brain learns, forgets, and grows, they can design a learning process that isn't only more efficient but far more sustainable.

With all this new knowledge, one truth is certain: focus, determination, and consistency are the forces that transform theory into mastery.

Learning science can guide the process, but only sustained effort turns knowledge into skill.

References

1. Clearwater, L. (2024). Understanding the Science Behind Learning Retention | Reports | What We Think | Indegene. [online] www.indegene.com. Available at: https://www.indegene.com/what-we-think/reports/understanding-science-behind-learning-retention.

2. Dylan Wiliam [@dylanwiliam]. (2017, January 25). I’ve come to the conclusion Sweller’s Cognitive Load Theory is the single most important thing for teachers to know [Tweet]. X. https://x.com/dylanwiliam/status/824682504602943489

3. Ericsson, K. A., Krampe, R. T., & Tesch-Römer, C. (1993).
   The role of deliberate practice in the acquisition of expert performance.
   Psychological Review, 100(3), 363–406.

4. Garnett, S. (2020.). Cognitive Load Theory A handbook for teachers. [online] Available at: https://www.crownhouse.co.uk/assets/look-inside/9781785835018.pdf.

5. Geary, D. C. (2007). An evolutionary perspective on learning disability in mathematics. Developmental Neuropsychology, 32(1), 471–519. https://doi.org/10.1080/87565640701360924

6. Geary, D. C. (2008). An evolutionarily informed education science. Educational Psychologist, 43(4), 179–195. https://doi.org/10.1080/00461520802392133

7. George A. Miller (1956). The magical number seven, plus or minus two: Some limits on our capacity for processing information. Psychological Review, 63(2), 81–97. https://doi.org/10.1037/h0043158

8. Nelson Cowan (2001). The magical number 4 in short-term memory: A reconsideration of mental storage capacity. Behavioral and Brain Sciences, 24(1), 87–114. https://doi.org/10.1017/S0140525X01003922

9. Oakley, B. (2014). A Mind for Numbers: How to Excel at Math and Science (Even If You Flunked Algebra). New York: TarcherPerigee.

10. Sweller, J. (1988). Cognitive Load during Problem Solving: Effects on Learning. Cognitive Science, [online] 12(2), pp.257–285. doi:https://doi.org/10.1207/s15516709cog1202_4.

‌

‌

Real world applications aren’t just about showing data on a screen. They solve real problems, work with real users, and handle situations that don’t always go as planned. This is where many developers struggle.

When I review junior developers’ résumés, I notice a common pattern: the projects section is often filled with beginner apps that look very similar. In today’s job market, this is usually not enough. Employers want to see that you can build something useful, something people would actually use.

The goal of this article is to help you move past simple Hello World projects like todo apps, calculators, and basic CRUD applications. By the end, you’ll understand how to approach building real applications that solve real problems and feel closer to what is built in the real world.

You might be wondering why you should listen to me.

Over the last 10 years, I’ve spent a lot of time building, breaking, and rebuilding software. I have experimented, failed many times, and eventually built applications that thousands of people use every day. A few weeks ago, I launched one of my own SaaS products and watched real users use it at scale, with over a thousand active users during peak hours, without the system crashing.

I’m sharing this because I’ve been where you are now.

If you continue reading, you will:

• Learn from real experience building applications used by real users

• Learn what not to do, based on years of mistakes and lessons

• Learn what actually works and what helps you stand out as a junior developer

• Clear up common misconceptions that slow people down

This article is not about theory. It’s about building real things.

To drive this point home, we’ll build a real world application that solves a real problem and is used by real people. Along the way, you’ll learn how to come up with real application ideas, how to build them with simple tools, and how to serve them to many users.

If this sounds like something you’re up for, then let’s get started.

Table of Contents

1. You Probably Think You Don’t Know Enough

2. How to Find Real World Application Ideas

3. What Are We Going to Build

4. Prerequisites

5. Step 1: Setting Up the Backend

6. Step 2: Adding Background Removal to the Backend

7. Step 3: Building the Frontend

   • Running and Testing the Application Locally

8. Step 4: Putting the Backend on the Internet

   • Deploying the Backend on Cloud Run

   • Updating the Frontend to Use the Live Backend

9. Step 5: Making the Backend and Frontend Work Together CORS

10. Step 6: Putting the Frontend on the Internet

11. Final Thoughts What You Just Built Matters

You Probably Think You Don't Know Enough

Before we begin, I want to clear up the most common misconception beginners have.

Many developers believe they don’t know enough to start building real world applications. They think they need to learn more JavaScript, more Python, or another framework before they are ready. Some even think learning React is the final step that will suddenly make everything click.

This belief is very common, but it’s not true.

If you know how to write HTML, CSS, and a simple loop or function in any programming language, you already have most of what it takes to build a real world application. This tutorial is proof of that.

That’s why I am writing this article. Not to tell you to learn more first, but to show you how far you can go with what you already know.

How to Find Real World Application Ideas

One question beginners ask a lot is, “What kind of apps should I build?”

This is rarely talked about, but it matters more than most people think.

A simple rule is this: build things that already exist.

Look at the apps you use every day, especially the simple ones. Tools that do one thing well. If you find yourself using an app often, that app is solving a real problem.

For example, people use background removers to clean up images. They use URL shorteners to share links. They use notes apps to save quick thoughts. None of these ideas are new, but they are real.

You don’t need to invent something original. You need to understand a problem and build a working solution for it.

When you replicate real tools, you naturally learn how real applications are structured. You also end up with projects that make sense on a résumé, because they solve problems people recognize.

That’s exactly what we are going to do in this tutorial.

What Are We Going to Build?

I’ll tell you now, it is not going to be another Hello World application. We’re going to be building a background remover web application.

This is the kind of tool people actually use. Designers use it for images, content creators use it for thumbnails, and developers build similar features into real products. It works with real files, real data, and real results.

If you want to see the final result before we start building, you can try the working app here: https://iamspruce.github.io/background-remover/

We’ll build this app using simple tools on purpose. Plain HTML, CSS, and JavaScript for the frontend, and Python for the backend. No heavy frameworks and no complicated setup.

Before we continue, let me clear up another common misconception.

Many developers believe that for an application to be taken seriously, it must be built with complex frameworks. In my experience building applications for clients around the world over the last 10 years, not a single client has ever asked me what framework I used.

They only cared about one thing: Did it work, and did it solve their problem?

Users won’t care how your app is built. They care that it works. If HTML, CSS, and JavaScript can solve the problem, there’s no reason to wait months just to learn a new framework.

Now that we understand why we’re building this app and what problem it solves, it’s time to start writing code.

Prerequisites

Before we start writing code, let’s quickly talk about what you need.

This tutorial is not for absolute beginners, but it’s also not super advanced. If you’ve built small things before and you want to build something that actually feels real, you’re in the right place.

What You Should Already Know

You should be comfortable with:

• Basic HTML: You know what inputs, buttons, images, and divs do.

• Basic CSS: You can style a page and make it look presentable.

• Basic JavaScript: You know how to listen for a button click and send a request using fetch.

That’s enough to follow along.

You don’t need React or any other frontend framework.

Backend Knowledge

For the backend, you don’t need to be a Python expert.

You just need to understand that:

• Python can run a server

• A server can receive requests

• A server can send back responses

Everything else will be explained as we go.

Tools You Need

Make sure you have these installed:

• Python 3.9 or newer

• Git

• A code editor like VS Code

• A browser

No Docker knowledge or cloud experience required.

GitHub Account (Important)

We’ll deploy the backend directly from GitHub, so you’ll need a GitHub account.

If you’ve never pushed a project to GitHub or hosted one before, I’ve already written a beginner-friendly guide you can follow first.

Read that article, then come back here.

A Quick Mindset Check

This is not a copy-paste tutorial. You will see real errors. Things may break. That’s normal. That’s how real applications are built.

Now that we’re clear on what you need, let’s start writing code.

We’ll begin with the backend. This is an important decision, so let’s explain it properly.

Step 1: Setting Up the Backend

What Is a Backend and Why Do We Need One?

A backend is a program that runs on a server and does the heavy work for an application.

In our case, the heavy work is image processing. Removing a background from an image requires libraries that can’t run inside the browser. Browsers are designed for safety and user interaction, not for this kind of processing.

That’s why we need a backend.

The backend will:

• Receive an image from the user

• Remove the background

• Send the processed image back

The frontend will simply talk to this backend later.

Keeping Things Simple on Purpose

Because this might be your first real project, we’re going to keep the backend as simple as possible.

• One programming language (Python)

• One backend file

• No complex folder structure

• No advanced concepts

This is intentional. Real world applications don’t have to start out complex. They typically start small and grow.

Project Structure

Create a new folder called:

background-remover

Inside it, create a folder for the backend:

background-remover/
  backend/

Move into the backend folder:

cd background-remover/backend

Now create a virtual environment:

python -m venv env

A virtual environment keeps this project’s dependencies separate from everything else on your computer. This is standard practice and something you’ll see in real projects.

Now activate it:

macOS or Linux:

source env/bin/activate

Windows:

env\Scripts\activate

Now create a folder for your application code:

mkdir api

Your structure should now look like this:

background-remover/
  backend/
    env/
    api/

At this stage, nothing looks impressive yet. That’s normal.

Installing FastAPI

We’ll use FastAPI to build the backend API.

Install it together with Uvicorn, which is the server that runs our app:

pip install fastapi uvicorn

FastAPI allows us to define endpoints clearly and with very little code, which is perfect for us.

Creating the First Backend File

Inside the api folder, create a file called main.py.

Add the following code:

from fastapi import FastAPI

app = FastAPI()

@app.get("/health")
def health():
    return {"status": "ok"}

Let’s pause and understand what this does.

• We created a FastAPI application

• We added a /health endpoint

• This endpoint simply returns a message

Before building real features, developers always confirm that their server actually runs. That is exactly what this endpoint is for.

Running the Server

From inside the backend folder, start the server:

uvicorn api.main:app --reload

Now open a new terminal and run:

curl http://localhost:8000/health

You should see:

{"status":"ok"}

This is an important moment.

You now have:

• A running backend server

• A real HTTP endpoint

• A response coming from your own code

This is how real backend services start.

Why We Did This First

At this point, you might wonder why we didn’t jump straight into background removal.

The reason is simple: if the server doesn’t run, nothing else matters.

By starting with a health endpoint, we removed uncertainty. We know the server works. Everything we add next is built on top of something we already know is working.

Now that the foundation is in place, we can move on to the real feature.

Step 2: Adding Background Removal to the Backend

Before we write any code here, we need to clear up an important misconception.

A Common Misconception About Machine Learning

When people hear “background removal,” they often think machine learning is too advanced for them.

In real world development, this is almost never how it works.

You aren’t expected to build machine learning models yourself. You use libraries created by others and focus on integrating them correctly.

That is exactly what we’re doing here.

Installing the Background Removal Library

Install the required packages:

pip install rembg pillow onnxruntime

• rembg handles the background removal

• pillow helps us work with images

For our purposes here, you don’t need to understand how these libraries work internally. You only need to know how to use them.

Adding the Background Removal Endpoint

Now update main.py so it looks like this:

from fastapi import FastAPI, UploadFile, File
from rembg import remove
from PIL import Image
import io

app = FastAPI()

@app.get("/health")
def health():
    return {"status": "ok"}

@app.post("/remove-bg")
async def remove_bg(file: UploadFile = File(...)):
    image_bytes = await file.read()
    image = Image.open(io.BytesIO(image_bytes))

    output = remove(image)

    buffer = io.BytesIO()
    output.save(buffer, format="PNG")
    buffer.seek(0)

    return buffer.getvalue()

Let’s explain this carefully.

• The endpoint accepts an uploaded image

• The image is read into memory

• The background is removed

• The result is saved as a PNG with transparency

• The image is returned to the client

This endpoint is the core of our application.

Testing the Endpoint With curl

Before building the frontend, we’ll test the backend directly.

Run this command:

curl -X POST \
  -F "file=@person.jpg" \
  http://localhost:8000/remove-bg \
  --output result.png

Open result.png. If you see the background removed, then the backend is complete.

At this point, you have built a backend that:

• Accepts real user input

• Processes real data

• Returns a meaningful result

This is a real backend.

Where We Are Now

Let’s pause and summarize:

• We set up a backend server

• We confirmed that it runs

• We added a real feature

• We tested it without a frontend

This is exactly how real developers work.

In the next section, we’ll build a simple frontend that talks to this backend and turns it into something users can interact with.

Step 3: Building the Frontend (What the User Actually Sees)

At this point, our backend is working.

It can receive an image, remove the background, and send the result back. But right now, only developers can use it, because it requires terminal commands.

To make this useful to actual (non-technical) people, we need a frontend.

The frontend is simply the part of the application users see and interact with in their browser.

Clearing a Common Misconception About Frontends

Many beginners think building a frontend means learning a framework first.

This is not true.

Frameworks help later, but they aren’t required to build real applications. Under the hood, every frontend still comes down to HTML, CSS, and JavaScript.

That’s why we are using plain HTML, CSS, and JavaScript here. No React, no build tools, no setup. Just the basics.

What Our Frontend Will Do

Our frontend has one job. It will:

• Let the user select an image

• Send that image to the backend

• Receive the processed image

• Show it on the screen

• Allow the user to download it

That’s all.

If it does these things correctly, it’s a real frontend.

Creating the Frontend

Go back to the root of your project and create three files:

index.html
styles.css
app.js

This simple setup is very common. Each file has a clear responsibility, which makes the code easier to understand.

Writing the HTML Page

Open index.html and add the following:

<!DOCTYPE html>
<html>
  <head>
    <title>Background Remover</title>
    <link rel="stylesheet" href="styles.css" />
  </head>
  <body>
    <h1>Background Remover</h1>

    <input type="file" id="imageInput" />
    <button id="removeBtn">Remove Background</button>

    <div class="result">
      <img id="resultImage" />
    </div>

    <a id="downloadLink" download>Download Image</a>

    <script src="app.js"></script>
  </body>
</html>

Right now, this page won’t do anything interesting. That’s expected.

HTML only describes what should be on the page. The behavior comes from JavaScript, which we’ll add after we add some styling.

Adding Some Basic Styling

Open styles.css and add this:

body {
  font-family: sans-serif;
  max-width: 600px;
  margin: 40px auto;
}

button {
  margin-top: 10px;
}

.result {
  margin-top: 20px;
}

img {
  max-width: 100%;
}

#downloadLink {
  display: none;
  margin-top: 10px;
}

This is not about making things look fancy.

The goal here is simply to make the page readable and pleasant to use. Many real internal tools look no better than this. (And you can always improve the styling later if you want.)

Connecting the Frontend to the Backend

Now we’ll write the JavaScript that makes everything work.

Open app.js and add the following code:

const imageInput = document.getElementById("imageInput");
const removeBtn = document.getElementById("removeBtn");
const resultImage = document.getElementById("resultImage");
const downloadLink = document.getElementById("downloadLink");

removeBtn.addEventListener("click", async () => {
  const file = imageInput.files[0];

  if (!file) {
    return;
  }

  const formData = new FormData();
  formData.append("file", file);

  const response = await fetch("http://localhost:8000/remove-bg", {
    method: "POST",
    body: formData,
  });

  const blob = await response.blob();
  const imageUrl = URL.createObjectURL(blob);

  resultImage.src = imageUrl;
  downloadLink.href = imageUrl;
  downloadLink.style.display = "inline";
});

Let’s slow down and explain what’s happening here:

• We read the image selected by the user

• We wrap it in FormData so it can be sent to the backend

• We send it to our /remove-bg endpoint

• We receive the processed image back

• We display it and prepare it for download

This is the moment where the frontend and backend finally talk to each other.

Running the Frontend With Live Server

Before testing, make sure your backend is still running.

Now, instead of opening index.html directly, use the Live Server extension in VS Code.

If you don’t have it installed, just open VS Code extensions, search for “Live Server”, and then install it. Then right click on index.html and click “Open with Live Server”.

This starts a small local server for the frontend.

Why does this matter?

Many browser features work better when files are served through a server instead of opened directly from the file system. Using Live Server also matches how real frontends are served.

Testing the Full Application Locally

Now choose an image and click the button.

If everything is working:

• The image is sent to the backend

• The background is removed

• The result appears on the page

• The download link shows up

Take a moment here. You have just built:

• A backend that processes real data

• A frontend that talks to it

• A complete application running locally

This is already more than a “Hello World” project.

Clearing One More Misconception

Some beginners look at this and think: “This feels too simple to be a real app.”

This is another misconception. Real applications aren’t defined by complexity. They’re defined by usefulness. If your app solves a real problem and people can use it, it’s a real application.

In the next section, we’ll take this exact app and put it on the internet so anyone can use it.

Step 4: Putting the Backend on the Internet

Right now, your backend is running on your computer.

That means:

• It works only for you

• If you close your laptop, it stops

• If someone opens your frontend, it cannot reach your backend

To fix this, we need to run the backend on a computer that is always online.

This process is called deployment.

A Simple Way to Think About Deployment

Deployment does not mean writing new code.

It simply means this: instead of running your backend on your laptop, you run it on another computer that never sleeps.

Everything we do next exists only to make that happen.

Why We Aren’t Using Netlify or Vercel

You might be wondering why we aren’t using Netlify or Vercel. Those platforms are great, but they’re mainly for frontends.

They work best when your app is:

• Static HTML, CSS, and JavaScript

• A frontend framework like React or Vue

• Small serverless functions

Our backend is different. It’s a Python server that:

• Stays running

• Accepts image uploads

• Processes images

• Uses heavy native libraries for background removal

This kind of backend needs a real server, not a lightweight serverless function.

That’s why Netlify and Vercel aren’t a good fit here.

Why We’re Using Cloud Run

Instead, we’re using Cloud Run.

Cloud Run lets us run real backend servers on Google’s infrastructure without managing servers ourselves.

We’re using it because:

• It supports full Python backends

• It deploys directly from GitHub

• It handles scaling and servers for us

• It works well with heavy workloads

• It’s beginner-friendly

Most importantly, it lets you deploy a real backend without learning cloud commands or CI/CD pipelines.

Preparing the Backend for Cloud Run

Before deploying, we need to make sure our backend is ready.

Creating requirements.txt

Inside the backend folder, create a file called requirements.txt.

Add this:

fastapi
uvicorn
rembg
pillow
onnxruntime

This file tells Cloud Run which Python libraries to install.

Creating a GitHub Repository

Cloud Run deploys directly from GitHub, so our code must live there.

From the project root, run:

git init
git add .
git commit -m "Initial background remover project"
git branch -M main
git remote add origin YOUR_REPO_URL
git push -u origin main

This single repository will be used for both backend and frontend.

Deploying the Backend on Cloud Run

Now open your browser and go to Google Cloud Console.

1. Create a New Project

Open Google Cloud Console and click New Project. Give it a name (for example: background-remover) and then click Create.

2. Open Cloud Run

Use the search bar at the top and search for Cloud Run. Then open it.

Cloud Run will automatically enable the required APIs.

You will be asked to set up billing. Google gives you $300 free credit, which is more than enough for this tutorial.

3. Start Creating the Service

Click Create Service and choose Deploy continuously from a repository.

4. Connect Your GitHub Account

Select GitHub as the repository provider and authenticate your GitHub account. Then install Google Cloud Build on your GitHub account. Choose only the repository you want to deploy.

This allows Google Cloud to build and deploy your code automatically.

5. Select the Repository

Then choose the repository you just installed Cloud Build on and select the main branch.

6. Configure the Build

Now comes the important part: building the context directory.

Set this to:

backend

This tells Cloud Run:

“My backend code lives inside the backend folder.”

For the entry command, enter:

uvicorn api.main:app --host 0.0.0.0 --port 8080

This is how Cloud Run starts your FastAPI server.

7. Configure Container Resources

Our backend runs a background-removal model, which is heavy.

So we must increase resources.

• Change memory from 512 MB → 2 GB

• Set CPU to 4

This ensures the model can load and run properly.

8. Deploy

Now click Create.

Cloud Run will:

• Build your app

• Install dependencies

• Create a container

• Deploy it to the internet

You’ll see logs showing the build and deployment process.

This can take a few minutes. That’s normal.

Checking That the Backend Is Live

Once deployment finishes, Cloud Run will show you a public URL.

Test it:

curl https://YOUR_CLOUD_RUN_URL/health

If you see:

{"status":"ok"}

Your backend is officially live on the internet.

Pause here for a second.

You just deployed a real backend. Congratulations.

Updating the Frontend to Use the Live Backend

Open app.js.

Replace:

http://localhost:8000/remove-bg

With:

https://YOUR_CLOUD_RUN_URL/remove-bg

Save the file and reload the frontend.

Step 5: Making the Backend and Frontend Work Together

At this point, we have two things:

• A backend running on the internet

• A frontend running in the browser

Now we want them to talk to each other.

Open your frontend, select an image, and click the button. You’ll notice that it still doesn’t work. This is expected.

What Is Happening Here?

Your frontend is running on one address, while your backend is running on another address.

Browsers are very strict about this. By default, a browser will block requests from one website to another unless the backend explicitly allows it. This is a security feature.

This rule is called CORS.

Clearing a Common Misconception About CORS

When beginners see a CORS error, they often think something is broken.

Nothing is broken. CORS is simply the browser saying: “I need the backend to confirm that this frontend is allowed to talk to it.”

So all we need to do is tell the backend: “It’s okay for requests to come from my frontend.”

Allowing Only Our Frontend (Not Everyone)

Instead of allowing requests from everywhere, we’ll allow requests only from our frontend. This is a good habit to learn early.

Open backend/api/main.py.

Add this import at the top:

from fastapi.middleware.cors import CORSMiddleware

Then, after creating the FastAPI app, add this:

app.add_middleware(
    CORSMiddleware,
    allow_origins=[
        "http://127.0.0.1:5500",
        "http://localhost:5500"
    ],
    allow_methods=["POST"],
    allow_headers=["*"],
)

Why these URLs?

If you’re using the Live Server extension, your frontend is usually served on port 5500. These are the addresses your browser is using locally.

We’re telling the backend: “Only accept requests from this frontend.”

That is exactly what we want.

Redeploying the Backend

Any time you change backend code, you need to redeploy it.

Since our backend is deployed on Cloud Run and set up with automatic deploy, redeploying is simple, all you need to do is push your changes.

From the project root, run:

git add .
git commit -m "Add CORS configuration"
git push

Cloud Run will automatically detect the change and redeploy your backend.

Wait for the deployment to finish. Once it’s done, your backend will now allow requests from your local frontend.

Testing Again

Reload your frontend in the browser.

Select an image and click the button. This time, it should work.

You just handled a real browser security rule that every production app runs into. That alone is a huge learning step.

Step 6: Putting the Frontend on the Internet (GitHub Pages)

Right now, your frontend works only on your computer.

Just like the backend earlier, this means no one else can use it.

Let’s fix that.

Why GitHub Pages?

Our frontend is:

• Just HTML, CSS, and JavaScript

• No backend code

• No build step

This makes it perfect for GitHub Pages. GitHub Pages can host static sites for free, and it’s very beginner friendly.

Preparing the Frontend for Deployment

Make sure all your frontend files are inside the frontend folder:

frontend/
  index.html
  styles.css
  app.js

Open app.js and make sure the backend URL is the Cloud Run URL, not localhost.

fetch("https://YOUR_CLOUD_RUN_URL/remove-bg", {
  method: "POST",
  body: formData,
});

Save the file.

Pushing the Frontend to GitHub

We already created a GitHub repository earlier, so we’ll reuse it.

From the project root, run:

git add .
git commit -m "Add frontend and prepare for GitHub Pages"
git push

Enabling GitHub Pages

1. Go to your repository on GitHub.

2. Open Settings.

3. Click Pages.

Under Source, select:

1. Branch: main

2. Folder: /(root)

Save everything. After a few seconds, GitHub will give you a URL. This URL is now your frontend on the internet.

Updating CORS for the Live Frontend

Now that the frontend is live, go back to backend/api/main.py.

Replace the local origins with your GitHub Pages URL:

allow_origins=[
    "https://YOUR_GITHUB_USERNAME.github.io"
]

Commit and push the change:

git add .
git commit -m "Update CORS for GitHub Pages"
git push

Cloud Run will redeploy the backend automatically.

Final Test

Open your GitHub Pages URL.

Upload an image, remove the background, and download the result.

Everything is now live.

Where You Are Now

Let’s be very clear about what you just did.

You:

• Built a real backend

• Deployed it to the internet

• Built a frontend

• Deployed it to the internet

• Fixed real production issues

• Connected everything properly

This is not a demo project. This is a real application.

In the final section, we’ll wrap things up, talk about what you learned, and where you can go next.

Final Thoughts: What You Just Built Matters

At this point, it is worth stopping and looking back at what you have actually done.

You didn’t just follow steps. You didn’t just copy code. You built a real application.

Let’s Be Clear About What You Accomplished

You started with nothing more than basic tools and ideas.

By the end of this tutorial, you:

• Built a backend that processes real data

• Used a machine learning tool without fear or overthinking

• Exposed a backend to the internet

• Built a frontend with plain HTML, CSS, and JavaScript

• Connected the frontend and backend properly

• Deployed both parts so real users can access them

This is exactly how real applications are built, just at a smaller and more manageable scale.

Why This Is No Longer a “Beginner Project”

Many projects are called beginner projects, but they stop at showing things on a screen.

This one does not.

Your app:

• Accepts real input

• Performs real work

• Runs on real servers

• Handles real browser rules

• Can be shared with anyone

That is the difference between learning syntax and building software.

The Most Important Lesson in This Tutorial

The most important thing you should take away from this is not the project you built.

It is this: You didn’t need to “know more” before you started.

You learned by building. You figured things out as they appeared. You fixed problems when they showed up.

That is how experience is gained. No one has experience before building real applications. No one lacks experience after building many of them.

What You Can Do Next

This project isn’t the end. It’s a starting point.

Here are a few ideas you can explore next, using what you already know:

• Improve the user interface

• Add loading states and better feedback

• Restrict image size or file types

• Add simple rate limiting

• Build another small tool that solves a real problem

You don’t need to jump to frameworks yet.

If you can build a few more projects like this, frameworks will make a lot more sense when you meet them.

One Last Thought

If this was your first real project, you should be proud of yourself.

You moved past tutorials, built something useful, and put it on the internet. That’s the line many developers never cross.

Now that you have crossed it, the next one will be easier.

So keep building!

Source Code and Live Demo

If you want to explore the full project or build on top of it, you can find everything here.

• Live application: https://iamspruce.github.io/background-remover/

• GitHub repository: https://github.com/iamspruce/background-remover

If you have questions, reach me on X at @sprucekhalifa. I write practical tech articles like this regularly.

It is better to be a samurai in a garden than an agricultural worker in a war - Miyamoto Musashi

In this article, I’ll share my story.

When I was younger, I thought I was destined to be a failure in life. To be isolated from everyone. But years later, I realized I was actually destined for success.

I went from wasting thousands of hours playing video games to giving a lecture to medical professionals called “Trustworthy AI: The Role of Small Models in Critical Systems.”

And I went from being told I was dumber than most people based on an IQ test I took as a 14 year old low self-esteem kid, to becoming a frequent contributor to freeCodeCamp. I’ve written articles on interpretable AI, applied math, and advanced tech. And these articles have now reached more than 200,000 people worldwide.

And this is just the beginning.

When it comes to education, I owe gratitude to three people and the organizations they lead:

• Salman Khan, founder of Khan Academy

• Quincy Larson, founder of freeCodeCamp

• Andrew Ng, co-founder of Coursera and founder of DeepLearning.AI

I also owe a lot to the great author of the book Atomic Habits: An Easy & Proven Way to Build Good Habits & Break Bad Ones – James Clear.

I’m sharing my story to inspire others who are struggling in their lives just like I was.

I’m also writing this for those who know me or will know me personally, so that they can understand where my determination comes from and why I am relentless.

Here’s what I’ll cover:

1. Where I Was: Misery, Depression, and Isolation

2. My Transformation: Learning Triple Integrals and Programming

3. One of the Best Choices in My Life: Why I Chose Electrical and Computer Engineering

4. Being Restless and Determined: My Work Ethic in University

5. My Projects while in NOVA FCT: AI Projects, International Student Organizations, and freeCodeCamp Articles

6. My Personal Philosophy at 21 Years Old and View on Envy and Negativity

7. Where I Am Today: A Fraction of What I Have Achieved

8. Final Thoughts: Have an Adaptive Grand Strategy for Your Life

Where I Was: Misery, Depression, and Isolation

Photo by Nikko Balanial on Unsplash

"As it turns out, it was that very rock bottom that became the firmest foundation I had ever planted my feet on." — Mandy Hale

Five years ago, I was in a different place and was a completely different person.

Like many teenagers, I started playing video games and became addicted to them. Over time, games became an escape from reality and all my problems, including my bad grades and many other issues.

At age 14, I still held ambitions in my heart. I dreamed of being someone who would help others, maybe as a doctor or an engineer.

But after an IQ and vocational guidance test, I was told that I was incapable of doing these things. That I lacked the intelligence needed. That it was unrealistic for me to pursue these types of degrees.

Eventually, and because of many comments, opinions, and expectations of others, I began to believe in this lie for years.

Over time, depressed and constantly escaping reality, my grades plummeted and I got worse and worse. And this only made the prospect of going to college less and less likely.

By 11th grade, I was:

• Extremely shy and anxious

• Struggling academically

• Over 2000 hours in video games on two games alone:

  • 1000 hours in GTA V

  • 1000 hours in Destiny 2

2000 hours equals nearly 83 days.

This means that in these two games, I lost more than two months of my life.

But from these wasted hours, I learned English. This became crucial when learning online.

In January 2020, I was tired of everything. In particular, I was sick of the misery of always being at the bottom and of so much negativity towards and around me.

So I made these vows to myself for the rest of my life:

• Never again would I worry or care about what other people say about me.

• I would no longer accept the limitations imposed by others or myself on my growth.

• And as for the limitations I imposed on myself, I would rethink to see if they were really impossible or if I could actually conquer them.

As a result, I started relearning and learning everything by myself to make sure I succeeded in the national exams.

My Transformation: Learning Triple Integrals and Programming

Photo by Joshua Earle on Unsplash

"The expert in anything was once a beginner."
— Helen Hayes

I started going through chemistry exercises in the 10th and 11th grades using books from school and YouTube videos. In two weeks, I relearned or learned most of the material I needed to know.

I started doing the same for mathematics, something I always found hard due to a lack of basic foundational mathematics knowledge.

I found it hard, that was, until I discovered Khan Academy.

With the Khan Academy, I rebuilt myself, going from struggling with basic math to mastering double and triple integrals, all within five to six months.

My method was simple:

• Study a little bit every day.

• Take detailed notes

• Redo quizzes or units tests until I scored more than 90%

  • For topics that I found harder or failed to understand, I did the practice exercizes

• Use YouTube to close any knowledge gaps

For example, for Algebra I, where I started to relearn math, I say how many units there were. Each unit had a certain number of topics. As of 2025, Algebra I has, from units with mastery exercises, 89 topics.

For those 89 topics, I watched the videos and did the quizzes. According to my scores, I would either go on to the next video (if I felt confident), or stop, rewatch the video, go through the same material on YouTube, do practice exercises, and then try to do the quiz again.

I decided that I needed to do at least three topics every day. This way, by doing 3 topics per day, I could finish Algebra I by the end of one month.

But I was so motivated and so focused on it that I did more than 3 topics per day.

I did the same for Algebra II, and all the others until College Calculus BC.

Some days, I completed more than 8 topics. Other days, I struggle to even do 2. But I made sure that I mastered mathematics and its foundation for the rest of my life.

This was not just about grades. It was about regaining belief and confidence in myself.

I also read many books, primarily self-help, to make myself better. Over the years, I have started reading fewer self-help books and have started focusing on non-fictional books that explain to me how the world works.

COVID-19: Accelerating My Learning in Programming and Machine Learning

When the pandemic hit, I started accelerating my learning in other areas, like programming and physics. In many online classes, I didn’t pay attention as well as I should’ve – and I found myself prioritizing self study on topics I found more important. And I always used my time to learn more about programming.

I learned Python and C through free YouTube courses for beginners on freeCodeCamp’s channel.

This was where I first learned Python.

And C:

Soon after exploring C programming, I realized that programming languages are just tools. Once you master one, others come more naturally.

I studied data science tutorials on the web and on YouTube. This way, I learned how to import Python libraries in virtual environments. I also began building projects with Python libraries I found interesting and made it a habit to explain every line of code to myself as if I were the teacher.

For example, I started working with the scikit learn Python library to make simple linear and logistic models that could make make predictions.

I also decided to explore Deep Learning and taught myself how to work with Arduino and circuits. In other words, I learned how to train the architecture of neural networks to predict things.

I found this hard to master compared to triple integrals at the time!

But this way, I understood one very important thing about Deep Learning: to truly understand and master it, I needed to know, deeply, some difficult mathematics concepts. And I also needed to learn quickly about the new research coming out.

One of the Best Choices in My Life: Why I Choose Electrical and Computer Engineering

Photo by Nicolas Thomas on Unsplash

"Opportunities multiply as they are seized."
— Sun Tzu

After completing the Portuguese national mathematics exam in the 12th grade, I chose Electrical and Computer Engineering (ECE). I choose this area, because it would challenge me and allow me to gain the skills to learn and apply new mathematics by myself without anyone teaching me.

It was also broad:

• If I liked, I could follow an electrical engineering area. Like circuits, power systems, or telecommunications.

• If an electrical engineering subarea was not in my best interest, I could follow a computer science path or apply math in banking or other areas where people who know applied math work.

The ECE degree also allwed me to unite the following areas:

• Advanced Mathematics

• Programming (from low-level like assembly and C to high-level like Python)

• Physics (circuits, robotics, communication systems)

I wanted to become someone who not only mastered knowledge but could also create new systems and ideas from it.

I knew that I was laying the foundation for something greater than just academic success.

What Did I Gain Exactly?

Over time, I learned the many skills I needed to understand all the new AI research coming out after completing AI specializations.

I also learned hard math and applied mathematics areas such as:

• Partial differential equations: how they can represent and model real phenomena, like the economy of a country.

• Pure harmonic analysis: Fourier and Laplace transformations and how integral transformations allow us to see problems in other ways.

• Complex analysis: application of derivatives and integrals in a complex domain, with real and imaginary numbers.

• Numerical analysis: how math used to approximate analytical math is used by computers to get faster results.

• Signal and control theory: how the architecture of systems is studied to ensure rocket, train, and car control systems are stable, despite possible disturbances in the systems.

Not to mention physics classes like:

• Classical mechanics

• Electromagnetism

While these topics may not be applied in depth to AI, learning them helped me develop an incredible intuition into systems thinking. It also greatly improved my ability to learn hard STEM concepts on my own.

Being Restless and Determined: My Work Ethic in University

Me at 18 years old

"Success is the sum of small efforts, repeated day in and day out." — Robert Collier

I adopted a very rigorous work ethic.

When my work ethic failed to achieve what I wanted, I adapted with more knowledge and learned very deeply what I did wrong so as not to repeat it.

For example, in the first semester, my first grades were not the best. So, I read:

• Deep Work

• The Effective Executive: The Definitive Guide to Getting the Right Things Done

• How to Become a Straight-A Student: The Unconventional Strategies Real College Students Use

These books taught me how to focus and prioritize what needed to be done. This became essential as I entered one of the most demanding phases of my life.

In addition, I used Notion as a management system and Google Calendar as a schedule system.

Every week, I transferred next week's tasks from Google Calendar to Notion. This way, I never forgot anything and never worried about forgetting anything.

I had two simple scalable systems that worked very well for managing everything I did.

In the scheduling system, I would place certain events on repeat, for example:

1. Every week:

   • Read the top articles of the week on Subreddits dedicated to programming and others topics so I could keep learning and growing. Same with communities on Stack Exchange Network.

• Read new articles on IEEE Spectrum and learn as much as possible about what is happening currently.

2. Every two weeks:

   • Plan my studying according to time available, as well as all class and other resources I could get for tests, projects, and exams.

3. Every month:

   • Review my annual objectives and prioritize what was important and urgent to do in that month. Also, review new opportunities that appeared that aligned with my objectives this year and in my life.

This way, I was always aligned and efficient. And all this was from a Notion database.

Very often, I started working at 8:00am and continued until around 9:00 or 10:30am, when my classes often started. At that time, I studied, did student organization work, completed online courses and specializations, worked on AI projects, wrote freeCodeCamp articles, and many tasks.

I went beyond studying just the subjects from my degree:

• I also studied history, economics, and geopolitics to understand the hidden incentives that shape the world.

• I developed the habit of studying the architecture of things, from political systems to technology, understanding how they work to design better systems.

• I attended many free online and university events to learn as much as possible.

I also treated weekends as opportunities to grow and work, and did not stop. This was not possible 100% of the time, but most days I was able to do so.

In this way, I completed Coursera’s prestigious Deep Learning Specialization, a very important achievement in my journey.

I also read many books and listened to podcasts while taking public transportation, ensuring that no time was wasted.

My Projects While in NOVA FCT: AI Projects, International Student Organizations, and freeCodeCamp Articles

Me at 21 years old.

"The strength of the team is each individual member. The strength of each member is the team."
— Phil Jackson

International student organizations often offer opportunities that are rarely found in local college clubs.

These student organizations are also often better managed than some local clubs, which can sometimes suffer from internal politics focused on titles rather than making a real contribution to society.

For this reason, I sought international organizations that pushed members towards real impact and development.

After a while, I became interested in BEST (Board of Engineering Students of Technology), a large international organization of student organizations spread over 80 groups around European universities. I joined the local group, BEST Almada, one of the 80 local BEST groups across Europe that helps foster the development of students through courses and events.

I also became deeply involved in the IEEE, the world’s largest non-profit professional association, where I served as the Vice-Chair of the IEEE NOVA Student Branch. Currently, I contribute nationally in the IEEE Portugal Section by creating videos for social media.

Thanks to IEEE, I was able to go to the IEEE Melecon conference in Porto last year to speak with some amazing scientists and researchers.

Here’s a key thing I learned from IEEE that I want to share: Communication, alignment of expectations between everybody, and knowing how to navigate social dynamics is crucial for any project or initiative to succeed. Of course, the culture of the organization and a lot of other variables are important as well. But I believe communication is one of the most important and critical factors.

Along this path, I worked on projects like Eurostatify AI, which aimed to provide European public data insights and hidden patterns that are accessible to researchers and policymakers. I also led the Doctor AI Project as part of a Hackathon in March 2023, where I developed two AI bots using Flutter and the ChatGPT API to help doctors make better decisions.

Each step helped me forge myself into someone capable of inspiring and leading others. I also taught complex topics in my freeCodeCamp articles, such as how CPUs work in depth, interpretable AI, quantum AI, and even how to design a control system for rockets.

I was involved in local student clubs before I realized the value of joining international organizations. In Europe, these organizations bring unique opportunities, are usually better managed than local groups. They’re a great place for developing soft skills as well.

So in the end, joining international student organizations was one of the best decisions of my university life.

My Personal Philosophy at 21 Years Old and View on Envy and Negativity

Photo by Giammarco Boscaro on Unsplash

"Freedom lies in being bold."
— Robert Frost

Here’s one thing I’ve learned over the years: You need to make your own path. Chasing social status and falling prey to social pressures isn’t worth it, and you shouldn’t be blinded by these things. True freedom comes from defining your own path. Developing relationships with professors and mentors, learning from books, and taking advantage of solid free learning resource are all things that can help you go further in life.

But what about envy and negativity from others?

Well, unfortunately these will always be part of our lives. Being envious is human nature, and various forms of negativity will likely continue to exist. Anyone who works and achieves any level of success will inevitably attract envy and negativity.

The best response is not to react and to ignore it completely. Just keep growing.

Some people will disappear, mock you, envy you, or hate you – but just try to let it all go. Keep walking your path.

Time is precious. Don’t waste it on:

• Meaningless opinions

• Video games

• Distractions

I find it sad that, despite living in such an exciting time, and despite unprecedented access to knowledge and education, advances in technology, and immense global connectivity, some people still choose to hate and be envious of others. But as I said before, it’s human nature and there is little we can do about it.

Just remember: you have opportunities today that previous generations could only dream of. Take advantage of them to the fullest and worry about your own personal growth.

Where I am Today: A Fraction of What I Have Achieved

Me in a Tesla factory in Silicon Valley

"I am not a product of my circumstances. I am a product of my decisions."
— Stephen R. Covey

At 21, I am finishing my degree in Electrical and Computer Engineering at NOVA FCT.

So far:

• I’ve been accepted into the Silicon Valley Fellowship Program: Only 18 out of 600 are accepted to visit Silicon Valley's top companies and universities.

• I’ve delivered a talk to doctors about AI called "Trustworthy AI - The Role of Small AI Models in Critical Systems.". Before this, I delivered other smaller talks.

• I’ve completed Coursera AI specializations such as the Deep Learning Specialization from DeepLearning.AI and Reinforcement Learning Specialization from the University of Alberta.

• In IEEE (the largest non-profit professional association in the world), I served as the vice chair of my faculty IEEE NOVA SB student branch, and I am now an IEEE PT Officer, creating videos for social media.

• I’ve had twenty articles published on freeCodeCamp since 2023 that have accumulated around 200,000 views. They are related to advanced applied math, AI, and technology. (Link below)

• I’ve been recognized as a Top Open Source Contributor for freeCodeCamp in 2022, 2023, and 2024

Final Thoughts: Have an Adaptive Grand Strategy for Your Life

Silicon Valley Fellowship post about me

"What you do makes a difference, and you have to decide what kind of difference you want to make."
— Jane Goodall

My life objective was and still the same when I was 14, 7 years ago:

• Help as many people as possible. In their opportunities to make their life’s better and in making society better for future generations that will come after mine.

My strongest advice for anyone: Have a grand strategy for your life.

A grand strategy is a type of long-term strategy in which nations align power and resources to achieve their objectives. You must align your actions, skills, and knowledge towards your purpose.

I used to be afraid of public speaking and so many other things. Not anymore.

Now, I know I am destined to contribute, inspire, and leave a mark on other people's lives for the better.

If you feel stuck, remember:

• You can change! It will be hard. Many people will not want it.

• Ignore all that and focus on yourself.

It takes effort, patience and courage, but it is possible.

Thanks to all organizations for the opportunity to contribute to society and grow as a person:

• NOVA School of Science and Technology and its student association, AEFCT

• IEEE Portugal Section

• Silicon Valley Fellowship

• BEST and BEST Almada

• Magma Studio

I also want to thank all the university professors at NOVA FCT who taught me, especially the ones from the department of electrical and computer engineering.

Finally, I want to express my gratitude to Portuguese society. Not long ago, in Portugal, pursuing higher education, especially in STEM, was inaccessible to many. Thanks to the efforts of past generations, today, young people like me can pursue these opportunities and contribute back to society.

This is just the beginning of my impact on society.

My FreeCodeCamp blog:

You may have tried every trick you know but still feel lost. But have you tried creating a visual representation of the problem so you can see how the code actually works?

I’m talking about using a flowchart.

In this article, you’ll learn how flowcharts work along with some common symbols and labels you can use in your flowcharts. We’ll also discuss some popular diagramming tools you can use to create flowcharts more easily. Finally, we’ll walk through how to actually build a flowchart so you can start using them in your projects.

Table of Contents

• What is a Flowchart?

• A Flowchart’s Symbology, the Limitations of Symbols, and Solutions

• Common Symbols and Labels Used in Flowcharts

• How to Add Shapes to Your Flowchart: Generalization vs Refinement

• Popular Diagramming Tools for Creating Flowcharts

• How to Build a Flowchart – Methodology and Example

• Conclusion

What is a Flowchart?

Simply put, a flowchart is a diagrammatic representation of an algorithm. It’s called a flowchart because it not only represents the steps but also depicts the direction the “job” flows as tasks are transferred to the next entity.

In many cases, a flowchart is considered part of a larger family of diagrams, usually referred to as flow diagrams. And although both names are commonly used, we’ll stick to the use of flowcharts to represent algorithms for now.

Here’s an example of a flowchart:

You’ll notice that it uses certain different shapes and colors – we’ll discuss these further below.

How Common Are Flowcharts These Days?

“Aren’t they from the time of, like, Cobol?” you might ask. Well, yes they are – and from even before that. Flow diagrams were quite popular from their introduction in the 1920’s all the way to the 1970’s. But their use started to fall off soon after that.

So you might wonder: are developers actually using flowcharts – or any kind of diagram – nowadays? I did some quick research across different developer community chats. I found that while not all devs say they use flowcharts, many of them mentioned that they were important in helping them sketch a vizualization of the code or the system.

I also found that senior developers were less interested in the use of diagrams because they usually knew the algorithms or the codebase almost by heart. But newer developers who were exposed to a codebase for the first time, revisiting a forgotten algorithm, or those needing to share some code with others tended to use flowcharts more often.

Why Do Devs Use Flowcharts?

Here are some of the most common reasons developers use flowcharts these days:

• Focus: A visual resource to help you think about a problem.

• Planning: Map out your steps before diving in.

• Sharing standard processes: As a tool to facilitate the reading of standard processes.

• Communicating and teaching: Explaining your code to both technical and non-technical people.

• Documenting: Keep track of your work in a way that’s easy to follow.

• Analysing existing code: Break down your code and others’ to see what’s really going on.

Of course, there are other methods you could use to cope with the situations listed above. But there are advantages to using flowcharts over other methods that have to do with the way we process information in our brain.

Still, making flowcharts is an intellectual process that entails some risks, particularly when it comes to clarifying information. So we need the right tools and a methodology to work with them.

In the following sections, we will go through all those points in more detail:

• The semiotic of the flowchart – that is, the use of symbols to convey information. We’ll also discuss the role of the flowchart as an information tool, its limitations, and how to address them.

• The most common symbols, their meanings, and how to use them

• The intellectual processes of constructing flowcharts and their risks

• A methodology to help you reduce those risks

• The available tools to create flowcharts with a quick introduction to the one we will use for our examples

A Flowchart’s Symbology, the Limitations of Symbols, and Solutions

Earlier, I defined a flowchart as a diagram of sequences of steps, or workflow, of an algorithm. But we can also understand the flowchart as a “language”: when using a flowchart, we are translating the description of an algorithm from a verbal / textual language to a more symbolic one.

In other words, we can define a flowchart as a visualization of a streamlined workflow where we identify steps and relations by substituting meaningful symbols for verbal / textual descriptions.

How Symbols Work

What are the advantages of using a visualization based on symbols to understand an algorithm?

Physically, our brain has to make more of an effort to extract meaning from either text or numbers than it does from visual attributes and shapes. For example, after some learning and under the relevant context, it is easy to get the meaning of this street sign:

This sign may work better than writing a board explaining that drivers should be careful as there are kids crossing the road.

In our example, if you have to pause to read the explanatory board, by the time you learn what the message is it could be too late. But our brain makes a faster evaluation of the situation when presented with the sign after some training.

Also, visual attributes and shapes can not only refer to concrete, tangible objects, but also to concepts and actions. For example, if you have done arithmetics before, you’ll know the meaning of the following symbols:

When we use a symbol to convey meaning, whether concrete or intangible, we usually talk about semiosis. Semiosis is the process of producing and interpreting signs and symbols to convey meaning. It involves the interaction between a symbol, its meaning, and the person or machine interpreting it. This process is central to the communication, understanding, and creation of knowledge in both people and machines.

Symbolic communication takes advantage of our innate visual processing skills. This helps reduce the need for long-winded explanations because the observer has learned somehow what the sign means. Instead of “semiosis”, some people prefer the term abstraction to refer to the same process.

That it is what we do with flowcharts: abstracting meanings through symbols.

The value of semiotics in a visualization is substantial. Using meaningful symbols in a visualization such as a flowchart allows you and your audience to focus on patterns that written text, such as code or a script, can’t easily tell or describe.

And that is where the power of visualizations like flowcharts resides.

But flowchart symbols are not operators like you’d find in mathematics. Rather, they’re representations. In fact, they might represent something specific to the person who draws them.

Because of this, the symbols alone are often insufficient to fully convey abstract concepts. For example, the term "database” can represent many types of systems or technologies, and can have many different setups and uses. Also, as technology evolves, some symbols may lose their relevance.

To address this, clear textual explanations should accompany the shapes, ensuring the flowchart remains meaningful and avoids vagueness. You can also add styling and even images to strengthen the symbols’ meaning.

Common Symbols and Labels Used in Flowcharts

When creating a flowchart, you can use custom symbols, but it’s typically a good idea to stick to certain conventions. Conventions ensure better communication as well as consistency of messaging across different flowcharts.

The ANSI/ISO standards list more than 30 recognized flowchart shapes, though their usage isn’t strictly regulated. This allows vendors and developers to agree on best practices.

Since these symbols require textual and styling support anyway, some devs argue that you can reduce the number of shapes to a “necessary few” versatile symbols instead. I refer to these as "wildcards”. Wildcards can represent broader abstractions when paired with clear text and or styling. But don’t hesitate to use other standard symbols if you think that they bring more clarity to your flowchart.

For our example, we will focus on the most common shapes. Some of the most common and most versatile shapes are:

As you can see in the table above, we have the following shapes:

• Oval (a start or end point)

• Arrow (a connector that shows relationships between shapes)

• Parallelogram (an input or output)

• Rectangle (a process)

• Diamond (a decision)

Let’s go through each of these now and examine how they work and how to use them.

The Terminator (Oval) Shape

This is the oval shape, called the start/end shape. It marks the starting and ending points of the process/system. The oval indicates the beginning or end result of the workflow, and the potential outcomes of a path.

Many devs use the oval shape, along with the words “start” and “end/stop/finish” for clarity.

Some people prefer to use a single circle to represent the start and a double circle to represent the end of a flowchart:

I personally prefer the circle – but it’s up to you. Just make sure you pick one and stick with it for consistency.

The Arrow or Flowline Shape

Also called the link or the edge by vendors and practitioners, this shape represents the connection between two steps. Also depending on its shape, it might indicate if that flow is broken, failed, or if it is an alternate path or process, and more.

The most common representation is the arrow, which indicates the direction of the workflow between two steps. The arrow points in the direction of the next step in the process.

When working with flowcharts, I accompany arrow flowlines and any other flowline with concise descriptions about the next step, sometimes with information about variables and, when it makes sense, the current state.

The Process (Rectangle) Shape

You can represent a process using a rectangle in a flowchart. It’s also referred to as a box:

A box can represent a single step, like an expression (for example, x = y*x²), a entire block statement, like “loop through array and update values by multiplying by 2”, or an entire sub-process, like an existing function or even a module.

The process shape is a proper wildcard and it can morph into many things, so it’s important to add a label to it and using text or other resources like formatting to clarify its meaning.

The Decision (Diamond) Shape

The decision is represented by a diamond. It is an abstraction for a condition’s test, a YES/NO, or TRUE/FALSE question. It is the equivalent of an IF/ELSE statement in coding.

The text accompanying this shape is a question formulating a comparison between an entering value and a control value. The flowchart usually splits into different branches depending on the answer or consequences after you use the decision shape:

The result of the decision box determines the next step in the process workflow. It’s usually declared to only answer a simple question, but you can abstract the question so it looks similar to an IF/ELSE IF/ … /ELSE control statement in coding, with lines representing different decisions.

When one of the flows returns to the decision shape from where it left, we are talking about a loop:

The interpretation is like asking to test the condition again after going through some steps along a specific workflow branch, then checking if the answer has changed.

The Input/Output (Parallelogram) Shape

You can use the parallelogram shape as an abstraction for data that’s available for input or output or for resources used or generated. It indicates that some information is required at this point in the workflow.

The input/output shape is typically accompanied by the following text:

• Either “input” or “output”, so you know which is being represented. You can also write other similar words like “get” / “put”, “in” / “out”, and so on.

• An input or an output could be related to a variable that you are planning or you already have in your code. If that variable should have an expected type when either entering as input or output, I would also add the type.

• Its corresponding state, as long as it provides more clarity to the flowchart.

• Optionally, it would be also useful to mention the source of the input / output. Is it a dataset? A manual entry? A form? Will it be printed in the console?

Notice that the whole point of the use of this shape is to trace the entry or the exit of data into or out of the process. Therefore, this shape is valuable when you want to have at least an idea of data exchange.

Finally, a less common symbol, but one that I use often is…

The Preparation (Hexagon) Symbol

The preparation symbol is represented by an hexagon and it abstracts the setup for the following step. I usually use this shape to declare all the initial conditions when the workflow begins. I accompany this shape with a list of variables, their types, and even functions or initial event settings, like event listeners, together with their initial values.

How to Add Shapes to Your Flowchart: Generalization vs Refinement

Now that you understand the basics of the symbols, you may be wondering how to insert them into the diagram.

Especially for large diagrams, you’ll want to be very intentional about adding shapes. You’ll need to make careful decisions about placing and the number of shapes you’ll use, otherwise your flowchart could become unreadable.

You’ll need to make decisions about things like:

• where to place the shapes so it results in a tidy flowchart.

• which of those shapes are essential to the understanding of the workflow, and which are not.

Placing is perhaps the most difficult task of making a flowchart. If you are manually constructing your flowchart, unfortunately there’s not a simple formula that instructs you where to place the shapes in order to prevent overlapping. It’s up to you to visually resolve the placement and to decide when any overlap makes your diagram unreadable.

As you’ll see later, there are computationally-based solutions for the placing of shapes. But there is a simple rule that applies to all cases: the smaller the flowchart, the easier it is to place the shapes. So reducing the number of shapes and only including the key shapes is key to creating a clear flowchart.

Keep in mind that I’m not suggesting that you try to create the most minimalistic flowchart you can. Just that you try to make the simplest one that conveys enough information to help you understand the workflow.

How to Choose Which Shapes to Use

Deciding which shapes to use can turn into an iterative process of adding, moving, or removing text or symbols into or out of the flowchart.

There are two competing tendencies here: generalization and refinement.

For example, the next figure shows three different flowcharts that demonstrate how to use a coffee machine:

In the image above, you can see that the example on the left is the one with less explanations and fewer shapes, while the one on the right has more details.

In the same way, depending on your needs and the specific details you want to get out of the visualization, the flowchart can be more generalized or it can be more refined. In fact, it might acquire some elements of subjectivity, which usually rely on the amount of information and knowledge you have about the process before looking at the flowchart.

Generalization:

In the case of flowcharts, generalization, also known as lifting, is when you enclose several steps into a few words and / or symbols. There are two reasons to use a more generalized approach:

1. You and your audience are competent enough to complete the information not provided by the flowchart.

2. You and your audience don’t know much about that specific step.

In the second case, there are two situations you might be dealing with:

1. Even if you don’t know much about that part of the process, you can keep that step generalized because that step plays a small role in providing information that’s essential to you. Or,

2. The point is critical for you to understand the process, but you and your audience simply don’t know more.

It’s in the second situation when you have to try to “open the box”. And this is done through refinement.

Refinement:

Refinement consists of adding more steps and more words and symbols in order to add more detail to a procedure. It usually follows researching and studying.

When you’re refining your flowchart, this doesn’t necessarily mean that you know absolutely nothing about the procedure. What you’re looking for is something that allows you to point to specific details, and what comes before and what comes next.

But how much generalization is helpful? And how much refinement?

When your flowchart is too general, it results in a simpler visualization but it doesn’t contain much information. You might have to use more words or rely on inner knowledge in order to explain what the chart or a step means. The first flowchart in the previous image is the most generalized of all of them.

The risk of over-generalization is non-information.

The process of refinement involves the opposite risk, and is, in my view, more dangerous. If you don’t control the refinement process, you might end up with an absolute mess, like this:

The above diagram isn’t a flowchart, but the risk is the same. The risk of excessive refinement is noise.

There are several rules and mechanisms that help you prevent reaching an unnecessary level of either refinement or abstraction. This is what we are going to learn in the next sections. But first, let’s take a quick look at the available tools you can use to make diagrams and flowcharts.

Popular Diagramming Tools for Creating Flowcharts

Now that you know the shapes, what they are for, and have some idea about how to use them, you can start building a flowchart.

But before doing so, I’m going to make a short detour to talk about the tools you can use to build flowcharts.

Nowadays, the options are many. You can use online as well as offline resources. Some are specialized for building diagrams, while others are more general. Some you can access for free, and others are more for enterprise operations and come with high fees.

Below, you’ll find a quick table categorizing some of the dedicated tools I have used in the past or that I have been investigating recently.

No-code or low code tools:

The large majority of the existing specialized diagramming tools are designed to help people without coding skills.

When using these types of tools, you have to manually construct the diagram by dragging-and-dropping shapes into an (online) editor: you select the shape and move it around until you find your preferred place for it on the screen. There are functionalities to draw the flowlines (“connectors”) also by a dragging action, and you can always edit the shapes to add text or styling.

Script-based tools:

But there are also some less well-known tools that have been around for a while that are rising in popularity now: the script-based options. With these kinds of tools, you describe the shapes and relationships by scripting them according to the syntax of the tool.

These kinds of tools have the relative advantage that the diagram will be drawn for you on a rendering screen or image. An algorithm will try to find the best place for your shapes on the screen without you having to place them manually.

AI tools:

Then there are the AI tools. Many of those tools are based on the scripting tools. Some of them work as follows:

1. the AI interprets either a descriptive prompt or the code itself

2. Then it translates the prompt into a script using a scriptable diagramming tool

3. The diagram renders according to the AI-generated code.

I’ve found that these AI tools are still not quite up to the task for more complex projects – but they can come handy if you just want a quick solution. One that I have used is codetoflow.io, but there are also (guess what…) ChatGPT plugins you can use.

Parsers

Even before the AI tools came around, there were the parsers. They map steps and relationships into shapes based on well-established syntax rules. Some of those parsers are turning to AI instead, as the AI generators are easier to program and require less maintenance. But sometimes the rule-based parsers can be more precise if the rules they are based on remain without changes.

Some of those tools read on binary code, which is a better proxy to follow the full workflow, something that popular AI tools are not capable of. Some IDEs, like Eclipse, allow you to add plugins to draw a flowchart of your code based on binaries. One example is drgarbagetools which works only for Java in Eclipse.

General-purpose tools:

Apart from those dedicated tools, you can always use others that are not specifically built for diagramming. I have used PowerPoint and Google Slides in the past, and there are other presentation applications that support the ANSI / ISO shapes’ catalogue. You can also use tools like Figma, Miro, or others. There are too many others to list here.

And finally, there is always pen a paper.

Our Example: Using Mermaid.js

For the example in this tutorial, I’ll be using one of the scripting tools called Mermaid. One reason for using a script-based tool is the ease with which you can update the flowchart along the way. And this will come in handy when we reach the generalization / refinement step.

Although other tools do not hinder the generalization/refinement process, the fact that you might find yourself redoing the whole flowchart manually could become quite time consuming. With a script-based tool, you can focus mostly on writing down the right relationships and shapes, while you let the program place the shapes for you.

Although I’m using Mermaid here, I’m not prescribing the use of any particular tool for the examples ahead. You can use the one that suits your needs and with which you feel the most comfortable. None of them are perfect, and they all have their own merits.

But if you want to learn more about Mermaid, I’ve written another tutorial for you that’ll give you a general overview of the tool and how to use it. I will also provide the syntax I am using to create the examples so you can try it yourself.

How to Build a Flowchart – Methodology and Example

When building a flowchart, you can follow these steps:

1. Define the scope of your flowchart

2. Find the start of the workflow

3. Trace the workflow to the end while using high levels of generalization for the steps

4. Select what should be refined and what can be left generalized

5. Iterate: Research. Refine. Test. Research. Refine or Generalize. Test. Research. Refine or Generalize…

6. Enhance

7. Extend (optional)

Step 1: Define the Scope of Your Flowchart

It’s important to be clear about what you want to do with your flowchart. Is it representing a full codebase or just a fragment of a script? Is it an algorithm that you want to study or is it an analysis of some existing code? Do you want a detailed explanation of a workflow or just look at the relationships?

Having a clear goal for your flowchart will help you guide its construction.

For this example, we are going to use an exercise from freeCodeCamp’s curriculum:

const character = "#";
const count = 8;
const rows = [];

for (let i = 0; i < count; i = i + 1) {
  rows.push(character.repeat(i + 1))
}

let result = ""

for (const row of rows) {
  result = result + row + "\n";
}

console.log(result);

Our purpose here is to understand this code, particularly to gain more insights about the for-loops.

Step 2: Find the Start of the Workflow

Once you have an idea of what you want to do with your flowchart, try to figure out the point from where the workflow begins. If it involves analyzing existing code, bear in mind that the start of the workflow might not be at the start of your target code. Just keep in mind that whatever triggers the whole procedure, that is an indication that the “start” is there.

The workflow usually starts with the setting of the initial declarations and values, so we could say that our flowchart could start like this for this example:

flowchart TD
start((start)) --> |variable declaration| varDeclaration{{"*character*(str) 
                                          *count*(num) 
                                          *rows*(list) 
                                          *result*(str)"}}
varDeclaration -.-> C["..."]

Step 3: Trace the Workflow to the End and Use High Levels of Generalization in Each Step

Once you’ve found the starting point, try to systematically trace the workflow steps from start to end. If there are procedures along the way, you can compact them into more generalized steps using no more than two shapes.

The most common shape for depicting a generalized step is the process shape. Candidates to keep generalized are functions, control statement blocks like loops or if-statements, modules, or even libraries. Labels of those steps should consist of general descriptions of the things that are happening or should happen at that step.

For our example, we can represent our workflow and in particular the for-loops at a general level like this:

flowchart TD
start((start)) --> |variable declaration| varDeclaration{{"*character*(str) 
                                          *count*(num) 
                                          *rows*(list) 
                                          *result*(str)"}}
varDeclaration -->|"Use *character* and *count* to fill the *rows* list through a for-loop with strings"| forloop01["for-loop01 with *count* as control: str.repeat(*character*) --> *rows*.push(str)"]
forloop01 --> |"Use the updated *rows* list to create a new *result* string"| forloop02["for-loop02 along *rows* items: 
*row* --> 
*result* = *result* + *row* + '\n'"]
forloop02 --print output to the console--> consolelog["console.log(*result*)"]
consolelog --> stop(((stop)))

Step 4: Determine What Requires Refinement and What to Leave Generalized

Stop for a while and review the schema you’ve created. Once you have a picture of the whole workflow, you’ll want to decide which sections might require more details.

In our case, we’ll refine the parts of the flowchart that deal with the two for-loops. Describing a for-loop is a typical example when learning to create flowcharts, but I also realized that the two for-loops in our exercise are not of the same type. So I thought it would be interesting to see if the flowchart can reveal how they compare.

Step 5: Time to Iterate (Research, Refine or Generalize. Test. Repeat.)

What you’ve prepared up to Step 4 is a general sketch of the workflow. Now it’s time to dig into the areas where more detail is required. During this process, sometimes you’ll find yourself coming back to an abstraction while looking for the clearest way forward with your flowchart.

There are two things that will help you in this process:

1. New Shapes: this is the time when you may want to use some other shapes. Start with the most common ones. Use other shapes as long as you can give them a clear role in your flowchart and they help you reduce a long explanation about what the replaced shape does.

2. Text: Extend the use of text to explain the workflow. It should be more specific to the algorithm itself.

This process ends when you are satisfied with the clarity and level of detail of your flowchart. But there are a best practices that allow you to control the process:

• Try to keep everything to a single page.

• Keep the number of shapes to around 20 per page.

• Avoid line-crossing more than 4 times. Use connectors when that happens. Having to explain 5 or more connections is likely not a good thing.

After any change, test your flowchart. Testing is the most subjective aspect of the methodology. There might not be a way to test the flowchart result against a tangible outcome.

If that makes you uncomfortable, try to think in the following way: the flowchart can be seen as a sort of ordered TODO list or brainstorm notes describing what the code or system should do in order to accomplish a desired task.

A flowchart is similar to this TODO list. But instead of writing all those steps as comments or even pseudo-code, you are using (conventional) symbols.

But barring the advances of AI or any use of flow-based programming, comments are not code, no matter how detailed they are.

So the decision of whether the flowchart is working or not is left to you and your audience. The most important question to resolve here is: is the information provided by the flowchart enough to understand what you need to understand about the process? Is it revealing something new? Is it helping you organize your ideas more clearly?

If you are still not satisfied, then repeat the process. But don’t feel like you have to stick to this process alone. You can always stop this effort and look for another way to explain your procedures if you find that a flowchart won’t work for you.

You could facilitate the refining and the clarity of the output by doing some additional research. Try to find how other people describe the procedure you are about to work on. Is there something about the language that you should keep in mind? Whenever possible, don’t start from scratch.

Also, try to be faithful as much as possible to the actual way in which the procedure should be coded, especially if you are refining. But don’t forget that it’s a representation. Feel free to work on a draft when not enough information is available.

Let’s go back to our example. I did some quick research to find out how others might interpret a for-loop in a flowchart. I found this reference useful to guide my own description:

This approach seems to be fairly standard and I will try to include some of those steps in my flowchart. I also found that according to JavaScript documentation, the kind of for-loop we are about to represent repeats until a specified condition evaluates to false, just like in the flowchart above.

Let’s start by working on the first for-loop only:

flowchart TD
    start((start)) --> |variable declaration| varDeclaration{{"`*character*(str)
    *count*(num)
    *rows*(list)
    *result*(str)`"}}
    varDeclaration --> |**Start First Loop**: entering initial values of *i* and *count*| inputToLoop01[/"`input: 
                                                                                                            *count* = 8
                                                                                                            *i* = 0
                                                                                                            `"/] 
    inputToLoop01 --> forLoop01{"`Is *i* < *count*?`"}
    forLoop01 -.NO: something happens..-> stop(((stop)))
    forLoop01 --> |YES| inputI[/"`input: *i*`"/]
    inputI --> |"`create strings of length (*i* + 1) from *character*`"| repeatStr["**new string** = character.repeat(i+1)"]
    repeatStr --> |"`add newly created string 
            at the end of *rows* list`"| pushToRows["`rows.push(**new string**)`"]
    pushToRows --> |"`bottom of the block: update *i*`"| updateI[/i = i+1/]
    updateI --> |evaluate condition| forLoop01

Perfect.

Let’s now focus on the second for-loop. It turns out that it’s syntactically different from the previous one. And in fact, there are different kinds of loops in programming. The one we refined earlier is usually known as the “traditional” one, or better a numeric range type for-loop. The second one is an iterator type for-loop.

An iterator is a functionality that moves incrementally along a group of values or items. That functionality can have subprocesses to initialize the iterator – one to get the current value the iterator is pointing to, as well as a subprocess to go to the next one.

Also, remember that a for-loop stops repeating a workflow branch as soon as the condition evaluates to false.

Let’s try to reflect all this knowledge when refining the second for-loop. I will generalize the first for-loop for the sake of clarity:

flowchart TD
    start((start)) --> |variable declaration| varDeclaration{{"`*character*(str)
    *count*(num)
    *rows*(list)
    *result*(str)`"}}
    varDeclaration --> |**Start Range-Based Loop**: entering initial values of *i* and *count*| forLoop01["Range-Based For-Loop"]
    forLoop01 -- enter Iterator-Based For-Loop --> inputToLoop02[/"`INPUT:
                                                                *rows* (list of str of size *count*)
                                                                *result* (empty str)`"/]
    something --> stop(((stop)))
    inputToLoop02 --> forLoop02{"`Are there still *rows*' items?`"}
    forLoop02 --> |YES: get the current one| row[/"GET: *row* = currentItem(*rows*)"/]
    row --> |"concatenate the current *row* item plus a line (\n) to the current value of *result*"| newStr["**new string** = *result* + *row* + '\n'"]
    newStr --> |change the value of *result* for **new string**|newRes[*result* = **new string**]
    newRes --> |"`bottom of the block: move to next item`"| updateR[/"nextItem(*rows*)"/]
    updateR --> forLoop02
    forLoop02 --> |NO: we exhausted all the items| something

Now we have a clear flowchart for each of the for-loops! We had to first understand what the loops were about, and then had to find a way to represent them. We used refinement and generalization to expand / contract the information rendered by the flowchart.

At the end, we just have to accept that these are still approximations — in order to get how those for-loops really work, we would have to go learn more about JavaScript, probably looking through the JavaScript source code, or even closer to the machine by analysing binaries. But I’m personally satisfied with the information I got from the analysis.

Now after making these changes, we can come back and merge both flowcharts (for each of the for-loops) to complete the full representation of the code:

flowchart TD
    start((start)) --> |variable declaration| varDeclaration{{"`*character*(str)
    *count*(num)
    *rows*(list)
    *result*(str)`"}}
    varDeclaration --> |**Start Range-Based For-Loop**: entering initial values of *i* and *count*| inputToLoop01[/"`INPUT: 
                                                                                                            *count* = 8
                                                                                                            *i* = 0
                                                                                                            `"/] 
    inputToLoop01 --> forLoop01{"`Is *i* < *count*?`"}
    forLoop01 --> |YES| inputI[/"`GET: *i*`"/]
    inputI --> |"`create strings of length (*i* + 1) from *character*`"| repeatStr["**new string** = character.repeat(i+1)"]
    repeatStr --> |"`add newly created string 
            at the end of *rows* list`"| pushToRows["`rows.push(**new string**)`"]
    pushToRows --> |"`bottom of the block: update *i*`"| updateI[/i = i+1/]
    updateI --> |evaluate condition| forLoop01
    forLoop01 -->|NO| outputRows[/"`OUTPUT: *rows* list of string items of size *count*`"/]
    outputRows --> |**Start Iterator-Based For-Loop**: entering initial values of *rows* and *result*| inputToLoop02[/"`INPUT:
                                                                *rows* (list of str of size *count*)
                                                                *result* (empty str)`"/]
    inputToLoop02 --> forLoop02{"`Are there still *rows*' items?`"}
    forLoop02 --> |YES: get the current one| row[/"GET: *row* = currentItem(*rows*)"/]
    row --> |"concatenate the current *row* item plus a line (\n) to the current value of *result*"| newStr["**new string** = *result* + *row* + '\n'"]
    newStr --> |change the value of *result* for **new string**|newRes[*result* = **new string**]
    newRes --> |"`bottom of the block: move to next item`"| updateR[/"nextItem(*rows*)"/]
    updateR --> forLoop02
    forLoop02 --> |NO: we exhausted all the items| outputResult[/"`OUTPUT: *result* (str)`"/]
    outputResult --> |"`display *result* on the console`"|displayResult["`console.log(*result*)
            fa:fa-display`"]
    displayResult --> stop(((stop)))

Step 6: Enhance the Flowchart

Sometimes, specially with large flowcharts, the repeated use of similar shapes requires additional enhancement to provide more clarity. Normally you won’t quite know what you need to enhance until you have the full picture of something more final.

One way to do this is by grouping sections of the workflow. For that, you can use styling, like coloring the shapes, to highlight similar or related steps. It can also be helpful to highlight elements in the workflow that are really playing a fundamental role in the analysis.

You can also create groups of sub-procedures by boxing them (that is, placing a box around related elements of the flowchart).

Let’s apply some enhancements to our final flowchart by boxing and coloring:

flowchart TD
    start((start)) --> |variable declaration| varDeclaration{{"`*character*(str)
    *count*(num)
    *rows*(list)
    *result*(str)`"}}
    varDeclaration --> |**Start Range-Based For-Loop**: entering initial values of *i* and *count*| inputToLoop01[/"`INPUT: 
                                                                                                            *count* = 8
                                                                                                            *i* = 0
                                                                                                     `"/]:::input 
    subgraph RANGE_BASED_LOOP
    inputToLoop01 --> forLoop01{"`Is *i* < *count*?`"}
    forLoop01 --> |YES| inputI[/"`GET: *i*`"/]:::get
    inputI --> |"`create strings of length (*i* + 1) from *character*`"| repeatStr["**new string** = character.repeat(i+1)"]
    repeatStr --> |"`add newly created string 
            at the end of *rows* list`"| pushToRows["`rows.push(**new string**)`"]
    pushToRows --> |"`bottom of the block: update *i*`"| updateI[/i = i+1/]:::input
    updateI --> |evaluate condition| forLoop01
    end
    forLoop01 -->|NO| outputRows[/"`OUTPUT: *rows* list of string items of size *count*`"/]:::output
    outputRows --> |**Start Iterator-Based For-Loop**: entering initial values of *rows* and *result*| inputToLoop02[/"`INPUT:
                                                                *rows* (list of str of size *count*)
                                                                *result* (empty str)`"/]:::input
    subgraph ITERATOR_BASED_LOOP
    inputToLoop02 --> forLoop02{"`Are there still *rows*' items?`"}
    forLoop02 --> |YES: get the current one| row[/"GET: *row* = currentItem(*rows*)"/]:::get
    row --> |"concatenate the current *row* item plus a line (\n) to the current value of *result*"| newStr["**new string** = *result* + *row* + '\n'"]
    newStr --> |change the value of *result* for **new string**|newRes[*result* = **new string**]
    newRes --> |"`bottom of the block: move to next item`"| updateR[/"nextItem(*rows*)"/]:::input
    updateR --> forLoop02
    end
    forLoop02 ---> |NO: we exhausted all the items| outputResult[/"`OUTPUT: *result* (str)`"/]:::output
    outputResult --> |"`display *result* on the console`"|displayResult[/"`console.log(*result*)
            fa:fa-display`"/]
    displayResult -->|finish| stop(((stop)))

    style start fill:black, color:#fff
    style displayResult fill: #DFFF73
    style stop fill:grey, color:#fff, stroke: white
    classDef input fill:#F8D192
    classDef get fill:#F8D062
    classDef output fill:#ECF892

Step 7: Extend the Flowchart

This step is optional. If you have done what you can to keep the flowchart as clear as possible – but you are finding that it still needs more refinement – you may be dealing with a complex process.

In this case, it’s time to think about a separate flowchart to continue or extend the one you are working on. There are ways to indicate the connection between pages. You can also show a section of a flowchart as a generalization and show a more refined flowchart on a separate pages using references.

I won’t go into the details of how to do that here, as this article is long enough as it is. And in this case, I think we can keep our flowchart to just one page, so I won’t go further with creating new pages for it.

So we are done!

Conclusion

When making a flowchart, we are not looking to imitate our code. Rather, we’re looking to understand it. This means that the flowchart has to be clear.

And if you use your flowcharts correctly, along with the right tools, they can help you reveal patterns and hidden operations, as well as stay organized, reduce overwhelm, and ultimately make coding feel more manageable. This will ultimately improve your coding skills and your state of mind.

So give flowcharts a try — you might be surprised at how much they can help you out.

A few years ago, I was introduced to React and immediately fell in love with its component-based, state-driven approach to building web applications.

But as I delved deeper into its ecosystem, I encountered not just React, but a range of supporting libraries like Material UI, React Router, Reactstrap, Redux, and more. While exciting, these new concepts and libraries could also feel overwhelming.

I soon realized that mastering React requires a solid understanding of modern JavaScript, especially the ES6+ features. This realization encouraged me to revisit some fundamental JavaScript topics, which helped me become more comfortable with React and write cleaner, more efficient code.

In this guide, I will share my notes as a concise and practical reference. These key JavaScript concepts will give you a strong foundation before you dive deep into React. Whether you’re a beginner or revisiting the language, this guide should give you a boost as you tackle the React ecosystem.

Let’s Get Back to Work

Since React is based on JavaScript, it’s essential to have a good grasp of the language before you start learning React.

I recommend a comprehensive resource like The Modern JavaScript Tutorial for an in-depth review. But if you feel confident about most of JavaScript and just need a brush-up, here’s my recommended list of crucial topics:

1. Template Literals

2. Arrow Functions

3. Default Parameters (or Values)

4. Destructuring Objects and Arrays

5. Rest and Spread Operators

6. Map, Filter, and Reduce Methods

7. Mutability Issues with Methods like Array Sort

8. Ternary Operator

9. Short-Circuiting and Logical Operators

10. Optional Chaining

11. Asynchronous JS (Callbacks, Promises, Async/Await)

12. Closures

13. Modules (import/export)

14. Event Handling and Bubbling

15. Classes and Prototypes

1. Template Literals

Template literals simplify string interpolation and multiline text formatting. By using backticks (`___` ), you can embed expressions into strings with ${}. This makes concatenating variables and expressions with text easy, eliminating the need for cumbersome string concatenation.

let numEggs = 4;

console.log(`In breakfast, I eat ${numEggs} eggs.`);
//Output: In breakfast, I eat 4 eggs.

console.log(`Today, I ate only half of it, I ate just ${numEggs/2} eggs.`);
//Output: Today I ate only half of it, I ate just 2 eggs.

Additionally, template literals support multiline strings (without needing the newline character, that is \n, and also you can add spaces). This lets developers create more readable and organized code.

console.log(`Today I had:
- Breakfast
- Lunch
- Dinner`);
/* Output (now shows multiline text as shown below): 
Today I had:
- Breakfast
- Lunch
- Dinner
*/

With their flexibility and clarity, template literals have become a preferred method for handling strings and dynamic content in modern JavaScript.

2. Arrow Functions

Arrow functions provide a more concise syntax for writing functions and automatically bind this to the context in which they're declared. They are a staple of React development, as they simplify event handlers, lifecycle methods, and other functional logic. Let’s explore different variations of arrow functions.

Arrow Function with a Single Argument: When an arrow function has a single argument, you can omit the parentheses. Here’s an example:

const greet = name => `Hello, ${name}!`;
console.log(greet('John')); // Hello, John!

Arrow Function without Arguments: If there are no arguments, you still need to use parentheses.

const sayHello = () => 'Hello, world!';
console.log(sayHello()); // Hello, world!

Arrow Function with Multiple Arguments: For multiple arguments, parentheses are mandatory.

const add = (a, b) => a + b;
console.log(add(2, 3)); // 5

Single-Line Function Body (Implicit Return): When the function body is a single expression, you can omit the return keyword and curly braces. This is known as an implicit return.

const multiply = (x, y) => x * y;
console.log(multiply(4, 5)); // 20

Multi-Line Function Body: For more complex logic or multiple statements, you need curly braces, and an explicit return is required if the function returns a value.

const getFullName = (firstName, lastName) => {
  const fullName = `${firstName} ${lastName}`;
  return fullName;
};
console.log(getFullName('John', 'Doe')); // John Doe

Returning an Object: To return an object directly, wrap the object in parentheses to avoid confusion with the function body.

const createUser = (name, age) => ({ name, age });
console.log(createUser('Alice', 30)); // { name: 'Alice', age: 30 }

Arrow Functions in Callbacks: Arrow functions are often used as callbacks for array methods like map, filter, and reduce.

const numbers = [1, 2, 3, 4];
const squares = numbers.map(num => num * num);
console.log(squares); // [1, 4, 9, 16]

To learn more about how arrow functions compare with other ways to define functions, you may read this blog on ways to write JS functions.

3. Default Parameters (or Values)

Default parameters allow functions to have pre-set values if no arguments are passed, or when an argument is undefined. This feature is helpful when writing flexible components in React, where you may not always pass every prop or argument.

function greet(name = 'Stranger') {
  console.log(`Hello, ${name}!`);
}
greet(); // Hello, Stranger!
greet('Alice'); // Hello, Alice!

It is relevant to mention here that there’s another commonly used approach in JavaScript, which is leveraging logical operators like || to set a default value when the given value is falsy (that is, values like 0, null, undefined, false, or "").

function greet(name) {
  const finalName = name || 'Stranger';
  console.log(`Hello, ${finalName}!`);
}

greet(); // Hello, Stranger!
greet(''); // Hello, Stranger!
greet('John'); // Hello, John!

The above process uses a concept called short-circuiting of logical operators, which is discussed in Section 9 below.

4. Destructuring Objects and Arrays

Destructuring allows you to extract values from arrays and properties from objects into variables. This concise syntax makes your code cleaner and more readable.

To extract specific values from an array or object, use destructuring by enclosing the desired variables within curly braces for objects or square brackets for arrays.

// Example of Array Destructuring
const [first, second] = [10, 20];
console.log(first); // 10

// Example of Object Destructuring
const user = { name: 'Alice', age: 25 };
const { name, age } = user;
console.log(name); // Alice

Destructuring is commonly used in React for handling props and state. To see more specific use cases of destructuring with code examples, read this quick reference on destructuring.

5. Rest and Spread Operators

The rest and spread operators are incredibly versatile and widely used in JavaScript. Both are represented by three dots (...), but their meanings differ depending on the context in which they are used.

Spread Operator: Expands elements of an array or object.

The spread operator is primarily used to unpack arrays or objects into individual elements. This is especially useful for creating shallow copies or merging arrays (and objects) without mutating the original.

const arr1 = [1, 2, 3];
const arr2 = [...arr1, 4, 5];
console.log(arr2); // [1, 2, 3, 4, 5]

/* arr2 is created by spreading the elements of arr1 
 and then adding additional values */

The spread operator can also be used to copy objects or combine objects:

const obj1 = { name: 'Alice', age: 25 };
const obj2 = { ...obj1, job: 'Engineer' };
console.log(obj2); // { name: 'Alice', age: 25, job: 'Engineer' }

/* obj2 is created by spreading the properties of obj1
 and adding a new property */

This is a common pattern when updating the state in React applications.

Rest Operator: Collects multiple elements into an array.

The rest operator does the reverse: it collects multiple arguments or elements into a single array. It’s especially useful when working with variadic functions (functions that accept a variable number of arguments).

function sum(...args) {
  return args.reduce((total, num) => total + num, 0);
}
console.log(sum(1, 2, 3)); // 6

In this example, ...args gathers all arguments passed to the function into an array. This allows the function to handle any number of arguments dynamically.

You can also use the rest operator to collect remaining properties of an object or elements of an array:

const [first, ...rest] = [10, 20, 30, 40];
console.log(first); // 10
console.log(rest);  // [20, 30, 40]

This technique is particularly useful in React when working with props, where you might want to extract specific properties and pass the rest down to child components.

6. Map, Filter, and Reduce Methods

The map(), filter(), and reduce() methods are incredibly powerful for array manipulation in JavaScript, and they play a crucial role in React for tasks like rendering lists, filtering data, and summarizing information.

• Map: Transforms elements of an array

• Filter: Creates a new array with elements that pass a condition

• Reduce: Accumulates values into a single result

1. Map Method

The map() method creates a new array by transforming each element of the original array according to the function provided. This method is essential in React for dynamically rendering lists of components from arrays of data.

// Example (Basic Usage):
const numbers = [1, 2, 3, 4];
const doubled = numbers.map(num => num * 2);
console.log(doubled); // [2, 4, 6, 8]

In React, map() is commonly used to render lists of components. Here's how you might use it in a React component:

// Example (Rendering a List in React):
const users = [
  { id: 1, name: 'Alice' },
  { id: 2, name: 'Bob' },
  { id: 3, name: 'Charlie' }
];

function UserList() {
  return (
    <ul>
      {users.map(user => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
}

/* Note that each <li> element in the list has a unique 'key' prop.
It is required by React when rendering lists like this */

2. Filter Method

The filter() method creates a new array with all elements that pass the condition specified in the callback function. It's frequently used in React when you want to display only certain items based on user input or a specific condition.

// Example (Basic Usage):
const numbers = [1, 2, 3, 4, 5];
const evenNumbers = numbers.filter(num => num % 2 === 0);
console.log(evenNumbers); // [2, 4]

For a use case, imagine you have a list where some tasks are completed while some are not. So, you can use filter() to display (render) only the tasks that are not yet completed.

// Example (Filtering Data in React):
const todos = [
  { id: 1, task: 'Learn JavaScript', completed: true },
  { id: 2, task: 'Learn React', completed: false },
  { id: 3, task: 'Build a project', completed: false }
];

function TodoList() {
  const incompleteTodos = todos.filter(todo => !todo.completed);
  return (
    <ul>
      {incompleteTodos.map(todo => (
        <li key={todo.id}>{todo.task}</li>
      ))}
    </ul>
  );
}

3. Reduce Method

The reduce() method executes a reducer function on each element of the array, resulting in a single output value. It's used when you need to accumulate data, such as summing values or combining objects.

// Example (Basic Usage):
const numbers = [1, 2, 3, 4];
const sum = numbers.reduce((total, num) => total + num, 0);
console.log(sum); // 10

You might use reduce() in React to calculate a summary of some data, like the total price of items in a shopping cart — considering the items’ individual price and quantities:

// Example (Using reduce() in React):
const cart = [
  { id: 1, name: 'Apple', price: 1.5, quantity: 3 },
  { id: 2, name: 'Banana', price: 1, quantity: 2 },
  { id: 3, name: 'Orange', price: 2, quantity: 1 }
];

function CartSummary() {
  const total=cart.reduce((sum, item)=>sum + item.price * item.quantity, 0);
  return (
    <div>
      <h3>Total: ${total}</h3>
    </div>
  );
}

These array methods are invaluable in React for manipulating and displaying data dynamically. They allow for clean, readable, and declarative logic within your components.

You can also combine these methods to create powerful data transformations. For example, you can filter an array and then map the results: filter() is used to extract only the adult users, and map() is then used to create a list of their names.

// Example: combined use of filter and map methods
const users = [
  { id: 1, name: 'Alice', age: 25 },
  { id: 2, name: 'Bob', age: 17 },
  { id: 3, name: 'Charlie', age: 30 }
];

const adultNames = users
  .filter(user => user.age >= 18)
  .map(user => user.name);
console.log(adultNames); // ['Alice', 'Charlie']

The map() and filter() methods are easier to grasp because they follow a simple "one-to-one" or "one-to-zero-or-more" relationship: map() transforms each element into a new one, while filter() includes or excludes elements based on a condition, returning a similarly structured array.

In contrast, reduce() is more complex, as it accumulates values into a single result rather than maintaining a one-to-one relationship. It requires managing both the current value and an accumulator, making it conceptually different and harder to interpret than map() or filter().

The optional initial value in reduce() adds to the complexity, as it sets the starting point for the accumulation. Without it, the first array element is used as the accumulator, which can cause unexpected results with empty arrays or non-numeric data. To get consistent results for your use of the reduce() method, you may read about the importance of an initial value.

7. Mutability Issues with Methods like Array Sort

The Array.sort() method sorts the elements of an array in place, meaning it mutates the original array. For example:

const numbers = [4, 2, 3, 1];
numbers.sort();
console.log(numbers); // [1, 2, 3, 4]

While this works in plain JavaScript, it’s problematic in React, where immutability is crucial for correctly managing state.

React detects state changes by comparing previous and new states and triggers re-renders based on those changes. But when an array is mutated in place (like with sort()), React may fail to recognize the change, leading to stale UI updates or unpredictable behavior.

To avoid this, it’s best to create a copy using the spread operator (...) or slice() before sorting, ensuring that the original state remains unchanged:

const numbers = [4, 2, 3, 1];
const sortedNumbers = [...numbers].sort();
console.log(sortedNumbers); // [1, 2, 3, 4]

Methods like map(), filter(), reduce(), or copying arrays/objects before modifying them is essential for preserving immutability and ensuring reliable state management in React.

8. Ternary Operator

The ternary operator is a shorthand for conditional statements. It has the syntax condition ? expressionIfTrue : expressionIfFalse. If the condition evaluates to true, it executes the expressionIfTrue. If it’s false, it executes the expressionIfFalse.

let isUserRegistered = true;
let message = isUserRegistered ? 'Please login' : 'Please Sign-up';
console.log(message);
//Output: Please login

In React, it is an efficient replacement for the if-else statements in certain scenarios — like conditional rendering, which delivers elements and components based on certain conditions or values of state or props data.

9. Short-Circuiting and Logical Operators

Logical operators like && (AND) and || (OR) can be used to create clean and concise conditional logic in JavaScript. In React, these operators often determine whether a component or JSX element should render.

1. Logical AND (&&)

The && operator evaluates the expression on the left side first. If it's true, the right-hand expression is evaluated and returned. If the left side is false, the entire expression short-circuits, meaning the right-hand expression is ignored.

let isLoggedIn = true;
console.log(isLoggedIn && 'Welcome back!'); // Welcome back!

This behavior is often used in React for conditional rendering, like so:

function UserGreeting({ isLoggedIn }) {
  return (
    <div>
      {isLoggedIn && <p>Welcome back!</p>}
    </div>
  );
}

This is a common pattern in React for rendering UI based on certain conditions without needing an explicit if statement.

2. Logical OR (||)

The || operator works in the opposite way. It evaluates the left-hand expression first, and if it's true (or any truthy value), it returns that value. If the left-hand expression is false (or any falsy value), it evaluates and returns the right-hand expression.

let username = '';
console.log(username || 'Guest'); // Output: Guest

In React, this is useful for providing default values, like so:

function UserProfile({ username }) {
  return (
    <div>
      <p>Hello, {username || 'Guest'}!</p>
    </div>
  );
}

Note that the nullish coalescing operator (??) is similar to the logical OR operator (||), but with a key difference in how they treat falsy values.

The nullish coalescing operator (??) specifically checks if the left-hand side is either null or undefined. If the value is null or undefined, it returns the right-hand side. This allows 0, false, and '' to be treated as valid values and not overridden. You can read about this and more such nuances associated with JavaScript Operators.

3. Combining && and || for Complex Logic

You can also combine && and || to create more complex conditional logic or nested logic.

let isAdmin = false;
let isLoggedIn = true;
console.log(isAdmin && 'Admin Panel' || isLoggedIn && 'User Dashboard'); 
// Output: User Dashboard

This can be useful in React for deciding what to render based on multiple conditions having an interplay.

function Dashboard({ isAdmin, isLoggedIn }) {
  return (
    <div>
      {isAdmin && <p>Welcome to the Admin Panel</p>}
      {!isAdmin && isLoggedIn && <p>Welcome to the User Dashboard</p>}
    </div>
  );
}

10. Optional Chaining

Optional chaining (?.) is a powerful feature introduced in JavaScript (ES2020) that allows you to safely access deeply nested properties of an object without worrying about encountering undefined or null errors.

In traditional JavaScript, accessing nested properties of objects could result in errors if any part of the chain was undefined or null, causing your code to break. Optional chaining provides a cleaner and safer way to handle these scenarios.

The optional chaining operator short-circuits and returns undefined if the value before it is null or undefined. This prevents the code from throwing an error when trying to access the properties of a null or undefined value.

let user = { name: 'Alice', address: { city: 'Wonderland' } };
console.log(user?.address?.city); 
// Output: Wonderland

// Without optional chaining
let user1 = { name: 'Bill' };
console.log(user1.address.city); 
// Output: Error: Cannot read property 'city' of undefined

// With Optional Chaining:
let user2 = { name: 'Caleb' };
console.log(user2?.address?.city); // undefined

Optional chaining can also be used in different scenarios, such as   with function calls (to check if a function exists before invoking it), while accessing elements in arrays (especially when you’re unsure whether the array exists or whether it has enough elements), or while accessing dynamic properties, as shown below:

// Optional Chaining with Functions:
let user1 = {
  name: 'Alice',
  greet: () => 'Hello!'
};

console.log(user1.greet?.()); // Hello!
console.log(user1.sayGoodbye?.()); // undefined

// Optional Chaining with Arrays:
let users = [{ name: 'Alice' }, { name: 'Bob' }];
console.log(users[0]?.name); // Alice
console.log(users[2]?.name); // undefined

// Optional Chaining with Dynamic Properties:
let user2 = { name: 'Bill', preferences: { theme: 'dark' } };
let property = 'preferences';
console.log(user2?.[property]?.theme); // dark

property = 'settings';
console.log(user2?.[property]?.theme); // undefined

When working with deeply nested objects, optional chaining can save you from having to write repetitive null checks at every level.

let user = { profile: { address: { city: 'Wonderland' } } };

// usage without optional chaining (using short-circuiting):
if (user && user.profile && user.profile.address && user.profile.address.city) {
  console.log(user.profile.address.city);
}

// usage with optional chaining (saving repititive null checks):
console.log(user?.profile?.address?.city); // Wonderland

In React, optional chaining is particularly useful when dealing with props, API responses, or any data that may not always be available. It helps prevent errors when rendering components based on dynamic or incomplete data.

Optional chaining significantly reduces the complexity of your code, making it cleaner and more readable, especially when dealing with deeply nested structures.

// Example usage of Optional Chaining in React
function UserProfile({ user }) {
  return (
    <div>
      <p>Name: {user?.name}</p>
      <p>City: {user?.address?.city ?? 'Unknown'}</p>
    </div>
  );
}

11. Asynchronous JS: Callbacks, Promises, Async/Await

JavaScript is a single-threaded language,  meaning  it can execute one task at a time. But handling asynchronous operations is crucial, especially for tasks like fetching data in React. Callback functions are one of the earliest patterns used to handle asynchronous behavior, like so:

function fetchData(callback) {
  setTimeout(() => {
    console.log("Data fetched");
    callback({ user: "John", age: 30 });
  }, 2000);
}

fetchData((data) => {
  console.log("User:", data.user);
});

/* Output:
Data fetched
User: John
*/

So, as you can see, callbacks are effective for handling simple operations that depend on asynchronous tasks, like the example above.

But when multiple asynchronous tasks rely on each other, callbacks can lead to deeply nested code, commonly referred to as callback hell.

To solve this problem, promises were introduced. A promise is an object that represents the eventual completion (or failure) of an asynchronous operation and its resulting value. Instead of nesting multiple callbacks, promises allow chaining, leading to more structured and readable code.

Similarly, the Fetch API, which is commonly used for handling network requests in React applications, returns a promise which you can handle like so:

function fetchUserDetails(userId) {
  return fetch(`https://api.example.com/users/${userId}`)
    .then((response) => {
      if (!response.ok) {
        throw new Error('Failed to fetch user details');
      }
      return response.json();
    })
    .then((data) => {
      console.log("Fetched user details");
      return { id: userId, name: data.name };
    });
}

function fetchPostsByUser(user) {
  return fetch(`https://api.example.com/users/${user.id}/posts`)
    .then((response) => {
      if (!response.ok) {
        throw new Error('Failed to fetch posts');
      }
      return response.json();
    })
    .then((posts) => {
      console.log(`Fetched posts for ${user.name}`);
      return posts;
    });
}

// Chain promises
fetchUserDetails(1)
  .then((user) => fetchPostsByUser(user))
  .then((posts) => console.log(posts))
  .catch((error) => console.error("Error:", error));

Promises provide a more readable way to handle sequential asynchronous tasks. They also simplify error handling using .catch(). But, while promises eliminate the deep nesting of callbacks, chaining too many .then() calls can still become verbose and hard to follow.

Introduced in ES2017, async/await makes working with promises even simpler. With async/await, asynchronous code looks and behaves more like synchronous code, which greatly improves readability. Here’s how it works:

• async function: An async function returns a promise. The async keyword allows the function to return a resolved promise implicitly.

• await expression: Inside an async function, await pauses the execution of the function until the promise resolves. It simplifies promise handling, as we can directly assign the resolved value to a variable.

async function getUserAndPosts(userId) {
  try {
    const user = await fetchUserDetails(userId); // Waits for user details
    const posts = await fetchPostsByUser(user);  // Waits for posts
    console.log("Posts:", posts);
  } catch (error) {
    console.error("Error:", error);
  }
}

getUserAndPosts(1);

/* Output:
Fetched user details
Fetched posts for John
Posts: ["Post 1", "Post 2"]
*/

Async/await makes asynchronous code appear synchronous, which greatly improves readability and maintainability. The try/catch block also simplifies error handling, making it consistent with how errors are caught in synchronous code.

Error Handling in Async Code

Error handling in asynchronous code can be tricky. Callbacks require error-first handling, while promises and async/await offer more structured approaches, as shown below:

// Handling Errors with Promises
fetchUserDetails(1)
  .then((user) => fetchPostsByUser(user))
  .then((posts) => console.log(posts))
  .catch((error) => console.error("Error fetching data:", error));

// Handling Errors with Async/Await
async function getUserAndPosts() {
  try {
    const user = await fetchUserDetails(1);
    const posts = await fetchPostsByUser(user);
    console.log(posts);
  } catch (error) {
    console.error("Error fetching data:", error);
  }
}

Understanding the evolution of asynchronous JavaScript helps you write efficient, non-blocking code. For more details, you can read this article on the evolutionary progress of Asynchronous JavaScript.

12. Closures

A closure in JavaScript is created when a function “remembers” the variables from its outer scope, even after the outer function has finished executing. This means that a function retains access to the environment it was created in, making closures essential for managing data across different contexts.

function outerFunction(outerVar) {
  return function innerFunction(innerVar) {
    console.log(`Outer: ${outerVar}, Inner: ${innerVar}`);
  };
}

const newFunction = outerFunction('React');
newFunction('JavaScript'); // Outer: React, Inner: JavaScript

In React, closures are crucial for handling state and props within functional components. They allow functions like event handlers or asynchronous callbacks to access the latest state values even after re-renders.

For example, the useState and useEffect hooks rely on closures to "remember" and manage state across renders.

function Counter() {
  const [count, setCount] = useState(0);
  const increment = () => setCount(count + 1); // Closure keeps track of count
  return <button onClick={increment}>Count: {count}</button>;
}

Understanding closures ensures that you can effectively manage state and handle events in React, keeping your components consistent and predictable.

13. Modules (import/export)

React projects are highly modular, meaning that the code is split into multiple files or components, each handling a specific responsibility. This modularity is enabled by ES6 modules, which allow you to export values, functions, or components from one file and import them into another.

Understanding how to use import and export is essential for organizing React applications and making code reusable and maintainable.

In the following example, the greet function is exported from module.js, making it accessible to other files.

// module.js
export const greet = () => console.log('Hello');

In anotherFile.js, we import the greet function from module.js and can now use it as if it were defined locally, like so:

// anotherFile.js
import { greet } from './module';
greet(); // Hello

React components are often exported from their own files and then imported into a central component (like App.js), allowing you to break down your UI into smaller, reusable pieces.

// Button.js
export default function Button() {
  return <button>Click me</button>;
}

// App.js
import Button from './Button';

Understanding this import/export structure is fundamental in React for managing components, reusing logic, and keeping code clean and modular.

Here, you may note that CommonJS was a popular module system for Node.js (server-side JavaScript) before ES6. It allowed you to export values from a file using module.exports and import them using require().

While it worked well in Node.js, it wasn't natively supported by browsers. With the rise of React and other frontend libraries, the need for a native, browser-supported and standardized module system became essential and ES6 provided that.

14. Event Handling and Bubbling

React relies heavily on event handling to respond to user interactions. Events in React are managed through Synthetic Events, which provide cross-browser consistency and performance optimization. Understanding event bubbling, a process where events propagate from the target element up through its parents, is crucial for controlling component behavior.

// Example in vanilla JavaScript:
document.querySelector("button").addEventListener("click", function() {
  console.log("Button clicked");
});

In the above example, clicking the button triggers the event listener, and the event “bubbles” up through parent elements unless stopped. React handles this similarly with its onClick events:

// Example in React:
function handleClick() {
  console.log("Button clicked");
}

function App() {
  return <button onClick={handleClick}>Click me</button>;
}

In React, event bubbling can lead to multiple event handlers being triggered in nested elements. For example, a parent’s onClick can be triggered when its child button is clicked unless it is prevented by calling event.stopPropagation() inside the child button’s handler method — which then prevents the click event from reaching the parent div. This ensures that only the desired event is handled.

// Example of How to Stop Event Bubbling:
function handleButtonClick(event) {
  event.stopPropagation(); // Prevents bubbling
  console.log("Button clicked");
}

function handleDivClick() {
  console.log("Div clicked");
}

function App() {
  return (
    <div onClick={handleDivClick}>
      <button onClick={handleButtonClick}>Click me</button>
    </div>
  );
}

React’s architecture, with its component-based structure and Synthetic Event System, reduces the need for stopPropagation() in most cases—for example, in simpler apps where both a parent and child component are not handling the same event like a click.

But in more complex UI structures, where multiple elements handle the same event (for example, onClick), and you want to prevent the parent element from reacting to the child’s event, stopPropagation() becomes crucial for controlling event flow. This is especially important in scenarios like nested modals, dropdowns, or accordions, where a click inside the modal should not trigger a click handler on the outer container.

15. Classes and Prototypes

While functional components are now dominant in React, understanding JavaScript classes and prototypes is still valuable, especially when working with class-based components or maintaining legacy code. JavaScript classes provide a blueprint for creating objects, and they work by leveraging prototypes under the hood.

class Person {
  constructor(name) {
    this.name = name;
  }  

  greet() {
    console.log(`Hello, I'm ${this.name}`);
  }
}

const person = new Person('Alice');
person.greet(); // Hello, I'm Alice

In this example, the Person class defines a constructor to initialize the name property, and a greet() method that prints a message. When you create a new instance of Person, the method is available through JavaScript’s prototype chain.

Though React moved towards functional components with hooks, class-based components were the standard prior to React 16.8. Understanding classes is useful when dealing with codebases that use class components or when you need to understand features like lifecycle methods (componentDidMount, componentDidUpdate, and so on) and this binding, which are more prevalent in class components.

Final Thoughts

Mastering the key JavaScript concepts outlined in this tutorial will give you a solid foundation as you dive into React development.

React heavily relies on modern JavaScript features like map(), filter(), destructuring, and the spread operator, all of which streamline how data is manipulated and components are rendered. And concepts like immutability, optional chaining, and the nullish coalescing operator are critical for writing clean, bug-free code that interacts effectively with dynamic data.

By understanding how these JavaScript features work together, you'll be well-equipped to write more efficient, maintainable React applications.

So, as you begin your React journey, make sure your JavaScript fundamentals are rock-solid—you'll find that it pays off as you tackle more complex challenges in your React projects. Also, if you find I missed any important concept here, please let me know. I will add it back to the article for an updated version.