DEV Community: Renato Silva

Architecture Saved My Project - Swapping an ORM for Pure SQL in Minutes

Renato Silva — Fri, 17 Apr 2026 19:02:47 +0000

In the world of software development, we are often told that Clean Architecture and SOLID principles are "over-engineering" for small projects. This week, I proved that theory wrong in the most practical way possible: I fired my ORM.

The Goal

I was building a Minimalist Feedback API. The plan was simple: use Prisma 6 with SQLite to persist data. I had already built my Core Domain (Entities) and Business Logic (Use Cases), keeping them isolated from external frameworks.

The Problem: When Tools Fight Back

As I moved to the infrastructure layer, I integrated Prisma 6. However, I ran into unexpected breaking changes and rigid configuration requirements—specifically the deprecation of certain URL properties in the schema files that were previously standard.

I had two choices:

Spend hours debugging a tool's internal configuration and fighting its "opinionated" setup.
Rely on my architecture to swap the tool entirely.

The Pivot: From Prisma to SQLite

Because I used the Repository Pattern, my Use Cases didn't know Prisma existed. They only knew about an abstract interface (or contract) called FeedbackRepository.

I decided to drop the ORM and implement a native SqliteFeedbackRepository using the standard sqlite3 driver.

1. The Repository Swap

I created a new implementation. Note how the logic remains focused only on data persistence, keeping the code clean and predictable:

// src/repositories/sqlite/sqlite-feedback-repository.js
const sqlite3 = require('sqlite3').verbose();
const { FeedbackRepository } = require('../feedback-repository');
const { randomUUID } = require('crypto');

// Connect to the database file
const db = new sqlite3.Database('./database.db');

class SqliteFeedbackRepository extends FeedbackRepository {
  /**
   * Persists a new feedback into the SQLite database
   */
  async create(data) {
    const id = randomUUID();
    const createdAt = new Date().toISOString();

    return new Promise((resolve, reject) => {
      const stmt = db.prepare(
        "INSERT INTO feedbacks (id, name, email, message, createdAt) VALUES (?, ?, ?, ?, ?)"
      );

      stmt.run(id, data.name, data.email, data.message, createdAt, (err) => {
        if (err) return reject(err);
        resolve({ id, ...data, createdAt });
      });

      stmt.finalize();
    });
  }

  /**
   * Retrieves all feedbacks from the database
   */
  async listAll() {
    return new Promise((resolve, reject) => {
      db.all("SELECT * FROM feedbacks ORDER BY createdAt DESC", [], (err, rows) => {
        if (err) return reject(err);
        resolve(rows);
      });
    });
  }
}

module.exports = { SqliteFeedbackRepository };

2. Dependency Injection in Action

In my server.js, the only change required was the import line. This is the Liskov Substitution Principle in the real world: the ability to replace an implementation with another without breaking the system.

// server.js
// Swapping the implementation is as simple as changing one line:
const { SqliteFeedbackRepository } = require('./repositories/sqlite/sqlite-feedback-repository');

// The rest of the setup remains identical!
const repository = new SqliteFeedbackRepository(); 
const submitFeedback = new SubmitFeedback(repository); // Use Case stays the same!

Why This Matters

If my database logic had been leaked into my Routes or Use Cases, a change like this would have forced me to rewrite a significant portion of the application.
Instead, it took me less than 10 minutes to pivot and have a fully working API again.

"Software architecture is the art of postponing decisions until you have more data. Or in this case, the art of making tools replaceable."

Key Takeaways

Don't be a hostage to your tools: If a library is causing more friction than value, be ready to replace it.
Isolate your Domain: Keep your business rules pure. They should not care if you are using an ORM, a Cloud DB, or a simple text file.
Pragmatism > Hype: Sometimes, "boring" technology like native SQL is exactly what you need to keep the project moving forward.

What about you?
Have you ever had to swap a core library mid-project? Let's discuss in the comments!

Check out the live API here: [https://https://minimalist-feedback-api.onrender.com/feedbacks]
(Note: Since this uses a free-tier ephemeral SQLite, the data resets on every deploy)

Final Thoughts

The biggest takeaway from this project was learning how to navigate version incompatibilities between technologies.

I saw firsthand how a solid architecture acts as a safety net. It turned what could have been a complete project restart into a series of manageable, easy-to-execute changes. Tools will always change, but good architecture ensures your business rules remain constant.

Beyond the Terminal: Why My Next Project is a Minimalist API

Renato Silva — Tue, 31 Mar 2026 17:53:05 +0000

Moving from local tools to network services. Let's talk about the architecture and challenges of building a professional Feedback API.

In my last posts, I shared the journey of building a CLI tool with a focus on simple architecture and automated testing. It was a success in terms of local automation.

But in the real world, software often needs to live on the network. It needs to be available for multiple users, persist data in a database, and handle concurrent requests.

That’s why my next project is a Minimalist Feedback API.

Here is why I’m building it and the "Senior-level" architectural choices I’m making.

The Use Case: A Universal Feedback Bridge

Many developers build beautiful static portfolios (using Astro, Next.js, or Hugo). But when it comes to adding a "Contact Me" or "Feedback" form, they hit a wall. They usually end up using a third-party paid service or a complex backend.

I’m building a lightweight, professional service that any static site can "talk to" to store messages and feedbacks.

The Architectural Shift: Clean Thinking

For this API, I’m not just throwing everything into a single server.js file. I’m introducing a simplified version of Clean Architecture.

1. Domain First, Framework Second

The "Business Logic" (what defines a valid feedback) should not depend on whether I'm using Express, Fastify, or even if I'm saving to MongoDB or PostgreSQL. The heart of the application will be isolated.

2. Validation as a First-Class Citizen

In a CLI, you control the input. In an API, the world is a chaotic place. I’ll be using Zod to ensure that only "clean" data enters my system. No validation, no entry.

3. Dependency Injection

I want to be able to test my logic without actually hitting a real database. By using Dependency Injection, I can swap a "Real Repository" for a "Mock Repository" in my tests instantly.

The Tech Stack for 2024/2025

To keep it modern and fast, I’ve chosen:

Node.js (Runtime)
Fastify: Faster and more modern than Express, with great TypeScript support.
SQLite + Prisma: For easy setup and type-safe database queries.
Jest: Because a professional API without tests is just a disaster waiting to happen.

What to Expect in the Next Posts

I’ll be documenting the Step-by-Step construction of this API.

Part 1: Designing the Domain and Entities.
Part 2: Setting up the HTTP Layer with Fastify.
Part 3: Database Integration and Migrations.
Part 4: Deploying with Docker/Cloud.

The goal isn't just to show you "how to code an API," but how to engineer a service that you’d be proud to show in a technical interview.

When you build an API, what is your biggest challenge? Authentication, Database design, or Deployment? Let's talk in the comments!

Stop Losing Your Documentation Images: Building a Practical CLI with Node.js

Renato Silva — Sun, 29 Mar 2026 15:58:22 +0000

External images in Markdown are a risk. I built a tool to solve this, focusing on simple architecture and testability.

Have you ever opened an old GitHub repository or a blog post only to find "broken image" icons everywhere?

It happens because we rely on external hosts. If the host goes down, your documentation dies.

In my last articles, I talked about Senior Mindset and Simple Architecture. Today, I’m putting those words into practice. I built MIL (Markdown Image Localizer): a CLI tool that finds remote images in your files, downloads them locally, and updates your links automatically.

Here is how I built it and why the "how" matters more than the code itself.

The Problem: The Fragility of the Web

We often use direct links for images in Markdown.

Dependency: If the source site changes, your image breaks.
Offline Access: You can't read your docs properly without internet.
Manual Labor: Downloading 20 images and updating 20 links manually is a waste of an engineer's time.

The Solution: MIL (Markdown Image Localizer)

I designed this tool following three core principles: Simplicity, Separation of Concerns, and Testability.

1. Simple Architecture

Instead of one giant file, I split the logic:

Parser: Pure logic to find URLs using Regex.
Downloader: Handles the I/O and HTTP requests.
Processor: Orchestrates the flow.
CLI: The entry point that talks to the user.

Why? Because if I want to turn this into a VS Code extension or a Web API tomorrow, the "Core" logic is already isolated.

2. Reliability through Testing

I didn't just "hope" the Regex worked. I implemented unit tests using Jest.
Before the first commit, I ensured that:

It ignores local images.
It handles duplicate URLs (no redundant downloads).
It returns empty results when no images exist.

"Code without tests is just a rumor."

See the Code

You can check the full source code, the folder structure, and the tests here:
👉 GitHub: markdown-image-localizer

How to run it:


bash
git clone [https://github.com/rj-dev/markdown-image-localizer](https://github.com/rj-dev/markdown-image-localizer)
npm install
node index.js your-file.md

The Art of Finishing: Why a Working "Simple" Project is Worth More Than a Perfect "Unfinished" One

Renato Silva — Sun, 29 Mar 2026 11:21:40 +0000

We all have a folder full of unfinished projects. Here is why finishing a small, simple tool is the best thing you can do for your career right now.

We’ve all been there.

You have a "revolutionary" idea for a SaaS. You spend three days picking the perfect CSS library. Two days setting up a complex Docker environment. Another week debating which state management tool to use.

And then... you stop.

The project stays in your /dev folder, gathering digital dust.

In the professional world, an unfinished "perfect" architecture is worth zero. A simple, working, and tested script that solves a real problem is worth everything.

As I prepare to launch my first practical projects here on DEV.to, I want to talk about the "Mindset of Done."

1. The "Scope Creep" Trap

The reason we don't finish things is that we let the scope grow too fast.
"It needs a login!"
"It needs a dashboard!"
"It needs to be mobile-responsive!"

The Senior Approach: Cut everything until you have the Minimum Viable Value. If you are building a CLI tool to rename files, just make it rename files. Everything else is a distraction for "Version 2."

2. Shipping is a Feature

Shipping—actually putting your code on GitHub with a README and a release—is a skill.

When you finish a project, you deal with the "unfun" parts that teach you the most:

Fixing that last annoying bug.
Writing the installation guide.
Setting up a simple CI/CD.

Recruiters don't look for "Genius in Progress." They look for "Engineers who Deliver."

3. The "90/10" Rule of Software

The first 90% of a project is fun. The last 10% (documentation, edge cases, final polish) is where the real engineering happens.

Most developers quit at 90%. If you can push through that last 10%, you are already ahead of the majority of the market.

How AI Helps You Cross the Finish Line

I use AI specifically to kill the "Last 10%" friction:

"The Boring Stuff": I ask AI to generate the package.json or requirements.txt based on my imports.
"README Architect": I describe my project and ask: "Write a clear 'How to Install' section for a beginner."
"Edge Case Hunter": I share my logic and ask: "What is the one thing that will make this crash when a user runs it for the first time?"

AI is my "Finishing Assistant." It handles the friction so I can focus on the core value.

Next Week: The First Commit

I’m done talking about theory.

Next week, I’ll be sharing the first repository of this series: A CLI Tool built with Simple Architecture. It’s not going to be a 10,000-line monster. It’s going to be a clean, tested, and finished piece of software that solves a specific problem. I’m doing this to show you that "Simple and Done" is the ultimate senior flex.

How many unfinished projects do you have in your folders right now? Let's be honest in the comments!

The Seniority Gap: Why Companies Hire Solutions, Not Just Syntax

Renato Silva — Thu, 19 Mar 2026 19:37:49 +0000

Technical skills are the baseline. But what actually gets you hired at high-level positions? Let's talk about the gap between coding and engineering.

I’ve interviewed hundreds of developers over the last decade.

Many of them were brilliant at solving LeetCode puzzles. They knew every obscure feature of their favorite language.

But when I asked them: "How would this code impact the business if the requirements changed tomorrow?"... they went silent.

This is the "Seniority Gap." Companies aren't looking for people who can just type code. They are looking for Engineers who can bridge the gap between a business problem and a sustainable technical solution.

Before I share my upcoming practical projects on GitHub, I want to talk about the three pillars that actually make a developer "Hirable" in today's market.

1. Context Over Syntax

A junior developer focuses on how to write a loop. A senior developer focuses on why that loop is necessary and if there’s a way to avoid it entirely.

When you show a project to a recruiter, don't just show the code. Explain the context:

What problem were you solving?
Why did you choose this specific approach over others?
What were the constraints?

2. The "Maintainability" Mindset

Code is written once, but read and modified a thousand times.

If your project is "clever" but impossible to understand six months later, it’s a liability, not an asset.

In the professional world, clarity is more valuable than brilliance. High-level developers write code that looks "obvious" because they’ve done the hard work of simplifying the complex.

3. Ownership and "The Big Picture"

Professional engineering is about taking ownership.

It’s about knowing how your code is deployed.
It’s about understanding if your API is slow for the end-user.
It’s about ensuring that your tests actually protect the business logic.

When you demonstrate that you care about the entire lifecycle of the software, you stop being a "task-taker" and start being a "partner."

How AI Helps You Close the Gap

AI is the ultimate tool for expanding your perspective beyond the code editor. Use it to simulate "Business Thinking":

"Roleplay as a Product Manager": Feed your project idea to the AI and ask: "What are the 3 biggest risks for this project from a business perspective?"
"Critique my Architecture": Ask: "If I need to scale this to 10x the users, where will it break first?"
"Documentation for Humans": Use AI to help you write a README that speaks to both developers (technical) and managers (value-driven).

AI handles the "how," which leaves you free to master the "why."

Final Thought: Setting the Stage

In my next posts, I will finally open my GitHub for the projects I’ve been talking about.

But I won't just dump code there. I’ll be applying everything we’ve discussed: Simplicity, Testing, and Business Value. I want to show you that a "Senior Portfolio" isn't about how many stars you have, but about how clearly you demonstrate your ability to solve real problems.

Are you ready to stop just "coding" and start "engineering"? What’s the biggest non-technical challenge you face at work? Let’s discuss below!

Mistakes I Made as a Developer (And What They Taught Me)

Renato Silva — Sun, 15 Mar 2026 09:17:50 +0000

If you stay long enough in software development, you will make mistakes.

Not small ones.

Real ones.

Bugs in production.

Bad architectural decisions.

Features that had to be rewritten from scratch.

When I started my career, I thought good developers avoided mistakes.

Now I understand something different:

Good developers learn faster from them.

Here are some mistakes I made during my journey — and what they taught me.

1. Trying to Know Everything

Early in my career I believed I needed to understand everything.

Every framework.

Every new tool.

Every programming language trend.

The result?

Constant context switching.

I was learning many things, but mastering none.

What I eventually realized is that depth matters more than breadth.

It's better to deeply understand a few tools than to superficially know many.

2. Writing “Perfect” Code Too Early

Another mistake I made was trying to write perfect code from the beginning.

Spending too much time:

refactoring early
overthinking architecture
worrying about edge cases that never happened

But software development is iterative.

Often the best approach is:

Write something simple → make it work → improve it later.

Perfection too early slows progress.

3. Avoiding Asking Questions

For a long time I hesitated to ask questions.

I thought it might make me look inexperienced.

So instead I would spend hours stuck on problems that could have been clarified in minutes.

Eventually I realized something important:

Good teams respect thoughtful questions.

Asking for help is not weakness.

It's efficiency.

4. Underestimating the Importance of Communication

At first I believed programming was mostly about writing good code.

But over time I learned that communication is just as important.

Explaining decisions.

Discussing trade-offs.

Aligning with teammates.

Great developers are not only good coders.

They are also good communicators.

5. Ignoring the Bigger Picture

When you're early in your career, it's easy to focus only on the code in front of you.

But software exists inside larger systems.

Understanding things like:

system architecture
user impact
scalability
product goals

changes the way you approach problems.

Coding becomes more intentional.

6. Waiting Too Long to Build Personal Projects

For a long time, most of my coding happened only at work.

But personal projects teach things that professional environments sometimes don't.

They give you:

full ownership
freedom to experiment
the chance to try new ideas

Even small projects can expand your thinking as a developer.

7. Not Realizing How Long the Journey Is

In the beginning, I thought becoming a strong developer would happen quickly.

But this field is a long-term journey.

There is always more to learn.

New tools.

New patterns.

New ways to solve problems.

And that's actually one of the best parts of it.

Final Thought

Mistakes are not the opposite of progress.

They are part of it.

Every developer has a list of things they would do differently today.

The important thing is to keep learning from those experiences and keep moving forward.

Because in software development, improvement is continuous.

And that's what makes the journey interesting.

Why I’m Choosing Simplicity for My Next GitHub Projects

Renato Silva — Sun, 15 Mar 2026 09:10:12 +0000

I’m starting a series of practical projects to demonstrate that clean, simple architecture is the best way to build software. Here is the plan.

In my last post, I talked about why Simple Architecture is a superpower.

But talk is cheap. Code is what matters.

To prove that you don't need overengineered systems to build high-quality software, I’m starting a series of small, real-world projects that I’ll be sharing on GitHub.

My goal is twofold:

To show that a clean, well-tested "boring" stack is often better than a complex trendy one.
To help other developers see how to structure projects that are easy to maintain and scale.

Here is the "Mental Framework" I’m using to choose my tools and why this matters for your career too.

1. The "Boring Technology" Rule

For these projects, I’m avoiding the "flavor of the week" frameworks.

I’m choosing technologies that are stable, have great documentation, and a strong community. Whether it's Node.js, Python, or Go, the focus isn't on the language itself, but on how I solve problems with it.

Why? Because companies don't want a developer who experiments with their production code. They want someone who delivers reliable solutions.

2. Focus on "Core Logic" first

In the upcoming projects, you will notice that the business logic is separated from the framework.

If I’m building a CLI Tool (my first project!), the logic that calculates a task shouldn't care if it's running in a terminal or a web server. This is the heart of simple architecture.

3. README as a First-Class Citizen

A project without a good README is like a book without a cover.

For every repo I share, I’m focusing on:

The "Why": What problem does this solve?
The "How": Clear installation and usage instructions.
The "Tests": Showing that the code works as expected.

How AI is Helping Me Prototype Faster

I'm using AI to speed up the "setup" phase of these projects. Here’s how:

"Boilerplate Generation": Instead of spending an hour setting up a folder structure, I ask AI to generate a clean, modular structure based on my architectural rules.
"Documentation Drafts": I feed my code to the AI and ask it to write the first draft of the README. I then refine it to ensure it has my "voice" and technical accuracy.

AI allows me to focus on the decisions, while it handles the repetition.

What’s Coming Next?

The first project will be a CLI Tool designed to solve a common developer pain point. It will be small, fast, and 100% open-source.

I want to show you that a professional repository isn't about the number of files, but the quality of the decisions inside them.

What do you value most when you look at someone's GitHub? The complexity of the code or the clarity of the documentation? Let's talk below!

Simple Architecture: The Secret Skill of High-Impact Developers

Renato Silva — Sun, 08 Mar 2026 16:01:13 +0000

Most developers overcomplicate systems thinking it makes them look "senior." Real seniority is building things that stay simple.
tags: architecture, programming, softwaredevelopment, career

When I started my career, I thought a "Senior Architect" was someone who could draw the most complex diagrams.

I thought that if a system didn't have layers of abstractions, microservices, and design patterns everywhere, it wasn't "professional."

I was wrong.

After 10+ years, I realized that complexity is a debt you pay every day.

The most impressive thing you can build is a system that a junior can understand in 30 minutes, but that can still handle millions of requests.

Here is how you can start thinking about "Simple Architecture."

1. YAGNI (You Ain't Gonna Need It)

This is the golden rule.

We often build "generic" solutions because we think: "What if we need to change the database next month?" or "What if we need to scale to a billion users tomorrow?"

Reality check: You probably won't.

When you build for a future that hasn't happened yet, you are wasting the company's time and making the current code harder to maintain.

The Simple Rule: Build for the problems you have today. Design your code to be easy to change, not pre-built for everything.

2. Follow the "Delete" Principle

A good architecture is not measured by how much code you add, but by how much code you can safely delete.

If your "Business Logic" is mixed with your "Database Logic" and your "UI Logic," you can't change anything without breaking everything.

The Simple Fix: Keep things separated.

Keep your rules in one place.
Keep your data access in another.
Make sure they talk to each other through clear, simple "contracts."

3. Don't Invent Your Own Problems

Before you decide to use a complex tool (like Redux, Kubernetes, or a NoSQL database), ask yourself: "Does this solve a problem I actually have, or am I just following a trend?"

Sometimes, a simple SQL table and a well-organized folder structure are all you need for 90% of projects.

How AI Can Help You "Simplify"

AI is great at generating code, but it's even better at simplifying it. Use it as a "Complexity Auditor":

"Spot the Overengineering": Paste a piece of your architecture/code and ask: "Is there a simpler way to achieve this result without these abstractions?"
"Explain the Logic": Ask AI: "If a Junior developer reads this, what would be the most confusing part?" Then, refactor that part.
"Contract Design": Use it to help define simple interfaces between your modules, ensuring they stay decoupled.

AI can help you find the shortest path between a problem and a solution.

Final Thought: The Path to Your Next Project

Simple architecture isn't about being "lazy." It's about being strategic.

In my next posts, I’m going to start sharing small, real-world projects on GitHub that follow these principles. No "hello world" stuff, but real tools built with simplicity and scalability in mind.

If you want to build a portfolio that actually catches the eye of a recruiter, stop showing them how "complex" you can be. Show them how efficient you are.

What is the most overengineered system you've ever worked on? Tell me your horror stories in the comments!

Why You Hate Testing (And How to Stop Worrying About Your Code)

Renato Silva — Fri, 06 Mar 2026 09:27:09 +0000

Testing isn't about finding bugs. It's about buying your freedom and sleeping better at night. Let's change how you look at QA.
tags: testing, programming, career, softwaredevelopment

"I don't have time to write tests. I have features to deliver."

I said this for years.

I thought I was being productive. I thought I was fast.

But I wasn't fast. I was just leaving a trail of "time bombs" behind me.

Every time I touched an old piece of code, I was terrified of breaking something. Every deployment felt like a gamble. Every weekend, I was afraid of getting a notification that the production server was down.

If you hate testing, it’s probably because you’re looking at it the wrong way.

1. Testing Is Not for the Machine

The computer doesn't care if your code is tested. It will run whatever you give it.

Testing is for You.

It’s a gift you give to your "Future Self."

When you have a solid test suite, you gain the freedom to refactor, the freedom to change frameworks, and the freedom to go on vacation without checking your email every five minutes.

2. Don't Test "Implementation," Test "Behavior"

The biggest reason developers struggle with tests is that they try to test how the code works.

If you change a variable name and your tests break, your tests are too fragile.

The Secret: Test the output, not the journey.
If I put 2 + 2 into the function, I expect 4. I don't care if the function uses a loop, a library, or magic to get there. Focus on the results that matter to the user.

3. The "Cost of Fixing" Rule

A bug found during development costs $1 to fix.
A bug found in a Pull Request costs $10.
A bug found in Production costs $100 (and your reputation).

Writing tests is like paying for insurance. You hope you never need it, but you're incredibly glad it's there when a disaster happens.

4. Start Small: The "One-Test" Rule

Don't try to reach 100% code coverage overnight. It’s a trap.

Start by testing the "Happy Path"—the most common way a user uses your feature. If that works, you’ve already eliminated 80% of the risk.

Confidence is built one test at a time.

How AI Can Help You Write Better Tests

Writing tests used to be tedious. Not anymore. You can use AI to do the "heavy lifting" so you can focus on the logic:

"Generate Edge Cases": Paste your function and ask AI: "Give me 5 edge cases (null values, empty strings, huge numbers) that could break this code."
"Explain the Failure": If a test fails and you don't know why, ask AI: "This test is failing with error X. Based on this code, what am I missing?"
"Boilerplate Assistant": Use AI to generate the repetitive setup code (Mocks and Stubs) so you can get straight to the assertions.

AI makes testing faster, but your human experience is what decides what is worth testing.

Final Thought

A Senior Developer isn't someone who never makes mistakes.

A Senior Developer is someone who builds systems that catch those mistakes automatically.

Stop thinking of testing as a chore. Start thinking of it as your "Freedom Policy."

How do you feel about testing? Is it a part of your daily workflow or a "nice-to-have" that never happens? Let's talk in the comments!

How to Read Code You Didn't Write (Without Losing Your Mind)

Renato Silva — Tue, 03 Mar 2026 20:01:16 +0000

Reading other people's code is a superpower. Here is a practical guide on how to navigate a new codebase without feeling overwhelmed.

Opening a new, massive codebase for the first time feels like being dropped in the middle of a foreign city without a map.

The folders are unfamiliar.
The naming conventions are strange.
The logic seems to jump from one file to another for no apparent reason.

When I was a junior, this terrified me. I thought that if I couldn't understand it all in ten minutes, I wasn't "smart enough" for the job.

But here is the truth: Reading code is harder than writing it.

Even for experienced engineers.

If you are struggling to understand a legacy project or a teammate’s Pull Request, here is a mental framework to help you navigate the chaos.

1. Stop Trying to Understand Everything at Once

The biggest mistake is trying to read a codebase like a book—from start to finish.

Software is a web, not a linear story.

If you try to understand every single line in your first hour, you will burn out before you even find the main function.

The Fix: Focus on a single "Path of Execution." Pick one feature (e.g., "User Login") and follow only the code related to that specific flow. Ignore everything else for now.

2. Find the "Entry Points"

Every application has a starting point.

In a React app, it might be App.tsx or your router file.
In a backend API, it’s the Routes or Controllers.
In a script, it’s the main function.

Start there. Ask yourself: "Where does the data enter the system?" Once you find the door, it's much easier to follow the hallway.

3. Look at the Tests (The Secret Documentation)

If the project has good tests, you are in luck.

Documentation can lie or be outdated. Tests never lie.

Read the test descriptions (the it or test blocks). They tell you exactly what the code is supposed to do in plain English. If you see a test named should_return_error_when_email_is_invalid, you’ve just learned a business rule without reading a single line of complex logic.

4. Use "Print Debugging" as a Compass

Sometimes, modern IDEs and debuggers are overkill when you just want to see how things connect.

Don't be afraid to sprinkle some console.log or print statements throughout the code.

"Did the code reach this line?"
"What does the data look like at this point?"

Seeing the output in your terminal makes the abstract code feel real and tangible. Just remember to delete them before you commit!

5. Reverse Engineer the UI

If it's a frontend project, use the browser's "Inspect Element" tool.

Find a unique CSS class or a specific piece of text on the screen. Then, search for that string in your code editor. This will lead you directly to the component responsible for that part of the app.

It’s like working backward from the result to the cause.

6. Write Your Own Comments

As you explore, you will figure things out. Don't let that knowledge vanish.

Add temporary comments:
// This function calculates the total price including tax
// This part seems to handle the database connection

Treat the codebase like a map you are drawing while exploring a cave. These notes are your breadcrumbs.

7. Use AI as Your "Code Translator"

We live in an era where you don't have to decipher complex logic alone. AI can be a powerful ally when reading unfamiliar code—if you use it correctly.

Instead of asking "What does this whole project do?", try these specific prompts with a snippet of code:

"Explain the data flow in this function": Great for understanding how an input becomes an output.
"What are the edge cases handled here?": This helps you see the hidden logic you might have missed.
"Refactor this for readability": You don't have to keep the refactored code, but seeing a "cleaner" version of the same logic can help you understand the original intent.

Treat the AI like a Senior Developer sitting next to you. Ask it questions, but always verify the answers against the actual behavior of the system.

Final Thought

Reading code is a muscle.

The first time you do it, it’s painful. The second time, it’s slightly less confusing. By the hundredth time, you start seeing patterns instead of just syntax.

Don't rush yourself. Be patient with your brain.

You don't need to know how the whole clock works to tell the time.

What is your biggest challenge when joining a new project? Let’s talk about it in the comments!

Things I Wish I Knew When I Started Learning Programming

Renato Silva — Mon, 02 Mar 2026 13:17:49 +0000

When I first started learning programming, I thought the hardest part would be understanding the code.

I was wrong.

The hardest part was everything around it.

The confusion.

The frustration.

The feeling that everyone else understood things faster than I did.

Looking back now, after many years working as a software engineer, there are a few things I wish someone had told me earlier.

Not technical things.

Human things.

1. Feeling Lost Is Part of the Process

In the beginning, everything feels overwhelming.

You see terms like:

APIs
Frameworks
Databases
Containers
Cloud

And it feels like an endless mountain of things you need to learn.

What nobody tells you is that even experienced developers feel lost sometimes.

Technology moves fast.

No one knows everything.

Learning how to navigate uncertainty is part of becoming a developer.

2. Progress Is Slower Than You Expect

When you start learning programming, you often imagine quick progress.

Maybe a few months of study and then things will feel easy.

But real growth in programming happens slowly.

Sometimes you spend hours fixing a tiny bug.

Sometimes you feel stuck for days.

And then suddenly, months later, you realize something that once felt impossible now feels normal.

Growth in programming is quiet.

It happens gradually.

3. Everyone Struggles More Than They Show

When you look at experienced developers online, everything seems polished.

Clean repositories.

Confident explanations.

Well-written code.

What you don't see are the messy parts:

The debugging sessions that took hours
The mistakes
The rewrites
The moments of doubt

Behind every clean solution is usually a lot of trial and error.

4. Building Things Changes Everything

For a long time, I focused mostly on learning.

Courses.

Documentation.

Tutorials.

But the moment things really started to change was when I began building things on my own.

Small tools.

Simple applications.

Experiments.

Building forces you to think.

It exposes gaps in your understanding.

And it creates the kind of learning that sticks.

5. It's Okay Not to Know Everything

One of the biggest mindset shifts in this field is accepting that you will never know everything.

And that's okay.

Being a good developer isn't about knowing all technologies.

It's about:

Learning continuously
Solving problems
Staying curious

The goal isn't perfection.

The goal is progress.

6. The Journey Is Longer Than You Think — and That's Good

Programming is not something you master quickly.

It's a long journey.

But that's part of what makes it interesting.

There is always something new to explore.

A new concept to understand.

A better way to solve a problem.

And over time, what once felt confusing becomes familiar.

Final Thought

If you're learning programming right now and sometimes feel lost, frustrated, or behind…

You're not alone.

Most developers have felt that way at some point.

The important thing is not to rush the process.

Keep learning.

Keep building.

Keep showing up.

Over time, things start to make sense.

And one day you'll look back and realize how far you've come.

5 Signs You're Learning Programming the Wrong Way

Renato Silva — Mon, 02 Mar 2026 13:11:50 +0000

Learning programming today is easier than ever.

Thousands of courses.

Endless tutorials.

AI assistants that can explain almost anything.

And yet, many beginners spend years learning without feeling truly confident.

Why?

Because they are unknowingly learning the wrong way.

Here are five signs that might be happening to you.

1. You Consume More Than You Build

You watch tutorials.

You follow along with instructors.

You understand the explanation.

But when the video ends, you rarely build something on your own.

Learning by watching feels productive.

But programming is a construction skill, not a consumption skill.

You only grow when you struggle to build something yourself.

2. You Keep Restarting From Scratch

Many beginners do this cycle:

Start a course
Reach the middle
Feel confused
Restart another course

It creates the illusion of progress.

But restarting constantly prevents you from reaching the stage where learning actually becomes deep: problem solving.

3. You Avoid Problems That Feel Too Hard

When you encounter something difficult, you might:

Immediately search for the full solution
Copy code without understanding it
Skip the problem entirely

But difficult problems are where real growth happens.

Struggle is not a sign of failure.

It’s a sign that your brain is adapting.

4. Your Learning Has No Direction

Sometimes beginners jump between topics:

Frontend this week
Backend next week
A bit of AI
A bit of cloud
A new framework every month

Exploration is good.

But without focus, your progress becomes shallow.

Depth matters more than variety early on.

5. You Wait Until You Feel “Ready”

Many people delay building real projects because they think:

“I need to learn more first.”

But in programming, readiness comes after action, not before.

Your first projects will be messy.

Your code will be imperfect.

That’s normal.

Every good developer has written bad code.

A lot of it.

A Better Way to Learn Programming

A simple structure works surprisingly well:

Learn a concept
Build something small with it
Break it
Fix it
Improve it

Repeat.

Progress in programming is iterative.

Not linear.

Where AI Fits Into This

AI can accelerate learning.

It can:

Explain errors
Suggest solutions
Generate starter code
Help you debug faster

But AI should support your learning — not replace your thinking.

The key is to understand the solution, not just obtain it.

Final Thought

If learning programming feels harder than it should, the problem might not be your intelligence.

It might be your approach.

Shift from consuming to building.

From avoiding problems to confronting them.

From waiting to starting.

That’s when things begin to change.