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:

1. CLAUDE.md and rules shape behavior.

2. Skills package reusable know how.

3. Hooks enforce automatic actions.

4. Subagents isolate work.

5. 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 behavior. 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 emphasizes 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?

Photos by Alain Pham, Calle Macarone, Tatiana Rodriguez, Yuriy Vertikov, Toa Heftiba, Jason Leung on Unsplash

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.

TypeScript is a statically typed superset of JavaScript, developed and maintained by Microsoft. It’s called a "superset" of JavaScript because it extends the capabilities of JavaScript by adding additional features while maintaining compatibility with existing JavaScript code. This means that any valid JavaScript code is also valid TypeScript code.

TypeScript extends JavaScript by adding type annotations, which provide static type checking at compile time. TypeScript code is written in .ts files and, before it can be run in the browser or on a server, it’s transpiled into standard JavaScript using tools like the TypeScript compiler (tsc).

There are some key features of TypeScript that are worth highlighting.

Key Features of TypeScript

1. Static Typing: TypeScript allows us to define the types of variables, function parameters, return values, and object properties. This helps catch type-related errors during development, rather than at runtime.

2. Type Inference: TypeScript can infer types based on the values you assign, so we don’t always need to explicitly declare types.

3. Modern JavaScript Features: TypeScript supports all modern JavaScript features, including ES6+ features, and compiles them down to JavaScript versions that are compatible with older environments if needed.

4. Interfaces and Generics: TypeScript introduces interfaces and generics, which allow for more flexible and reusable code by enabling complex type definitions and contracts.

5. Tooling and IDE Support: TypeScript provides excellent tooling support. Most modern IDEs, like Visual Studio Code, provide features like autocompletion, type checking, and inline documentation, which make development more efficient.

6. Optional Static Typing: While TypeScript encourages static typing, it’s optional. We can gradually introduce types into a JavaScript codebase, making the transition to TypeScript more manageable.

All these features sound good, but why should we use TypeScript? There are several compelling reasons why TypeScript has become increasingly popular among developers and why it can be a valuable addition to our development toolkit.

Why Should We Use TypeScript?

1. Improved Code Quality:

   • Early Error Detection: By catching errors at compile time rather than at runtime, TypeScript helps prevent common bugs, such as typos, type mismatches, and incorrect function signatures.

   • Better Documentation: Type annotations serve as self-documenting code, making it easier for developers to understand what a function or variable is expected to do without needing to refer to external documentation.

2. Enhanced Developer Experience:

   • Intelligent Code Completion: TypeScript provides better autocompletion and IntelliSense in IDEs, which can speed up development and reduce errors.

   • Refactoring Support: TypeScript’s static type system makes it easier and safer to refactor code. The TypeScript compiler can highlight potential issues when renaming variables, moving functions, or restructuring your codebase.

3. Scalability:

   • Large-Scale Applications: For large projects, TypeScript’s type system can help manage and understand complex codebases, making it easier to maintain and scale applications.

   • Collaboration: In teams, TypeScript can enforce consistency and clarity, making it easier for multiple developers to work on the same codebase.

4. Compatibility with JavaScript:

   • Gradual Adoption: We can start using TypeScript incrementally in existing JavaScript projects. TypeScript files can coexist with JavaScript files, allowing teams to adopt it at their own pace.

   • Interoperability: TypeScript is fully compatible with existing JavaScript libraries and frameworks. We can use JavaScript libraries in TypeScript projects and even write TypeScript declarations for them.

5. Popular Framework Support:

   • React, Angular, Vue: TypeScript is widely used in modern frontend frameworks and libraries. Angular, for instance, is built with TypeScript, and React and Vue have strong TypeScript support, making it easier to use TypeScript in our frontend projects.

Now that we now a little bit abut TypeScript features and the reasons why we should use it in our projects, lets take a look at how TypeScript code actually looks like.

Basic TypeScript Example

Let's say we have a function that takes two numbers as input, adds them together, and returns the result. In JavaScript, this might look like:

function add(a, b) {
  return a + b;
}

const result = add(5, 10);
console.log(result); // 15

This works, but there's no type checking. We could accidentally pass non-number values, leading to unexpected results.

Now let’s take a look how this example looks like when using TypeScript.

The Same Example in TypeScript

function add(a: number, b: number): number {
  return a + b;
}

const result = add(5, 10);
console.log(result); // 15

// TypeScript will catch this error if we try to pass non-number arguments:
// const wrongResult = add(5, "10"); // Error: Argument of type 'string' is not assignable to parameter of type 'number'.

In the previous code snippet we can see TypeScript in action:

• Type Annotations:

  • The a: number and b: number annotations specify that a and b must be numbers.

  • The : number after the function parameters indicates that the function returns a number.

• Error Prevention:

  • If we try to call add(5, "10") with a string instead of a number, TypeScript will throw an error during development, preventing potential bugs.

In this example we can see a couple of benefits introduced by TypeScript:

1. Type Safety: The function guarantees that it only works with numbers, reducing the chance of runtime errors.

2. Documentation: The type annotations act as a form of documentation, making it clear what types of arguments the function expects and what it returns.

3. Better Tooling: When using an IDE like Visual Studio Code, TypeScript provides autocompletion and inline type checking, which helps prevent mistakes.

Install and Run TypeScript

Enough with the theory. Let’s get our hands dirty.

In order to install TypeScript, we could follow the indications in the official documentation, and run:

npm install typescript --save-dev

If we are using VSCode, these extensions will improve the overall use of TypeScript in our development environment:

• Name: JavaScript and TypeScript Nightly Description: Enables typescript@next to power VS Code's built-in JavaScript and TypeScript support

• Name: Pretty TypeScript Errors Description: Make TypeScript errors prettier and more human-readable in VSCode

Running the TypeScript Compiler

In order to compile our TypeScript files into JavaScript files that the browser can understand, we need to run:

npx tsc --init # <- run this the first time to generate a tsconfig.json file

npx tsc # <- run this to compile the project

# or

npx tsc <file_name>

Here’s an example of errors in our code being picked up by TypeScript:

After running the npx tsc command, a JavaScript file will be generated as a result of the compilation process.

Fundamental Types

Now let’s go back to the theory so we can learn TypeScript fundamental types.

1. The any Type

The any type can represent any JavaScript value. It's a "catch-all" type that disables type checking for that variable and the default type when we don’t specify a type explicitly.

It's recommended to avoid any because it defeats the purpose of using TypeScript for type safety.

let myVar: any; // <- the 'any' keyword can be ommited
myVar = 42;
myVar = "text";

2. Primitive Types

string: Represents textual data.

let userName: string = "Damian";

number: Represents numeric data, including integers and floating-point numbers.

let age: number = 30;

boolean: Represents true or false.

let isActive: boolean = true;

null and undefined: Represent the absence of a value.

let emptyValue: null = null;
let notAssigned: undefined = undefined;

3. Array Types

Arrays can be defined with a specific type for their elements.

The type is defined as type[].

let hobbies: string[] = ["photography", "hiking"];
let lottoNumbers: number[] = [1, 2, 3];

4. Object Types

Objects can be typed by specifying the types of their properties.

Define object types using { property: type; }.

let person: {
  name: string;
  age: number;
} = {
  name: "Damian",
  age: 21 // I wish...
};

5. Union Types

Union types allow a variable to hold multiple types.

Use the pipe (|) to combine types.

let id: number | string;
id = 42; // valid
id = "42"; // also valid

6. Tuple Types

Tuples allow you to express an array with a fixed number of elements, each with a specific type.

Define using [type1, type2, ...].

let address: [string, number];
address = ["Main Street", 123];

7. Enum Types

Enums allow us to define a set of named constants.

Useful for representing a fixed set of related values.

enum Color {
  Red,
  Green,
  Blue
}
let favoriteColor: Color = Color.Green;

8. Function Types

You can define the types for the parameters and return value of a function.

This helps ensure functions are called with the correct arguments.

// Regular function definition
function add(a: number, b: number): number {
  return a + b;
}

// Arrow function definition
const add: (a: number, b: number) => number = (a, b) => {
  return a + b;
}

9. Void Type

Used when a function does not return a value.

function logMessage(message: string): void {
  console.log(message);
}

10. Type Aliases

Allows us to create custom types using the type keyword. By convention, type aliases names start with a capital letter.

This simplifies complex type definitions.

type Person = {
  name: string;
  age: number;
};

let person1: Person = { name: "Harry", age: 35 };
let person2: Person = { name: "Ron", age: 34 };

Type Inference

Let’s now move on to a TypeScript characteristic that could make our lives easier when working with types.

Type inference in TypeScript is a feature where the compiler automatically infers the types of variables, functions, and other expressions based on the values or context in which they are used, without the need for explicit type annotations.

If we initialize a variable when we declare it, TypeScript infers its type based on the assigned value.

let age = 30; // TypeScript infers that 'age' is of type 'number'
age = "thirty"; // Error: Type '"thirty"' is not assignable to type 'number'

For functions, TypeScript infers the return type based on the function's return statements.

function add(a: number, b: number) {
  return a + b; // TypeScript infers the return type as 'number'
}

const result = add(5, 10); // 'result' is inferred to be of type 'number'

If we create an array and initialize it with values, TypeScript infers the type of the array elements.

let names = ["Alice", "Bob", "Charlie"]; // TypeScript infers 'string[]' as the type
names.push(42); // Error: Argument of type 'number' is not assignable to parameter of type 'string'

Benefits of Type Inference

Type inference has some nice benefits:

• Less Boilerplate: We can write less code because we don't have to explicitly annotate types in many cases.

• Readability: It makes the code cleaner and easier to read since the types are automatically inferred from the context.

• Type Safety: Even though types aren't explicitly annotated, we still get the benefits of TypeScript's type checking.

When to Rely on Inference

We shouldn’t always rely on type inference, but there are some situations when depending on type inference can be a good idea: simple cases like variables, function return types, and straightforward data structures.

For more complex scenarios or when the inferred type might be unclear, it's better to use explicit annotations to make the code's intention clear.

Type Inference Example

Here's a practical example of type inference:

let greeting = "Hello, world!"; // TypeScript infers the type as 'string'

function multiply(a: number, b: number) {
  return a * b; // TypeScript infers the return type as 'number'
}

const result = multiply(5, 10); // 'result' is inferred to be of type 'number'

let numbers = [1, 2, 3]; // TypeScript infers the type as 'number[]'
numbers.push(4); // This is fine
// numbers.push("five"); // Error: Argument of type 'string' is not assignable to parameter of type 'number'

In this example, even though we didn't explicitly define the types for greeting, result, and numbers, TypeScript automatically inferred the correct types based on the context.

Interfaces and Type Aliases

In TypeScript, interfaces and type aliases are both tools that allow us to define custom types. They help us describe the shape of objects, specify the types of data structures, and enforce a consistent structure across our code. Although they have similar purposes, there are some differences in their syntax, capabilities, and best-use scenarios. Let's break down what each one is and how to use them effectively.

Interfaces

An interface is a way to define a contract for the shape of an object. Interfaces are primarily used to describe the structure of objects, including their properties and methods. They can also be extended or implemented, which makes them very useful for object-oriented programming and large-scale applications.

Here's a basic example of how to define and use an interface in TypeScript:

interface User {
  name: string;
  age: number;
  isAdmin: boolean;
}

const user: User = {
  name: "Alice",
  age: 30,
  isAdmin: true,
};

In this example User is an interface that describes an object with three properties: name, age, and isAdmin. The user variable is then defined to adhere to the User interface, ensuring it has all the required properties with the correct types.

Extending Interfaces

One powerful feature of interfaces is that they can be extended, allowing us to build upon existing types:

interface Person {
  name: string;
  age: number;
}

interface Employee extends Person {
  employeeId: number;
}

const employee: Employee = {
  name: "Bob",
  age: 25,
  employeeId: 12345,
};

Here, Employee extends Person, meaning it inherits the properties of Person and adds its own (employeeId).

Optional Properties and Read-Only Properties

Interfaces can define optional properties and read-only properties:

interface Car {
  brand: string;
  model: string;
  year?: number; // Optional property
  readonly vin: string; // Read-only property
}

const myCar: Car = {
  brand: "Toyota",
  model: "Corolla",
  vin: "1234567890",
};

// myCar.vin = "0987654321"; // Error: Cannot assign to 'vin' because it is a read-only property.

In this example, year? indicates that year is an optional property and readonly vin means that the vin property cannot be modified once it is set.

Type Aliases

A type alias is another way to define a type in TypeScript. It can describe objects, primitive types, union types, intersections, and even function signatures. Type aliases are more flexible than interfaces because they can represent more than just the shape of an object.

Defining a Type Alias

Here's how to define a type alias:

type Point = {
  x: number;
  y: number;
};

const point: Point = {
  x: 10,
  y: 20,
};

In this example, Point is a type alias that defines an object with two properties: x and y.

Type Aliases for Primitive Types and Unions

Type aliases are not limited to objects; they can also be used to create unions, intersections, and custom types:

type ID = string | number;

let userId: ID;
userId = "abc123";
userId = 456;

type Result = "success" | "failure" | "pending";

const taskStatus: Result = "success";

In the above example, ID is a type alias that can be either a string or a number. Result is a type alias that can only be one of the three specified string literals.

Type Aliases for Function Types

We can also use type aliases to define function signatures:

type Greet = (name: string) => string;

const greetUser: Greet = (name) => {
  return `Hello, ${name}!`;
};

console.log(greetUser("Alice")); // Output: Hello, Alice!

This feature will become one of the most used ones when working with TypeScript in a React project.

Interfaces vs. Type Aliases

While both interfaces and type aliases can be used to describe the shape of objects, there are some key differences:

• Use Cases:

  • Interfaces are generally preferred for defining the structure of objects, especially when those objects are meant to be extended or implemented by classes.

  • Type aliases are more versatile, as they can describe objects, unions, intersections, and primitives. They are often used for complex types or when using union and intersection types.

• Extensibility:

  • Interfaces can be extended using the extends keyword, which is useful in many object-oriented programming scenarios.

  • Type aliases cannot be extended in the same way, but they can combine types using intersections (&).

• Merging:

  • Interfaces can be merged across multiple declarations. This is particularly useful when working with third-party libraries where you might want to extend existing interfaces.

  • Type aliases cannot be merged.

• Syntax:

  • The syntax for interfaces is more concise when defining object shapes, while type aliases offer more flexibility in representing different kinds of types.

• Open vs Close:

  • One major difference between type aliases vs interfaces are that interfaces are open and type aliases are closed. This means we can extend an interface by declaring it a second time:

      interface Kitten {
        purrs: boolean;
      }
    
      interface Kitten {
        colour: string;
      }
    

    But we can’t extend type aliases in the same way:

      type Puppy = {
        color: string;
      };
    
      type Puppy = { // it throws an error
        toys: number;
      };
    

When to Use Which?

We should use interfaces when defining the shape of objects and when we expect to use inheritance or class-based implementations.

We should use type aliases when we need to define more complex types like unions, intersections, or when you need the flexibility to define different kinds of types beyond just objects.

Generics

Generics in TypeScript are a powerful feature that allows us to create reusable and flexible components, functions, or types that can work with a variety of data types while maintaining type safety. They enable us to write code that is more abstract and can handle different types without losing the benefits of TypeScript's type-checking.

Generics is one of the key TypeScript features we’ll be using in our React projects.

Without generics, we might have to write multiple versions of the same function or component for different data types. Generics let us write a single version that works for any type, which makes our code more reusable and maintainable.

Basic Syntax of Generics

A generic type is defined using a type parameter, which is usually denoted by a single capital letter like T (short for "Type"). The type parameter is specified in angle brackets (<T>) and can be used in the function, class, or type alias.

Example: Generic Function 1

Let’s take a look at an example of a generic:

function identity<T>(value: T): T {
  return value;
}

const result1 = identity<string>("Hello, world!"); // result1 is of type 'string'
const result2 = identity<number>(42); // result2 is of type 'number'

In this example, the identity function takes a type parameter T. When you call the function, you can specify the type explicitly (e.g., identity<string>("Hello, world!")), or TypeScript can infer it automatically.

Example: Generic Function 2

Here's another simple example of a generic function:

function insertAtBeginning<T>(array: T[], value: T) {
  const newArray = [value, ...array];
  return newArray;
}

const demoArray = [1, 2, 3];

const numberArray = insertAtBeginning(demoArray, -1);
// Equivalent to: function insertAtBeginning<number>(array: number[], value: number): number[]

const stringArray = insertAtBeginning(["a", "b", "c"], "z");
// Equivalent to: function insertAtBeginning<string>(array: string[], value: string): string[]

const wrongStringArray = insertAtBeginning(["a", "b", "c"], 42);
// Error: Argument of type 'number' is not assignable to parameter of type 'string'.typescript(2345)

In this example, the insertAtBeginning function takes a type parameter T and two function parameters: the first one will be an array containing all the elements of the same type T, and the second one will be a single value of the same type T. When we call the function, TypeScript can infer all the types automatically.

If we try to pass two different types to the function, as in the wrongStringArray case, it will fail.

Example: Generic Classes

Generics can also be used with classes:

class Box<T> {
  content: T;

  constructor(content: T) {
    this.content = content;
  }

  getContent(): T {
    return this.content;
  }
}

const stringBox = new Box<string>("A string");
console.log(stringBox.getContent()); // "A string"

const numberBox = new Box<number>(123);
console.log(numberBox.getContent()); // 123

The Box class is generic, meaning it can hold any type of content. The type parameter T is used in the property content, the constructor parameter, and the return type of the getContent method. We can create instances of Box with different types, such as string or number.

💡 Note: When we define an array type, we normally do this:

let numbersArray: number[] = [1, 2, 3]

But the number[] notation is syntactic sugar. What we are actually using is:

let numbersArray: Array<number> = [1, 2, 3]

So, we are actually using generics here. There’s an Array generic class that receives a parameter of type number and returns an array of numbers.

Example: Generic Interfaces

Generics can also be used with interfaces:

interface Pair<T, U> {
  first: T;
  second: U;
}

const stringNumberPair: Pair<string, number> = {
  first: "one",
  second: 1,
};

const booleanArrayPair: Pair<boolean, boolean[]> = {
  first: true,
  second: [true, false, true],
};

The Pair interface takes two type parameters, T and U, which represent the types of the first and second properties, respectively. This allows us to create pairs of different types, like string and number or boolean and boolean[].

Example: Generic Constraints

We can also add constraints to generics to ensure that the types used meet certain requirements. For example:

function getLength<T extends { length: number }>(item: T): number {
  return item.length;
}

console.log(getLength("Hello")); // 5
console.log(getLength([1, 2, 3, 4])); // 4
// console.log(getLength(42)); // Error: Argument of type 'number' is not assignable to parameter of type '{ length: number; }'

The getLength function is generic, but it requires that the type T has a length property. This constraint is defined using T extends { length: number }. This ensures that we can only call getLength with types that have a length property, such as strings or arrays.

Setting Up a React Project with TypeScript

Let’s now finally start applying what we have learned about TypeScript in a React project.

In order to work with TypeScript in a React project, we need to configure our building tool (Vite, Create React App, etc.) to support TypeScript.

If we are working with Vite, we can implement TypeScript in our React project like so:

❯ npm create vite@latest  

Need to install the following packages:
create-vite@5.5.1
Ok to proceed? (y) 
✔ Project name: … react-ts
✔ Select a framework: › React
✔ Select a variant: › TypeScript

Scaffolding project in /Users/damian/Programming/Workspaces/react-the-complete-guide-course-code/30-typescript-foundations/react-ts...

Done. Now run:

  cd react-ts
  npm install
  npm run dev

❯ cd react-ts

❯ npm install

added 195 packages, and audited 196 packages in 39s

42 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

❯ npm run dev

> react-ts@0.0.0 dev
> vite

  VITE v5.4.0  ready in 1738 ms

  ➜  Local:   <http://localhost:5173/>
  ➜  Network: use --host to expose
  ➜  press h + enter to show help

By selecting the Select a variant: › TypeScript our project will now have files with tsx extension instead of jsx, indicating those are TypeScript files. Vite will take care of transpiling TypeScript into JavaScript during the build process.

Function Components with TypeScript

In React, a function component is a JavaScript function that returns JSX (a syntax extension that looks like HTML, used to describe the UI structure).

Let’s take a look at an example without TypeScript:

function Todos(props) {
  return <ul>{
    props.items.map(
      item => <li key={item}>{item}</li>
    )
  }</ul>;
}

When working with React function components, we can explicitly define the types for the props that our component will receive.

TypeScript enhances this function component by adding static type checking. This allows us to catch errors at compile-time rather than at runtime, making our code safer and easier to maintain.

import React from 'react';

const Todos: React.FC<{ items: string[] }> = (props) => {
  return (
    <ul>
      {props.items.map((item) => (
        <li key={item}>{item}</li>
      ))}
    </ul>
  );
};

export default Todos;

Let’s try to understand what’s going on here.

1. React.FC (or React.FunctionComponent):

   • React.FC is a generic type provided by React that stands for "Function Component."

   • It is a type definition that ensures our function component adheres to the standard React function component structure.

   • By using React.FC, we automatically get the children prop included, which is often useful when we want to allow other components or elements to be nested inside our component.

2. Defining Props:

   • In the example, { items: string[] } is the type definition for the props that the Todos component will receive.

   • This definition means that the items prop is required and must be an array of strings.

   • If we want to make a prop optional, we can add a question mark (?) after the prop name, like { items?: string[] }.

3. Using Props:

   • Inside the function component, we can access the props via the props object.

   • In this case, props.items is used to map over the array and render each item as a list item (<li>).

   • The key attribute in the list item is important for React's reconciliation process when rendering lists. This has nothing to do with TypeScript.

4. Exporting the Component:

   • Finally, the component is exported using export default Todos;, making it available for import and use in other parts of our application.

Key Benefits of Using TypeScript with React Function Components

These are the key benefits we get when using TypeScript in a function component (React.FC):

• Type Safety: By defining the types of props, we ensure that our component only receives the expected types, reducing runtime errors.

• Documentation: The types serve as self-documentation, making it easier to understand what a component expects.

• Code Completion: TypeScript provides better code completion and IDE support, helping us write code more efficiently.

• Optional Props: TypeScript makes it easy to handle optional props and provide default values if needed.

Working with Forms and Refs

Let’s now discuss how wee can work with forms and refs in a TypeScript-based React component with this ecample:

import { useRef } from "react";

const NewTodo = () => {
  const todoTextInput = useRef<HTMLInputElement>(null);

  const submitHandler = (event: React.FormEvent) => {
    event.preventDefault();

    // const enteredText = todoTextInput.current?.value
    const enteredText = todoTextInput.current!.value;

    if (enteredText.trim().length === 0) {
      // Throw error
      return;
    }
  };

  return (
    <form onSubmit={submitHandler}>
      <label htmlFor="todo">Todo text</label>
      <input type="text" name="" id="todo" ref={todoTextInput} />
      <button>Add ToDo</button>
    </form>
  );
};

export default NewTodo;

💡 Note: Some of the code used in this article has been created as part of my notes wilst taking the Udemy course React - The Complete Guide 2024 (incl. Next.js, Redux), so expect certain similarities with the code shown in that course.

This code is a TypeScript-based React component that demonstrates several important TypeScript and React concepts. Let's break down and explain each of these concepts:

• const todoTextInput = useRef<HTMLInputElement>(null);

  • useRef with TypeScript:

    • Here, useRef is used to create a reference to an HTML input element. The type parameter <HTMLInputElement> is passed to specify the type of DOM element that todoTextInput will reference.

    • Type Parameter <HTMLInputElement>:

      • TypeScript uses this to enforce that the ref object will be tied to an HTMLInputElement, ensuring type safety. For example, todoTextInput.current will be inferred to be of type HTMLInputElement | null.

      • 

    • Initial Value null:

      • The initial value of todoTextInput is null, indicating that the ref is not yet pointing to any DOM element when the component first renders. This is common when using refs to access elements that will be rendered later.

• const submitHandler = (event: React.FormEvent) => {}

  • Event Handling in TypeScript:

    • This line defines a submitHandler function that is triggered when the form is submitted.

    • Type Annotation React.FormEvent:

      • The event parameter is explicitly typed as React.FormEvent, which is a type provided by React for form events. This ensures that event has the properties and methods available for form events, such as preventDefault().

• const enteredText = todoTextInput.current!.value;

  • Non-Null Assertion Operator (!):

    • todoTextInput.current! is using the non-null assertion operator (!), which tells TypeScript that we are certain current is not null at this point in the code.

    • This operator is useful when we are sure that a value is non-null or non-undefined, but TypeScript’s type system isn't aware of it. However, it should be used with caution as it can bypass TypeScript’s safety checks.

    • If we don’t know if the element is going to be null or have a value, we can use the optional chaining operator ? operator instead.

  • Accessing DOM Element Value:

    • todoTextInput.current!.value accesses the value property of the input element, which contains the text entered by the user.

Working with Functions as Props

When working with functions as props in React TypeScript, it’s important to define the types of the props, including the functions.

When passing a function as a prop, we need to define its type signature in the props interface. This includes specifying the function's parameters and return type.

For example, if we have a function (onClick) that takes a string as a parameter (message) and returns nothing (void), we can define it like this:

type MyComponentProps = {
  onClick: (message: string) => void;
};

Remember that, if the function returns a value, we specify the return type instead of void.

Let’s say we now have a Button component that accepts a click handler function:

import React from 'react';

type ButtonProps = {
  onClick: (message: string) => void;
};

const Button: React.FC<ButtonProps> = ({ onClick }) => {
  return (
    <button onClick={() => onClick('Button clicked!')}>
      Click Me
    </button>
  );
};

export default Button;

In this example, the onClick function prop takes a string argument and returns void. When the button is clicked, the onClick function is invoked with the message "Button clicked!".

When we use this Button component, we need to pass a function that matches the expected signature:

import React from 'react';
import Button from './Button';

const App: React.FC = () => {
  const handleClick = (message: string) => {
    console.log(message);
  };

  return (
    <div>
      <Button onClick={handleClick} />
    </div>
  );
};

export default App;

Here, handleClick is passed as a prop to the Button component. Since handleClick matches the expected function signature, TypeScript ensures type safety.

Handling Optional Function Props

If a function prop is optional, we can add a question mark (?) to make it optional in the type definition:

type ButtonProps = {
  onClick?: (message: string) => void;
};

In the component, you would then check if the function exists before calling it:

const Button: React.FC<ButtonProps> = ({ onClick }) => {
  return (
    <button onClick={() => onClick?.('Button clicked!')}>
      Click Me
    </button>
  );
};

This ensures that onClick is only invoked if it has been provided.

Example with Multiple Function Props

If our component requires multiple functions as props, we can define them all in the props type:

type ModalProps = {
  onClose: () => void;
  onConfirm: (confirmed: boolean) => void;
};

const Modal: React.FC<ModalProps> = ({ onClose, onConfirm }) => {
  return (
    <div>
      <button onClick={() => onConfirm(true)}>Confirm</button>
      <button onClick={onClose}>Close</button>
    </div>
  );
};

In this example, Modal accepts two functions: onClose, which takes no parameters and returns void, and onConfirm, which takes a boolean and returns void.

By carefully typing function props, we enhance the maintainability and reliability of our React components, catching potential errors early during development.

Working with State

When working with state in React using TypeScript, we can leverage TypeScript's type system to ensure that our state is well-defined and type-safe.

Defining the State Type

First, we need to define the type of data that our state will hold. Depending on the complexity of our state, this could be a primitive type (like a string or number), an array, an object, or even a more complex structure like a union type.

For example, if our state is a simple string:

const [todo, setTodo] = useState<string>("");

If our state is an array of objects:

type Todo = {
  id: string;
  text: string;
  completed: boolean;
};

const [todos, setTodos] = useState<Todo[]>([]);

Using useState with Type Inference

TypeScript often infers the type based on the initial state value. For instance:

const [count, setCount] = useState(0); // TypeScript infers count is a number

However, if our state starts with null or an empty array, TypeScript may infer it as null or never[], which isn't always what we want. In such cases, we should explicitly provide the type.

Handling Complex State

For more complex state shapes, like objects or arrays, we might want to define a specific type for the state:

type FormState = {
  name: string;
  email: string;
  age: number;
};

const [formState, setFormState] = useState<FormState>({
  name: "",
  email: "",
  age: 0,
});

In this example, we ensure that formState has a well-defined shape, and any updates to it must conform to this structure.

Optional State and Union Types

Sometimes our state might be optional or can hold different types. We can use union types or null to represent such cases:

type User = {
  id: string;
  name: string;
};

const [user, setUser] = useState<User | null>(null);

In this example, user can either be a User object or null. This is useful when dealing with data that might not be immediately available, like user data fetched from an API.

Handling State Changes with Type Safety

Using TypeScript, we can ensure that our state updates are type-safe. This prevents common mistakes like trying to update the state with an incompatible type.

For example, trying to update the formState with an incompatible type would result in a TypeScript error:

type FormState = {
  name: string;
  email: string;
  age: number;
};

const [formState, setFormState] = useState<FormState>({
  name: "",
  email: "",
  age: 0,
});

setFormState({ name: "New Name", email: "new@example.com" }); // Error: age is missing

Working with Context

Using React's Context API with TypeScript allows us to define the types of data that the context will hold and ensures type safety across our components. Let’s see next how we can effectively use Context in React with TypeScript.

Creating a Context with TypeScript

When creating a context, we first define the type for the context value. For example, let's say we are working with a theme context:

// Step 1: Define the type for the context value
type ThemeContextType = {
  theme: string;
  toggleTheme: () => void;
};

// Step 2: Create the context with a default value
const ThemeContext = React.createContext<ThemeContextType | undefined>(undefined);

Providing the Context

Next, we create a provider component that will supply the context value to its child components:

// Step 3: Create the provider component
const ThemeProvider: React.FC<{ children: React.ReactNode }> = ({ children }) => {
  const [theme, setTheme] = React.useState("light");

  const toggleTheme = () => {
    setTheme((prevTheme) => (prevTheme === "light" ? "dark" : "light"));
  };

  return (
    <ThemeContext.Provider value={{ theme, toggleTheme }}>
      {children}
    </ThemeContext.Provider>
  );
};

Consuming the Context

To use the context value in a component, we can use the useContext hook. TypeScript will automatically infer the type of the context value:

import React, { useContext } from "react";

const ThemeToggleButton: React.FC = () => {
  // Step 4: Consume the context value
  const themeContext = useContext(ThemeContext);

  // TypeScript ensures that themeContext is not undefined
  if (!themeContext) {
    throw new Error("ThemeToggleButton must be used within a ThemeProvider");
  }

  const { theme, toggleTheme } = themeContext;

  return (
    <button onClick={toggleTheme}>
      Current Theme: {theme}
    </button>
  );
};

Handling Undefined Context

In the example above, we handle the case where the context might be undefined. This can happen if a component tries to consume the context without being wrapped by the provider. TypeScript's strict null checks will help catch these potential issues.

Alternatively, we can provide a default context value instead of undefined to avoid this check:

const defaultContextValue: ThemeContextType = {
  theme: "light",
  toggleTheme: () => {},
};

const ThemeContext = React.createContext<ThemeContextType>(defaultContextValue);

Using Context in a Larger Application

To integrate this into a larger application, we would wrap our application (or a portion of it) with the ThemeProvider, as we normally do when working with the Context API:

import React from "react";
import ReactDOM from "react-dom";
import App from "./App";

ReactDOM.render(
  <ThemeProvider>
    <App />
  </ThemeProvider>,
  document.getElementById("root")
);

Inside App, any component that needs access to the theme can use the useContext hook as shown above.

Configuring TypeScript: tsconfig.json

Let’s now finish by discussing the tsconfig.json configuration file.

The tsconfig.json file is a configuration file for the TypeScript compiler. It specifies the root files and the compiler options required to compile a TypeScript project. Let's break down the following tsconfig.json example:

{
  "compilerOptions": {
    "target": "ES2020",
    "useDefineForClassFields": true,
    "lib": ["ES2020", "DOM", "DOM.Iterable"],
    "module": "ESNext",
    "skipLibCheck": true,

    /* Bundler mode */
    "moduleResolution": "bundler",
    "allowImportingTsExtensions": true,
    "isolatedModules": true,
    "moduleDetection": "force",
    "noEmit": true,
    "jsx": "react-jsx",

    /* Linting */
    "strict": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "noFallthroughCasesInSwitch": true
  },
  "include": ["src"]
}

General Settings

1. compilerOptions:

   • This section contains various options that control how the TypeScript compiler (tsc) behaves.

2. target:

   • "target": "ES2020" specifies the target JavaScript version for the compiled output. Here, ES2020 is used, meaning the TypeScript code will be compiled to be compatible with ES2020 features.

3. useDefineForClassFields:

   • "useDefineForClassFields": true instructs the compiler to use the define behavior for class fields, which aligns with the latest ECMAScript standard for how class fields are initialized.

4. lib:

   • "lib": ["ES2020", "DOM", "DOM.Iterable"] defines the libraries to be included in the compilation.

     • ES2020 provides the ES2020 standard library.

     • DOM includes the standard DOM types, which are necessary for web development.

     • DOM.Iterable adds support for DOM types that are iterable, like NodeList.

5. module:

   • "module": "ESNext" sets the module system for the output to ESNext, which supports the latest ECMAScript module syntax. This is often used with modern JavaScript bundlers that can handle ES modules.

6. skipLibCheck:

   • "skipLibCheck": true disables type checking for all declaration files (.d.ts files). This can speed up the compilation process but might hide some potential type issues.

Bundler Mode Settings

1. moduleResolution:

   • "moduleResolution": "bundler" adjusts how modules are resolved. This is optimized for bundlers like Webpack or Vite that manage module imports differently than Node.js or TypeScript’s default resolution strategy.

2. allowImportingTsExtensions:

   • "allowImportingTsExtensions": true allows importing TypeScript files (.ts and .tsx) with their extensions in the import statements, which is often necessary when working with bundlers.

3. isolatedModules:

   • "isolatedModules": true ensures that each file is treated as a separate module. This is essential when using a bundler or tools like Babel to transpile TypeScript.

4. moduleDetection:

   • "moduleDetection": "force" forces the detection of modules even in files that don’t have explicit imports or exports, ensuring that all files are treated as modules.

5. noEmit:

   • "noEmit": true prevents TypeScript from emitting any output files. This is useful in scenarios where TypeScript is used solely for type checking, and the actual JavaScript code is handled by a bundler.

6. jsx:

   • "jsx": "react-jsx" specifies how JSX syntax should be transformed. react-jsx refers to the modern JSX runtime introduced in React 17, which does not require import React from 'react' at the top of files that use JSX.

Linting Options

1. strict:

   • "strict": true enables strict type-checking options, which includes several flags that make TypeScript's type system more robust and error-prone. This is the recommended setting for most projects to catch potential issues early.

2. noUnusedLocals:

   • "noUnusedLocals": true raises an error when local variables are declared but never used, helping to keep the codebase clean and free of unnecessary variables.

3. noUnusedParameters:

   • "noUnusedParameters": true raises an error if a function parameter is declared but never used. This can help identify unused or unnecessary parameters in functions.

4. noFallthroughCasesInSwitch:

   • "noFallthroughCasesInSwitch": true prevents unintentional fall-through in switch statements, where the execution moves to the next case if a break statement is missing. This reduces potential bugs in switch statements.

The include Options

1. include:

   • "include": ["src"] specifies the files or directories that should be included in the TypeScript compilation. Here, it’s set to include all files within the src directory.

Final Words

Integrating TypeScript with React offers a powerful combination that enhances code quality, reduces runtime errors, and makes our applications more scalable. By leveraging TypeScript’s type system, we gain better insights into our codebase, which helps us catch potential issues early during development. Throughout this article, we've explored the benefits of using TypeScript in React projects, including type safety, improved tooling, and enhanced developer experience.

Whether we're building small components or large, complex applications, TypeScript ensures that our code remains robust and maintainable. As we become more comfortable using TypeScript with React, we can start to explore advanced patterns like generics, utility types, and type guards, further improving the flexibility and safety of our applications.

With these tools at our disposal, we can confidently build modern, reliable React applications that stand the test of time. So, let's start embracing TypeScript in our React projects and unlock its full potential today.

See you in the next one! 🖖

Front-End Development: Crafting User Experiences

Front-End Development in a Nutshell

Front-end developers are specialists who focus on creating the user-facing aspects of websites and applications. If you enjoy working with designs, visual elements, and have a keen eye for user experience, front-end development might be your calling.

Pros of Front-End Development

1. Direct impact on user experience

2. Opportunity to express creativity and innovation

3. Specialization in a focused set of technologies

4. High demand in larger companies

Cons of Front-End Development

1. Narrow focus might limit versatility

2. Complex and sometimes messy technology landscape

3. Limited exposure to back-end technologies

Going Deeper into Front-End Development

Front-end developers are the architects of the digital user experience. They specialize in creating the visual and interactive elements of websites and applications that users directly engage with. If you have a passion for design, user interaction, and creating seamless digital experiences, front-end development might be your ideal path.

Key Responsibilities

• Building complex user interfaces

• Enhancing user experience (UX)

• Ensuring accessibility for all users

• Developing responsive designs for various devices

• Implementing (asynchronous) interactivity

Technologies and Skills: Front-end developers typically work with a core set of technologies, including HTML, CSS, and JavaScript. However, the field is constantly evolving, with new frameworks and libraries emerging regularly. Some popular front-end technologies include React, Vue.js, Angular, and CSS preprocessors like SASS.

Why Choose Front-End Development

• Creative Expression: Front-end development offers significant opportunities for creativity. You'll work closely with designers to bring visual concepts to life and have the freedom to innovate in how users interact with digital products.

• Immediate Visual Impact: One of the most satisfying aspects of front-end work is seeing your code translate directly into visual elements that users interact with. This immediate feedback can be highly rewarding.

• Focus on User-Centric Design: If you're passionate about creating intuitive, accessible, and enjoyable user experiences, front-end development allows you to directly influence these aspects.

• Specialization: By focusing on front-end technologies, you can become a true expert in your field. This specialization can make you highly valuable, especially in larger companies where roles tend to be more clearly defined.

• High Demand: With the increasing emphasis on user experience in the digital world, skilled front-end developers are in high demand, particularly in established companies with complex products.

Challenges to Consider

• Rapidly Changing Landscape: Front-end technologies evolve quickly. Staying up-to-date requires continuous learning and adaptation.

• Browser Compatibility: Ensuring consistent experiences across different browsers and devices can be challenging and sometimes frustrating.

• Performance Optimization: With the growing complexity of front-end applications, optimizing for performance becomes increasingly important and challenging.

• Collaboration: Front-end developers often need to work closely with designers, back-end developers, and other stakeholders, requiring strong communication skills.

Career Growth

As you progress in your front-end career, you might specialize further in areas like performance optimization, animation, or accessibility. You could also move into roles like UI/UX designer, front-end architect, or even transition into full-stack development if you decide to broaden your skill set.

Is Front-End Development Right for You?

Consider front-end development if you:

• Enjoy working on visual and interactive elements

• Have a keen eye for design and user experience

• Are comfortable with continuous learning to keep up with new technologies

• Want to specialize and become an expert in a focused area of web development

• Thrive on seeing the immediate results of your work

Remember, while front-end development offers a clear specialization, it's still a diverse field with plenty of room for growth and exploration. The key is to align your choice with your interests, strengths, and long-term career aspirations.

Full-Stack Development: Bridging the Gap

Full-Stack Development in a Nutshell

Full-stack developers are the jack-of-all-trades in the web development world. They work across the entire application stack, from the user interface to the server-side logic and databases.

Pros of Full-Stack Development

1. Versatility and broader skill set

2. Ability to build complete projects from scratch

3. Larger job market in most technology stacks

4. Valuable for startups and small teams

Cons of Full-Stack Development

1. Risk of being spread too thin across multiple domains

2. Challenges in time management and staying updated

3. Potential for slower specialization and career progression

Going deeper into full-stack development

Full-stack developers are the versatile problem-solvers of the web development world. They possess the skills to work on both the client-side and server-side of web applications, effectively bridging the gap between front-end and back-end technologies. If you enjoy tackling diverse challenges and want a comprehensive understanding of web development, the full-stack path might be your ideal choice.

Key Responsibilities

• Developing both client-side and server-side components

• Designing and managing databases

• Implementing business logic

• Handling DevOps tasks

• Creating and consuming APIs

• Ensuring seamless integration between front-end and back-end systems

Technologies and Skills: Full-stack developers work with a wide array of technologies. On the front-end, they use HTML, CSS, and JavaScript, often with frameworks like React or Angular. On the back-end, they might work with languages like Python, Ruby, Java, or Node.js, and frameworks such as Django, Ruby on Rails, or Express. Database management (SQL and NoSQL) and version control systems are also crucial skills.

Why Choose Full-Stack Development

• Versatility: As a full-stack developer, you'll have the ability to work on all aspects of a web application. This versatility can make you invaluable to smaller teams and startups.

• Comprehensive Understanding: Full-stack development provides a holistic view of web applications, allowing you to understand how different components interact and influence each other.

• Problem-Solving Opportunities: With knowledge spanning the entire stack, you're well-positioned to troubleshoot complex issues and optimize overall application performance.

• Project Ownership: Full-stack skills enable you to build complete projects from the ground up, which can be particularly satisfying for personal projects or when working in small teams.

• Broader Job Market: Many companies, especially startups and scale-ups, value the flexibility that full-stack developers bring to their teams.

Challenges to Consider

• Breadth vs. Depth: As a full-stack developer, you'll need to balance having a broad knowledge base with developing deep expertise in specific areas.

• Keeping Up with Multiple Domains: Staying current with both front-end and back-end technologies can be time-consuming and challenging.

• Time Management: Juggling responsibilities across different areas of an application requires strong time management and prioritization skills.

• Potential for Overwhelming: The vast scope of knowledge required can sometimes feel overwhelming, especially for those new to the field.

Career Growth

As a full-stack developer, your career path can be quite flexible. You might choose to specialize in a particular stack (e.g., MEAN or LAMP), transition into a technical lead or architect role, or even move into project management. The broad skill set you develop can also be a stepping stone to more specialized roles if you discover a particular area you're passionate about.

Is Full-Stack Development Right for You?

Consider full-stack development if you:

• Enjoy working on diverse challenges and learning new technologies

• Want to understand how web applications work from end to end

• Are interested in building complete projects independently

• Thrive in dynamic environments where you wear multiple hats

• Have strong problem-solving skills and enjoy optimization across different layers of an application

Remember that while full-stack development offers great versatility, it also requires a commitment to continuous learning across a broader range of technologies. The key is to find the right balance between breadth and depth that aligns with your career goals and the needs of your potential employers or projects.

Full-stack development can be an excellent choice for those who want to maximize their versatility in the job market and gain a comprehensive understanding of web development. However, it's important to be prepared for the challenges that come with maintaining such a broad skill set.

Making Your Choice

To decide between front-end and full-stack development, consider the following:

1. Personal interests: Do you enjoy visual design and user interaction, or are you more excited by complex problem-solving across the entire application?

2. Career goals: Are you aiming for specialization in a large company, or do you want the versatility to work in startups or on personal projects?

3. Learning style: Are you comfortable diving deep into a specific area, or do you prefer a broader understanding of multiple technologies?

4. Job market: Research the demand for both roles in your target industry and location.

5. Long-term vision: Consider how each path aligns with your long-term career aspirations and the type of projects you want to work on.

Remember, there's no one-size-fits-all answer. Many developers start in one area and transition to the other as their careers progress. The key is to choose the path that aligns best with your passions and goals.

Whichever path you choose, continuous learning and adaptability will be crucial in the ever-evolving world of web development. Whether you decide to specialize in crafting beautiful user interfaces or tackle the full spectrum of web applications, your journey in software development promises to be exciting and rewarding.

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.

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.

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.

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 detailednotes on 80 specific topicscovered 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:

• Overseas Migration

• Labour Force

• Housing Occupancy and Costs

• Total Value of Dwellings

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.

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:

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

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.

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.

Discover the power of knowledge! Grab my newest free Notion template, packed with detailednotes on 80 specific topicscovered 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!

🗞️ NEWSLETTER -*If you want to hear about my latest articles and interesting software development content, [subscribe to my newsletter](https://mailchi.mp/22b236f812b1/subscribe-to-newsletter).*

🐦 TWITTER/X -*Follow me on[Twitter/X](https://twitter.com/DamianDemasi).*

Before you even begin with Rails, it's crucial to have a solid grasp of what Ruby is and what it is used for.

1. Ruby

In a Ruby on Rails project, you need to install Ruby because Ruby on Rails is a web framework built using the Ruby programming language. Ruby is the foundational language that powers Rails and provides the core functionality for developing web applications.

So, let’s see some of the reasons why you need to install Ruby to work on a Ruby on Rails project:

• Language Dependency: Ruby on Rails is written in Ruby, and it is tightly integrated with the Ruby language. Rails leverages the features, syntax, and capabilities of Ruby to create web applications efficiently. Without Ruby, Rails cannot function as it relies on the underlying Ruby language for its codebase.

• Executing Rails Commands: Many of the command-line tools and utilities used in Rails development, such as rails new, rails generate, and rails server, are Ruby scripts. These commands initiate specific actions within your Rails application and are executed using the Ruby interpreter.

• Application Logic: In a Rails project, you write application-specific logic and business rules in Ruby code. As Rails implements the MVC pattern, you’ll use Ruby code to define and implement models, controllers, and views, as well as business logic and data manipulation. Without Ruby, you wouldn't have the language required to express these aspects of your application.

• Gem Management: RubyGems is the package manager for Ruby, and it plays a crucial role in installing and managing the various gems (libraries and plugins) used in a Rails project. RubyGems is Ruby-based, and when you install gems, they become part of your Ruby environment.

• Integrating with Web Servers: When you run a Rails application, it is served by a web server, such as WEBrick or Puma. These servers are Ruby-based and interact with the Rails application using Ruby.

1.1. Model, View, Controller (MVC)

MVC stands for Model-View-Controller, and it's a design pattern that separates an application into three interconnected components:

1. Model: The Model represents the data and business logic of the application. It deals with database interactions, data validation, and encapsulates the rules for manipulating the data. In a Ruby on Rails app, the models are often implemented using ActiveRecord, which provides an Object-Relational Mapping (ORM) layer for database operations.

2. View: The View is responsible for presenting the data to the user. It encompasses the user interface components, layouts, and templates that generate the HTML and other content displayed in the browser. In Rails, Views are often created using embedded Ruby (ERB) templates, allowing dynamic content to be mixed seamlessly with static HTML.

3. Controller: The Controller acts as an intermediary between the Model and the View. It receives requests from the user's browser, processes them, and communicates with the Model to retrieve or modify data. Once the data is prepared, the Controller selects the appropriate View template to render the response, which is then sent back to the user's browser.

The MVC framework provides a clear separation of concerns, making it easier to maintain and extend the application over time. Changes to the user interface (View) can be made independently of the data and business logic (Model), and vice versa. This separation enhances code organization, collaboration among developers, and the overall flexibility of the application.

In a Ruby on Rails app, this architecture is central to the framework's philosophy and greatly contributes to its efficiency and productivity.

1.2. RubyGems

RubyGems is a package manager for the Ruby programming language. It is a tool that simplifies the process of installing, managing, and distributing Ruby libraries (gems) and applications. Gems are pre-packaged libraries or plugins that extend the functionality of Ruby applications, making it easier for developers to add features or reuse code in their projects.

Here are the key features and functions of RubyGems:

• Gem Installation: RubyGems allows developers to install gems effortlessly with a single command. When a gem is installed, it becomes available for use in Ruby projects, and its functionality can be accessed within the code.

• Gem Management: Once installed, RubyGems helps developers manage gems in their projects. It allows you to view installed gems, uninstall unnecessary ones, and update gems to their latest versions.

• Gem Dependency Resolution: RubyGems handles gem dependencies, meaning when you install a gem, it automatically installs other gems that the target gem requires to function properly. This ensures that all necessary dependencies are met without requiring manual intervention.

• Gemspec Files: Each gem typically includes a gemspec file, which contains metadata about the gem, such as its name, version, author, description, and required dependencies. The gemspec file provides essential information for RubyGems to install and manage the gem correctly.

• Centralized Repository: RubyGems operates on a centralized repository known as the RubyGems.org or RubyGems server. This repository serves as the central hub for hosting and distributing Ruby gems. Developers can publish their gems on RubyGems.org for others to use.

• Bundler Integration: Bundler is another essential tool in the Ruby ecosystem that manages gem dependencies for a specific project. It works hand in hand with RubyGems to ensure that the correct versions of gems are installed and used in a particular project.

• Community Contribution: RubyGems fosters a vibrant community of gem developers who contribute to the vast ecosystem of gems available. The community continuously develops and maintains gems, making them available for public use.

Read more about RubyGems here.

2. Databases

In a Ruby on Rails project, you need to install SQLite3 (or another database adapter) because Rails relies on a database to store and manage the application's data. SQLite3 is one of the supported database adapters in Rails, and it is often used as the default database for development and testing environments due to its simplicity and ease of setup.

You might be curious about what are the key components and concepts related to data storage and management in a Ruby on Rails application, so let’s do a quick exploration of them:

• Data Persistence: Rails applications are typically designed to interact with a database to store and retrieve data. The database acts as a persistent storage solution, allowing the application to store information across multiple user sessions and server restarts.

• Models and Active Record: In Rails, models are Ruby classes that represent database tables. Models are created using Active Record, which is a Rails feature that provides an Object-Relational Mapping (ORM) layer. Active Record maps Ruby objects to database records, allowing developers to interact with the database using familiar Ruby syntax.

• Migration and Schema: Rails uses database migrations to manage changes to the database schema over time. Migrations are Ruby scripts that describe changes to the database structure, such as creating tables, adding columns, or modifying indexes. When migrations are run, they update the database schema accordingly.

• Database-Backed Applications: Many Rails applications are database-backed, meaning they rely on a database to handle various aspects of the application, such as storing user data, managing authentication information, and recording application-specific data.

2.2. RoR is database-agnostic

Ruby on Rails is designed to be database-agnostic, which means you can use a variety of databases with it. However, Rails has a closer integration with certain databases, and some databases are more commonly used due to their compatibility and community support.

While you can technically use any database with Rails, it's important to consider factors such as compatibility, performance, and community support. The databases that are well-supported and commonly used with Ruby on Rails include PostgreSQL, MySQL, and SQLite. These databases have established gems (libraries) and documentation to facilitate their integration with Rails.

• PostgreSQL: PostgreSQL is a powerful open-source relational database management system. It's known for its advanced features, extensibility, and support for complex queries. Many Rails developers prefer PostgreSQL for its robustness and support for handling large datasets.

• MySQL: MySQL is another popular open-source relational database system. It's widely used in Rails projects and is known for its speed and reliability. MySQL is a good choice for projects that require scalability and high performance.

• SQLite: SQLite is a lightweight, file-based relational database engine. It's often used in development and testing environments due to its simplicity and ease of use. While it might not be suitable for high-traffic production applications, it's a great choice for smaller projects or testing purposes.

Learn more about SQLite3 here.

3. Rails

Finally, let’s talk about Rails. Ruby on Rails, often simply referred to as Rails, is an open-source web application framework written in the Ruby programming language. As discussed earlier, Rails follows the Model-View-Controller (MVC) architectural pattern and aims to provide a productive and convention-over-configuration approach to building web applications. It was created by David Heinemeier Hansson and was first released in 2004.

Rails has many features that make it a great framework to work with, although sometimes it can feel a bit overwhelming (especially when you are just starting to learn how to use it). Here's an overview of some of its main features:

• Full-Stack Web Framework: Rails is a full-stack web framework, meaning it provides a comprehensive set of tools and libraries for developing the entire web application, including handling the backend logic, managing the database, and rendering the frontend views.

• Convention over Configuration: Rails follows the principle of convention over configuration, which means it makes assumptions about how the application should be structured and configured. By adhering to these conventions, developers can achieve more straightforward and consistent development without having to specify every detail explicitly.

• Model-View-Controller (MVC) Pattern: Rails follows the MVC pattern, which separates the application into three components: models, responsible for managing data and business logic; views, responsible for rendering the user interface; and controllers, responsible for handling user requests and coordinating the models and views.

• Active Record: Rails includes Active Record, an Object-Relational Mapping (ORM) layer that simplifies database interactions by representing database tables as Ruby objects. Active Record allows developers to work with the database using familiar Ruby syntax, reducing the need to write raw SQL queries.

• RESTful Architecture: Rails encourages the use of Representational State Transfer (REST) principles for designing web applications. RESTful routes and actions provide a consistent and predictable way to interact with resources in the application.

• Scaffolding: Rails provides scaffolding, a code generation feature that automatically creates a basic set of controllers, models, and views for a specific resource. Scaffolding accelerates development by quickly providing a working prototype of the application.

• Gems and RubyGems: Rails leverages RubyGems, the package manager for Ruby, to manage dependencies and integrate third-party libraries (gems) into the application. Gems extend the functionality of Rails and allow developers to add features to their projects with ease.

• Active Support: Rails comes with Active Support, a collection of utility classes and standard library extensions that provide additional functionality to Ruby. Active Support includes methods for working with dates, strings, collections, and more.

• Security: Rails includes built-in security features to protect against common web application vulnerabilities, such as Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF).

• Community and Ecosystem: Rails has a vibrant and active community of developers who contribute to its ongoing development and maintenance. The Ruby on Rails ecosystem includes numerous gems, plugins, and tools that further enhance the framework's capabilities.

I intend to go into each of these features (and more) in more detail in the upcoming posts, so stay tuned! 📻

4. Closing thoughts

This post discussed Ruby on Rails (RoR) and its foundational aspects. Understanding these concepts is important for creating good RoR applications, whether you're experienced or just starting out.

Before learning Rails, you should know Ruby well. Ruby is the foundation of Rails and is used for making web applications.

RoR supports many databases, including PostgreSQL, MySQL, and SQLite. This means you can choose the one that fits your project best.

RoR is a powerful and productive framework with many features:

• Full-Stack Framework

• Convention over Configuration

• MVC Pattern

• Active Record for Database Interaction

• RESTful Architecture

• Scaffolding for Rapid Prototyping

• Integration of Gems and RubyGems

• Active Support

• Embedded Security Features

• Flourishing Community and Ecosystem

My aim with this post was to give developers a good understanding of Ruby's role in Rails, the importance of database adapters like SQLite3, and the many capabilities of the Ruby on Rails framework itself. With this knowledge, you can now confidently start digging into creating dynamic and efficient web applications with Ruby on Rails.

Thanks for reading, and see you next time! 👋

Bonus: knowledge check!

Cover photo by Yulian Alexeyev - Unsplash

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

• Eloquent JavaScript: Mutability

• MDN: Mutable

• MDN: Immutable

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.

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:

• CodeWars
• LeetCode
• CoderByte
• CodeChef
• HackerRank

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.

1. Metalearning,
2. Focus, and
3. 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.

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

1. The importance of Grit
2. The key to consistency: Habits
3. Why doing Deep Work is important to have productive study sessions
4. Why you should Care about Your Craft, and
5. 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!

Next posts

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.

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:

1. The importance of having a good idea of Why you want to learn how to code
2. How Passion is overrated
3. Why it’s important to have a Growth mindset
4. Why you shouldn’t rely on Motivation
5. 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!

Next post

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.

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:

1. Start by analysing the workflow the code is following that affects a particular section of code.
2. If nothing wrong is found, we could use the React Developer Tools to analyse each component closely.
3. 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.
4. 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.

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:

1. Print a line of 5 hash symbols
2. Print 5 lines of 5 hash symbols
3. Find a way to decrease a number as a count grows
4. 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:

1
2
3
4
5

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:

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

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:

5
4
3
2
1

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.

I have finished my CSS study progress tracker Notion template and I want to share it with you! Before continuing, if you haven't got the HTML version of this template, you can take a look at it here.

A quick look at the CSS study template

In this Notion template, you will find a progress bar that automatically updates whenever you check a topic as completed, 73 CSS topics classified in three difficulty levels (initial, medium and advanced) and divided into 19 topic groups (ranging from Animation to Layout and Responsive Web Design).

Each topic has a link to an online source discussing it (usually Mozilla Development documentation), and space for you to take notes on it.

As always, feel free to modify this template and adapt it to your needs.

How to use the template

Once more, I wanted to create a template that is easy to use and leave room for you to tweak it as you see fit. The steps to add a new topic (on top of the 73 already there), and mark it as completed once it has been studied is simple:

Step 1: add a new topic

Add a new topic to the "CSS topics and roadmap" database (you can do this on any of the two pages of the template), choose the level, its group, and its order.

But most importantly, choose the corresponding related value in the "Related to Progress (Property)" (don't worry, there is only one). This will link this database with the progress bar tracker.

Step 2: add notes to the topic

Each of the 73 topics I have shared has a link to an MDN page with explanations for that topic.

I encourage you to use this topic page to create your "repository" of notes about it.

Step 3: making progress

Once you are happy with how much do you know about a certain topic, you can click the checkbox under the "Completed" column to mark the topic as learned. This will trigger an update on the progress bar, and it will grow accordingly, thus measuring your progress automatically.

Step 4: customisation

As I said before, you can customise the template as you like. Something I'll do is hide the "Completed" and "Goal" columns of the Progress section to make it more minimalistic.

Getting the template

🤷‍♂️ - "This is all good and all, but Damian, where can I get the Notion template?"

😅 - Grab your mouse and smash this link: download CSS Study Progress Tracker Notion Template

The template is totally free, but I present you with the option of paying any amount you like for it so I can keep investing my time and effort into creating this kind of content for you 😊.

Final words

Please, let me know in the comments section what do you think about this template, as I would love to improve it. I'm also working on a Role Playing Game (RPG) quest-based template to keep us motivated during our learning progress, so consider subscribing to my newsletter to get a notification when it's out (and maybe some ideas about what you would like to include in it)!

Cheers!

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

🐦 TWITTER - Follow me on Twitter.

The HTML Study Progress Tracker Notion Template

This template focuses on a specific topic: HTML. Thanks to researching great books and awesome internet sources, I have compiled the 42 most important subjects that we need to learn for mastering HTML. In the template, you can find the topic, its category, the difficulty level (according to my own experience), and checkboxes to keep track of what you have learned so far.

The objective of presenting HTML topics this way is to build some sort of road map to help us navigate the learning process. Each topic has an order that I have seen works best, but you can jump around as you see fit.

Measuring progress

The template also includes a Study Progress Tracker (patent pending 😉) that shows in a clear way your progress through the HTML part of the web development learning journey. I have asked people to tell me what are some of the challenges they find in their learning path, and many have replied that an unclear way of measuring progress is one of their main challenges. This is the reason behind this part of the template, and it's just a suggestion that you can change and alter as it works best for you.

How to use the template

I wanted to create a template as easy and straightforward to use as possible, so as not to include too much friction into the process of using it. The steps to add a new topic (on top of the 42 already there), and mark it as completed once it has been studied is simple:

Step 1: add a new topic

Add a new topic to the "HTML topics and roadman" database (you can do this on any of the two pages of the template), choose the level, its group, and its order.

But most importantly, choose the corresponding related value in the "Related to Progress (HTML topics)" (don't worry, there is only one). This will link this database with the progress bar tracker.

Step 2: add notes to the topic

Each of the 42 topics I have shared has a link to an MDN page with explanations for that topic.

I encourage you to use this topic page to create your "repository" of notes about it.

Step 3: making progress

Once you are happy with how much do you know about a certain topic, you can click the checkbox under the "Completed" column to mark the topic as learned. This will trigger an update on the progress bar, and it will gro accordingly, thus measuring your progress automatically.

Step 4: customisation

As I said before, you can customise the template as you like. Something I'll do is hide the "Completed" and "Goal" columns of the Progress section to make it more minimalistic.

Getting the template

🤷‍♂️ - "This is all good and all, but Damian, where can I get the Notion template?"

😅 - I almost forgot! You can get the template from this link: download HTML Study Progress Tracker Notion Template

The template is totally free, but I present you with the option of paying any amount you like for it so I can keep investing my time and effort into creating this kind of content for you 😊.

Final words

Please, let me know in the comments section what do you think about this template, as I would love to improve it. I'm also working on a CSS template that I should release soon, so consider subscribing to my newsletter to get a notification when it's out!

Cheers!

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

🐦 TWITTER - Follow me on Twitter.

The app makes use of several MongoDB features:

• Search indexing for auto-complete and normal searches using MongoDB Atlas.
• Serverless functions that are called to perform the actual auto-complete and search features using MongoDB Realm.
• The capacity to do a fuzzy search, querying the data for the top 10 closest matches to the search term.

In this project, I also implemented a save to favourites functionality using localStorage, and React pagination to browse through the multiple documents returned by MongoDB.

The app was developed using:

• React for the front end with the following packages:
  • realm-web: for the MongoDB connectivity and Realm access
  • html-react-parser: for parsing the data contained in the documents
  • react-paginate: to paginate the documents returned by MongoDB
• Next.js for the back end
• Heroicons for the icons
• TailwindCSS for the styling

👉 Watch it live here: https://hackathon-mongodb-devto.vercel.app/

About the web app

The project is basically a glossary search app. The user can search a web development related term and save it as a favourite.

On the start page, the app will present a list with all the terms that are present on the MongoDB database. As there are quite a lot of them, they are paginated.

Once the user starts searching for a particular term, the search field will offer auto-complete options after the third character is entered in the input field. This is accomplished by calling a serverless function on MongoDB Realm.

This is the code for the function:

exports = function (arg) {
    let collection = context.services.get("mongodb-atlas").db("hackathon_db").collection("web_glossary");

    let pipeline = [
        {
            $search: {
                index: "autoCompleteDefinitions",
                "autocomplete": {
                    "query": arg,
                    "path": "title",
                    "tokenOrder": "sequential"
                }
            }
        },
        {
            $limit: 10
        },
        {
            $project: {
                // "_id": 0
                "title": 1
            }
        }];

    return collection.aggregate(pipeline);
};

What this function does is to build a pipeline that searches the auto-complete index (defined in MongoDB Atlas) for query matches, limits those matches to 10, and returns the title of the matching documents. As a result, a dropdown list is shown when the user searches for a term, and the user can select one of them to see its definition:

Here is a demo of this functionality in action:

The user can also type a term on the search field and press Enter or click on the Search button. This will call another serverless function defined in MongoDB Realm that will deliver the first 10 matches that are similar to the query sent by the user.

This allows for fuzzy matching terms. For example, the user can enter javoscrpt, and MongoDB will return documents that are a close match to that term, such as JavaScript. This is a really awesome functionality! MongoDB will also return a score indicating how close to the query term is the returned result.

Here is a demo of this functionality in action:

In case you are wondering, this is the code for this serverless function:

exports = function (arg) {
    let collection = context.services.get("mongodb-atlas").db("hackathon_db").collection("web_glossary");
    let pipeline = [
        {
            '$search': {
                'index': 'searchDefinitions',
                'text': {
                    'query': arg,
                    'path': {
                        'wildcard': '*'
                    },
                    'fuzzy': {}
                }
            }
        },
        {
            $project: {
                title: 1,
                excerpt: 1,
                score: { $meta: "searchScore" }
            }
        },
        {
            $limit: 10
        }
    ];

    return collection.aggregate(pipeline);
};

I wanted to keep this app simple enough to focus on the MongoDB aspect of it, so if you think it's quite bare-bones, that's the reason why. That's also the reason behind the data (the definitions) not being polished enough.

Link to Source Code

You can take a look at the app source code in my GitHub repository.

Additional Information and Resources

Initial research

Before starting working on this hackathon, I knew one thing: I wanted to implement auto-complete on a search bar because that was something I had never done before. This was the initial stepping stone that pushed me to create a project for the hackathon.

I explored several ideas regarding what the app was going to be all about, ranging from an e-commerce store to hire Hobbits to help around the house, to a database of monsters from Dungeons and Dragons (D&D), and some other cool ideas, but all of them had one fatal flaw: the user should know what to search for. Not many people know by heart the names of Hobbits or D&D demons, so I switched to something more proper for the audience of this hackathon: web development terms.

Doing my research I came across the MDN Glossary of Web-related terms definitions. I found out that I could clone their repository and get all the definitions straight from their GitHub repository, so I did just that!

Data preparation

My goal was to get all the definitions from MDN and transform them into JSON format so I could upload that into a MongoDB collection (a table, in SQL language). Unfortunately, due to the nature of the data, it wasn't an easy task.

The glossary data from MDN is divided into multiple files in markdown format, and I wasn't planning on copying and pasting that by hand. After some online search, I came across the markdown-json package which, after some trial and error, converted all my markdown files into a single JSON file. I did this directly in the console:

npx markdown-json -c ./my-app-settings.json -p */*.md

Once the data was ready, I created a new database and collection on MongoDB and imported the JSON file.

Learning about MongoDB Atlas

I didn't know anything about MongoDB Atlas, so I wanted to know what it was capable of and how I could use it. I found an awesome tutorial by codeSTACKr (who, as far as I know, is working for MongoDB) in which he builds an e-commerce solution using MongoDB Atlas.

After building that app, I had an idea of what I could be doing with my own app. I used React, Next.js, and TailwindCSS to build it, as well as a couple of packages to implement certain functionalities, such as pagination and HTML parsing (the glossary terms extracted from MDN are described using HTML code). I tried to make my app as different from the tutorial as possible so I could actually learn and understand what I was doing. I hope to have accomplished that.

Another great resource for understanding how MongoDB works is its official documentation. This proved to be helpful when I had to modify and delete the collection, because I had to do this using the MongoDB shell.

If you would like a full, detailed, tutorial about how to build this app, please send me a message to my Twitter account.

I hope you enjoyed this post. Hopefully, I managed to inspire you to build your own implementation of the MongoDB features I described earlier.

Cheers!

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

🐦 TWITTER - Follow me on Twitter.

The problem with programming being intangible

Learning web development is not like actually building something with our hands. Programming is abstract, and we can't actually "touch" our program, which gives us a sense of not having accomplished something. By contrast, a carpenter can start working on building a chair, and after a while, the carpenter can point to the chair, even touch it, and say "I've built that!". As programming, and much of the knowledge work, is intangible, we need a way to improve the feedback on our effort. Using progress indicators is a great way of doing so.

The key to succeeding in your study process (and for building projects) is to stick to a good habit of learning and building every day. According to James Clear, the best way to stick to a habit is to make it satisfying. This is where visual measures come into play.

Habit trackers

Visual measures can be presented in many different ways, such as journaling, progress bars, and page numbers in a book. They are useful because they add immediate feedback and satisfaction after performing a habit, making habit trackers one of the best ways to measure our progress.

The way in which we track our progress needs to be attractive and satisfying, thus making it enjoyable, something we aspire to do after finishing a habit.

Habit trackers and other visual forms of measurement can make your habits satisfying by providing clear evidence of your progress.

• Clear, James. Atomic Habits (p. 204). Penguin Publishing Group.

Implementing habit trackers

We should be mindful of tracking things that are under our control, such as how many hours we invest in programming a project, and avoid tracking things outside our control, such as how many people star our project on GitHub or how many followers we have on Tech Twitter.

The activities we can track can be broadly divided into two categories depending on:

• how much effort we invest, and
• how much progress we have made.

Tracking effort

Effort can depend on time (how many hours do we clock in) or on repetition (how many projects we have built).

In order to track time, I usually use a time-tracker app. My favourite is Clockify.

I use time tracking like this:

• 👉 First, define how much time I will invest in the activity. For example, if the activity is "studying JavaScript", I will say "I will invest 1 hour a day, 5 days a week, on studying JavaScript". This is the minimum, and I'll do my best effort to invest at least this amount of time in the activity.
• 👉 Second, define this activity as a project in the time tracking app. By doing so, I can get detailed information on the app regarding how much time I invested over the days.
• 👉 Third, start tracking time on the app.
• 👉 Fourth, periodically analyse how this activity is going by taking a look at the time tracking report.

For example, as shown in the picture above, during the months of June, July and August, I spent 205 hours studying JavaScript.

By doing this, I can go from "I studied some JavaScript during 2021" to "I spent 205 hours focusing on JavaScript during June, July and August of 2021". I have a number, a real measurement that I can use to get a better feeling of the progress I'm making on JavaScript.

If what we want is to track repetition, we can just decide, for example, on how many projects we want to build for a specific goal. We can say that we want 3 projects on our portfolio, so we will track how many projects we are building, and this will give us a sense of advancing towards our goal.

I usually use Notion for this, but you can use any app, or just pen and paper.

Tracking progress

Tracking progress is ideal for activities that take a long time, and that have a beginning and an end. A course or book on JavaScript is the ideal subject to track this way.

What I do in this case is to divide the activity into smaller chunks. If I want to study a book, I will use the book's chapters as steps to measure the progress. If I want to measure a Udemy course, I will use each separate class (video) as a step to measure my progress.

For example, as of December 2021, the Eloquent JavaScript book has 21 chapters plus the introduction, so I will divide my progress on the book into 22 steps. Each time I finish a chapter, I will mark one of those steps as done by increasing the Commpleted counter on the tracking app/system.

A similar methodology will be used on Udemy courses or on the freeCodeCamp syllabus.

My preferred tool for measuring this is, again, Notion. You can take a look at the template I use by downloading it from here, and going to the Study progress section.

Closing thoughts

Tracking our progress can help us to get a feeling of how much have we accomplished towards a goal, and can also contribute to sticking with difficult habits, such as studying web development every day or building projects. I encourage you to try some of these techniques and see for yourself if they are useful to you.

I would love to hear if you have implemented habit tracking before, or if you have a different method to track your progress, so feel free to post it in the comments section.

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

🐦 TWITTER - Follow me on Twitter.

In one of my last posts, Using Notion to organise programming topics, a lot of people asked me to share the Notion template I was using to build my commonplace book about Web Development. So, after spending quite some time removing personal information from it, and polishing it a bit, I would like to share with you a template you can use to create your own commonplace book.

👉 You can download the template by clicking here. 👈

In this template, you will find over 440 pages containing:

• Over 270 HTML and CSS related questions to practice your knowledge in a spaced repetition manner.
• Dozens and dozens of useful links.
• Information about CSS, HTML, JavaScript, ReactJS, Ruby on Rails, SQL, and more!
• Cheatsheets.
• Link to free tutorials and courses.
• Mindset (to stay strong in the web development journey).
• Information and links about APIs, tools, libraries, web development resources, etc.
• Resources for code practice.
• Problem-solving strategies.
• Lists of interesting articles.
• Useful blogs, podcasts and newsletters.
• The best YouTube channels I could find.
• And much, much more!

Please, feel free to create a copy of this template and adapt it to your own needs. I found it very useful in my journey of becoming a Web Developer, and I still use it almost every day. It has become an extension of my brain, and I rely on it every time I have a question or doubt.

I did my best to remove any copyrighted or personal content but, if you find any, please let me know so I can delete it.

I would like to know any suggestions on how to improve this template, and I'm even considering uploading it to GitHub so I can transform it into a collaborative commonplace repository. Let me know what you think about that.

I hope you enjoy 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.

I will ask coach Gandalf for his opinions on different topics, and he will pour his wisdom and bluntness over us during the whole post.

The truth about new year's resolutions

🧑‍💻 - Hey, coach Gandalf, what do you feel about new year's resolutions?

🧙‍♂️ - My dear little human, most of us have been there: a new year is coming, we feel this is our chance to stop some bad habits and start new ones, a perfect body and a perfect wallet are just around the corner. January 1st, we start doing that thing we planned on doing. A week later we find the first excuses on why we are permitted to skip a couple of days (or eat that tasty cake, or buy that nice mechanical keyboard -our third one-). Two weeks later we find ourselves sliding into bad habits once more, telling us that they are not as bad after all. Our motivation explodes into the air a few moments after liftoff, like a failed rocket launch 🚀💥. You don't believe me? Take a look at this article describing why only 9% of people stick to their resolutions for a full year.

🧑‍💻 - Hm... OK, maybe that's a bit too blunt, don't you think? I guess you are cranky because you ran out of tobacco for your pipeweed or something...

But... motivation!

🧑‍💻 - I'm motivated! But sometimes I don't feel like it...

🧙‍♂️ - Allow me to be blunt once more: motivation is overrated. According to this article by James Clear (the guy who wrote the great book Atomic Habits) describing how motivation works, motivation often comes after starting a new behaviour, not before. You don't feel like it? You don't feel in the mood to start typing code, going through that Udemy course, writing that blog post (😉)? Guess what: we all feel like that most of the time. What we need to do is just start. We can say to ourselves "I will just do 10 minutes of this, and then I can drop it". Chances are that we are going to stick for more than 10 minutes, and the motivation will start growing after we started working on the thing we just don't feel like.

Don't focus on the objective, focus on the system instead

🧑‍💻 - Coach, I love setting goals!

🧙‍♂️ - Do you know that people that reach their goals, and people that don't, have the same goals in common? (Laughs while exhaling smoke from his pipe.) I guess I'm a fan of James Clear because he's back with another great article: Forget About Setting Goals. Focus on This Instead.

Goals can provide direction and even push you forward in the short term, but eventually, a well-designed system will always win. Having a system is what matters. Committing to the process is what makes the difference.

🧙‍♂️ - Don't think too much about your objective, your goal. Instead, focus your full attention on the day to day tasks you need to do in order to achieve that goal. Our system could be a series of habits that enable us to learn to program. Waking up early and studying programming, taking some time each day to write code, bundling habits (from Atomic Habits), stopping chasing rabbit holes on the Internet, limiting our social network use, doing regular exercise and sleeping well to improve our cognitive stamina, are just some examples of what we could do.

🧙‍♂️ - In the end, learning to program and becoming who we want to become does not depend on a new year starting or on an ambitious goal. It depends on what we are doing day in and day out to support our identity: we are now a programmer.

Tools to help us maintain consistency along the way

🧑‍💻 - This looks that is going to be hard...

🧙‍♂️ - This journey is not going to be easy, nor short. I can promise you moments of struggle, uncertainty, and despair. But don't panic! Not all who wander are lost. Here are some tools that are going to help you succeed in this path:

• 🛠 Grit: a ferocious determination to put in the work. Being able to be resilient and hardworking. Know in a very deep way what is what you want. (From the book: Grit)

• 🛠 A growth mindset: the view you adopt for yourself profoundly affects the way you lead your life. The hand you’re dealt is just the starting point for development. The growth mindset is based on the belief that your basic qualities are things you can cultivate through your efforts. (From the book: Mindset)

• 🛠 A strong identity and habits that support that identity: habits shape your identity, and vice-versa. What type of person do you want to be? A programmer? What habits do a programmer have? Will he/she/them be binging Squid Game, or learning React to build an app? (From the book: Atomic Habits)

• 🛠 Be able to do deep work: the ability to perform activities in a state of distraction-free concentration that pushes your cognitive capabilities to their limit. (From the book: Deep Work)

🧙‍♂️ - If you would like to learn a bit more about these tools, I would like to share with you four book summaries made by Brian Johnson:

• 📓 Grit

• 📓 Mindset

• 📓 Atomic Habits

• 📓 Deep Work

(You can find all these books in your favourite bookstore, of course.)

The web development path

🧑‍💻 - Thanks for the useful tips, coach Gandalf. Where should I start my web development journey?

🧙‍♂️ - Now that we have established how we can improve our chances of succeeding in learning web development, let's talk about what I think is the best path to follow. There are many tools and technologies to learn, and you can take a look at a road map here. I think the best option is to start with the Front-end, as it's the path that will have a not-so-steep learning curve (compared with DevOps or Back-end) and high demand for jobs.

🧙‍♂️ - A word of caution: many times you'll feel drawn to free resources. You should be careful! Many of the free resources are not as deep or thorough as you need them to be. They will leave gaps in your knowledge and you will lose time filling them. I think the best approach is to commit yourself to a comprehensive course, even if you have to pay for it. I'm a strong believer that Udemy is the best option for this. Pick a topic you are interested in learning and search for Udemy courses about it. Read comments, reviews, and recommendations. There is always a Udemy sale, so you shouldn't spend more than $35 for a full course (that usually has 45+ hours of content).

🧙‍♂️ - One more thing: try not to jump around too much. Stick with the technology and content you are learning until the course or project is finished. This will prevent gaps from forming in your knowledge, and help you avoid tutorial hell.

1st step: Git

🧑‍💻 - So... what is the first step?

🧙‍♂️ - Starting with Git will allow you to become familiar with the terminal and the way in which software is built. You can create repositories from day 1, something that will look great on your GitHub profile. It will allow you to keep track of all your code and projects, and I think i's a great way to get your feet wet with the world of programming in general.

Steps:

1. Udemy course: Git Complete: The definitive, step-by-step guide to Git. Start your journey by taking this course. You can implement the concepts learned here during the rest of your student (and professional) path.

The importance of building stuff

🧙‍♂️ - During your journey, you will be tempted to absorb information as fast as possible to achieve that highly desired outcome: become a web developer. But please, don't just work on the theory. As soon as you start learning HTML and CSS (and JavaScript and React later on), you should be building your own projects. They can be small (just a button), medium (a website), or big (a full web application). Build, build and then build some more (and keep track of them on GitHub). This is how the information you are absorbing is going to be transformed into actual knowledge.

2nd step: Bootcamp (optional)

🧑‍💻 - Should I take a Bootcamp or just focus on each topic separately?

🧙‍♂️ - If you are not in a hurry and you have spare time, taking a coding Bootcamp will teach you the overall technologies involved in the web development journey. You are not going to learn those topics deeply, though, which means that you will have to study them after the Bootcamp. Most good Bootcamps are lengthy and require you to absorb many different topics in a cramped time frame.

🧙‍♂️ - You have two main options when choosing a Bootcamp: doing it online, or doing in in-person. Usually, online ones are cheaper but require a greater commitment on your part in order to finish them. In-person Bootcamps are more expensive, but it's easier to finish them because you have paid a lot of money, and you have to go to a specific place at a certain date and time. Another pro for the in-person ones is that you will actually meet people in the same boat as you are.

🧑‍💻 - I agree. I actually took a Bootcamp course on Udemy, and I found it very useful to gain an overall knowledge of the things involved in the web development process. The Bootcamp I took back in the day (2019-2020) had 405 lectures spread across 47 hours of content. This translated into almost 148 hours of actual study (I used a time tracker app to measure it). As I was working and studying at the same time, those 148 hours spread over 5 to 6 months. Initially, I estimated, at the most, half of that time, so beware.

Optional step:

• Udemy course: The Web Developer Bootcamp 2022. This is the BootCamp I took and I can highly recommend it. Colt is a great teacher and the course has many projects that you can build.

Or

• Udemy course: The Complete 2022 Web Development Bootcamp. I haven't taken Angela's course but I have read many positive comments from people (not only on the Udemy page) recommending it.

Either one your choose, you can't go wrong.

3rd step: HTML and CSS

🧑‍💻 - OK, I now know Git (and maybe I have finished a BootCamp). What's next?

🧙‍♂️ - You still don't know what you don't know. You need to dive deep into HTML and CSS. In this step, you will learn about the correct structure an HTML document should have, accessibility (WAI-ARIA), new HTML5 elements you should use and which ones to avoid, how to style an HTML document, CSS custom properties, good practices, grid, flexbox, etc.

🧙‍♂️ - If you previously took a BootCamp, chances are that you didn't learn these topics in a thorough way, so here is where we are diving deep into these concepts. There are many, many, resources from which you can choose to learn HTML and CSS, so do your research and choose wisely. I would suggest to you to choose good teaching materials, and not just what's free or fashionable.

🧑‍💻 - I agree with you, Gandalf. I remember that I almost entered a "paralysis by analysis" stage when researching where or how I could get good quality teaching materials for HTML and CSS. I ended up selecting a free course, a book and a Udemy course, and I feel that those resources were some of the best I could have selected.

Steps:

1. freeCodeCamp: Responsive Web Design Certification. Start by taking this free course so you can have a basic and general idea about HTML and CSS.

2. Book: Learning Web Design: A Beginner's Guide to HTML, CSS, JavaScript, and Web Graphics, 5th Edition. After finishing the freeCodeCamp course, pick up this book. It is highly recommended because it will teach you important concepts such as how the Internet works, HTML, CSS, best practices, an introduction to JavaScript, and much more.

3. Udemy course: Advanced CSS and Sass: Flexbox, Grid, Animations and More! . Only take this course after having covered freeCodeCamp course and the Learning Web Design book if you have spare time and want to dive deeper into CSS and SASS.

4th step: JavaScript

🧑‍💻 - I now know how to build a repository of my code, create an HTML document and use CSS to style it. What now?

🧙‍♂️ - The logical projection from here is learning JavaScript. It's the universal programming language for websites and it is supported by all main web browsers. This is where the core of your journey should be focused on, and the stepping stone that you'll use to learn libraries and frameworks in the future. You should take your time in learning JavaScript, and avoid jumping into a library or framework without feeling comfortable with JavaScript first.

🧑‍💻 - I couldn't agree more! I'm now working professionally with React but I find myself using JavaScript code and concepts learned in this stage of my studies all the time.

Steps:

1. freeCodeCamp: JavaScript Algorithms and Data Structures Certification. Start by taking this free course so you can have a basic and general idea about JavaScript.

2. Udemy course: The Complete JavaScript Course 2022: From Zero to Expert! . After finishing freeCodeCamp's course, take this one on Udemy. It's the best course I have ever taken on Udemy, and it will not only teach you JavaScript (in depth), but also programming concepts and best practices. This is a must-do!

3. Book: Eloquent JavaScript, 3rd edition. You can read this book in digital format for free, or you can buy it in physical format from Amazon. It's a great book, but a bit too technical for beginners. If you still have spare time, read it; if you don't want to spend more time in this section, skeep it and revisit it in the future. Most of the concepts covered in the book are also covered in the previous Udemy course.

5th step: React

🧑‍💻 - I feel like Neo when he said "I Know Kung Fu".

🧙‍♂️ - Unfortunately, chances are that by now you were too focused on learning by absorbing information. What you should be doing by now is putting that knowledge into practice. This step is ideal for that. Now you are going to learn JavaScript's libraries and frameworks. You have a bunch of them to choose from, and the one you select should depend on what is being used in your area (a quick job search will tell you that). The top three you can choose from are:

JavaScript libraries:

• React

JavaScript frameworks:

• Vue

• Angular

This might help you to get an idea of how they compare among themselves in terms of interest:

Source.

🧙‍♂️ - I recommend choosing React, as it is very used worldwide, and you can use it to design mobile or desktop applications in the future (using React Native) if that's something you are interested in.

Steps:

1. freeCodeCamp: Front End Development Libraries Certification. Start by taking this freeCodeCamp course to get a feel of React. You will learn how web applications are built professionally, in the real world.

2. Udemy course: React - The Complete Guide (incl Hooks, React Router, Redux). Maximilian will teach you (and reinforce) programming concepts as well as React in depth. This is a very good, up to date, course, and I can recommend it.

6th step: Job Ready

🧑‍💻 - OK, so, I have spent several months learning all of this and building many projects by myself (with Google's help). What should I do next?

🧙‍♂️ - Once you have finished all these courses and built some applications and projects of your own, you are now ready to start applying for Front-end Development jobs. Now you should be building your portfolio, writing a good resume and LinkedIn profile, and reviewing the most important concepts learned so far.

🧙‍♂️ - The whole path to get to this point will take you from 6 months to 1.5 years (or more), depending on your previous knowledge and how well you are learning the concepts you are presented with.

7th step: Going Back-end

🧙‍♂️ - The Front End Developer path is far from over, but by now you should feel comfortable enough to jump into the Back-end. But that is a story for some other time.

🧑‍💻 - Thanks, coach Gandalf! I wish you were real so I could high-five you!

🧙‍♂️ - Remember this: you are the hero of your story. Ask yourself: what would a hero do in my situation? How does a hero endure these obstacles, slay these dragons?

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

🐦 TWITTER - Follow me on Twitter.