Claudio is a Principal Consultant at Improving Houston. He has been developing software for 25+ years. When not building software, consulting with clients, doing presentations, delivering training, or hanging out with his family, he can probably be found working on his music.


The Principles of Principals

I always get a kick out of seeing my American-born friends often write principle when they mean principal. Another mistake I see is writing recieve/concieve instead of receive/conceive.

I often wonder why such mistakes are so glaring to me. Here’s what I’m thinking…

Sound vs Meaning

When I’m about to write a sentence that requires either the word principle or principal, I’m not thinking of their sound; I’m thinking of their meaning.

Visual images come to mind as I think of their meaning, and they’re often connected to how I’ve learned those meanings in my primary language (Brazilian Portuguese). So if I’m about to write “The kids were called by the school’s principal“, the image in my mind is that of the main person at the school. On the other hand, if I’m about to write “The kids were schooled on principles“, the immediate connection in my mind is a fundamental truth.

Side note: I’ve recently noticed someone using “verses” when they meant “versus” (maybe they should have stuck with “vs”?)

English as Second Language

In the case of words such as receive and conceive, I do believe I’m never confused about their spelling because of their Portuguese counterparts: receber and conceber.

So when I think of the word that means I’ll be given something, the immediate spelling connection starts as “rece…” (from “receber”), and then my mind makes the quick switch into English, “receive“.

Errors and Relatable Mistakes

It’s interesting for me when I’m in a group of people conversing in English, and many members of this group aren’t native English speakers.

While some of our mistakes may simply sound like plain errors to a native speaker, they’re relatable mistakes for me.

For example, I’ve heard colleagues from India and Mexico say a sentence such as “I did it today morning“, instead of “I did it this morning“; I used to make the same mistake many years ago because that’s how the sentence would structurally go in Brazilian Portuguese.

Words, Meaning, Context, Perspective

Words are important.
Their meaning is more important.
Context drives meaning.
Perspectives help identify and understand the context.

It’s interesting to see how the mind makes these connections.

Please share any resources you might know that could help me understand this better.

Leave a comment

JetBrains Rider: Removing “private” from C# code

I prefer NOT to see the “private” keyword in C# code. As a quick update to that post, here’s how to set up JetBrains Rider to not add “private” when it creates code, and also to remove it when using its “Reformat and Cleanup Code” feature:

Leave a comment

Meeting Interesting People

I’m meeting a lot of interesting people.

I’m meeting people who seem to think and talk just like me, even though our mother languages aren’t the same.

I’m meeting former presidents, senators, and their wives. Republicans and democrats.

I’m meeting people who made important decisions and later changed their mind.
People who talk about other people or subjects; sometimes they agree with each other, sometimes they don’t.

I’m meeting poets. Philosophers. People who speak with very polished language, others who have a potty mouth.

I’m meeting people who have never existed, yet, their stories resonate with me.

I’m meeting people who speak to me from the past.
Some have been long gone. Sometimes I wish we had met when they were still alive. Sometimes I’m glad I didn’t.

I met a youngster who translates wise words from the past into words I can understand with my limited command of the language.

I met people who told me a fictional story written in the past, about their future; a future which is my present.
And stories about their future which is also my future.

I’m meeting my heavy metal heroes, and learning about their struggles and successes.

I’m meeting people I haven’t heard from in decades.

I’m meeting extraordinary people who have accomplished amazing things in their life and are willing to share their stories.

People who are able to say so much using so few words.

I’m meeting people who help me ask important questions in life.
People who give me advice I can use in many areas of my own life.
They teach me things in a manner I can relate.

I’m meeting people whose storytelling skills take me on adventures I may never get to experience myself, or maybe I will.

People who are sharing knowledge with me I didn’t even know I’d either need or be interested in.

I’m meeting people I feel compelled to introduce them to friends and colleagues.

I’m meeting immigrants whose stories of proving others wrong I enjoy a lot.

I’m meeting with people to discuss lessons learned from other people we’ve met.

I’m meeting a lot of interesting people.

Leave a comment

Thoughts On Books – A Complaint-Free World

Will Bowen’s A Complaint Free World is among my favorite books read in 2022.

Going through my notes I see that I’ve done a lot of pondering and it still makes me think deeply through many of the points raised.

Here is a summary of some of my thoughts on it.

Best Advice

This piece of advice sums up the book for me:

Don’t hold back, don’t hold it in, just make sure you are stating only the facts, to someone who can resolve the issue.

Don’t cry out. Speak up.

Stop Whining like a Baby

We complain. Too much.

“The squeaky wheel may get the grease. But if it squeaks too much, it ends up getting replaced.”

Brilliantly put. That one stuck with me as it put into words some of my own experiences.


But sometimes we just need to vent a little. Right?

Well, no.

Venting is a form of complaining.

People will mirror what they see. Our words. Our body language.

Complaining is like bad breath…

“It seems that complaining is like bad breath – we notice it when it comes out of someone else’s mouth but not when it comes from our own.”

As our awareness of our own complaints go up, so does our perception of complaints from others.

I started being aware of things I used to complain quite a bit before, stopped doing that, then got annoyed when others did the complaining I used to, and then found out I became aware of it and learned to smile at myself and move on. Rinse and repeat.

When asking “why me?”

Our complaints are often followed by the question “why me?”

We can also ask the same question when we’re grateful for someone or something.

Using a Jar of Awesome and sharing that Gratitude helps with that.

The fifteenth

The author talks about a friend who had established a practice of having only one day every month when he could complain about something. That day was the 15th.

The point is that, by the time the 15th comes, he had already forgotten what he wanted to complain about.

The practice of distancing ourselves from the things that upset us is one that yields great results.

Focus Beyond the problem

“Not every problem needs to be overcome, just the ones stopping you from getting where you want to be.” – Ann Hill

The book talks about looking through the problem. Instead of talking about or focusing on the problem, switch over to the desired outcome, and only to people who can either provide the solution or help us get there.

Criticism and Sarcasm

Both criticism and sarcasm are forms of complaint.

Criticism: it made me rethink how I conduct code reviews.
Sarcasm: it made me think before I use sarcasm (“what’s the complaint disguised as sarcasm?”)

Summing up

I’ll be revisiting my notes on this book multiple times. There are many other things I’ve picked up from it that I decided to leave out of this post to keep it short. But I want to close this with a great passage about leadership:

Leadership can be a daunting task. The use of criticism is an indication of a leader who lacks the resources to truly lead.
A leader’s job is the careful balancing of inspiration and direction.

Leave a comment

On Curiosity

Most adults are envious of how easily children learn languages.

“I’m too old to learn a second language. I wish I could learn like those kids”, they say.

Why is that?

A common response is: “…a child doesn’t have all of the responsibilities I have as an adult.”

I’ve been thinking the main reason is another one, though: we stop being curious as we age. We even get annoyed when others don’t stop being curious as they age.

A child asking why several times is cute.
A teenager or adult asking why several times is simply annoying.

It’s very hard to learn not just a language, but anything, if we don’t ask why; if we stop being curious.

Look at Bruce Dickinson, not only the famous singer for Iron Maiden, but also a songwriter, airline captain, aviation entrepreneur, motivational speaker, beer brewer, novelist, radio presenter, fencer, and film scriptwriter (great TedX talk, From Rock Star to Businessman). How did he learn all of that? The title of his autobiography, What does this button do?, says it all: curiosity!

For the last couple of years I’ve been noticing someone else who also embodies the notion of approaching life with a beginner’s mind: The Charismatic Voice’s Elizabeth Zharoff, an accomplished opera singer who can sing at this level.

In her reaction videos, she analyzes vocal techniques of several singers across all sorts of music genres and singing styles.

I enjoy watching her reactions because she always shows genuine childlike curiosity. It’s interesting to see her discovering the sound of a wah pedal, or hearing sounds she’s absolutely not used to, such as the chromatic runs in guitar solos by Randy Rhoads.

She always finds positive things to say, be it in the lyrics or in the emotion the singer delivers the words, regardless of whether it happens using a pretty, harsh, or tired (from age) voice.

She is curious about learning how different singers produce certain sounds. When she hears singers producing different types of screaming, she wants to understand how they do it without harming their vocal folds, even taking a singer who’s a specialist on harsh vocals to a clinic to have a camera put in his throat while he sings and see what the doctors find out. She’s even learning to growl herself!

Watching Elizabeth curiously react to singers and music I’ve been listening to for over 4 decades has helped me renew my appreciation for them through exploration of nuances I didn’t even realize were there, but most importantly, she’s a constant reminder of how to keep a beginner’s mind, and the growth that comes from it.

Instead of thinking/saying “been there, done that”, I’m practicing turning it into “hmm, what else is in there? A button! What does it do? And why?”

I’ll close this post by quoting a question from this interesting article that asks “is curiosity the greatest virtue?

“Could you perhaps work on your ability to become curious, to cultivate curiosity as a habit? If so, how?”

Leave a comment

Hi, I’m Lame.

Did this post’s title offend you? I hope not; it wasn’t my intention.

Shortly after emigrating to the US, I learned many words I didn’t know before, including badass, laidback, and lame. The latter came up in a statement such as this one:

“Dude, compared to Master of Puppets, Metallica’s album Load is lame.”

I knew the context. I inferred the meaning of lame as “dull”. For 20 years, that was the only meaning I had either seen or heard used for that word. Until the following exchange happened in a Slack channel:

Some person: “Facebook is now Meta.”
Me: “Lame.”
Another person: “You shouldn’t use that word. It’s offensive.”

I was puzzled. I looked up the word and found something like this:

“Having a body part and especially a limb so disabled as to impair freedom of movement.”

I am positive that definition has no ties to the meaning I’ve intended in the context of that Slack thread.

Ironically, if we look up the meaning of my name, this is what we find:

“Who’s responsible for that?”
“Hey, that’s offensive!”

As someone born in Brazil, I could feel offended when…

  • My Spanish-speaking friends spell out loud a word with the letter “q” in it
  • My American fellows say “coup” or text me “CU”

The other day I was watching this comedy news show and the guy was making fun of vanity plates that may be offensive to some people. He then shows this one, and how it’s offensive to him (saying a meaning that could only exist in his mind):

Well, for me, the immediate thought that came to mind is that “FDP” is Brazil’s equivalent to “SOB”.

Context is very important.

I’m Lame.

Leave a comment

Remembering what I read

Last year I’ve run into this video on How to Read Faster, by Mark Mason, which includes tips on remembering what you’ve read. I figured I can also share some of my thoughts about it.

Why do I highlight passages on books?

When Mason talks about remembering what you’ve read, he mentions he sees no value in highlighting books. He thinks of it from the standpoint of how (or why) we normally have to read at school: “you’re tested on what you’ve read”.

I don’t do it from that perspective.

Highlighting makes me slow down when I’m speed reading. It makes me tell my brain “that’s important/interesting… take your time.”

When I finish the book, I come back and go through the pages, looking for my highlights, and often I find things I wanted to explore further.

Why do I take notes as I read?

Same reason as with highlighting.

Note-taking makes me slow down and further assimilate the content I’m reading.

I write down my own words to connect with the content. I use words from anecdotes and similar experiences or existing knowledge that I may want to associate with the content.

How does this apply to my life?

The notes and highlights help me think how the content applies to my life.

Talk about the ideas with other people

Mark also mentions this idea. I’ve been recommending people do that as a deliberate practice to improve their public speaking: learned something new or had some challenging experience? Tell someone else over lunch or at a water fountain conversation!

Many of my talks are created like that.

Printed vs Ebooks

I’m used to consume books in all different types of formats. But I’ve noticed that it’s easier for me to remember information when I read a printed copy. There’s something about picking up a book, flipping through the pages, feeling the book’s weigh… that seems to help me.

Do I want to remember everything?

I do NOT want or need to remember everything. I’m usually fine with knowing in which book I’ve read about something so I can later go back to it for more. Having a good process and system to find that faster is a bonus.

With that said, I haven’t had to read a book with the goal of taking a test in several years.

Leave a comment

Test-First vs Test-Last

When practicing Test-Driven Development, we’re supposed to write a test first. I’ve heard developers say “it doesn’t matter if we write the test before or after the implementation, as long as we do it.

This is how I think of it:

Writing the implementation first, and then writing tests for it, sounds like implementation-driven tests. Such tests are shaped by the implementation and end up reflecting the implementation’s dependencies and how it works, unless the tests are refactored into BDD-style specs (see the differences between TDD and BDD), which is hardly ever the case.

Writing the test first, and then the implementation, drives the implementation. Test-driven development. That’s why many people (myself included) rather think of TDD as test-driven design, placing focus on the design aspect of the practice.

“Why does that matter?”

Shift in perspective.

By quickly jumping into writing code, we’re also quickly distancing ourselves from the real-world problem we’re supposed to solve.

“So, there’s no value in writing tests for existing (legacy) code?”

Yes, there is. Please do so. And once the tests are written, refactor them so to document the feature and NOT the implementation. In other words, they document why the code exists, not how it works.

I believe reading tests should go like this:

  • WHY this feature exists
  • HOW the API supports it (input/output)
  • WHAT supports the API (classes, components, methods, functions…)

In that order.

The tests/specs are not for a business feature, but instead, a technical feature?
Same thing: Why ➡️ How ➡️ What.


Leave a comment

Thoughts On Books – Head First Design Patterns

Just wrapped up a book club on Head First Design Patterns (HFDP). Here’s a summary of what I shared at our Lightning Talks.

I read the “Gang of Four” (GoF) book, “Design Patterns: Elements of Reusable Object-Oriented Software“, in the early 2000s. That was a tough read for me; very dense, and hard to relate to. Good book, but not what I needed at the time.

Then ran into the 1st edition of HFDP in 2005:

I loved the way the book taught the concepts, using a good mix of analogies with real-world things I can immediately relate to, principles, and some code in between. I’ve been recommending that book to whoever asked, and wanted to revisit it to see how well it aged.

For the book club, we picked up the 2nd edition, published in 2021:

As with the 1st edition, all the source code is Java, which I’ve never worked with. But that doesn’t matter because the code is there only to give examples of the concepts (the most important thing) explained. The knowledge acquired is transferrable.

With that said, there was one chapter that I think spent too much time explaining some very specific aspects of Java, but that didn’t affect my enjoyment of the book, as I could visualize its counterpart in .NET. I do see that section being a little harder to grasp for developers who may solely focus on the frontend, though.

Going through the book this 2nd time, I realized that when I read it the first time I still didn’t know about the SOLID principles; that I learned a couple of years later. This time, I noticed I was anticipating where they were going with some explanation, and eventually, they’d drop in things like “Dependency Inversion Principle”. While the book calls out DIP, it never mentions SOLID. I can’t recall if the 1st edition mentioned anything related to SOLID at all. Anyway, I enjoy learning in a spiral, and it was good to revisit the content from this perspective of having acquired more knowledge and experiences over the years.

Speaking of experiences, the book club had a good mix of previous experiences; some members already had a lot, others were just getting started, some had more experience with backend than frontend development, some had more with functional programming than object-oriented programming languages. It all added to our having great conversations.

Here are some of my key takeaways…


The book does a good job at sharing not just patterns, but also principles, which help us understand better why certain patterns exist. Here are a few examples of principles that were brought up:

Program to an interface, not an implementation

That’s the D in SOLID: Dependency Inversion Principle, or DIP, already mentioned earlier.

Favor composition over inheritance

I first learned OOP in Visual FoxPro in a very inheritance-heavy way. It took me a while to understand and internalize why I should favor composition over inheritance.

This is what made the lightbulb go off for me:

Swapping behaviors with inheritance is done at compile time.
Swapping behaviors with composition is done at run time.

There are other things to consider, such as composition making it easier to follow the Single Responsibility Principle, but understanding the power it brings to run time behavior is huge.

Principle of Least Knowledge

Aka Law of Demeter, I kind of like Principle of Least Knowledge better.

For a common example, let’s try this one:


The code above doesn’t do things to the cart; it does to the cart’s Items property. Is that a list, a collection, or what? That’s excessive information. How about this version, instead?


That way, the code only knows of the cart and it adds a product to it; how it stores the items is none of our business.

A simplistic way to think about it: too many dots reaching into an object means bad!


The book covers one pattern per chapter, including Strategy, Observer, Decorator, Factory, and Command.

There’s a chapter on Compound Patterns, more specifically, Model-View-Controller (MVC). That one mentions other patterns that are often part of MVC: decorator, adapter, abstract factory, observer, strategy, composite, and iterator.

The very last chapter lists “leftover” patterns (about 10 of them). What was interesting to me is that there are a few patterns that would probably not be considered leftovers if the book was focused on .NET, such as Mediator, Builder, and Chain of Responsibility.


I’ve been seeing a number of people putting OOP down in favor of Functional Programming, steering away from content on design patterns because “that’s what the old folks do”. Why not leverage both?

Take as an example this snippet that uses the Command pattern:

That’s the OO way of implementing it, with classes, methods, and interfaces. Since the Do method takes in an ICommand interface, that parameter could also be wrapped in a decorator(s) or adapter, implemented as different strategies or created by factories, etc.

One could argue that if the ICommand interface only has one method, Execute, it could be replaced by a function, represented in the snippet below as an Action:

Action is a delegate, which in C# is an object that represents a reference to a method (or function). Those can also be created by factories, wrapped in decorators, etc. So we’re in OO land, but approaching it with a functional perspective.

When working in functional languages, one can also leverage knowing design patterns, and their intent, and then consider whether they’d be appropriate in solving a problem there. Concepts such as commands, adapters, proxies, and factories, are out there and may come in handy, regardless of language, syntax, you name it.

Patterns in life

I like how the book uses things from life, such as restaurant menus and TV remotes, to explain the concepts.

It’s a fun exercise to look at other things around us and how they relate to some patterns.

Take this image as an example:

The plug and the outlet work together based on agreed interfaces; the outlet sees the plug, and the plug sees the outlet.

What if we want to put a timer to shut off the outlet after a certain time? We use something like this…

Or we could also use something like this:

Heck, we could even use both. The plug and the outlet wouldn’t care; they wouldn’t even know those decorators were there.

What if the plug and the outlet conform to different interfaces (standards)? We use an adapter (but we can also still use those decorators)!


I really like how the book defines anti-patterns:

An Anti-Pattern tells you how to go from a problem to a BAD solution.

Shared Vocabulary

One of the main reasons to learn design patterns is to build a shared vocabulary; we can condense full sentences, paragraphs, and long explanations, down to a single word. That is, as long as everybody in the room knows what that pattern is! If people aren’t familiar with it, that’s an opportunity to learn and grow together.

I like the book’s list of great places to leverage the shared vocabulary:

  1. In design meetings
  2. With other developers
  3. In architecture documentation
  4. In code comments and naming conventions
  5. To groups of interested developers

Zen mind is a Beginner mind

Do not let all that pattern knowledge overly influence design decisions.

Yup, always go with the simplest solution. Let patterns emerge.

Leave a comment

I am doing it wrong

Take a deep breath, open up your mouth, and say it out loud in a full voice: “You are doing it wrong!”

You’ve done that before, right? I know I have. Once we know something (or think we do), it’s very easy to say someone is doing it wrong. Software developers do that. A lot.

  • “Wow, you’re using this library instead of that library? You’re doing it wrong!” 
  • “You’re using this pattern instead of that pattern? You’re doing it wrong!”,
  • “You’re writing a blog post instead of writing code…” You got the idea.

Once upon a time, I used to put comments in code everywhere. My current self could visit my past self and say “you’re doing it wrong!” about commenting code.

Whatever it is we’re doing “right” today is likely going to be “wrong” tomorrow, as long as we make the conscious effort to improve every day.

The person we’re interacting with today may be in the part of their journey that’s similar to our own a year ago. What looks “wrong” now, may be right, all things considered; writing comments for every line of code may be right for someone just getting started.

I’ve been avoiding videos, articles, and other types of content that try to grab us with:

  • You‘re doing it WRONG!”
  • “NEVER do this”
  • “ALWAYS do that”
  • “I have read all these books on –whatever-. Here is what YOU should ALWAYS do.”

I remember back as teenager when I learned how to play Black Sabbath’s Paranoid on the guitar. I played it for years thinking that was one of the easiest tunes ever. Until I find a video of Tony Iommi (the person who wrote the song!), talking about one tiny aspect that pretty much every guitar player gets wrong when playing that song: “they play the main riff off the 7th fret on the 5th string, instead of the 12th fret on the 6th string, where it sounds heavier…”

Growing up in Brazil, it took me years after I’ve moved to the US to finally hear I was pronouncing words such as pitch and peach exactly the same way (yup, the attentive reader can probably see how I could sound rude at times).

Far too often we won’t do something because of the fear of being wrong.

We don’t try a new language because we’re afraid of mispronouncing words.

We don’t try playing an instrument because we’re afraid it’ll sound bad.

I’ve heard Tim Ferriss suggest we ask 3 questions before offering an opinion. Now that is good advice. I also like Derek Sivers’s thoughts on “your first reaction is usually outdated“.

Hello there, future-me; do you think I’m doing it wrong right now? Be thankful that I am doing it; if I weren’t, that version of you would not exist.

“Always remember that to argue, and win, is to break down the reality of the person you are arguing against. It is painful to lose your reality, so be kind, even if you are right.” – Haruki Murakami

Let’s be kinder to ourselves and others.