One GET Method, Not Ten: The Architecture Lesson That Rewired How I Think

This week I had one of those moments as a developer where a single sentence from a mentor rearranged how I see code.

I was building a feature — nothing fancy. I needed to retrieve data from my database based on different enums I had created. My plan was straightforward:

One method per enum. Clean. Organized. Done.

I was proud of it. Then my mentor looked at my code and said:

"You can actually create one HTTP GET method and use the enum type as the argument."

One sentence. Everything changed.

The Problem With "One Method, One Job"
I want to be clear — I wasn't being lazy. I was being naive about architecture.

I thought writing more methods = writing better code. I thought verbosity meant thoroughness. But here's what I missed:

If you're copy-pasting methods that differ only by a parameter, you're not architecting — you're repeating.

Here's roughly what my instinct told me to write:

[HttpGet("status/active")]
public IActionResult GetActiveItems() { ... }

[HttpGet("status/pending")]
public IActionResult GetPendingItems() { ... }

[HttpGet("status/archived")]
public IActionResult GetArchivedItems() { ... }

Three methods. Three routes. Three places to update when the logic changes.

Then my mentor showed me what it should look like:

[HttpGet("items/{status}")]
public IActionResult GetItemsByStatus(ItemStatus status)
{
    var items = _repository.GetByStatus(status);
    return Ok(items);
}

One method. One route. One source of truth.

The enum does the branching. The parameter does the work. The architecture stays clean.

Why This Matters Beyond the Code
This wasn't just a refactor. It was a lesson in software architecture principles:

DRY (Don't Repeat Yourself) — if the logic is the same, the method should be the same.

Single Responsibility, done right — one method can handle multiple cases if the variation is data, not logic.

Open/Closed Principle — adding a new enum value doesn't require a new method. The system extends without modification.

Less surface area — fewer endpoints means fewer bugs, fewer tests, fewer things to break.

The biggest takeaway? Architecture isn't built in big design docs. It's built in the small decisions you make when nobody's watching.

PUT vs PATCH: The Assumption That Humble Me
Same week, same project — I learned something else that embarrassed me a little.

I had been using PUT and PATCH as if they were interchangeable. I assumed they both just meant "update." I never questioned it.

They are not the same.

Method What it does When to use it
PUT Replaces the entire resource Full updates — send the

whole object
PATCH Updates only the fields you send Partial updates —
change one field, leave
the rest

Here's what that looks like in practice:

# PUT — replaces the entire resource
PUT /api/users/1
{
  "name": "John",
  "email": "[e-mail]",
  "role": "admin"
}

# PATCH — updates only what you send
PATCH /api/users/1
{
  "email": "[e-mail]"
}

With PUT, if you omit a field, it gets wiped. With PATCH, omitted fields stay untouched.

Small words. Completely different behavior. And I had been throwing them around casually as if the difference didn't matter.

Lesson: The things we assume we know are often the things we understand the least.

GitHub + Visual Studio: The Quiet Win
Not everything this week was a philosophical breakthrough. I also finally connected GitHub to Visual Studio so I can push my work straight from the IDE to my remote repo.

On paper, it's a few clicks. In practice, it removed friction from my daily workflow — and friction is what kills momentum.

Here's the quick version if you haven't done it yet:

# Or from the terminal inside VS:
git init
git add .
git commit -m "Initial commit"
git remote add origin https://github.com/yourname/yourrepo.git
git push -u origin main

That's it. Now every commit goes from my editor to GitHub without leaving the IDE.

The Three Lessons I'm Walking Away With

1. Simplicity is a skill, not a shortcut.
   Anyone can write more code. Real discipline is writing less and making it mean more.

2. Assumptions are the enemy of growth.
   The moment you stop questioning what you "already know" is the moment you stop growing.

3. Small wins compound.
   A mentor's sentence. A corrected assumption. A connected tool. None feel big in the moment — but stacked, they build the developer you're becoming.

Your Turn
I'm curious:

What's one "small decision" that quietly changed how you write code?

Was it a mentor's correction? A refactor you resisted? A tool you finally set up? Drop it in the comments — I'm learning in public and I want to learn from you too.

I'm a developer learning in public — sharing real lessons from real projects. Follow me here on Dev.to, or connect on [LinkedIn] and [X]. Let's grow together.