DEV Community: Blessed Emmanuel John chidera

PROGRAMMER, QUICK QUESTION:

Blessed Emmanuel John chidera — Thu, 24 Sep 2026 17:42:27 +0000

You could be one of the most talented developers in the room...

but if nobody knows you're in the room, who exactly is going to choose you?

Think about that.

You can learn C#.

You can learn JavaScript.

You can learn Python.

You can learn React, .NET, databases, cloud, AI...

You can collect certificates.

You can build projects.

You can have ten brilliant ideas sitting inside your head.

But if all of that stays hidden...

who knows?

And more importantly:

who can trust that you can actually do it?

Let me show you something.

You are reading this post right now.

You probably didn't know me before you saw it.

You didn't know what I was thinking.

You didn't know that I had this idea.

But I wrote it.

I put it out there.

And now...

you've seen it.

You now know that someone called ##John Kode / ##BlexonDev exists and is thinking about programming, building, learning, and the future of developers.

That is exactly what I mean by putting yourself out there.

This post is the example.

I didn't keep the idea in my head.

I didn't say:

_"I'll post it when I'm better."

"I'll post it when I have more followers."

"I'll post it when I'm an expert."_

I brought it into the lobby.

And you saw it.

 ###Think about an audition.

There is an arena.

Inside that arena, there are halls.

There are passages.

There are rooms.

There is the compound.

And then there is the main lobby.

The lobby is where people are arriving.

People are meeting.

People are introducing themselves.

People are showing what they can do.

People are being noticed.

Now imagine two programmers.

Both are talented.

Both can build.

Both have good ideas.

Both have spent years learning.

But one stays somewhere inside the building, quietly working on his projects.

The other walks into the lobby.

He starts talking to people.

He shows his projects.

He shares what he's learning.

He contributes to communities.

He puts his work online.

He connects with other developers.

He allows people to discover what he can do.

Which one has given opportunity a chance to find him?

That's the difference I'm talking about.

Programming isn't only about learning programming languages.

At some point, you have to ask:

Can I use what I've learned?

Can I build something?

Can I solve a problem?

Can I turn an idea into a working system?

Can I explain what I built?

Can I show my process?

Can I work with other people?

Can I contribute?

Because your skill needs evidence.

Don't just say:

"I know C#."

Show the C# project.

Don't just say:

"I'm learning web development."

Build the website.

Don't just say:

"I understand Git."

Show the repository.

Don't just say:

"I want to become a software engineer."

Start engineering something.

Let your work speak for you.

And once you have something to show...

put it in the lobby.

GitHub.

LinkedIn.

Dev.to.

Medium.

YouTube.

Facebook.

Your portfolio.

Open-source communities.

Developer communities.

Networking events.

Real conversations.

Real projects.

Real contributions.

These aren't just places to collect followers.

They're places where **your work can be discovered.

But there's another side to this.

Being visible without having anything to show isn't enough either.

You can walk into the lobby and announce:

_"I know C#."

"I know JavaScript."

"I have five certificates."

"I have ten ideas."_

And someone can simply ask:

"Show me."

That's where your projects matter.

Your GitHub matters.

Your portfolio matters.

Your documentation matters.

Your ability to explain what you built matters.

Your ability to solve problems matters.

Your consistency matters.

Because the goal isn't to look like a programmer.

The goal is to become one and have evidence to prove what you can do.

So don't misunderstand me.

I'm not saying:

"Stop learning and start posting."

I'm saying:

Learn.

Build.

Break.

Debug.

Document.

Share.

Connect.

Contribute.

And repeat.

Because there is a difference between having potential and giving people an opportunity to discover your potential.

Your talent can be hidden.

Your ideas can be hidden.

Your skills can be hidden.

Your projects can be hidden.

But opportunities cannot interact with what they cannot see.

So, programmer...

Don't spend your entire career waiting inside the building.

Step into the lobby.

Put your work where people can see it.

Let people discover you.

Let your projects introduce you before you even enter the room.

Let your work create conversations.

Let those conversations create connections.

Let those connections create opportunities.

And remember:

You don't have to be the best programmer in the room to enter the lobby.

You just have to be willing to **show up, build something real, and let people see it.

Because maybe...

**the opportunity you're waiting for isn't coming to find you.

Maybe you need to make yourself findable.

So, what are you building?

Don't just tell me.

Show me.

Programming #SoftwareDevelopment #Developers #BuildInPublic #GitHub #TechCommunity #blexondev #johnKode

AI & The Programmer: A Manifesto for Developers Who Refuse to Be Replaced

Blessed Emmanuel John chidera — Tue, 22 Sep 2026 17:59:58 +0000

There's a quiet question spreading through the developer world:

"If AI can write code, what happens to programmers?"

Some respond with denial — believing AI is simply hype and that software development will remain unchanged.

Others respond with surrender — accepting that AI will do the work, while developers simply describe what they want, copy the output, and hope it works.

I believe both responses miss the real question.

The question isn't:

"Will AI replace programmers?"

The better question is:

"What kind of programmer will you become when AI can do more of the work?"

Because AI is not simply something happening to programmers.

It is becoming something programmers can work with.

And that changes our responsibility.

Who This Is For

This is for the beginner writing their first program and wondering whether learning to code still matters.

It is for the developer who has become faster with AI but sometimes wonders whether they are becoming weaker at thinking.

It is for the experienced engineer designing systems, reviewing code, mentoring others, and trying to understand how AI changes the craft.

It is for the self-taught developer building alone.

It is for students, professionals, freelancers, architects, creators, and anyone who wants to use AI without surrendering their ability to think.

Because this is where the conversation should begin:

AI should make you more capable—not less capable.

What We Believe

We believe AI is one of the most powerful tools ever placed in the hands of a programmer.

We also believe that powerful tools can become dangerous shortcuts when the person using them stops thinking.

We believe the value of AI isn't simply how much code it can generate.

Its value is in how effectively a developer can use it to learn, reason, build, investigate, test, review, and improve.

We believe programming fundamentals still matter.

Perhaps more than ever.

Generating code is becoming easier.

Understanding what that code should do, whether it is correct, secure, maintainable, appropriate, and worth shipping remains an engineering responsibility.

We believe copy-pasting code you don't understand is not the same as learning to program.

You may have borrowed a solution.

You haven't necessarily developed the ability to solve the problem yourself.

We believe AI shouldn't only answer our questions.

It should challenge our assumptions.

Expose weaknesses in our reasoning.

Present alternatives.

Help us investigate.

Help us learn.

Help us become better thinkers.

And we believe BY MY SELF does not mean without help.

It means with ownership.

I can use AI.

I can use documentation.

I can use books.

I can use mentors.

I can use communities.

I can use every tool available to me.

But I must still understand what I am building and take responsibility for the decisions I make.

The goal isn't to become a programmer who never uses AI.

The goal is to become a programmer who can use AI without becoming dependent on it.

The Seven Principles

These seven principles form the spine of AI & The Programmer.

Every article, lesson, project, experiment, and BY MY SELF progress update can connect to one or more of them.

1. From Code Generation to Problem Solving

AI can generate code.

But software development begins before the code.

Understand the problem.

Define the requirements.

Identify the constraints.

Break the problem down.

Consider possible solutions.

Then use AI to accelerate the work.

Don't begin with:

"What code should I write?"

Begin with:

"What problem am I actually solving?"

2. From AI as an Answer Machine to AI as a Thinking Partner

The easiest way to use AI is to ask it for answers.

The more valuable way is to use it to improve your thinking.

Ask it to explain.

Challenge your assumptions.

Review your design.

Find weaknesses.

Generate alternatives.

Argue against your solution.

Give you hints instead of solutions.

AI becomes more valuable when the conversation becomes deeper than:

"Write this for me."

3. From AI Assistance to Human Ownership

Using AI doesn't remove responsibility from the developer.

If AI generated the code, you still need to understand it.

If AI proposed the architecture, you still need to evaluate it.

If AI suggested the fix, you still need to verify it.

If AI made the decision easier, you still need to own the decision.

BY MY SELF means the outcome is mine—even when the assistance wasn't.

4. From Copy-Paste to Understanding

Fast code isn't necessarily good code.

Working code isn't necessarily understood code.

Generated code isn't automatically production-ready code.

If I cannot explain it, test it, modify it, debug it, or defend the decision behind it, then I don't truly own it yet.

Use AI to accelerate understanding—not to bypass it.

5. From Accepting AI's Output to Verifying It

AI can be useful.

AI can also be wrong.

It can misunderstand requirements, make incorrect assumptions, invent APIs, produce insecure code, introduce unnecessary complexity, or recommend something inappropriate for the system.

Therefore:

Generate → Inspect → Question → Test → Verify.

Never confuse confidence with correctness.

6. From Learning With AI to Becoming Capable Without It

AI should increase your capabilities, not hide your weaknesses.

Learn the fundamentals.

Practice without assistance.

Build from scratch.

Debug your own mistakes.

Then bring AI into the process.

The goal isn't to prove that you can work without AI every minute.

The goal is to know that:

AI is helping you—not carrying you.

7. From Programmer to AI-Augmented Engineer

The future isn't simply about writing code faster.

It is about thinking at a higher level.

Understanding requirements.

Designing systems.

Making trade-offs.

Reviewing implementations.

Understanding architecture.

Testing assumptions.

Managing complexity.

Communicating decisions.

Using AI throughout the development lifecycle.

The developer of the future isn't merely someone who knows how to prompt.

It is someone who knows:

what to ask, why to ask it, how to evaluate the answer, and what to do with it.

The BY MY SELF Principle

This is the foundation underneath everything I am building.

LEARN

Understand the concept before rushing to implementation.

THINK

Attempt to reason through the problem yourself.

BUILD

Turn your understanding into something real.

BREAK

Allow yourself to encounter mistakes and unexpected behavior.

DEBUG

Investigate instead of immediately searching for a replacement answer.

UNDERSTAND

Find out why the solution works.

DOCUMENT

Record what you learned so the experience becomes reusable knowledge.

REPEAT

Every project becomes another opportunity to become more capable.

AI belongs inside this cycle.

It does not replace the cycle.

My AI Operating Principle

I don't believe there is a universal percentage that every developer must follow.

But I have a personal rule:

Think more than you delegate.

My goal is to spend more of my effort understanding the problem, reasoning about the solution, making decisions, and verifying results than simply producing output.

If AI is doing all the thinking, I'm not becoming a better developer.

If AI is accelerating work I understand and can evaluate, then it is making me more capable.

AI should accelerate my hands—not replace my mind.

The Commitment

I am not writing this from the position of someone who has already mastered everything.

I'm writing it as a developer in motion.

I'm learning programming.

I'm building projects.

I'm making mistakes.

I'm debugging.

I'm experimenting with AI.

And I'm documenting what happens.

My goal is to become a confident, independent developer who can build real software, explain what I build, understand the decisions behind it, and take responsibility for the work I produce.

I'm building under the name Blessed Codes.

I'm laying the foundation for something bigger called BlexonDevco.

And I'm doing it through one principle:

BY MY SELF.

Not alone.

Not unaided.

But with ownership.

The thinking is mine.

The decisions are mine.

The mistakes are mine.

The growth is mine.

The work carries my name.

AI can help me build it.

But AI cannot become me.

The Invitation

If you're a beginner, learn with me.

If you're an intermediate developer, challenge the ideas.

If you're experienced, challenge the standard.

If you're an architect, challenge the assumptions.

If you're building alone, know that independence does not require isolation.

And if you use AI every day, ask yourself:

Is AI making me better—or merely making me faster?

Because faster isn't always better.

A faster developer who understands less isn't necessarily becoming a stronger engineer.

The goal is capability.

The Future

The developers who thrive alongside AI will not necessarily be those who resist it.

Nor will they necessarily be those who surrender everything to it.

They will be the developers who learn to think with AI while remaining capable of thinking beyond it.

They will know when to ask.

When to investigate.

When to challenge.

When to verify.

When to reject an answer.

And when to put the AI aside and solve the problem themselves.

That is the kind of developer I am working to become.

And this series is the record of that journey.

"I'm no longer just preparing to become a developer. I'm becoming one."

Welcome to AI & The Programmer.

Welcome to BY MY SELF.

Welcome to the work.

— John Kodes

We Reinvented OOP by Making a Sandwich (Before Writing Any Code)

Blessed Emmanuel John chidera — Sat, 19 Sep 2026 22:28:18 +0000

A weak developer stares at an empty .cs file and starts typing syntax until the red squiggly lines go away.

A software engineer designs the system before touching a compiler.

Most programming tutorials rush straight into syntax:

"Here is an int. Here is a for loop. Here is public static void Main. Good luck!"

The result? Beginners hit tutorial hell. The second they face a blank screen, their brain locks up. They know the keywords, but they don't know how to decompose a problem.

Inside our engineering mentorship program (BY MY SELF), we ran an experiment with an apprentice named John: Build the entire conceptual foundation of Object-Oriented Programming (OOP) without writing a single line of C# first.

Here is the step-by-step breakdown of how it unfolded—and how it will sharpen your problem-solving skills.

1. The Sandwich Challenge: Computers Have Zero Context

To a human, "Make me a cup of coffee" is simple. Your brain automatically fills in the gaps: find a mug, boil water, add grounds, pour.

A computer doesn't know what "make" is. It doesn't know what "coffee" is. It has zero implied context.

We gave our apprentice his first challenge:

The Challenge:
You are programming an autonomous robot with zero real-world knowledge.
It has: Bread, Butter, a Knife, a Plate, and Cheese.
Write an algorithm that gives step-by-step instructions to assemble a cheese sandwich.

Here was his first attempt:

1. Name the items:
   A = Bread, B = Butter, C = Knife, D = Plate, E = Cheese
2. Place A on D
3. Using C take B = F
4. Then F is placed on A
5. E is placed on F
6. A + B + E = G
7. G + D = result
8. result = Sandwich

It looks reasonable to a human. But let's run an engineering audit on it.

2. Debugging Human Logic

When we reviewed the algorithm like a senior engineer reviewing a Pull Request, three major bugs surfaced:
🐛 Bug 1 : Undefined Verbs ("Take")
Using C take B = F
What does "take" mean to a mechanical robot actuator? Does it slice the butter? Scoop it? Stab the block? At what angle? How many grams?
Engineering Rule: Ambiguity in requirements creates defects in production.
🐛 Bug 2 : Commutativity Fallacy
A + B + E = G (Bread + Butter + Cheese = Sandwich)
In algebra, addition is commutative:
A + B == B + A
Does physical assembly work that way? No!
If you put butter under the bread, you get a greasy plate and a structural catastrophe. You cannot use mathematical operators to hide unstated physical actions.
🐛 Bug 3 : Container Leak
G + D = result (where D = Plate)
If you eat the sandwich, do you eat the plate?
The plate is an execution environment / container (like memory allocation).
The sandwich is the data payload. Conflating your data with your runtime infrastructure leads to memory leaks and dirty architecture.

3. Inventing a Mini-Language: The Birth of "State"

For attempt #2, the apprentice separated ingredients from tools and containers, defining operational verbs:

Entities: Bread, Butter, Cheese
Tools: Knife
Container: Plate
Operations:
SCOOP: Engage knife at an angle to collect butter.
SPREAD: Distribute scooped material evenly over a surface.
LAY: Place an entity onto a base. Then he wrote: SPREAD(Butter, Bread) -> Stack 1 Look closely at what happened here. When butter is spread onto bread, the bread doesn't vanish into a completely new element. The bread simply undergoes a state transition: [ Bread (Plain) ] ── SPREAD(Butter) ──> [ Bread (Buttered) ] This is one of the most critical ideas in computer science:

State is the condition or configuration of an entity at a specific 
point in time. Actions don't just "do things"—they trigger state 
transitions.

4. The Bank Test: Command-Query Separation

To ensure this model wasn't just about physical objects, we tested it against pure information: a Bank Account.
Given an account with Balance = $5,000 and Status = Active, we analyzed four operations:

DEPOSIT($1,000)
WITHDRAW($500)
CHECK_BALANCE()
CLOSE_ACCOUNT()
When looking at CHECK_BALANCE(), the apprentice noticed something crucial:
State Before: Balance = $4,500
Action: CHECK_BALANCE()
State After: Balance = $4,500 (Unchanged!)
Output: $4,500

He had just independently discovered Command-Query Separation (CQS):

OPERATIONS
                        │
         ┌──────────────┴──────────────┐
         ↓                             ↓
     COMMANDS                       QUERIES
   (Mutations)                  (Observations)
   - Change State                - Read State
   - Produce Side Effects        - Zero Side Effects
   - e.g., WITHDRAW()            - e.g., CHECK_BALANCE()

An action doesn't always mutate an entity. Some actions simply inspect and return data.

5. The 100-Cars Dilemma: Why Classes Exist

Finally, we hit him with a scalability problem:

"Imagine you're building a racing simulation. A car has Speed, Fuel, and an Engine. It can Accelerate(), Brake(), and Refuel(). Now imagine you need 100 cars on the track. How do you design this without writing Accelerate() 100 separate times?"
His response:

"You create a single car template.
The template defines what every car HAS and what every car DOES.
Then you stamp out 100 individual cars from that template, 
each holding its own numbers."

Without reading a single programming textbook, he had just defined the relationship between a Class and an Object Instance

CAR CLASS (The Blueprint)
                 ┌───────────────────────────┐
                 │ State:                    │
                 │   Speed, Fuel, Engine     │
                 │ Behavior:                 │
                 │   Accelerate(), Brake()   │
                 └─────────────┬─────────────┘
                               │
                      Instantiate with `new`
                               │
         ┌─────────────────────┴─────────────────────┐
         ↓                                           ↓
     car1 (Object)                               car2 (Object)
  ┌─────────────────┐                         ┌─────────────────┐
  │ Speed = 120 km/h│                         │ Speed = 0 km/h  │
  │ Fuel  = 30 L    │                         │ Fuel  = 80 L    │
  └─────────────────┘                         └─────────────────┘

6. The Rosetta Stone: From Mental Model to C

Here is how our apprentice's first-principles thinking maps directly to professional C#:


Conceptual Model     │Software Engineering     │C# Syntax
                        │Concept                │
Car Template            │Class                    │public class Car 
                        │                       │{ ... }
Individual Stamped Car  │Instance / Object    │Car car1 = new 
                        │                       │Car(0, 50);
Speed, Fuel, Status │Properties / Fields  │public double Speed 
                        │                       │{ get; set; }
Accelerate, Brake   │Methods (Behaviors)  │public void 
                        │                       │Accelerate(double 
                        │                       │amount)
Input Value (20 km/h)   │Parameters / Arguments   │(double amount)
Car(speed, fuel)       │Constructor           │public Car(double 
                        │                       │speed, double fuel)   
                        │                       │
Query (CheckSpeed)  │Return Value         │return this.Speed;

Now look at that exact model written in clean, idiomatic C#:

public class Car
{
    // Properties (State)
    public double Speed { get; private set; }
    public double Fuel { get; private set; }
    public bool IsEngineRunning { get; private set; }

    // Constructor: Defining initial state upon creation
    public Car(double initialSpeed, double initialFuel)
    {
        Speed = initialSpeed;
        Fuel = initialFuel;
        IsEngineRunning = false;
    }

    // Command (State Mutation with Business Logic)
    public void Accelerate(double amount)
    {
        // Guard clause: Cannot accelerate if the engine is off!
        if (!IsEngineRunning) return;

        Speed += amount;
    }

    // Command
    public void StartEngine()
    {
        IsEngineRunning = true;
    }

    // Query (State Observation)
    public double CheckSpeed()
    {
        return Speed;
    }
}

Notice the guard clause
if (!IsEngineRunning) return;

The Takeaway

Syntax is just typing. AI tools and IDE autocompletion can generate syntax for you in seconds.
Engineering is the architecture of thought.
Before you write your next class, method, or function, step away from the keyboard and ask:

What are the core Entities?
What is their State at any point in time?
Is this method a Command (mutating state) or a Query (reading state)?
What rules prevent this entity from entering an invalid state? 💬 Discussion Question for the Comments

Next up in our curriculum is Memory & Variables:
If we run:
code

C#
double speed = 100;
speed = speed + 20;

What physically happens to the previous value of `100` in memory?

How would you explain variables and assignment to a complete beginner without using the word "variable"?
Drop your best explanations below! 👇
Now look at that exact model written in clean, idiomatic C#:

Why I Stopped Letting Screens Talk to the Database

Blessed Emmanuel John chidera — Wed, 16 Sep 2026 18:35:48 +0000

Most of us start a new front-end project the same way: open the template, rename MainPage, and start dropping controls. It feels productive. It is also how a lot of apps end up with business logic living inside XAML (or React, or whatever) and database calls scattered across pages.

I recently spent a focused session on the Management side of a real system. We deliberately did almost no feature work. Instead we decided where every future responsibility would live and how the pieces would be allowed to talk to each other. The result is a small set of rules I now treat as non-negotiable.

1. The front office is not the records department

The Management application is the place staff actually work. The API and the database are a different building. The only legal communication between them is HTTP + JSON.

That single rule has three practical consequences:

The Management project never references the infrastructure or data-access projects.
If the database later moves from SQLite to PostgreSQL (or anything else), the Management app does not care.
Every piece of data that reaches a screen has already passed through an explicit service boundary.

In other words, this is forbidden:

ChildRegistrationPage → AtipDbContext → SQLite

This is required:

ChildRegistrationPage
→ ChildRegistrationViewModel
→ AtipApiClient
→ HTTP
→ ATIP.Api
→ ChildService
→ AtipDbContext
→ Database

2. Screens are rooms; ViewModels are the people who run them

A page (View) decides what the room looks like. The corresponding ViewModel decides what happens when someone presses a button, what data is valid, and when the UI should show a spinner or an error.

Keeping the two separate is classic MVVM, but the discipline is easy to abandon once a deadline appears. The test I now use is simple:

If I cannot unit-test the decision logic without spinning up a real page, the logic is in the wrong place.

3. Not every data shape belongs in the domain

Domain entities live in a shared Core library. They represent the truth of the business. The Management UI often needs thinner or differently shaped objects — a list item that only shows four fields, a dashboard summary, a search filter. Those belong in the Management project’s own Models folder.

Mixing the two creates either leaky abstractions or awkward mapping code later.

4. Navigation is architecture, not an afterthought

We made the application open into a Shell whose first content is a Dashboard, not a registration form. That forces an explicit user journey:

Dashboard
└── Children
├── List
├── Register
└── Profile

Creating the navigation skeleton before the individual rooms is one of the highest-leverage early decisions you can make. In MAUI terms it looked like this:

<!-- AppShell.xaml -->
<Shell ...>
  <ShellContent
      Title="Dashboard"
      ContentTemplate="{DataTemplate views:DashboardPage}"
      Route="dashboard" />
</Shell>

And the startup chain is simply:

App → CreateWindow() → new AppShell() → DashboardPage

5. Create the rooms you need, not the ones that look professional

We created six folders:

Views
ViewModels
Services
Models
Components
Converters

We did not create empty classes inside them “just in case.” Architecture is not the number of folders; it is the consistent placement of responsibility. Empty scaffolding that never gets used is noise.
The real payoff
When the first real feature arrives, the only new code that needs to be written is:

a page in Views
its ViewModel
the calls inside the already-planned API client

Everything else already has a home. That is the quiet win of spending a session on architecture before the first line of feature code.
I still have to prove the empty Shell actually launches. After that, the next phase is the concrete AtipApiClient. But the hard part — deciding who is allowed to talk to whom — is already done.
Three questions before you write the first page
If you are about to start a new client application, try forcing yourself to answer these three questions first:

What is the single entry point the user will see?
Which project is allowed to know about the database?
Where will UI-specific shapes live, and how will they stay separate from domain entities?

The answers tend to save more time than any amount of clever code later.

What rules do you refuse to break on the client side? I’m curious what others have settled on after a few projects.

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

Blessed Emmanuel John chidera — Wed, 16 Sep 2026 07:10:12 +0000

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": "john@example.com",
  "role": "admin"
}

# PATCH — updates only what you send
PATCH /api/users/1
{
  "email": "newemail@example.com"
}

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

Simplicity is a skill, not a shortcut.
Anyone can write more code. Real discipline is writing less and making it mean more.
Assumptions are the enemy of growth.
The moment you stop questioning what you "already know" is the moment you stop growing.
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.

DEV Community: Blessed Emmanuel John chidera

PROGRAMMER, QUICK QUESTION:

but if nobody knows you're in the room, who exactly is going to choose you?

who knows?

who can trust that you can actually do it?

That is exactly what I mean by putting yourself out there.

Can I use what I've learned?

Being visible without having anything to show isn't enough either.

Learn.

Build.

Break.

Debug.

Document.

Share.

Connect.

Contribute.

Programming #SoftwareDevelopment #Developers #BuildInPublic #GitHub #TechCommunity #blexondev #johnKode

AI & The Programmer: A Manifesto for Developers Who Refuse to Be Replaced

Who This Is For

What We Believe

The Seven Principles

1. From Code Generation to Problem Solving

2. From AI as an Answer Machine to AI as a Thinking Partner

3. From AI Assistance to Human Ownership

4. From Copy-Paste to Understanding

5. From Accepting AI's Output to Verifying It

6. From Learning With AI to Becoming Capable Without It

7. From Programmer to AI-Augmented Engineer

The BY MY SELF Principle

LEARN

THINK

BUILD

BREAK

DEBUG

UNDERSTAND

DOCUMENT

REPEAT

My AI Operating Principle

The Commitment

BY MY SELF.

But AI cannot become me.

The Invitation

The Future

Welcome to AI & The Programmer.

Welcome to BY MY SELF.

Welcome to the work.

— John Kodes

We Reinvented OOP by Making a Sandwich (Before Writing Any Code)

1. The Sandwich Challenge: Computers Have Zero Context

2. Debugging Human Logic

3. Inventing a Mini-Language: The Birth of "State"

4. The Bank Test: Command-Query Separation

5. The 100-Cars Dilemma: Why Classes Exist

6. The Rosetta Stone: From Mental Model to C

The Takeaway

What physically happens to the previous value of 100 in memory?

Why I Stopped Letting Screens Talk to the Database

1. The front office is not the records department

2. Screens are rooms; ViewModels are the people who run them

3. Not every data shape belongs in the domain

4. Navigation is architecture, not an afterthought

5. Create the rooms you need, not the ones that look professional

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

What physically happens to the previous value of `100` in memory?