DEV Community: Damian Demasi

Claude Code Crash Course

Damian Demasi — Sun, 29 Mar 2026 06:21:51 +0000

The first time you look at Claude Code closely, it can feel like a box full of parts that all seem important, but not obviously related.

You see CLAUDE.md. Then rules. Then skills. Then hooks. Then subagents. Then MCP servers. Then… the list goes on. Then context management, planning before coding, verifying outputs, and avoiding letting the session turn into a mess. At first glance, it is easy to think: why are there so many pieces just to get an AI coding workflow working well?

But after spending some time with these concepts, I think the answer is actually pretty simple.

Claude Code is not one thing. It is a small operating system for AI-assisted development.

And like any good system, different parts exist for different jobs.

Start here. Claude Code needs memory, structure, and reach

A good mental model is this:

CLAUDE.md and rules shape behaviour.
Skills package reusable know-how.
Hooks enforce automatic actions.
Subagents isolate work.
MCP servers connect Claude to the outside world.

That is the big picture (mainly, because there is more to it, but this is enough to get us started).

Once you see it that way, the moving parts stop feeling random. They start feeling like layers. The interesting part is not learning each feature in isolation, but understanding what problem each one solves, and what happens when you try to use the wrong one for that problem. Anthropic’s docs make that distinction pretty clear. CLAUDE.md gives persistent instructions, rules can scope those instructions more precisely, skills extend Claude with reusable playbooks, hooks provide deterministic automation, subagents work in separate contexts with their own tools and prompts, and MCP is the bridge to external tools, data sources, and APIs.

`CLAUDE.md` and rules. The behavioural layer

If I had to pick the first thing to set up in Claude Code, it would be this.

CLAUDE.md is where you put persistent instructions that Claude should carry into every session for a project, for your personal workflow, or even across an organisation. The docs describe it as plain markdown that Claude reads at the start of every session. They also make an important point that is easy to miss: these instructions are context, not hard enforcement. So if the file is vague, bloated, or contradictory, performance drops. Anthropic recommends keeping it specific, concise, and well-structured, with a rough target of under 200 lines per file.

That last bit matters more than it seems.

A lot of people treat instruction files like a dumping ground. They keep adding preferences, workflows, architecture notes, testing conventions, edge cases, and random reminders until the thing becomes unreadable. Then they wonder why the agent follows it inconsistently. The problem is not that the model is “bad at instructions.” The problem is that the instruction layer is carrying too much weight.

That is where rules come in.

For larger projects, Anthropic recommends organising instructions inside .claude/rules/, and those rules can even be path-specific so they only load when Claude is working in matching areas of the codebase. That means you do not need every frontend rule, testing rule, security note, and data migration convention loaded all the time. You can scope them. In other words, CLAUDE.md should define the broad operating principles of the project, while rules help keep that guidance modular and targeted.

So, if you want one simple distinction:

Use CLAUDE.md for shared default behaviour. Use rules when the project is getting too big for one instruction file to stay sharp.

Skills. The reusable playbook layer

This is where Claude Code starts getting interesting.

A skill is not just “more instructions.” A skill is a packaged capability. Anthropic defines skills around a SKILL.md file. Claude can load a skill automatically when it is relevant, or you can invoke it directly with a slash command (/) based on the skill name (/my_skill). Skills can also include frontmatter, supporting files, argument handling, restricted tool access, and even subagent execution.

That changes the way you should think about them.

A rule says, “here is how we do things around here.”

A skill says, “when this kind of task appears, here is the exact playbook to follow.”

That is a huge difference.

For example, suppose your team has a repeatable workflow for debugging flaky tests, preparing release notes, reviewing API design, or migrating components from one pattern to another. You could try to cram that into CLAUDE.md, but then every session pays the context cost whether that workflow is relevant or not. Skills solve that by staying optional and task-focused. Anthropic explicitly positions them that way in the docs and even notes that for task-specific instructions that do not need to live in context all the time, skills are the better fit.

This is one of those places where the abstraction really clicks.

A good Claude Code setup is not just about telling the model how your codebase works, but about identifying which workflows deserve to become first-class tools.

That is what skills are.

Hooks. The enforcement layer

If CLAUDE.md and skills are about guidance, hooks are about guarantees.

Anthropic describes hooks as user-defined shell commands that run at specific points in Claude Code’s lifecycle. Their wording is important here: hooks provide deterministic control. In other words, they are for the things that must happen, every time, without relying on the model to remember or choose correctly. The best practices guide reinforces the same distinction: unlike CLAUDE.md, which is advisory, hooks are deterministic and guarantee the action happens.

That makes hooks the right tool for a very specific category of problems:

Run formatting after edits.
Block writes to protected files.
Send a notification when Claude needs input.
Reinject context after compaction.
Audit configuration changes.

Hooks are workflow mechanics. If you try to solve these mechanics with prompts alone, you are basically hoping the model behaves. Hooks exist so you do not need hope.

This is also where a lot of AI workflows quietly become trustworthy. Not because the model got smarter, but because some parts of the workflow stopped depending on the model entirely.

That is a pattern worth paying attention to.

The more a task sounds like “always do X when Y happens,” the more likely it belongs in a hook, not in a prompt.

Subagents. The isolation layer

Subagents are one of the clearest signs that Claude Code is built for agentic work, not just chat.

Anthropic describes subagents as specialised AI assistants that run in their own context window, with their own system prompt, tool access, and permissions. Claude can delegate work to them when a task matches the subagent’s description, and the subagent works independently before returning the result. The docs also point out why this matters: subagents preserve context, enforce constraints, specialise behaviour, and can route work to different models.

In long coding sessions, context gets polluted fast. Research, false starts, logs, file reads, debugging dead ends, and exploratory thoughts all pile into the same conversation. Anthropic’s best practices page repeatedly emphasises that context is the most important resource to manage, because performance degrades as the context window fills.

Subagents are how you stop every task from becoming everyone’s problem:

Need a security pass across many files? Use a security reviewer subagent.
Need research on a subsystem before implementation? Delegate it.
Need a focused investigation that should not clutter the main thread? Subagent.

I think this is one of the most underrated shifts in AI coding workflows. The question is no longer just “what should the model do?” It is also “which context should do it?”

That is a different level of workflow design.

MCP servers. The reach layer

Without MCP, Claude Code is mostly limited to the local environment and whatever tools it already has access to. With MCP, it can reach out.

Anthropic describes MCP, the Model Context Protocol, as an open standard that lets Claude Code connect to external tools and data sources through MCP servers. Their examples include issue trackers, monitoring platforms, databases, design tools, and workflow automation systems. They also note an important security warning: third-party MCP servers are not universally verified, and untrusted servers can introduce prompt injection or other risks.

This is where Claude Code stops being “an assistant in my repo” and starts becoming “an agent in my workflow.” That sounds exciting, and it is. But it also changes the stakes.

Once Claude can read tickets, inspect production signals, query a database, read Figma, or draft emails, the design problem becomes larger than coding. You are now designing an operational system. Permissions matter. Trust boundaries matter. Server choice matters. Tool access matters.

So while MCP is easily the most expansive capability in the stack, it is also the one that benefits most from restraint.

Just because Claude can connect to everything does not mean it should.

How these parts fit together in practice

Here is the cleanest way I can describe the whole stack:

CLAUDE.md tells Claude how to behave by default.
Rules narrow that guidance by topic or path.
Skills package repeatable expertise or workflows.
Hooks automate mandatory actions.
Subagents keep big or noisy tasks isolated.
MCP servers connect Claude to outside systems.

A practical workflow might look like this:

Your CLAUDE.md defines coding standards, project conventions, and preferred commands. A rule file adds stricter guidance for the /api directory. A skill gives Claude your internal release checklist. A hook runs linting after edits and blocks writes to a protected migration folder. A subagent handles security review in its own context. MCP connects Claude to GitHub, Jira, Sentry, and your database.

At that point, Claude Code is no longer just reacting to prompts, but operating inside a designed environment. And I think that is the real lesson here.

The quality of the workflow does not come from one magical feature. It comes from putting the right responsibility in the right layer.

Best practices that actually matter

Anthropic’s best practices page covers a lot, but a few ideas stand out because they connect directly to all the moving parts above.

First, give Claude a way to verify its work. Tests, screenshots, and expected outputs dramatically improve results because Claude can check itself instead of making you the only feedback loop.

Second, explore first, then plan, then code. Anthropic recommends separating research and planning from implementation, especially for tasks that touch multiple files or unfamiliar areas. That maps nicely to plan mode, but also to skills and subagents when you want a more structured workflow.

Third, provide specific context. Reference files, constraints, patterns, and symptoms. Claude can infer a lot, but it cannot read your mind (yet 😅).

And finally, manage context aggressively. Use /clear between unrelated tasks and avoid stuffing persistent instructions with everything under the sun.

Most of Claude Code’s “moving parts” are really context management tools in disguise.

Closing thoughts

When people first look at Claude Code, they often ask which feature matters most. I think that is the wrong question.

The better question is: what kind of problem am I trying to solve?

If the problem is persistent guidance, reach for CLAUDE.md and rules.
If the problem is reusable know how, reach for skills.
If the problem is guaranteed automation, reach for hooks.
If the problem is isolation and focus, reach for subagents.
If the problem is external connectivity, reach for MCP.

That is when the system starts making sense.

Claude Code does not become powerful because it has many parts. It becomes powerful when each part has a clear job. And honestly, that is probably the deeper pattern behind good AI workflows in general. Not more prompts. Not more cleverness. Better boundaries.

Practical takeaway:

Start with a small, sharp CLAUDE.md
Add rules only when the project needs more structure
Turn repeated workflows into skills
Use hooks for anything that must happen every time
Use subagents to protect context
Add MCP carefully, with trust and permissions in mind

Which part of Claude Code feels most useful to you right now: rules, skills, hooks, subagents, or MCP servers, and why?

InboxGuilt and the Tone Dial Feature

Damian Demasi — Sat, 07 Mar 2026 07:39:20 +0000

The Monday standup starts like they all do. Cameras on. Microphones half muted. Someone is chewing like they’re trying to hide it. Someone else has the haunted look of a person who woke up to a calendar invite titled “Quick sync” with no agenda.

Then Milo, the founder of InboxGuilt, joins the call ten minutes late, already mid sentence.

“Ok. Great. Love the energy. I’m going to keep this short.”

He never keeps it short.

He shares his screen. A slide deck appears with one title in 64pt font:

TONE DIAL

Under it, a single line.

Make the nudges feel personal. Make them feel… inevitable.

Milo grins like he’s proud of himself, which is always a bad sign.

“Here’s the thing,” he says. “We have product market fit. People are paying to be shamed by an email robot. That’s incredible. But we have a problem.”

He clicks to the next slide. It is a screenshot of an angry customer email.

Subject: “Your app is being rude to my entire company.”

Milo reads it out loud, dramatically.

“‘We asked for gentle reminders. Your system wrote, and I quote, ‘This has been pending long enough to qualify for a loyalty program.’ Our CEO received that. Please advise.’”

A couple of people laugh. Mostly because the line is good. Mostly because the CEO thing is terrifying.

Milo points at the email.

“This is feedback. This is engagement. This is… opportunity.”

He clicks again.

Now it’s a simple UI mock. A slider with five notches:

Friendly
Supportive
Firm
Manager energy
Consultant with a smile

He circles it like he’s revealing a cure for procrastination.

“The Tone Dial,” he says. “Admins pick a default tone for the org. Team leads can pick tone for their team. Users can choose a personal preference if the admin allows it. Everyone gets nudges that match their culture.”

He pauses.

“And,” he adds, “it is a paid feature.”

That wakes everyone up.

Milo keeps going. “This is a platform moment. This is how we stop accidentally emailing HR violations. This is how we increase retention. This is how we upsell.”

He flips to another slide. It’s a chart that goes up and to the right. Nobody knows what the y axis is. Nobody asks.

He turns back to the camera.

“So. I need someone to ship it this week. Ideally today. No pressure.”

You feel your stomach tighten. It is the physical sensation of a Jira ticket being assigned in real time.

Milo looks straight at you on the call.

“Perfect. You.”

A ping pops up. Jira. New ticket assigned.

IG 482. Implement Tone Dial for Nudge Generation

You click it. It is somehow both vague and terrifying.

Acceptance criteria, as written by Milo:

Add the Tone Dial setting to the admin dashboard.
Store the setting per org, per team, and optionally per user.
Update the nudge generation pipeline so the AI follows the selected tone.
Ensure we do not send anything that could get us sued.
Roll out behind a feature flag.
Add analytics tracking for Tone Dial usage.
Make it feel delightful.

You scroll down. There is a final note.

“Also, no breaking changes pls. We have a demo Thursday.”

You look back at the call. Milo is already wrapping up, which means he’s about to add one more thing.

“One last detail,” he says. “This is important.”

He leans in like he’s sharing a secret.

“I do not want the Tone Dial to just change adjectives. I want it to change the intent. Friendly is like, ‘Hey, you got this.’ Consultant with a smile is like, ‘Sharing for visibility that you said you’d do this yesterday.’ Same facts. Different emotional damage.”

He smiles again. The kind of smile that belongs in a case study.

“Ok. That’s it. Ship it.”

The call ends.

Your inbox pings. InboxGuilt is emailing you a nudge. It has your name in it, which feels personal in the worst way.

Subject: Quick nudge

Body: “Just flagging that you are now the owner of IG 482. No rush. Unless you consider Thursday a rush.”

You stare at it for a second.

Then you open Cursor.

The Power of Microtools: How AI and "Vibe Coding" Are Changing the Way We Build

Damian Demasi — Wed, 18 Jun 2025 11:58:59 +0000

TL;DR: We’re no longer limited to using generic productivity tools. With the rise of AI-assisted coding and platforms like v0, Bolt, Cursor, and Windsurf, it’s now possible to build simple, custom tools (microtools) that fit the way you think and work. This shift is not just about convenience; it marks a deeper change in how we relate to software. We’re moving from using tools to making them. These tools aren’t always clean or scalable, but they let you solve your own problems without waiting for someone else to build the solution. That said, real programming knowledge still matters, especially when you're building something meant to last. AI gives us speed and leverage, but it’s skilled developers who make things work.

Organizing your ideas, tasks, or notes often means using a general-purpose app like Notion, Evernote, or Trello. These tools are sleek and flexible, but they come with an unspoken rule: you have to adjust your workflow to match how the tool wants you to think. They are powerful, but often lack the flexibility to fully adapt to your specific needs or preferences.

Now, something is shifting. AI has made it easier than ever to experiment, automate, and create lightweight custom tools on your own. With AI copilots, natural language interfaces, and frictionless development environments, you can quickly build microtools, which are small, purpose-built scripts or apps tailored to your personal workflows.

These tools aren’t designed for scale or mass appeal. They’re meant for you. That specificity is powerful, but it also comes with limits. They might break easily, lack polish, or be hard to maintain. Still, for solving niche or personal problems, they might do the job far better than a bloated all-in-one platform.

Instead of changing your habits to fit someone else's design, now you can create simple tools that match the way you already think and get things done. This shift is not just about replacing the tools you already use. It's about gaining control over how those tools work for you.

What is "Vibe Coding"?

This new ability to quickly shape tools around your own thinking wouldn’t be possible without a shift in how we write code. That shift is best captured by the term "vibe coding.”

If you're not familiar with the term "vibe coding," here's a quick overview. The phrase was coined by computer scientist Andrej Karpathy, co-founder of OpenAI and former head of AI at Tesla, in early 2025. Vibe coding refers to a conversational, hands-off approach to programming that uses large language models to do the heavy lifting. Instead of writing code line by line, Karpathy explained it as: "I just see things, say things, run things, and copy-paste things, and it mostly works.”

Vibe coding is about getting quick, functional results from natural language prompts, with the AI generating most of the code. It's a fast, expressive, and surprisingly productive way to build, especially for throwaway weekend projects or exploratory ideas. That said, Karpathy himself noted its limitations. AI tools don’t always understand or fix bugs, and sometimes you're left experimenting until something works.

Vibe coding is not so much about writing perfectly structured code. It's more about moving quickly, trying things out, and learning through doing. You give up a bit of accuracy and detailed control so that you can experiment and make progress faster. For many people who build things, that trade-off feels worth it. It’s the perfect bridge between idea and execution.

Why Now?

The ecosystem of AI-powered tools has exploded, making the idea-to-app pipeline smoother than ever. What once took days now happens in hours, thanks to new platforms designed with builders, not just developers, in mind.

Take v0 by Vercel, for example (or Bolt, Lovable, and many others). It lets you generate not just UI components or full pages, but entire full-stack apps using natural language prompts. Want a dashboard with a few charts, a login screen, and a backend to store user data? Just describe it. v0 responds with React and Tailwind CSS code, and good business logic structured around a Next.js app. Once you're done, you can deploy straight to Vercel, with all the scalability and performance it provides.

For those who prefer to work closer to the code, tools like Cursor and Windsurf are redefining the developer experience. Both are forks of Visual Studio Code with built-in AI enhancements. They offer features like smart code generation, contextual refactoring, and natural language queries over your codebase.

You don’t need to start from scratch anymore. You can describe your app, vibe-code your way to a working version, and refine it with professional-grade tools.

This is why now is different. The boundary between idea and implementation is dissolving, and the time it takes to go from concept to working prototype has never been shorter.

The Shift: From Platforms to Personal Systems

Here’s the real unlock:

We’re moving from using tools to making them.

Instead of changing our behavior to fit the structure of existing apps, we now have the chance to design tools that match our individual needs. This may seem like a small shift, but it represents a big change in how we use and relate to technology.

For example, I used to track the progress on a personal programming project using Notion. I spent time trying to configure it to reflect the exact structure I needed to track the progress effectively, but it always felt like I was bending my process to fit someone else’s system. Now, I have a custom-built app I made in about half a weekend. It tracks and measures progress exactly how I want, lives online with its own database, and best of all, it’s shareable and open source. That means anyone can use it, and if they want, they can fork it and adapt it to suit their own workflow.

Even better, someone who doesn’t know how to tweak the code can still build their own version. With tools like v0 or Bolt, all they need is a clear idea and a few natural language prompts. Whether they want to replicate my app or build something entirely new, the entry point has never been more accessible.

In short, the tools are no longer the limit. Our creativity is.

How I Replaced Notion with a Custom Tool Built Using v0

Let me give you a concrete example. As I mentioned before, one of the microtools I built was designed to help me track progress on a side project more intuitively. It’s a dynamic task management app that runs on Next.js that lets you create projects with distinct areas and specific work items under each one.

Each project has a central dashboard featuring a progress bar that updates in real time as you mark items complete. This makes it easy to get a visual snapshot of how far along you are and estimate how much work still remains. You can add tasks, assign them to areas, sort them, and even import or export your data.

Everything is backed by Supabase, which handles both user authentication and database storage.

And here’s the part that still surprises me: I built it all using v0 by Vercel over half a weekend. What would have taken days of boilerplate setup and manual UI coding came together almost effortlessly with the help of AI.

This tool is now part of my daily workflow. It fits how I think, helps me stay on track, and reminds me that solving a personal pain point can be both useful and satisfying.

The best part? It’s not trying to be a full SaaS app. It doesn’t need to be. It’s just what I needed, and that’s the beauty of microtools.

You can try out this app, called Project Pulse, by visiting https://www.projectpulse.tools/ and creating an account. If you're interested in exploring or modifying the code, the full source is available at https://github.com/Colo-Codes/micro-app-project-progress-tracker.

I’d love to hear your thoughts: how would you use it, and what changes or improvements would you make?

But Don’t Get It Twisted: Knowledge Still Matters

Vibe coding is fun. It’s powerful. And it’s a great entry point. But there’s a ceiling.

Sooner or later, you’ll want to tweak that AI-generated component beyond what the prompt allows. Or you’ll hit a bug the copilot can’t fix. Or maybe you’ll want to optimize performance or build complex logic that requires actual software understanding.

That’s when real programming knowledge makes all the difference.

Despite all the AI hype, manual coding is far from dead. If anything, it’s more relevant than ever.

Being able to read and tweak code turns you from a passive user into an active true creator. It’s what lets you move from “good enough” to “exactly right.”

If you combine a builder’s mindset with foundational coding skills, you become incredibly effective.

And if you find yourself enjoying this kind of tinkering and building, that might be a sign it’s time to dive deeper. You could build a real career doing this.

Don’t Ship Vibes to Production

Vibe coding is excellent for small projects, weekend experiments, or solving specific personal problems. But it’s not a replacement for the structured practices required in professional software development.

If you're building something for yourself or validating an idea, vibe coding is a superpower. But when you’re working on production-grade software, especially if it will be used by real users, integrated into workflows, or scaled across teams, you need more than vibes. You need engineering discipline.

Professional projects demand:

Scalable architecture and maintainable code
Version control, testing, and CI/CD pipelines
Code reviews, documentation, and shared conventions
Performance considerations, security, and edge case handling

This is why vibe coding alone won’t cut it. You can use it to get started, but sustainable software requires real skills and best practices.

Companies don’t hire developers just to write AI prompts. They hire developers who understand the tools deeply and can apply them intelligently. When the software you build needs to be reliable, secure, and scalable, that depth matters.

AI is powerful. But experienced developers are what make it valuable.

So by all means, vibe-code your next side project or internal tool. But when it’s time to go pro, put on your engineering hat.

Final Thoughts

You don’t need to ship polished products. You don’t need to think in SaaS terms. You just need to solve your own problems, in your own way.

That’s the heart of microtools and vibe coding.

And with AI now helping us bridge the gap between idea and implementation, the only real limit is your curiosity.

📬 Subscribe to my newsletter for more insights on learning, coding, and making cool stuff.

💬 Or drop by X and say hi.

How to Learn Python Faster and Easier with This Notion Template

Damian Demasi — Wed, 14 Feb 2024 19:00:00 +0000

Do you want to learn Python or improve your skills in this popular programming language? If so, you might be interested in the Python for Everybody Specialization course on Coursera. It’s a great way to master the basics of Python and explore its applications in data analysis, web development, and more.

Python Notes Template

But what if you need some extra help or guidance along the way? Don’t worry, I’ve got you covered. I have created a Notion template that contains all the notes I made while doing the Python for Everybody Specialization course (80 different topics, to be exact 😅). These notes are clear, concise, and easy to follow. You can use them to support your learning journey in Python or as a standalone reference to understand Python concepts better.

Sounds good? Then download the free template from this link and let me show you how to access and use these notes.

First, you need to click on the “Python Notes” page in the main “Python Notes” template. This will take you to the Python Notes database, where you can find all the information you need.

The Python Notes template database has different views that you can switch between depending on your preferences and goals.

Topics

This is the default view, showing an ordered list of cards. These cards have my notes on each of the 80 topics covered in the course. It’s best to access them in the order they appear so you can build your knowledge step by step, in order.

When you click on a card, you’ll find a note explaining the concepts covered in a specific class.

At the bottom of the note, you’ll see a list of references in the form of cards. These references usually point to the class where the concept in the note was explained and other resources that can help you learn more about that specific concept.

Topic by Area

This view shows the list of topics conveniently organised by area of knowledge, such as variables, functions, loops, files, etc. You can use this view to focus on a specific area or review what you have learned.

Study Progress

This view helps you track your learning progress and stay motivated. Here, you can move cards across the “Not Started,” “In Progress,” and “Done” columns, showing the step each Python topic has reached in your learning journey.

Topics Table

This view provides a detailed view of how the notes are organized and their properties. This view is useful for creating new notes, editing their properties, and managing the overall composition of the Python Notes database.

That’s it! You’re ready to use the Python Notes template and boost your Python skills. I hope you find it useful and enjoyable. If you have any questions or feedback, feel free to leave a comment or contact me.

Download the template by clicking here.

Advanced Template

But... what if you want to go deeper into your learning journey? 🤔 Well, then you can get the advanced version of the Python Notes template! The Python Notes and Questions advanced template expands on the 80 topics offered in the free version with 375 related questions and two game-changing techniques: spaced repetition and interleaving learning. This template is not free but, trust me, it's worth every dollar you pay for it.

Get the advanced Python Notes and Questions template here!

Why Questions?

Do you want to learn more effectively and efficiently? If so, you should try answering questions about what you are studying. Answering questions is crucial for learning, especially when you use the spaced repetition technique. Let me explain why.

When you respond to questions about a topic, you're recalling information from your memory to form an answer. This practice of recalling helps you remember and reinforces your understanding of the topic, making it easier to grasp the information. It also helps you identify any gaps in your knowledge that you need to fill.

This Python Notes and Questions template implements two techniques to help you better grasp the concepts you are learning:

Spaced Repetition, and
Interleaving learning

Let's see how these techniques work and why they are useful.

Spaced Repetition

When you are trying to learn a new subject, such as Python programming, you might be tempted to read a book or watch a video course and try to learn everything in one go. However, this is not the most effective way to truly understand a subject. Research shows that you will forget most of what you learned after a short time, unless you review it periodically.

The most effective way to learn and remember something is to use spaced repetition. This means going back to review the material over time, at intervals that are based on how well you remember it. When you answer questions about a topic at different times, it helps your memory. It's like giving your brain a friendly reminder about the important details right when you might be starting to forget them.

The following image shows how spaced repetition works. The red line represents how much you remember over time if you review the material just once. The green lines represent how much you retain when you review the material periodically. As you can see, each time you review, you remember more and forget less. This way, you can achieve long-term retention of the information.

Source of image

Spaced repetition is a scientifically-backed learning technique (often employed with flashcards) to optimise the process of acquiring and retaining information. The underlying principle is based on the psychological phenomenon known as the "spacing effect," where the review of material is strategically spaced out over time to enhance memory retention.

Interleaved Learning

Another technique that can boost your learning is interleaving, or mixing up different topics or problem types. You might think that it is easier and more efficient to focus on one topic or problem type at a time, until you master it. However, this is not the case. Studies show that interleaving, or alternating between topics, can improve your learning outcomes and problem-solving skills in the long run.

Why is interleaving effective? Because it challenges your brain to switch between different kinds of information and tasks. This makes you pay more attention and think more deeply. It also helps you see the connections and differences between the topics or problems. This way, you can develop a more flexible and robust understanding of the subject.

Interleaving is especially useful when you are learning subjects that involve problem-solving, such as math, science, or programming. For example, if you are learning Python, instead of doing exercises on one topic, such as loops, you can mix up exercises on loops, variables, functions, and so on. This will help you apply your knowledge to different situations and avoid getting stuck in a rut.

Python Notes and Questions Template

Now that you know how spaced repetition and interleaving can help you learn better, you might be wondering how to use them in practice. Well, you are in luck, because I have designed this Python Notes and Questions template with these ideas in mind.

This template contains a collection of questions that cover various topics and levels of difficulty in Python programming. By answering these questions regularly, you can practice spaced repetition and interleaving, and improve your Python skills.

Answering questions regularly, especially with spaced repetition, in an interleaved manner, is like exercising your brain. It makes the information stick, helping you learn and remember things for a longer time.

Python Questions Template User Guide

Before you start using the Questions template for the first time, you need to do one simple thing. Click on the "Reset Questions Config" button. This button will automatically set up the dates in the template to start counting from the date you begin using it.

After clicking the "Reset Questions Config" button, a confirmation pop-up will appear in case you clicked it accidentally. You can click "Continue" to confirm, or "Cancel" to go back.

Once you confirm the "Reset Questions Config" button action, you're ready to start using the questions. Now, click on the "Python Questions" page.

The first view you'll see is the "Recall Today" view. Here, you'll find a series of cards with questions. These questions cover various topics, implementing interleaved learning.

Try answering the questions out loud, provide examples when possible, and make your own notes. After answering, click on the card containing your answer. This will reveal the correct answer, which is a summarised version of the note related to the question found on the Python Notes page of this template.

Below the answer, you'll find the "Source" section, containing a link to the actual note related to the question.

You can return to the question by clicking on the button highlighted in the image below or by pressing the ESC key on your keyboard.

After checking your answer with the provided one, you'll have two possible outcomes:

Your answer was incorrect: This means you need to revisit this question soon. Click the "Incorrect" button in the "Recall" section to mark the question for review again soon.

Your answer was correct: This means you understand the question well. You'll revisit it in the future, and how far in the future will depend on the "Question Level." All questions start at level 0. Increase their level by clicking on one of the five-level buttons in the "Recall" section:
- If the question level is 0, and your answer is correct, click "Level 1" to increase its level,
- If the question level is 1, and your answer is correct, click "Level 2," and so on.
As the "Question Level" increases, the time gap to revisit the question will also increase, implementing the Spaced Repetition technique.

You can see how the questions spread over time in the "Recall Calendar" view.

If you prefer to sort the questions by difficulty, use the "Questions by Difficulty" view.

Finally, you can view all the questions at once in the "Questions Table" view. This view is useful for performing administrative tasks on the Questions database, such as adding new questions or deleting ones you don't need.

One more thing

If you ever find that some topics, questions, or pages are missing in any of the templates, don’t forget to look at the bottom of the page. Notion sometimes hides extra information, so you’ll need to click on “Show more” (or something similar) to reveal the rest of the items.

Closing thoughts

That's all for now! I hope you had fun reading this and that you are finding the templates I shared with you helpful for learning Python.

See you in the next one! 🖖

🗞️ NEWSLETTER - If you want to hear about my latest articles and interesting software development content, subscribe to my newsletter.

🐦 TWITTER/X - Follow me on Twitter/X.

Python Project: Analysing Australia's Migration Trends and Economic Impact

Damian Demasi — Wed, 07 Feb 2024 08:58:52 +0000

Python for Everybody Capstone Project

In my recently completed Python for Everybody course, we wrapped up with a capstone project that got me diving into data exploration.

Recently, my attention was caught by discussions and news bits talking about how international migration shakes up Australia's job and housing scenes. So, with my curiosity fired up, I decided to dig into the data, hoping to discover connections between international migration and the trends in these markets.

Being an international migrant myself, I've got a personal stake in understanding how Australia's migration policies and the flow of immigrants play out in the country's economy.

Fortunately, Australia boasts an incredible data gold mine: the Australian Bureau of Statistics (ABS). I managed to search their data and find information about Overseas Migration, Labour Force, Housing Occupancy and Costs, and Total Value of Dwellings.

I initially intended to perform the following tasks with this data:

Database Integration: Import the data into a database for efficient querying and analysis.
Visualization: Generate maps, charts, and graphs to represent migration and economic data.
Economic Impact Analysis: Understand the economic impact of migration on housing and job markets.
Correlation Analysis: Identify potential correlations between migration, labour force, and housing data.

Discover the power of knowledge! Grab my newest free Notion template, packed with detailed notes on 80 specific topics covered during my journey through the University of Michigan's 'Python for Everybody' course on Coursera. Ready to level up your Python skills? Click here now!

Picking the Data Source

When I first dug into the data from the ABS, I noticed they had it neatly laid out in both MS Excel and CSV formats. Seemed like it could be pretty straightforward to handle, perhaps with a handy Python script.

The topics I was interested in were:

But then, I found out there was another door to this data exploration – an API provided by the ABS. This meant I could easily fetch the data using Python, push it into a database, and then dive into analysis mode. As the API provides an XML response, I could be using ElementTree to parse it.

After trying to build an API request on my own, I stumbled upon a tool that the Australian Bureau of Statistics provides to explore data called Stat Data Explorer. What's neat about it is that it lets you visually explore the data and even generates the right API request for the info you've seen.

So, I ditched the idea of using the initial data from the Excel files and opted to pick out the juiciest datasets for my analysis using this cool tool.

Note: you can take a more technical look at how I used the Stat Data Explorer and the API endpoints I got by taking a read to the README.md file in my GitHub repository.

Building a Data Fetching Script

I kicked things off by creating a nifty Python script called data_getter.py to get the data from the Australian Bureau of Statistics API. As I mentioned earlier, since the data dances in XML format, I enlisted the help of the xml.etree.ElementTree module to untangle its secrets 😅.

For the analysis, I set my sights on the period from 2011 to 2022. Why, you ask? Well, that's because the data for the number of residential dwellings is only available from 2011 onwards, and there was no migration data for 2023 at the moment of working on this project.

Once I processed the XML data, I tucked it neatly into an SQLite database named capstone.sqlite. Why SQLite? Because it's lightweight and easy to use (and the database that we have been using throughout the course).

After analysing it for a while, and a bit of trial and error, I came up with an Entity-Relationship Diagram (ERD) for the database that looks like this:

If you are following along with the code in my repository, you can test the data-fetching script by running python3 data_getter.py in your terminal.

Building a Data Normalization Script

Once I fetched the data, I spotted a little quirk – it wasn't playing nice in terms of consistency. The count of homes came in quarters, but the job scene spilled the beans monthly. So, I decided to bring order to the chaos and normalize the data, all cosy and snug in a yearly fashion, just like our migration data.

It was now the turn of another Python script: data_normaliser.py. This script not only handles the data makeover but also inserts the revamped data into a squeaky-clean database named capstone_normalised.sqlite. This polished database is all set to steal the spotlight for the grand finale – the analysis and visualization of our data tale.

Data Analysis

Now that our data is all neat and tidy, it was time to roll up our sleeves and dive into the world of analysis and visualization. To kick things off, I created a Python script called data_stats.py that churned out some essential statistics to explore:

Migration
- Year with highest migration
- Year with lowest migration
- Average Migration per year
- Average Migration per state
Employment ratio
- Year with highest employment ratio
- Year with lowest employment ratio
- Average employment ratio per year
- Average employment ratio per state
Dwellings (quantity)
- Year with highest dwellings number
- Year with lowest dwellings number
- Average dwellings number per year
Dwellings (price)
- Year with highest dwelling price
- Year with lowest dwelling price
- Average dwelling price per year

Note that you can test this script by running python3 data_stats.py in your terminal if you are following along.

This is an example of the output of the script:



➜  capstone_project git:(main) ✗ python3 data_stats.py

Getting migration data from database...

== ---------------------------------------- ==
   Migration statistics
== ---------------------------------------- ==
Highest Migration year was 2022 with 422,230 migrations.
Lowest Migration year was 2020 with -20,370 migrations.
    The Migration variation between the highest and lowest year is about 20.73 times the lowest year.
Average Migration per year is 45,061 migrations.
Average Migration per state is:
    New South Wales: 70,884 migrations
    Victoria: 61,682 migrations
    Queensland: 29,642 migrations
    South Australia: 11,857 migrations
    Western Australia: 21,871 migrations
    Tasmania: 2,165 migrations
    Northern Territory: 1,685 migrations
    Australian Capital Territory: 2,979 migrations
    Australia: 202,784 migrations



Getting employment ratios data from database...

== ---------------------------------------- ==
   Employment Ratio statistics
== ---------------------------------------- ==
Highest Employment Ratio year was 2017 with 73 %.
Lowest Employment Ratio year was 2013 with 55 %.
    The Employment Ratio variation between the highest and lowest year is about 1.33 times the lowest year.
Average Employment Ratio per year is 62 %.
Average Employment Ratio per state is:
    New South Wales: 60 %
    Victoria: 61 %
    Queensland: 61 %
    South Australia: 58 %
    Western Australia: 64 %
    Tasmania: 56 %
    Northern Territory: 70 %
    Australian Capital Territory: 68 %
    Australia: 61 %



Getting dwelling numbers data from database...

== ---------------------------------------- ==
   Dwelling Number statistics
== ---------------------------------------- ==
Highest Dwelling Number year was 2022 with 10,907 (x1000) dwellings.
Lowest Dwelling Number year was 2011 with 74 (x1000) dwellings.
    The Dwelling Number variation between the highest and lowest year is about 147.39 times the lowest year.
Average Dwelling Number per year is 2,201 (x1000) dwellings.
Average Dwelling Number per state is:
    New South Wales: 3,080 (x1000) dwellings
    Victoria: 2,545 (x1000) dwellings
    Queensland: 1,976 (x1000) dwellings
    South Australia: 764 (x1000) dwellings
    Western Australia: 1,049 (x1000) dwellings
    Tasmania: 241 (x1000) dwellings
    Northern Territory: 81 (x1000) dwellings
    Australian Capital Territory: 166 (x1000) dwellings
    Australia: 9,909 (x1000) dwellings



Getting dwelling prices data from database...

== ---------------------------------------- ==
   Dwelling Mean Prices statistics
== ---------------------------------------- ==
Highest Dwelling Mean Prices year was 2022 with 1,170 (x1000) AUD.
Lowest Dwelling Mean Prices year was 2012 with 297 (x1000) AUD.
    The Dwelling Mean Prices variation between the highest and lowest year is about 3.94 times the lowest year.
Average Dwelling Mean Prices per year is 576 (x1000) AUD.
Average Dwelling Mean Prices per state is:
    New South Wales: 810 (x1000) AUD
    Victoria: 671 (x1000) AUD
    Queensland: 514 (x1000) AUD
    South Australia: 453 (x1000) AUD
    Western Australia: 551 (x1000) AUD
    Tasmania: 401 (x1000) AUD
    Northern Territory: 473 (x1000) AUD
    Australian Capital Territory: 671 (x1000) AUD
    Australia: 645 (x1000) AUD

Data Visualisation

Moving on, I built a Python script named data_visualiser.py to whip up some captivating visualizations. Here's the end result:

A snazzy 2D chart laying out the data landscape on a national scale.
Four dynamic 3D charts, giving us a state-level peek into the data dimensions across Australia.

At first, I gave the 3d.js library a shot for the charts, but it struggled when I tried to juggle multiple data dimensions in the same graph. Not to worry, I pivoted to the plotly.js library, and it played nice, letting me plot those dimensions, but not without breaking a sweat 😓.

Oh, by the way, you can view these charts live online by clicking here!

The result was a grand chart focusing on Migration, Employment Ratio, Dwelling Quantity, and Mean Price nationwide. This beauty allowed me to dissect how these variables dance together and catch any trends. Now, mind you, correlation in this chart doesn't automatically mean causation – there's a whole orchestra of factors for a proper analysis. But for our project's sake, the plotted data paints quite the picture.

In 2020, a noticeable dip in migrations coincided with the aftermath of COVID-19, leading to a significant decline in the Employment Ratio—hinting at a rise in unemployment. The drop in employment is likely a result of the pandemic's impact on the job market rather than a direct consequence of decreased migration. Meanwhile, the number of available homes continued its steady growth, while the average dwelling price started a descent as it approached 2020.

As we stepped into 2021 and 2022, witnessing a resurgence in migration as Australia reopened its borders, a parallel spike in both the Employment Ratio and mean dwelling prices caught my eye. Interestingly, the number of dwellings maintained its consistent growth. The surge in mean dwelling prices during these years could be attributed to the increased influx of migrants, and the fact that the number of dwellings remained unaltered in its tendency, creating a higher demand for houses.

Interestingly, as migration gained momentum in 2021 and 2022, the Employment Ratio also showed improvement, suggesting that the increase in migration didn't negatively impact employment.

I dug into creating four more 3D charts, each showcasing the dynamics of Migration, Employment Ratio, Dwelling Quantity, and Mean Price across different states in Australia. These charts unveil interesting insights, like migrants showing a preference for New South Wales and Victoria. These states seem to play a significant role in the growing number of available homes. Meanwhile, the Northern Territory experiences a more gradual increase in dwelling prices, and its employment market appears to be in robust shape.

Employing a 2D line chart for a nationwide data overview proved effective in uncovering trends and correlations, aligning with the initial goal when first exploring the data. The use of 3D graphs to compare states added a dynamic and engaging layer to the analysis, offering a deeper understanding of the data dynamics across different regions.

Note: if you are following along, you can generate these charts by running python3 data_visualiser.py in your terminal and then opening the charts.htm file in your browser. The raw data for the charts can be found in the charts.js file.

Key Takeaways

The lessons learned from this project will undoubtedly have a positive impact on my future endeavours. It served as a platform to apply my recently learned skills in Python, SQL databases, data analysis, visualization, and interpretation. Despite the occasional challenges of navigating through real-world data, it significantly enhanced my problem-solving abilities. In essence, this project has been a valuable learning journey, contributing significantly to my growth as a software engineer.

🗞️ NEWSLETTER - If you want to hear about my latest articles and interesting software development content, subscribe to my newsletter.

🐦 TWITTER/X - Follow me on Twitter/X.

Navigating Mutability and Reference Issues in JavaScript

Damian Demasi — Mon, 27 Feb 2023 09:30:50 +0000

Mutability

Mutability refers to the ability of a value or data structure to be changed after it has been created.

Primitive values are immutable

Primitive values (string, number, bigint, boolean, undefined, symbol and null) are immutable, which means that they cannot be changed once created.

let myString = "Hello, world!"

// Attempting to mutate (change) the string:
myString[0] = "J"
// -> 'J'

// Proof that strings are immutable, because it didn't change:
myString
// -> 'Hello, world!'

The string "Hello, world!" will always be "Hello, world!".

We can change the value to which the variable is grasping (a new string that also will be immutable), but the string itself (the value) will remain the same (immutable):

let myString = "Hello, world!"

myString
// -> 'Hello, world!'

myString = "Hey, world!" 

myString
// -> 'Hey, world!'

myString[0] = "X"
// -> 'X'

myString
// -> 'Hey, world!'

Objects are mutable

Objects are mutable, as they can be modified:

// Object creation
const person = {
  name: 'Sarah',
  age: 30
};

// Change the value of a property
person.age = 42;

// Add a new property
person.gender = 'Female';

// Delete a property
delete person.age;

person;
// -> {
//     "name": "Sarah",
//     "gender": "Female"
// }

In this scenario, an object is mutable because we can change its properties.

If the object properties are other objects, their values will be mutable, whereas if they are primitive values, their values will be immutable.

person.gender[0] = "X"

person
// -> {
//     "name": "Sarah",
//     "gender": "Female"
// }

Even though an object is mutable, its properties might not be.

We can make an object immutable by using the Object.freeze() function:

// Object creation
const person = {
  name: 'Sarah',
  age: 30
};

Object.freeze(person)

person.name = "Connor"
person.enemy = "T-1000"

person
// -> {
// {
//     "name": "Sarah",
//     "age": 30
// }

The reference confusion in objects

When we assign a primitive value to a variable, we are making that variable point to a primitive value in the memory of the machine. We can then assign the variable to another variable, thus making the second variable grasp the first one, and, by extension, reference the same value.

If we wanted to change the value of the second variable, ss we cannot change primitive values (they are immutable), we could assign a new value. By doing so, the second variable will be referencing a new value.

let variable1 = "hello"

let variable2 = variable1

variable2 === variable1
// -> true

variable2 = "bye"

variable2 === variable1
// -> false

variable1
// -> 'hello'

variable2
// -> 'bye'

With objects, the behaviour is a bit different. We can assign an object to a variable, which means that the variable grasps the object, or has a reference to it. If we then assign that variable to another variable, the new variable will grasp the first one and, by extension, reference the same object. As objects are mutable, a change in the object will affect both variables.

const object1 = {
    value1: "abc",
    value2: 123
}

const object2 = object1

object2 === object1
// -> true

object2.value1 = "xyz"

object1
// -> {
//     "value1": "xyz",
//     "value2": 123
// }

object2
// -> {
//     "value1": "xyz",
//     "value2": 123
// }

On the other hand, we can define a new object in the second variable, and thus make it not reference the same object as the first one. One thing to note is that, even if all the object properties are the same, these two objects will be different:

const object1 = {
    value1: "abc",
    value2: 123
}

const object2 = {
    value1: "abc",
    value2: 123
}

object2 === object1
// -> false

object2.value1 = "xyz"

object1
// -> {
//     "value1": "abc",
//     "value2": 123
// }

object2
// -> {
//     "value1": "xyz",
//     "value2": 123
// }

References

Thanks for reading, and see you next time! 👋

🗞️ NEWSLETTER - If you want to hear about my latest articles and interesting software development content, subscribe to my newsletter.

🐦 TWITTER - Follow me on Twitter.

Cover photo by Ivana Cajina on Unsplash

Learning how to code: with our special guest, Ron

Damian Demasi — Wed, 12 Oct 2022 20:08:59 +0000

Let me introduce you to Ron, an ordinary person like you and me, except that he was born into a world of magic. Life led Ron to experience many adventures when he was young. Still, he somehow ended up working as a manager in a retail wizarding joke emporium, a job he ultimately got tired of. As he wanted to start working in something more rewarding, he began investigating a possible career in programming and, more specifically, in web development.

This content is also available on my YouTube channel, and you can watch it here:

But Ron knows he has some problems with his study techniques: he doesn’t know how to improve his weakest points, often thinks that tests are a waste of time, and constantly takes feedback incorrectly.

In this article, we will help Ron by teaching him how to attack his weakest points to improve them, how he can learn by testing himself about programming concepts and allow feedback to improve his coding skills.

This article is the second one about distilling the concepts presented in the book Ultralearning by Scott Yong. I apply those concepts to learning programming, as I believe they are very useful. If you wish to know more about these topics, I recommend reading the book.

I will publish at least two more learning principles applied to programming in the upcoming article, so you might want to subscribe to my newsletter get a notification when it's published.

OK, let's help Ron with the first principle: Drills.

Drills: Attack Your Weakest Point

As soon as Ron sat down and opened his online course about programming, he felt overwhelmed by the complexity of the topics he wanted to learn. According to the book, applying a "divide and conquer" approach is the best way to overcome these challenges.

Ron could break down complex topics into smaller pieces, understand them, practice them, and once he masters those small parts, put them back together.

The key idea behind drills is to choose critical concepts and practice them. Drills build up from the principle of Directness, discussed in my previous article, but it goes a bit deeper, with a narrower focus.

Suppose we start by putting into practice a programming concept through directness. In that case, we could then find the most complex components that produce the most significant impact on the main concept and create drills, which are essentially practice sessions, to improve them. After we have completed our practice sessions, we can go back to the central concept and see if we understand it better.

Ron finds it difficult to transfer this idea into practice, so let's give him a couple of tactics he can use to design his drills.

Tactic 1: Components

In this tactic, we will find ways to drill (practice) only one specific component of the concept or skill we are learning.

As it turns out, Ron has problems understanding the structure of HTML documents. In this case, he could practice small pieces of the HTML structure, such as the HTML version information. Once he has practised this piece until it comes natural to him, he can move on to other elements, thus growing his knowledge and expertise about HTML.

Tactic 2: Copycat

Sometimes we will need to practice a part of a concept that's not easy to reproduce by itself. In these situations, we could copy the features we don't want to practice to focus on the parts we do.

Ron wants to practice some HTML form elements, such as <input> and <label>. To do this properly, he will need to write a lot of HTML code just to reach the section in which he can finally introduce a <form> element and practice its sub-elements: <input> and <label>.

<!DOCTYPE html>
<html>
    <body>
        <h1>The label element</h1>

        <p>
            Click on one of the text labels to toggle the related radio button:
        </p>

        <form action="/action_page.php">
            <input type="radio" id="html" name="fav_language" value="HTML" />
            <label for="html">HTML</label><br />
            <input type="radio" id="css" name="fav_language" value="CSS" />
            <label for="css">CSS</label><br />
            <input
                type="radio"
                id="javascript"
                name="fav_language"
                value="JavaScript"
            />
            <label for="javascript">JavaScript</label><br /><br />
            <input type="submit" value="Submit" />
        </form>
    </body>
</html>

By using the copycat tactic, Ron can just copy and paste the code needed to build an empty form and build on top of that, practising the elements he wants to learn.

Building on this concept, and once Ron gains more knowledge about versioning systems, he could even use Git to create branches of his code and practice parts of it.

Tactic 3: The Programming Dojo

Another way to practice specific code concepts is to have a programming session around a coding challenge. Websites like CodeWars offer many coding challenges we can use to practice our coding skills and improve.

In websites like this one, Ron is not only going to write code but also look at other muggles', I mean people's, solutions, something that will teach him about the different ways a programming challenge can be solved.

🧑‍💻 Here is a list of sites to practice code:

Let's now help Ron to overcome his preconceptions about tests and use them as a learning tool.

Retrieval: Test to Learn

Ron is used to thinking about testing as a way to assess knowledge when, in fact, it's also a way of creating it. We should test ourselves before we feel confident, even if we don't know all the answers, because doing this will prepare our minds to pay attention to information that looks like a solution when we learn it later.

Ron is used to spending long hours passively reviewing his highlights on books and notes, hoping that something will stick to his memory, but this is not what retrieval is about. Retrieval is closing the book and trying to answer questions about the topic we just learned. This is why it's essential to build our own projects in programming because it's here when we discover what we know and don't know.

If we have the answers to what we want to retrieve, such as the book's answer keys, we can compare our recalled knowledge with the actual correct answers, thus improving our understanding and retention.

Ron is taking a course on JavaScript, and the instructor says, after showing how something is built, "OK, now you try to build this functionality". Ron should try to build it without taking a second look at how the instructor did it and Googling things he doesn't know or remembers. After he finishes creating it, he can continue watching the course and compare his solution with the solution provided by the instructor. This will trigger several "aha!" moments for Ron, keeping him engaged in the learning activities.

Ron should avoid doing simple retrieval, such as answering multiple-choice questions. He should try to do open retrieval: writing as much as he knows about a specific topic. This is the best method to make the most of his retrieval activities. For more details about the scientific proof behind this, read chapter 8 of the book Ultralearning.

Ron asks for some tactics about how to put the retrieval concept into practice, so let's take a look at the following ones.

Tactic 1: Free recall

After reading a book section or learning a new concept, we could try to write down everything we remember on a blank piece of paper. Doing this will help us to remember these concepts later.

Tactic 2: The question-book method

We often take notes during our learning process to highlight things that we consider to be important. A better way of taking notes is to write them down as questions to be answered later.

I actually did this when I was doing a Udemy course about JavaScript. As the course introduced concepts, I wrote them down on a Notion database in the form of questions. This is how I managed to write 318 questions (with their answers) and have them ready for my recall sessions.

For example, instead of writing "Type coercion is…" we could write "What is type coercion?" and refer to where we can find the answer. In this example, a link to a blog post in FreeCodeCamp will suffice: "Type coercion is the process of converting a value from one type to another (such as string to number)."

But I have a disclaimer to do, and I'm sure Ron is going to relate to this: even though I have all these questions, I'm still struggling to find time and energy to do some recall on them. So, don't be like me, and find time to answer the questions! 😅

Tactic 3: Self-generated challenges

As we go through our learning material, we could create challenges for ourselves to solve later. For example, if we are learning about APIs, we could create a challenge to use an API.

We could create a list of all these challenges to address later and have our own repository of code examples we could use in the future.

Let's now help Ron overcome his tendency to take feedback in the wrong way.

Feedback: Don't Dodge the Punches

During our learning process, we are going to find feedback. It could come from other people expressing their opinions, but more often than not, it will come from a computer: our code doesn't work as expected.

We shouldn't let our egos get in the way of this feedback. On the one hand, we can think that as our program is not working, we are not suitable to be programmers. Or on the other hand, believe that we are great programmers because we got our "Hello, world" code working on the first try.

Ron usually feels reluctant to share his code with others as he will face criticism. The bad news is that others must review our code, as this is a standard practice in the programming industry. Here we should remember the concept of having a growth mindset (as I discussed in the first article of this series) and don't take feedback or criticism in the wrong way. Feedback is what makes us better programmers.

Let's give Ron some tactics to improve his response to feedback and use it in the best way possible.

Tactic 1: Noise cancellation

Every time we receive feedback, it will be made of a constructive and noisy part. We should learn to disregard the noise and focus on the constructive part.

For example, someone can comment about Ron's code: "You are not good in programming because you forgot to clear the timeout in this React component. You should go back to selling magic jokes…". The constructive part of this feedback is that Ron should pay more attention to clearing timeouts in his code to avoid memory leaks, for example. The noise is the first and last part of this feedback, a subjective judgement someone made about Ron's capabilities as a programmer, and he should disregard that, as the person giving the feedback probably doesn't know Ron well. He can't possibly write code without making mistakes (that's why our code needs to be reviewed by peer programmers and pass quality assurance tests).

Tactic 2: Hitting the difficulty sweet spot

We need the computer's feedback when writing code, as it will tell us if the code is working or not. If Ron makes too many mistakes, or too few, he should decrease or increase the difficulty of the project he's working on to get helpful feedback.

Tactic 3: Metafeedback

This kind of feedback is not about the code we are writing but the overall success of the strategy we use to learn how to code.

Ron could experiment with different study methods, comparing and contrasting them. The best way to make this comparison is to test himself: does he learns more with method A or B? Which method takes more time? Which method is the most likely he will use in his study activities?

Closing thoughts

Coming to an end in this article, I hope we have given Ron a good idea about how he can improve his weakest points, learn effectively by testing himself and constructively take feedback to improve his coding skills. I'm sure Ron now feels more confident about learning how to program.

I want to remind you that there are at least two more principles I'll cover in the coming article, so you might want to subscribe to my newsletter to get a notification when it's published.

Have you ever felt like Ron did? Which one of the covered principles resonated most with you? Please leave your answer in the comments so we can discuss more about it.

Thanks for reading, and see you next time! 👋

🗞️ NEWSLETTER - If you want to hear about my latest articles and interesting software development content, subscribe to my newsletter.

🐦 TWITTER - Follow me on Twitter.

Learning how to code: the first 3 steps

Damian Demasi — Wed, 21 Sep 2022 21:37:14 +0000

In this post, I’m going to cover the concepts described in the book Ultralearning, and describe the first three principles:

Metalearning,
Focus, and
Directness

This content is also available on my YouTube channel, and you can watch it here:

Ultralearning is a book written by Scott Yong, and in it, he presents several principles that we can apply to learn difficult topics, such as programming. If you wish to know more about these topics, I highly recommend you read the book.

I’m going to publish at least 5 more learning principles applied to programming in the upcoming posts, so you might want to subscribe to my newsletter to get a notification when they are out.

By now, you are probably wondering what is ultralearning. It’s basically a strategy for gaining skills and knowledge that is both self-directed and intense. It’s not passive or entertaining, as could be conveniently watching a tutorial whilst relaxing on the couch.

Instead, it’s systematic and iterative. It’s the difference between wishful thinking (“oh… it would be nice to learn how to program, so let’s watch some YouTube videos about it”) and massive action (“as I’m convinced that I want to learn to program, I’m going to devote myself to that task”).

When applying the ultralearning principles, we are going to be learning by doing what we want to learn (this concept is called “directness”) and starting way before we are ready. This means that we are going to start programming in a new language from day 1. We will want to get instant feedback (the code is throwing error messages or not compiling), and in this way, we will know what needs to be corrected and improved. A clear example of this is taking a programming course on freeCodeCamp (which I highly recommend): you’ll start coding from the beginning, even though you don’t know much about code.

But why would we want to invest all that effort in order to learn to code? Learning a skill in a deep way like this can provide a sense of purpose in life because developing skills is meaningful.

One of the main themes throughout the book is having a challenge: a project on which we are going to be working on during our learning process. In our case, this project could be building a specific website or app whilst we are learning how to code. This will help to learn with purpose.

Now, it’s important to keep in mind that if some principles or approaches are not working, we should reassess them and change what needs to be changed.

OK, enough introduction. Let’s start with the first principle: Metalearning.

Metalearning

Our learning journey will start by drawing a map of what learning programming looks like. Here we should be interested in knowing how programming knowledge is acquired and structured.

But you don’t have to start from scratch. I’ve built a Notion template summarising the core topics involved in web development, a list of roadmaps and topics that are related to programming. You can download that template and modify it as you wish, expanding it according to your needs.

Going back to the principle of Metalearning, do your best to answer these three questions: “why?”, “what?”, and “how?”.

“Why?”

In my first post in this series, I talked about the importance of having a clear why. What’s the motivation to learn to program? To help answer this question, you can talk to programmers already doing what you want to do and ask them what they like most (and least) about their jobs.

“What?”

Build a list of knowledge and abilities you need to acquire. You can start with the Notion template I shared with you and build on top of it. Create lists of the concepts (ideas that need to be understood but not memorised), facts (things that need to be memorised), and procedures (anything that needs to be practised, actions to be performed).

“How?”

To find out the how, you can use two methods:

Method 1: Benchmarking

Find references on how people are learning to code. Look at the curricula used in universities, tables of content in online courses and books, and roadmaps (like the ones included in the Notion template). Try to find good quality materials.

Method 2: Emphasise and exclude

Considering why you want to learn to program, double down on the areas that are in line with your why. For example, you could want to learn web development to build an app to track tasks during different progress stages, like in Kanban methodology, so double down on web technologies and avoid learning low-level programming languages, like C, or game engines.

Once you have a clear idea about how to answer the “why”, the “what” and the “how”, it’s time to focus.

Focus

I covered this concept in the second post of this series when I spoke about Deep Work, but this is such an important principle that’s also present in the book Ultralearning.

We need to develop the ability to concentrate. We need to allocate portions of time in which we are going to be learning and make it easy to do so.

The most common struggles to focus happen when we are starting (we procrastinate) and when we need to maintain our focus (we get distracted).

Procrastination

To help cope with procrastination you can establish deadlines to help us start working on what needs to be done. It’s important to be able to recognise that we are procrastinating. We need to remember that the thing that’s unpleasant about the task is just the impulse, the first few minutes of it. Once we start doing the task (studying programming), the unpleasant sensation decreases.

A technique that can help us here is the Pomodoro timer: set 25 minutes to do the task and allow yourself to rest for 5 minutes after that. Repeat as many times as necessary.

Another useful technique is to use small checkpoints: we can start studying and finish when we have read a page, a chapter, or a specific topic.

Distraction

The key here is to enter a state of flow (some people call this being “in the zone”). In this state, our mind will be completely absorbed by the task we are performing. We need to set the difficulty of the task to something that’s not too hard or too easy, so we can achieve flow effortlessly.

But… we shouldn’t worry too much if we don’t manage to achieve a flow state. What we can do instead is to focus on achieving short goals. Similarly to the small checkpoints described earlier, this will help us to maintain motivation.

We also need to maintain a balance between studying programming and resting. 50 minutes to an hour is enough for many learning tasks. After that, we can rest for a while, and repeat the cycle again. Using the Pomodoro timer could also be helpful here.

Additionally, we need to make sure our environment is free from distractions such as our phones, watching videos or playing games during our study sessions, distracting noises, or the lack of tools to study (like pencils, books, or a lamp).

We should engage with the task. We can do this by taking notes to explain difficult concepts, asking questions to the book or video course (writing them down to look for the answers later), and trying to identify where we can apply what we are learning.

Finally, if we get stuck, we should take a break and let our focus expand. We can go for a walk, grab a snack, or have a quick chat with someone. This will bring new ideas to our consciousness that we can use to unstuck ourselves.

Let’s now move on to the principle of Directness.

Directness

We will learn better by doing the thing we want to do. Do you want to build a website? Start building it and learn what you need along the way. Doing this will feel difficult, frustrating, and painful even, so we are going to want to avoid it. But what we should do is focus on solving the problems practically, instead of loading ourselves with theoretical concepts. As the author of the book says: “Doing the thing that you want to get good at is when much of the learning takes place.”

We can apply different tactics to learn by doing.

Tactic 1: Project-based learning

We can organise our learning around producing something. For example, we can decide that we want to build the website for a restaurant, and we can divide that project into smaller pieces: user login components, menu bars, database tables for orders, etc. Then we can learn what’s needed for each of those parts. If you don’t know what you need to learn for each of the parts, jump into a forum (like Reddit), Twitter or Discord channel, and ask around to more experienced developers.

Tactic 2: Immersive learning

Surround yourself with the environment in which programming is being practised. Join Meetup groups, participate in open-source projects, explore Discord channels, and take part in hackathons or coding challenges. The objective is to look for things to do that can push us to learn new things.

Tactic 3: the overkill approach

Decide to do something that’s way more complex than the topic you want to learn. For example, instead of just learning JavaScript to build an interactive website, decide that you are going to teach a course about JavaScript and that this course will be publicly available. By doing this, even if we fail to deliver the course as we envisioned, we are going to be learning far more than we initially imagined when we thought about just building our JavaScript app.

Closing thoughts

Now, coming to an end in this post, I want to remind you that there are still at least 5 more principles that I’ll cover in the coming posts, so you might want to subscribe to my newsletter to get a notification when they are published.

🤔 Which one of the covered principles resonated most with you? Leave your answer in the comments so we can discuss more about it.

Don’t forget to download the Notion template in which I cover resources for learning web development and, programming in general, so you can start getting your feet wet with the programming world.

Thanks for reading and see you next time! 👋

🗞️ NEWSLETTER - If you want to hear about my latest articles and interesting software development content, subscribe to my newsletter.

🐦 TWITTER - Follow me on Twitter.

Learning how to code: what you should know first (part 2)

Damian Demasi — Mon, 05 Sep 2022 18:15:08 +0000

Are you thinking of learning how to code? I think there’s still something you need to know first…

This is the second post of a two parts series, and I’m going to cover:

The importance of Grit
The key to consistency: Habits
Why doing Deep Work is important to have productive study sessions
Why you should Care about Your Craft, and
Why you shouldn’t compare yourself to others

Just in case you missed it, this is the first article of this series.

You can watch this content on my YouTube video:

If you missed the first post, you should consider subscribing to my newsletter so you can get a notification when I publish my videos.

In this post, we are going to continue developing an attitude and mindset that will allow us to face the challenge of learning programming in the best way possible.

Let's start by discussing Grit.

Grit

Grit can be defined as a fierce determination to perform our work. Grit means being able to endure setbacks and work hard. Once more, keeping in mind our "why" will be very helpful here.

We can have a high potential (or almost none), but what’s really important is what we do with it.

Someone with great potential, like a person that understands mathematics and logic easily, but with no grit, will not be able to progress far in the programming journey.

On the other hand, someone with low potential, like a person that needs to read a definition several times to really understand it, but with plenty of grit, will progress far in programming.

If you want to know more about this topic, I recommend you read the book Grit.

Let's now move on to Habits.

Habits

We need to decide what our identity will be and develop habits that can sustain that identity. Our habits shape our identity, and, in turn, our identity also shapes our habits.

Ask yourself: What type of identity do you want to develop? Do you want to be a programmer? What habits does a programmer have?

We can define our identity as follows: “I’m a programmer that takes care in giving the best of himself or herself at this very moment“. Then, when we are about to do something that goes against that identity, we will have a clear indication of what we should be doing:

“Will a programmer that’s giving the best of herself sit to watch a Netflix show, or, instead, would she choose to work on a project for her portfolio?”
“Willa programmer that’s giving the best of himself choose to work or study without a break, or choose to go outside for a while to clear his head and stretch the body?”

The key here is not to fool ourselves, because we are the easiest person to fool.

To know more about this topic, I recommend you to read the book Atomic Habits.

Let's now talk about Deep Work.

Deep Work

According to Carl Newport, Deep Work is a “professional activity performed in a state of distraction-free concentration that pushes your cognitive capabilities to their limit”. The key here is “distraction-free concentration”.

If you wish to know more about this, read the book Deep Work.

One of the main obstacles to overcome in order to achieve distraction-free concentration are social networks (Facebook, TikTok, Reddit, Twitter, etc.). When we are studying programming, or working on a project, we should avoid using social networks if we want to keep the focus on the task at hand.

In his book, Carl Newport recommends allocating specific days and times in which we are going to be studying, distraction-free. This will help us to:

avoid burnout,
avoid pilling up subjects to learn or projects to practice, and
keep the focus on the studying activity.

The hours of our day are not all equal. We are going to be more productive at certain times of the day rather than others. For example, we could study best early in the morning, or in the late afternoon, so we need to pay attention to which time serves us better according to what we want to do.

What I usually do is assign a relative value to the different parts of the day. Early mornings are my most valuable hours. I’m full of energy, no one is going to interrupt me, and I can use those moments to study programming or work on a project, no matter the day of the week.

Let's now Care about our craft.

Care about your craft

What we do in our work and in our studying activities will be a reflection of the type of professional we want to be. Therefore, it will be in our best interest to do things the best way we can:

We shouldn’t be mindlessly studying, overlooking important topics.
We should try to care about the quality of the code we are writing (even if it just how well indented it is).

The objective here is to do whatever we do, in the best way we can, given our current circumstances.

I find it very helpful to ask myself if my future self (not someone else) would be proud of how and what I’m doing right now.

To learn more about this topic, you should read the book The Pragmatic Programmer.

Now... remember not to compare yourself with others.

Don’t compare yourself to others

We are all different, and you don’t know what paths have led people to where they are today. So, comparing yourself with someone else has no point.

Instead of comparing ourselves with someone else, choose to make that comparison with your own self.

Where were you 2, 5, or 10 years ago? Are you in a better position today? Did you know how to program 5 years ago? What about today?
Where could you be in 2, 5, or 10 years in the future, if you continue doing what you are doing? If you keep studying programming, could you become a senior developer 5 years from now?

This concept is so important to me that I’ve written down the question “How would my life be in 10 years if I stick to this?” (speaking of programming), and hung it over my monitor, together with my list of my "whys".

Finishing up

I want to remind you that this is just a guide to what I consider to be the best way to set the right mindset and attitude toward becoming a software developer.

Which one of these concepts resonated the most with you? Leave it in the comments so we can see which ones are the favourite picks!

In the next posts, I’m going to cover the concepts and techniques described in the book Ultralearning, so you may want to subscribe to my newsletter to get a notification when the video is out.

Thanks for reading, and see you next time! 👋

🗞️ NEWSLETTER - If you want to hear about my latest articles and interesting software development content, subscribe to my newsletter.

🐦 TWITTER - Follow me on Twitter.

Learning how to code: what you should know first (part 1)

Damian Demasi — Tue, 30 Aug 2022 18:50:21 +0000

Introduction

Are you thinking of learning how to code? 🤔 I think there’s something you need to know first…

This is the first post of a two-part series. In it, I’ll cover the following topics:

The importance of having a good idea of Why you want to learn how to code
How Passion is overrated
Why it’s important to have a Growth mindset
Why you shouldn’t rely on Motivation
Why focus on Systems over Goals

When starting the journey of learning programming, one tends to focus on the programming languages to learn, courses to take and books to read. But I think the most important thing is to develop an attitude and mindset that allow us to face the challenge of learning programming in the best way possible.

I discuss these concepts in my first published YouTube video! You can watch it here.

Have a clear idea of why you want to learn how to code

Knowing our why will help us to keep going when motivation fails us, and things get difficult 😰.

Ideally, your why would be internally focused, so don’t start studying programming just because you want to earn more money (something external). Programming is very hard, and doing it just for the money may not be a reason powerful enough to stick with it 💰💰💰.

Instead, try to find internal reasons why you want to study programming. For example, some of the internal reasons that work for me are:

To learn and grow personally and professionally.
To choose better quality problems and to choose a struggle to enjoy.
To build mastery at something.
To be an inspiration to others (family, friends, strangers).

Having a clear why will give meaning to the effort we are going to invest in our learning journey.

You can read more about this topic in the book Man’s Search for Meaning.

I actually have my why printed and hung on top of my monitor. I use it as a tool to lift my mood and motivation when I don’t feel like studying or when I’m stuck with a programming problem or bug. It reminds me of what I have chosen to do and the reasons behind that choice, something that’s very helpful as a reminder that I need to keep going in spite of feeling uncomfortable.

By deciding to become a programmer, I’m choosing to have better problems, because problems are going to be present no matter what we decide to do. One thing is to have problems that someone enforces on you, and a very different thing is to choose your own problems.

You can read more about choosing your own problems in the book The Subtle Art of Not Giving a F*ck.

Passion

I’ve been struggling to find my passion for most of my life. Ultimately, I’ve learned that passion is not something that you find, but something you build day by day.

You can choose an activity that sparks interest in you, but that interest will evolve into a passion over time. It’s because of this that we shouldn’t pay too much attention to passion when we are just starting with programming and give it time to build up.

Growth mindset

The Growth mindset is a concept developed by psychologist Carol Dweck. You can read more about it in her book Mindset.

The way in which we see ourselves deeply affects how we manage in life. If we perceive ourselves as someone who is not intelligent, or incapable of learning programming, we will start our learning journey on the wrong foot.

On the other hand, if we understand that intelligence is something we can develop over time, as well as most of our skills, we are going to be better prepared mentally to begin studying programming.

The growth mindset is based on the idea that our qualities can be cultivated and developed through effort.

You can have a deeper dive into this topic by reading this article.

Motivation

According to Steven Pressfield (author of The War of Art), motivation is the push we feel when “the pain of not doing something is worse than the pain of doing it”. For example, the pain of being in a job we hate is greater than the pain we feel when we must sit to study programming to change our careers, so we are pushed to sit and study how to code.

There are two types of motivation:

External: it’s outside of our control. For example, study programming to get a good salary in the future, solve a bug to receive praise from others, and prove someone’s code is wrong so others can see us as intelligent coders.
Internal: it’s in our control, within ourselves. For example: study programming to get good at it and gain mastery, solve a bug because we love our craft (our code), or solve someone’s else code because we care about delivering a good product.

We should focus on internal motivation, as it’s the only one we can control.

Furthermore, it’s very important to realise that motivation is the result of an action, not the cause of it. This means that motivation will come after we start doing the thing we need to do (but don’t feel like doing it). You can know more about this topic by reading the book Atomic Habits.

So, the key to keeping ourselves motivated is to make the thing we need to do as easy to start as possible. We can arrange a calendar with the times and places to study programming, for example, so our decision-making process can be automated.

We can follow the same ritual or habit each time we sit to study programming, thus conditioning our study activity. For example, we can choose the same place in the house, at the same time in the day, with the same music playlist, each time we sit to study.

You can have a deeper dive into this topic by reading this article.

Systems over Goals

It’s important to have a goal, a clear objective. But it’s also important not to focus too much on it. What we should do instead is to focus on the system we are going to use in order to achieve our goal.

Those who achieve a goal and those who don’t, ultimately have the same goal. So, having a goal by itself is not a guarantee to get it. Many people want to become programmers, but not all of them end up achieving that.

Focusing on our systems will help us to achieve our goals by providing discipline, reminding us why we are doing what we are doing, and avoiding procrastination.

For example, our system could look like this:

Wake up early
Take a shower so we can be more awake
Make our breakfast
Sit in front of the computer with our breakfast
Open the programming book or online course
Start to study whilst we are having breakfast, and do this for at least one hour (we are stacking habits here, as described in the book Atomic Habits)

By focusing on the process (our habits) we are working on our system every day. We are focusing on the immediate, without worrying too much about the future: all the programming languages we don’t know, or how much time is left to become a programmer. By focusing on the day-by-day tasks, we can diminish our anxiety.

If we keep applying our system, day in and day out, we are going to achieve our goal of becoming a programmer.

You can have a deeper dive into this topic by reading this article.

Finishing up…

I want to remind you that this is just a guide to what I consider to be the best way to set the right mindset and attitude toward becoming a software developer.

Which one of these concepts resonated the most with you? Leave it in the comments so we can see which ones are the favourite picks!

In the next post, I’m going to cover the rest of these concepts, so you may want to subscribe to my newsletter to get a notification when the post is out.

See you next time! 👋

🗞️ NEWSLETTER - If you want to hear about my latest articles and interesting software development content, subscribe to my newsletter.

🐦 TWITTER - Follow me on Twitter.

How to debug a React app

Damian Demasi — Mon, 02 May 2022 19:41:02 +0000

Introduction

Since I started working as a software developer, I find myself spending the majority of the day debugging a big react app. This is not the result of a poorly implemented code, but what I feel is the natural process in which I find myself involved daily:

I can debug to find the root cause of an actual bug
Or I can debug as part of the normal development process (most likely)

When hunting for actual bugs in the code, we need to focus on tools and systematic processes to analyse the code in search of what's not working and accept the fact that the person that wrote the code may not be available to answer our questions. Sometimes, though, the bug might have been introduced by ourselves 🙋‍♂️, and we can find it difficult to step in the shoes of our past selves in order to understand why we did what we did. No matter what's the case, they all have something in common: we need to use tools to help us debug the app and find what's wrong with it.

More often than not, I feel debugging is not solving a particular issue affecting a customer, but the natural process inherent to the development of software. If I want to create a feature for an existing app (or build one from scratch), I will often face code that is not working as it is supposed to 🤷‍♂️, and here is when I will pull out the "debugging arsenal" to find out what's wrong with the code in order to keep moving forward in the development process.

A special note: when a bug is introduced by ourselves

Let's apply some logic here: 🤔 if we have created a bug, then we are not in the position to be able to solve it, because if we could, we wouldn't have created it in the first place! This is why we need additional tools that can help us to step outside ourselves in the process of finding a bug, just like if we were detectives trying to solve a crime in which we are the prime suspect. We need to be methodical, go step by step, test a lot, and gather evidence. Here is where debugging tools come to our rescue.

Breakpoints and the `debugger`

When debugging a React app, I often find breakpoints to be very helpful. There are two main ways in which we can use them:

By writing the debugger statement in our source code
By clicking on a specific line of the code in the Chrome web browser (or Firefox, Edge, etc.) Developer Tools.

Using the `debugger` statement

The debugger statement invokes any available debugging functionality, such as setting a breakpoint. If no debugging functionality is available, this statement has no effect. - Source

Let's say we have a project in which we are interested in finding out what's happening in a particular section of code. In this example, I'm using the source code of my portfolio site, which you can find in this GitHub repository). I have introduced a bug, and now I will search for it using the debugger.

In this particular bug, the third animation related to the portfolio title is not working correctly, so I can write the debugger statement in that section of the code.

Once the file is saved and compiled, as soon as I reload the page and the browser parses that code, it will stop on the line that has the debugger statement on it. The browser will then display useful data in the Developer Tools pane.

We can see the value of variables at that moment by hovering over them in the source code, or in the panel located on the right, in the Scope section. Thanks to this, I can see that the value of the setIsAnimated1 function is being called with the wrong value.

Using breakpoints

Breakpoints work in a very similar way. To enable breakpoints we need to open our site in a web browser (I'm using Chrome in this case) and open the Developer Tools. Now, if we click in the Sources tab and in the tab with the file name that we are interested in debugging, we will see our source code once more, as happened in the previous method using debugger.

Note: for more information about the Developer Tools' Source tab, read this article.

Now, in order to create a breakpoint, we can click on the margin just next to the line number. These breakpoints will be listed in the panel shown on the right, in the Breakpoints section. We can now reload the page, and the loading of it will stop at the breakpoints we have set (we can click the play button to tell the browser that it should continue executing the code and, thus, loading the page).

If you want to learn more about this topic, and even set conditional breakpoints or stop the code execution when a node is removed, for example, I think you should read the Pause your code with breakpoints article.

React Developer Tools

The previous debugging tools apply not only to React apps but to any JavaScript app. But, when working with React apps in specific, we have a very useful tool: the React Developer Tools browser extension. You can find this extension by searching for it on the corresponding browser extension marketplace. For example, for Chrome, you can install it from this link.

The react Developer Tools is a set of two main tools:

the Components tool, where you can analyse the structure of the components,
and the Profiler tool, where you can see the time each component took to render and how they are updated.

The Components tab

In the Components tab, you will be able to see the component structure of the site you are analysing (left panel), as well as the props, hooks (for function components) or state (for class components) that a selected component has (right panel), together with a list of the ancestors that ended up rendering the component you have selected.

Just by the information this tool is presenting I think it's very valuable, but that's not all! You can also modify the props and hooks of the component you have selected, and this will affect the site in real-time, something that's very useful for debugging purposes. 🤯

The Profiler tab

As mentioned earlier, we can use the Profiler to record the time it took each component to be rendered. In order to do so, we need to click the Start profiling or Reload and start profiling buttons.

Once the site has been rendered, we'll need to click the Stop profiling button, and we will see a graph detailing the time each of the components took to be rendered. Instead of clicking on the Stop profiling button, we can interact with the site, clicking on buttons, menus, etc., and the profiler will record these interactions at a component level.

This is very helpful when we need to debug certain interactions with our app.

Bonus: check why a component was rendered

If we are interested in knowing why a particular component was rendered, we can activate this feature by clicking on the gear icon, then in the Profiler tab, and finally ticking the Record why each component rendered while profiling. checkbox.

Now we need to start a new profiling, just as before, and we'll be able to see extra information concerning the reasons why a component was rendered. Some of the most common reasons for a component to (re)render are, as you can see by using this tool:

the parent component was rendered
its props changed
its state-related hooks changed

I have found that recording why a component was rendered saved me many headaches when debugging a complex React app.

Workflow debugging

There are some occasions in which none of the previously mentioned tools can help us to find a bug. In this case, I like to use a "workflow debugging" approach. This method consists in start analysing the code in the closest region to where the bug is happening, and following the flow of the code "upstream": which method is creating this section of code, what's its parent, grand-parent, etc.

Let's say a header in our app has a wrong margin. We can start by analysing the code closest to this header, looking for methods that can be altering its margin, and then analysing the code that's affecting the header at higher levels, like an inverse Matryoshka doll.

Photo by Didssph on Unsplash

The debugging methodical process

In order to be consistent in how we proceed to find a bug, we can create our own process or framework by combining these tools and approaches. For example, when facing a bug we could:

Start by analysing the workflow the code is following that affects a particular section of code.
If nothing wrong is found, we could use the React Developer Tools to analyse each component closely.
If that analysis is not delivering results, we could apply breakpoints at different sections in the code and see how the variables are being altered.
If everything else fails, just comment out pieces of code and see what happens. Experiment.

Conclusion

We have many tools at our disposal to look for bugs, but it's not always easy to find them. I think it's very important not to feel frustrated when debugging an app, and to focus on a systematic, step by step process to analyse the code.

I'm sure I haven't covered all the techniques available for debugging a React app, so if you have one that's your favourite and that is not listed here, please share it in the comments so we can all learn from it. 😊

🗞️ NEWSLETTER - If you want to hear about my latest articles and interesting software development content, subscribe to my newsletter.

🐦 TWITTER - Follow me on Twitter.

Problem-solving techniques to avoid yelling at your computer

Damian Demasi — Tue, 12 Apr 2022 20:01:03 +0000

I have been facing some tough code monsters at work lately. I guess I'm out of shape and my sword isn't sharp enough, because I find myself struggling greatly.

This is the reason I decided to upgrade some of my attributes (especially intelligence and wisdom) in order to help me cope with this struggle. Luckily, I found a great loot: Think Like a Programmer, by Spraul, V. Anton.

This book explains how we should approach problems in order to solve them in a methodical manner. I have just started reading it, but I have already learned the basics of problem-solving techniques, and I wanted to share them with you.

General Problem-Solving Techniques

1. Always Have a Plan

When working on a solution to a problem, starting by typing code without a clear direction in mind is not a good idea. Sometimes I found myself typing without putting too much thought into it, just for the sake of building something fast and, if I’m "lucky", stumbling with the solution to the problem. This is an awful approach.

According to the book, we should always have a plan. In the beginning, the plan usually will consist in how we are going to find the solution to our problem.

Our plan will, most likely, require alterations along the way, and this is OK. Without a plan, we are directionless, we miss on evaluating possible scenarios and different alternatives to find a solution.

“I have always found that plans are useless, but planning is indispensable.” - General Dwight D. Eisenhower

I prefer to think about a plan as a map that allows seeing all the possible roads to a destination (or even draw new ones as they manifest along the journey).

The book emphasises that plans allow us to set intermediate goals, and achieve them. This is of extreme importance because by achieving these intermediate goals we feel we are making progress towards the solution. As we are usually going to struggle until the solution is found, feeling that we are making progress will help to cope with despair.

2. Restate the Problem

A problem that at first seems incommensurable, could be expressed in other terms, or in a different manner. At first sight, we might think the problem is one way, but upon restating it we can discover that it's something different.

Restating the problem in new, simpler or more familiar terms, could help us to redefine it and to come up with different solutions (hopefully, easier to implement than what we first thought would be).

Restating the problem could be thought of as one of the planning steps in solving a problem, and if we do restate the problem, we will be making progress towards the solution.

3. Divide the Problem

You don’t eat an elephant in one bite but in multiple small bites. Actually, I have never eaten an elephant, and I wouldn't either, as they are one of my favourite animals! But the metaphor is still applicable.

If the problem is too complex, divide it into smaller chunks. If we need to ask for user input, process the data, and store it in a database, start by building a simple input field that prints on the console, and build on top of that.

If we need to build a complex loop, we can start with one line, or a couple of lines, and manually perform the tasks that the loop should do until we have a clear idea of what is needed.

This is the technique I use the most when coding and is the one that helps me to keep my sanity when facing complex problems.

4. Start with What You Know

After dividing the problem into pieces, we can start by solving what we already know how to solve. Later we can focus on the tricky parts of it.

Does our problem require finding unique values? If we know how to use a Set in JavaScript, that could help us to solve it.

By starting with what you know, you build confidence and momentum toward the goal. - Spraul, V. Anton

5. Reduce the Problem

If the problem is too complex or if it can’t be subdivided into smaller pieces, we can reduce its complexity by applying (or removing) constraints to it.

Should a user be able to drag and drop tasks in our to-do app? Let’s write step by step all that is needed in order to implement this functionality and eliminate (for now) what’s too complex. Later we could review what we have left out and ask for help in order to solve those specific aspects of the problem (and not the whole problem).

The author of the book uses an excellent example here:

One never wants to be reduced to saying, “Here’s my program, and it doesn’t work. Why not?” Using the problem-reduction technique, one can pinpoint the help needed, saying something like, “Here’s some code I wrote. As you can see, I know how to find the distance between two three-dimensional coordinates, and I know how to check whether one distance is less than another. But I can’t seem to find a general solution for finding the pair of coordinates with the minimum distance.” - Spraul, V. Anton

6. Look for Analogies

We are often solving the same problem, but in a different flavour, over and over again.

We should pay attention to similarities between the problem we have in front of us, and other problems we solved in the past.

If the problem is totally new, that’s great, because it’s a great opportunity to put it inside our “cookie jar of solved problems” for future use.

7. Experiment

If everything looks dark and we don’t know why the program is behaving as if it had life on its own, experimenting with it can help us.

I usually use console.log as a “probing” method to find out what’s happening. We can tweak something here and there and see how the output gets modified. Then make hypotheses and put them to the test.

It is important to make a distinction between experimenting and guessing. Experimenting is a controlled process: we gather the information that can help us solve the problem. Guessing is typing code mindlessly and hoping for the best.

8. Don’t Get Frustrated

The final technique is more of a recommendation than a technique in itself: don't get frustrated.

I must confess that I had felt frustrated many times, and I can assure you that it didn’t help me one bit to solve the problem.

How does the rage you feel inside of you help you solve a problem? Why are you angry? Or a better question even: why do you choose to be angry?

Here is where two maxims of the Stoic philosophy come for our help:

“We suffer more often in imagination than in reality.” - Seneca

And:

“The chief task in life is simply this: to identify and separate matters so that I can say clearly to myself which are externals not under my control, and which have to do with the choices I actually control. Where then do I look for good and evil? Not to uncontrollable externals, but within myself to the choices that are my own…” - Epictetus, Discourses, 2.5.4–5

We have to learn to manage how we respond to frustration. As developers, it’s very likely that we are going to face bugs in our code or complicated features to implement on a daily basis, and a good portion of them are going to be difficult to solve. Hence, it’s better to learn not to feel frustrated because of this, but rather think of this as a “feature” of our job.

I often remember this question:

What shit sandwich do you want to eat? Because eventually, we all get served one. - Mark Manson

And then I realise: "I have chosen this struggle, so I shouldn't get mad because of it."

Something that can help us to get out of a frustrating moment is to iterate on these steps again: build a new plan, restate the problem differently, create different problem divisions and alterations, etc.

Practice time

Now, let’s put all these concepts into practice. I have adapted one of the problems presented in the book from C++ to JavaScript for convenience purposes.

By the way, you can get the source code from my repository (I plan on keep adding new problems as I move forward in reading the book): think-like-a-programmer-book-problems.

Write a program that uses a single console.log statement to produce a pattern of hash symbols shaped like half of a perfect 5 x 5 square (or a right triangle):

#####
####
###
##
#

Spraul, V. Anton. Think Like a Programmer (p. 26). Adapted from C++ to JavaScript by Damian Demasi.

The plan

We are going to take the problem, divide it into smaller pieces, and start solving the pieces one by one. We are going to search for analogies along the way. In the end, we will put everything together.

Restating the problem

After analysing the problem a bit deeper, we can see that there is a pattern that needs to be printed and that this pattern gets altered on each line. I don’t know about you, but this is suggesting “iteration” to me, so we will use some sort of loop to solve it.

Our restatement could be something like: “write a loop that prints a line of hash symbols where each line gets one less hash symbol that the previous one, starting with 5 symbols on the first line.”

Divide the problem

We can divide this problem like this:

Print a line of 5 hash symbols
Print 5 lines of 5 hash symbols
Find a way to decrease a number as a count grows
Apply point 3 to point 2

Start with What You Know

Let’s start by the easy part: print 5 hashes:

    let halfSquare = '';
    for (let i = 1; i <= 5; i++) {
        halfSquare += '#';
    }
    console.log(halfSquare);

Output:

#####

Great! It’s not much, but it’s honest work 😅.

Reduce the Problem

Now, instead of printing five lines with a decreasing number of hashes, let's print 5 lines with the same number of hashes. By doing this we are simplifying the problem and reducing its complexity and constraints.

let halfSquare = '';
    for (let i = 1; i <= 5; i++) {
        for (let j = 1; j <= 5; j++) {
            halfSquare += '#';
        }
        halfSquare += '\n';
    }
    console.log(halfSquare);

Output:

#####
#####
#####
#####
#####

Look for Analogies

In the previous block of code, we are using something we already know (a loop) to repeat the line of hashes 5 times, resulting in a nested for loop. This is our analogy.

Experiment

Now we need to find a way to decrease a value as the loop increases. In the book, this is referenced as “counting down by counting up”.

Let’s experiment to find this behaviour starting with the easier part: counting up.

for (let i = 1; i <= 5; i++) {
    console.log(i);
}

Output:

After looking at the expected end result (the triangle of hashes) and comparing it with our experiment, we can think of these numbers as the number of hashes that need to be subtracted on each line plus 1:

Line	Result
First line:	5 hashes - 1 + 1 = 5 hashes
Second line:	5 hashes - 2 + 1 = 4 hashes
Third line:	5 hashes - 3 + 1 = 3 hashes
Fourth line:	5 hashes - 4 + 1 = 2 hashes
Fifth line:	5 hashes - 5 + 1 = 1 hash

If we use 6 hashes, we can get rid of the “+ 1” part:

Line	Result
First line:	6 hashes - 1 = 5 hashes
Second line:	6 hashes - 2 = 4 hashes
Third line:	6 hashes - 3 = 3 hashes
Fourth line:	6 hashes - 4 = 2 hashes
Fifth line:	6 hashes - 5 = 1 hash

So, as 6 looks like an important number for our purposes, and as the subtracted number looks like the for loop iterating as a new line gets printed, let’s see what happens when we subtract the current iteration number from 6:

for (let i = 1; i <= 5; i++) {
    console.log(6 - i);
}

Output:

This is starting to look good!

So, as the first line will need to have 5 hashes, the iteration should go from 1 to 6 - 1 = 5.

let hashLine = '';
for (let i = 1; i <= 6 - 1; i++) {
    hashLine += '#';
}
console.log(hashLine);

Output:

#####

Moving to the next line, to build it our loop will need to change the i <= 6 - 1 condition to i <= 6 - 2 condition. This pattern is pointing to a loop incrementing a value on each iteration, and we already have that loop: it’s the outer for loop.

When combining these findings with what we already have we can arrive to the conclusion of our problem:

let halfSquare = '';
for (let i = 1; i <= 5; i++) {
    for (let j = 1; j <= 6 - i; j++) {
        halfSquare += '#';
    }
    halfSquare += '\n';
}
console.log(halfSquare);

Output:

#####
####
###
##
#

And this is the fruit of the struggle, the thinking and the experimenting.

Closing thoughts

Applying all these techniques at once is not easy for me. I discovered that I have “my way” of solving problems, but it’s often not the most suitable way of doing so. As with most new habits, implementing a particular process comes with a certain resistance. This is why I’m taking the approach of implementing these problem-solving techniques one step at a time (and I’ve noticed that I’m going full-on "inception" here, using the division of a problem into smaller pieces as a technique to implement the problem-solving techniques 🤯).

Notion templates, trackers and roadmaps

🙋‍♂️ Psst! Before you go, I have something to share with you. If you are a subscriber of my newsletter, you already know this, but in case you are not, I would like to share with you these 3 free resources:

👍 My Notion template with over 440 pages of web development content, so you can use Notion to organise programming topics.

👍 My HTML Study Progress Tracker and Roadmap Notion Template, so you can keep track of your progress in learning HTML concepts (and review them).

👍 And my CSS Study Progress Tracker and Roadmap Notion Template, to to the same as before but with CSS.

They are totally free for download and use, but I'm always open to donations (I need to buy coffee to transform it into code 😅).

🗞️ NEWSLETTER - If you want to hear about my latest articles and interesting software development content, subscribe to my newsletter.

🐦 TWITTER - Follow me on Twitter.

DEV Community: Damian Demasi

Claude Code Crash Course

Start here. Claude Code needs memory, structure, and reach

CLAUDE.md and rules. The behavioural layer

Skills. The reusable playbook layer

Hooks. The enforcement layer

Subagents. The isolation layer

MCP servers. The reach layer

How these parts fit together in practice

Best practices that actually matter

Closing thoughts

InboxGuilt and the Tone Dial Feature

The Power of Microtools: How AI and "Vibe Coding" Are Changing the Way We Build

What is "Vibe Coding"?

Why Now?

The Shift: From Platforms to Personal Systems

How I Replaced Notion with a Custom Tool Built Using v0

But Don’t Get It Twisted: Knowledge Still Matters

Don’t Ship Vibes to Production

Final Thoughts

How to Learn Python Faster and Easier with This Notion Template

Python Notes Template

Topics

Topic by Area

Study Progress

Topics Table

Advanced Template

Why Questions?

Spaced Repetition

Interleaved Learning

Python Notes and Questions Template

Python Questions Template User Guide

One more thing

Closing thoughts

Python Project: Analysing Australia's Migration Trends and Economic Impact

Python for Everybody Capstone Project

Picking the Data Source

Building a Data Fetching Script

Building a Data Normalization Script

Data Analysis

Data Visualisation

Key Takeaways

Navigating Mutability and Reference Issues in JavaScript

Mutability

Primitive values are immutable

Objects are mutable

The reference confusion in objects

References

Learning how to code: with our special guest, Ron

Drills: Attack Your Weakest Point

Tactic 1: Components

Tactic 2: Copycat

Tactic 3: The Programming Dojo

Retrieval: Test to Learn

Tactic 1: Free recall

Tactic 2: The question-book method

Tactic 3: Self-generated challenges

Feedback: Don't Dodge the Punches

Tactic 1: Noise cancellation

Tactic 2: Hitting the difficulty sweet spot

Tactic 3: Metafeedback

Closing thoughts

Learning how to code: the first 3 steps

Metalearning

“Why?”

“What?”

“How?”

Method 1: Benchmarking

Method 2: Emphasise and exclude

Focus

Procrastination

Distraction

Directness

Tactic 1: Project-based learning

Tactic 2: Immersive learning

Tactic 3: the overkill approach

Closing thoughts

Learning how to code: what you should know first (part 2)

Grit

Habits

`CLAUDE.md` and rules. The behavioural layer

Breakpoints and the `debugger`

Using the `debugger` statement