DEV Community: DevInTheMaking007

What’s your routine for getting unstuck when you've stared at the same bug for 3+ hours?

DevInTheMaking007 — Sun, 11 Oct 2026 05:29:56 +0000

[Boost]

DevInTheMaking007 — Tue, 06 Oct 2026 13:31:32 +0000

The Monorepo "Aha!" Moment: How to Share Code Without Breaking Everything 🤯

DevInTheMaking007 — Mon, 05 Oct 2026 12:59:16 +0000

Today, I had the incredible opportunity to dive deep into architectural patterns, specifically learning the crucial differences between a Monorepo and a Polyrepo.

When I talk about a Monorepo here, I'm specifically referring to a modular Monorepo. It isn't just a giant dumping ground for code; rather, it’s a system of clubbing multiple applications into a single repository where each application has its own cleanly defined, restricted boundaries.

Here is a quick look at what that structure might look like:
workspace/
│
├── apps/
│ ├── App-1/
│ │ ├── frontend/
│ │ └── backend/
│ │
│ └── App-2/
│ ├── frontend/
│ └── backend/
│
└── libs/
└── shared-backend/

The Good and The Bad ⚖️
This system is fantastic for tightly interconnected systems because it enables incredibly easy code sharing between applications. You don't have to publish internal packages or deal with version-syncing nightmares across different repos.

However, as the applications grow, this architecture comes with its own set of challenges:

The "Huge Repo" Problem: Cloning the repository takes a lot of time.

Disk Space: Local developer machines can face storage issues.

CI/CD Complexity: Build pipelines become complicated and require intelligent caching to only build what changed.

Boundary Discipline: It requires extremely clean and strict module boundaries to prevent spaghetti code.

The Big Doubt: The Shared Code Dilemma 🤔
Looking at the structure above, a major question hit me:
If we are sharing the backend code, what happens if a developer changes a shared function specifically to suit App 1... won't it accidentally break App 2?

The answer is yes, it absolutely will—unless you enforce strict boundaries and restrictions on that shared code. Relying on developers to "just be careful" doesn't scale. We need automated safety nets.

Here are two powerful ways to solve this:

1️⃣ Consumer-Driven Contracts (CDC) 📜
In this approach, the consumers (App 1 and App 2) strictly define what they expect from the shared backend.

How it works: App 1 writes a test stating its expectation. For example: "When I call getUserProfile(id), I expect a JSON response containing email, id, and name."

This expectation is saved into a contract file (often a JSON file) that lives directly inside App 1's test suite. If a developer modifies the shared backend in a way that violates this contract, the test immediately fails, blocking the bad code from ever being merged.

2️⃣ Automated API Guardrails (Linters & Type Checking) 🛡️
Instead of finding out about a breaking change during runtime or testing, we can catch it as the developer is typing.

Linters: We can use workspace lint rules (like those in Nx or Turborepo) to ensure applications can only import from public, stable API endpoints of the shared backend, preventing them from bypassing boundaries.

Strict Type Checking: If a developer alters a function signature in the shared backend (like changing a required parameter), strict type checkers like TypeScript or Pyright (for Python) will immediately detect the mismatch. The developer will see a compile-time error right in their IDE across every single application that consumes that function. They literally cannot compile the code until they fix the breaking change.

Wrapping Up
Moving to a Monorepo isn't just about moving folders around; it's about shifting how you handle dependencies and automation. Implementing contracts and strict compiler guardrails shifts the burden of safety from human memory to automated systems.

What are your thoughts on Monorepos? Have you faced the "shared code breaking everything" issue before? If I missed anything or if you have a different perspective, I would love to hear it! Please drop a polite comment below—let's learn together! 👇

👋 Hello, World! — My Developer Journey

DevInTheMaking007 — Sun, 04 Oct 2026 13:32:12 +0000

Hi! 👋 I’m a 23-year-old software engineer who recently made the transition from Software Testing → Software Development. 💻

For a long time, building and engineering applications genuinely fascinated me. I was always curious about how things work behind the scenes, how applications are designed, how different components communicate, and most importantly — how an idea eventually becomes something people can actually use.

I started my career as a Software Tester, which gave me a completely different perspective on software. But deep down, I always wanted to be on the other side of the process — building the application, solving problems, and turning ideas into working software.

Making the transition from QA to Development wasn't easy. 😅

There were a lot of concepts to learn, a lot of things I didn't understand initially, and plenty of moments where I questioned whether I was actually good enough to make the switch.

But I kept learning.
I kept experimenting.
I kept breaking things.
And, of course, I kept fixing them. 😂

And eventually, I made the transition. 🚀

Now, I want to use this space as my developer journal — a place where I document what I learn along the way.

It could be something big like understanding a new architecture or something as simple as finally understanding a concept that confused me for days.

I’ll share it all. 📝

🤝 Learn With Me

I don't consider myself an expert. I'm still learning every single day.

So if you come across something I write that is incorrect, incomplete, or could be explained better, please feel free to correct me — politely. 😄

I'd genuinely appreciate it.

Because I believe one of the best ways to learn something is to try explaining it to someone else.

Maybe sharing what I learn will also help me become more confident in my own progress. 🌱

So this isn't a blog where I pretend to know everything.

It's simply a place where I can say:

"This is what I learned today. This is how I understood it. Let's see how far I can go." 🚀

If you're also learning software engineering, switching careers, or simply curious about how software is built, you're welcome to learn along with me. 👨‍💻

Let's build, break, learn, and improve together. 🚀