TIL: Always Wrap Collections in API Responses

Note to future me:

You’ve learned this before. But it’s easy to forget or let teammates (or clients) make the same mistake.

Always return collections wrapped inside a response object from your APIs.

Adding fields, like pageNumber and itemCount, won’t break the UI or other clients. This is one of the few places where you should forget about YAGNI. Remember You Aren’t Gonna Need It? Is that still a guideline in the future with AI? Anyway…

Please, don’t do:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/", () =>
{
    return new[] { "Titanic", "Terminator" };
	//     ^^^^^
	// Please don't.
	// Otherwise a cute baby panda dies in the forest
});

app.Run();

Instead, please do:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/", () =>
{
    return new
    {
        Items = new[] { "Titanic", "Terminator" }
        // ^^^^
        // OK, with a proper object.
        // You know we're lazy with the examples
    };
});

app.Run();

Just today, in a client project, I realized we let this mistake happen and we had to update almost a dozens pages in a Blazor app.

Make this an API commandment.

The Subtle Sign You're Growing as a Coder

You know you’re growing when:

• You don’t get stuck on compilation errors for missing semicolons
• You’re not rushing to code without doing some planning
• You know when your code looks or feels funny

But there’s another subtle sign of growth:

You let others into your code and you don’t take critiques on your code personally.

Being an overprotective coder

Oh boy! In my first job, I didn’t want anyone else to touch my code.

Each team member worked solo, with almost no collaboration. And after finishing Clean Code, I thought only my code met all the standards. I didn’t want anyone else to infect it.

Then at my next job, it was almost the same story.

Along with a small team, I worked on the core features of the main app. Only a few touched it. And it hurt to see my code rewritten during the app redesign to make it scale.

Learning not to be one with the code

After moving between projects and companies, I eventually learned that I’m not my code.

Critiquing my code isn’t critiquing me. Bugs happen. Edge cases get missed. Requirements get misunderstood. And when that happens, someone will pick my code and say “Who wrote this crap?” The same way I said that when I inherited somebody else’s codebase.

Get your code in front of others, let them change it, tweak it, and critique it.

That’s the key to growing as a coder. And that’s why I wrote Street-Smart Coding: 30 Ways to Get Better at Coding. Nobody told junior me that writing simple code others could inherit and improve was part of growing.

Grab your copy of Street-Smart Coding here This is the roadmap I wish I had on my journey from junior to senior.

I'm Launching Street-Smart Coding: 30 Lessons to Help You Code Like a Pro (the Roadmap I Wish I Had Starting Out)

I spent five years in college learning to code.

A stupid dissertation delayed my graduation. But that’s another story.

Most of my five-year program didn’t prepare me for real-world coding. My real coding journey began at my first job, with one Google search: “how to get good at coding.”

I found a lot of conflicting advice:

• “Use comments”
• “Don’t use comments”
• “Do this”
• “Don’t do that”

Arrggg!

It took years of trial and error to learn what worked.

I had to survive on-call shifts, talk to stakeholders, and say “no” politely. More importantly, I had to learn that coding takes more than just syntax.

That’s why I wrote Street-Smart Coding— a roadmap of 30 lessons I wish I had when I started. For every dev who’s ever typed “how to get better at coding” into Google or ChatGPT. (Back in my days, I didn’t have ChatGPT… Wait, I sound like a nostalgic grandpa…)

Inside “Street-Smart Coding”

This isn’t a textbook. It’s a battle-tested guide for your journey from junior/mid-level to senior.

Some lessons are conventional.

Others were learned the hard way.

And a few are weird.

One lesson comes from a TV show. Nope, not Mr. Robot or Silicon Valley. That’s on Chapter #29. It will teach you about problem-solving.

You’ll learn how to:

• Google like a pro
• Debug without banging your head against a wall
• Communicate clearly with non-tech folks

…and 27 more lessons I learned over ten years of mistakes.

Now they’re yours.

Get your copy of Street-Smart Coding here and skip the years of trial and error. For launch week only: Pay what you want—even $1 or $2.

This TV Show Can Teach Problem-Solving Better Than Any Coding Class

Yesterday, I shared a surprising way to improve at coding: watching a TV show.

It wasn’t Silicon Valley or Mr. Robot or any other TV show featuring hackers. It was a show about doctors. I never thought hospital drama could teach problem-solving.

Watch House M.D.

Let me introduce you to Gregory House, the protagonist.

He’s not a regular doctor. He doesn’t like patients. He doesn’t wear a white coat or use a stethoscope either. He’s even sick and under constant medication. Weird, right?

But he gets the most complex, rarest cases because he’s a brilliant problem solver. He even runs his own department at the hospital.

Every episode is a masterclass in how to solve complex problems.

The #1 rule of problem-solving

There’s a line Dr. House says almost all the time:

“Everybody lies.”

That’s why Dr. House doesn’t like to see patients. He only trusts brain scans, blood tests, and other exams.

Let me ask you this:

How many times have you received a bug report and Customer Support claimed they had verified logs, reproduced steps, and validated user data… And after hours of debugging, you realize the real problem was something they had claimed to have checked in the first place? Arrggg!

If you ask Dr. House, everybody lies:

• End users lie.
• Documentation lies.
• Customer Support lies.
• Other engineers lie.
• Even you and I lie.

Always trust but verify.

That’s Dr. House’s #1 rule to solve problems.

House M.D has conflict and drama with excellent storytelling. But it also teaches powerful problem-solving lessons. I expand on what Dr. House has to teach us as coders in my book, Street-Smart Coding: 30 Ways to Get Better at Coding.

In my book, I suggest watching a TV show and hanging out in cafes to become a better coder. Yes! Because coding isn’t just syntax and speed. It’s also thinking like a doctor with complex cases.

Grab your copy of Street-Smart Coding here

7 Unconventional (But Surprisingly Effective) Ways to Get Better at Coding

Junior-me was obsessed with syntax.

Ten years ago, coding only meant learning languages. I was learning C#, keeping up with PHP, and sneaking into Python. I thought coding was only about symbols and lines of code.

But to grow as coders, you need more than learning syntax and typing symbols. Here are 7 unconventional ways to grow as a coder:

#1. Detach yourself from your code. You’ll write simpler code and become a better teammate. You’ll let others touch, critique, and work on your code.

#2. Reinvent the wheel to learn. It forces you to read, dissect, and really understand code. Try rebuilding one of your favorite libraries and tools. Just to learn, once you’ve understood how they work, stick to the real one.

#3. Do on-call at least once. Being paged after hours isn’t a pleasant experience. But you’ll learn to triage, debug, and stay calm under pressure. And more importantly, to communicate with non-technical people.

#4. Watch House M.D. This isn’t a TV show about coders or hackers, but about doctors. It’s a masterclass in problem-solving. You’ll see how they tackle complex problems until they find a solution. More useful than most coding classes.

#5. Learn to write. Not lines of code, but clear, direct prose. Writing sharpens how you present ideas and solutions. That’s why every coder should write. And it’s no surprise the higher up you climb the ladder, the less it’s about coding and the more about communication.

#6. Start and monetize a side project. A side project will teach you:

• Marketing and sales
• How to think like a builder
• Hosting and the Cloud aren’t free
• End users don’t care about clean code

#7. Learn polite ways of saying no. You’ll need this a lot. You will have to say no to unneeded complexity, scope creep, and burnout.

If you want to stand out as a coder, you need more than mastering syntax. Nobody ever taught me that starting out.

That’s why I wrote Street-Smart Coding: 30 Ways to Get Better at Coding, the roadmap I wish I had on my journey from junior to senior. Because the best coders don’t just type. They collaborate, build, and solve.

Grab your copy of Street-Smart Coding here