Storytelling Secrets from One of My Favorite House M.D. Episodes

I used to feel guilty about watching Netflix and TV shows.

I felt like I was wasting time when I could be grinding. But when I started to seeing things through a writer’s lens, Netflix and TV shows became a source of storytelling lessons.

I’ve been binge-watching House M.D. this year. I’m on season 7 (out of 8). No guilt.

Recently, I watched episode 13 of season 7, “Two Stories.” It’s one of my favorite episodes.

Here’s a breakdown of the storytelling and plot from that episode—no spoilers:

#1.

The episode starts with a schoolboy and schoolgirl getting into trouble and being taken to the principal’s office.

And guess who’s also there waiting for the principal? Yes, Dr. House. How the heck did he end up there? That’s the whole point of this episode.

Dr. House is intrigued by why the two students are there.

They made a deal: they’d explain why they’re there, only if he revealed why he was there too. Of course, he’s not a student.

#2.

Dr. House starts to tell them how he got to the principal’s office.

Then, we’re taken on a flashback to a couple of hours before. He’s in front of a classroom telling the students about what he does and about his most recent case.

This is the clever, ingenious, and my favorite part:

Dr. House is telling us the episode’s backstory while he’s telling other stories: the conversation outside the principal’s office, the flashbacks, and his speech in front of the classroom.

#3.

While sharing his most recent case in front of the classroom, Dr. House starts to recreate scenes from famous movies.

And, in the classroom, there’s a movie lover who recognizes every scene. That only makes the students more interested in what Dr. House has to say.

Apart from Dr. House, there are three more guests. It seems they’re a police officer, a counselor, and a businessman. Who the heck are they? That’s something revealed at the end.

Here’s a perfect example of Dr. House’s in front of the class:

Dr. House’s storytelling is so captivating that the students keep asking questions, leaving no room for the other guests to speak.

#4.

In the meantime, we’re taken back to the principal’s office.

The two students also begin sharing why they’re there. An innocent plot from a boy trying to get closer to his crush. I won’t spoil the details.

The episode jumps between their story and Dr. House’s story. All told in flashbacks.

#5.

Finally, all the stories connect.

We learn why Dr. House is there, who the businessman in the room is, and the clue that solves Dr. House’s case.

Oh, I forgot to mention:

All that time, Dr. House had a case. He was trying to solve it via phone calls, while his team was back at the hospital dealing with the patient’s complications.

My lessons?

1. Start by grabbing people’s attention with drama or mystery. For example, why is Dr. House outside a school principal’s office?

2. Tell stories in such a way that people have to ask “What’s next?” or “Wait a second, what about that?” Use suspense, cliffhangers, and unanswered questions. Always make them want more.

In front of the class, Dr. House shares clues that are left unresolved. He was trying to hack into a laptop. The students kept asking why.

3. A proven plot to follow: Make your characters have a conversation. Use the conversation to introduce flashbacks and tell about one of the characters’ past. Then, make all the flashbacks concur in a resolving scene that puts everyone back into the initial conversation.

Wait, it seems I just described Forrest Gump: a conversation on a bench, lots of flashbacks that explain the backstory, and a resolution that ties everything together. Turns out, great stories follow a blueprint.

By the way, here’s the breakdown of Six Triple Eight, a Netflix show I also watched with my writer’s lens on.

Stop Optimizing for Scale—Most Apps Don't Need It

In my Friday Links email yesterday, I shared one post called Programming Myths We Desperately Need to Retire.

Myth #5, “Let’s optimize for scale,” resonated a lot with me:

Most products never reach the scale you’re “preparing” for. And even if they do, you’ll have time—and budget—to refactor later.

Oh boy! Been there and done that.

At a past job, while working on a hotel management solution, we had to connect the reservation module to a third-party restaurant solution. The goal was for guests to pay their restaurant bills along with their hotel bills.

We were about six software engineers plus the QA team. We worked to make that solution scale to thousands of guests and restaurant orders. We built an eventually consistent solution with background processors using Hangfire, Domain-Driven Design, and all the best practices you can imagine.

There’s nothing wrong with that. The problem? When we finished our module and handed it off to the Product people. Nobody bought it. Six months of work…wasted.

The Product team only had a few leads when they pitched the idea to the Engineering team. But those leads weren’t going to wait six months for our integration. Or maybe the Product team wanted to list a new feature on the webpage so they could compare the product to the competitors. And after all that time optimizing for scale? Nobody bought it.

Friday Links: Coding myths, a pwned dating app, and Visual Basic

Hey, there.

Here are 4 links I thought were worth sharing this week:

#1. We as coders take pride in our craft. We like to follow principles and best practices: KISS, SOLID, DRY. But there are some coding myths we need to retire (8min).

#2. There’s one problem with the “get things done” attitude of startups: security. Here’s a breakdown of security issues found on a dating app (8min). They had broken one-time passwords and open endpoints. Security shouldn’t be an afterthought.

#3. A URL shortener is maybe the new “hello, world” for distributed apps. But building one doesn’t have to be that complicated. Here’s a simple not-overengineered alternative (6min).

#4. Dragging and dropping controls onto a canvas is normal these days. Even the word “controls” is normal. But someone has to come up with all those ideas. They started with the release of Visual Basic, back in the 80s. Here’s the history and legacy of Visual Basic (20min).

And in case you missed it, I wrote on my blog about cURL, a simpler and faster alternative to Postman (2min) and how to find all 3-digit numbers in a tree (4min).

(Bzzz…Radio voice) This email was brought to you by… Want to master SQL Server performance tuning? Brent Ozar, the leading SQL Server expert, is celebrating with a special anniversary sale.

Only this month, get the prerecorded Mastering bundle and save $400. This bundle includes four advanced courses covering indexes, queries, and full database optimization. Everything to optimize and tune your SQL server like a pro.

See you next time,

Cesar

Want to receive an email with curated links like these? Get 4 more delivered straight to your inbox every Friday. Don’t miss out on next week’s links. Subscribe to my Friday Links here.

Ditch Your Helpers and Utilities Classes Before They Ruin Your Code

Recently, I needed to track down how an old Visual Basic WebForms app stored a value from the database into the Session object.

But I didn’t know I was in trouble until I looked for the file in the GitHub repository and it said “(Sorry about that, but we can’t show files that are this big right now.)”

The file had 69,359 lines. Its name? GlobalFunctions.vb. You can guess what was in there just by looking at that name, right? It was a clear symptom of a deeper problem.

The problem?

The problem isn’t that it was a WebForms app in Visual Basic. We can write crappy code in any programming language. It was that huge “throw everything under the carpet” kind-of file.

It reminded me of one of the conventions I decided to ban: “Helpers” and “Utility” classes, full of unrelated static methods.

The solution?

If you’re tempted to write anything named with “Helpers,” “Utilities,” or worse, “GlobalFunctions,” please stop and consider how to split that class into smaller, more focused classes with clearer names. Smaller, well-named classes ease cognitive load, making them easier to work with.

Or even better, if you’re practicing DDD, before defaulting to a “Utility” class, ask yourself: does this belong inside an entity or value object instead?

cURL—A Simpler and Faster (and Free) Alternative to Postman

Postman still isn’t opening.

Five minutes after clicking the icon… Nothing. Maybe it’s calling home, checking in with the International Space Station, or just ghosting me. Who knows?

Today I found out about Bruno, a “Git-integrated, fully offline, and open source API client”. A simpler alternative to Postman. I had come across Bruno before but had forgotten about it.

But, there’s an even simpler alternative to Postman and Bruno.

When I want to test a single endpoint, I just:

1. Go to the Network tab on Chrome,
2. Right-click on the request I want to test,
3. Then click on “Copy as cURL (bash)”,
4. Then paste it into a Terminal, and
5. Press enter.

cURL is a “command line tool and library for transferring data with URLs”. It comes preinstalled with Git Bash for Windows. And I’m a “terminal Git user,” so I keep a terminal open all the time. Way faster than opening an Electron app.

Here are some cURL examples to send data:

$ curl --json '{"name":"some json here"}' https://example.com`
$ curl -s --json @body.json https://example.com
$ curl -s -i --json @body.json -H "header-name:header-value" https://example.com`
$ curl -d "data to PUT" -X PUT http://example.com/

Here’s the meaning of those options:

• --json: To POST a json request either as a json string or from a file.
• -s: Silent mode
• -i: To include response headers
• -k: To avoid validating SSL certificates. Handy when an ASP.NET Core project has HTTPS redirection.

Et voilà! No waiting, no upgrades, no paywalled features. cURL is faster and simpler than Postman, which still doesn’t open on my computer. I guess it’s time to upgrade it or simply use a better alternative.

PS: Turns out Postman finally opened… after an upgrade. Unnecessary drama. Arrggg!