Archive for category Software Development

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

Optimize code for reading, not debugging

I see a lot of code that includes variables not used for anything:

The variable inside of that method does not add anything to improve the understanding of the code. That’s normally done to make debugging easier, when setting a breakpoint and hovering over the variable to inspect it:

That way, the developer can set a breakpoint, and hover over the variable to inspect it.

Instead of doing that, I’d rather have that method written like this:

When I need to debug that method and inspect what it returns, I use the shortcut to *introduce a variable*, do my debugging, and then either undo the change or hit the shortcut to *inline the variable* (most IDEs support such refactoring. Even if the one I’m using doesn’t, creating a variable named *x* or *temp* should take no time).

Some IDEs, such as Rider, even show a method’s return in the debugger without the need for a variable, as seen below:

Summing up:

  • Optimize the code for reading
  • Get familiar with your IDE’s debugging capabilities
  • Change the code to facilitate debugging when needed
  • Change the code back for optimized reading before committing it

Leave a comment

Pragmatic Programmers – Philosophy and Approach

One of the book clubs I’ve joined last year with my fellow Improvers was on “The Pragmatic Programmer – Your Journey to Mastery – 20th Anniversary Edition”. I remember reading the 1st edition sometime around 2006 and am glad I reviewed its newer edition.

Here are some notes wrote down…

“You shouldn’t be wedded to any particular technology, but have a broad enough background and experience base to allow you to choose good solutions in particular situations.”

That! I have (bad) memories of wasting a lot of time because a particular tech stack was chose for no reason other than a marriage to a particular vendor, despite of it not offering the best technology to achieve the client’s goals.

Care about your craft: there is no point in developing software unless you care about doing it well.

I wouldn’t trust surgeons who don’t care about doing their craft well. Would you?

“Over the long term, your time investment will be rapid as you and your team become more efficient, write code that’s easier to maintain, and spend less time in meetings

I love the point above. I enjoy doing code review with team members so we can learn from each other. I’ve worked on teams where at some point we couldn’t tell which one of us wrote the code, because we’ve learned to value the same best practices, which we kept in mind in our daily work. Whenever someone learned something new, they’d share with the team, and we’d evolve together.

“We who cut mere stones must always be enviosioning cathedrals”

YES! Developers shouldn’t be content with dropping a button onto a form that when clicked shows whatever message; they should see through it and understand the bigger context.

If technology seems to be passing you by, make time (in your own time) to study new stuff that looks interesting. You’re investing in yourself, so doing it while you’re off-the-clock is only reasonable.

That’s precisely what I’ve been doing for a very long time. The main difference is that I started to apply that not only to technology, but also to many other areas of life. What I’ve done off-the-clock has always been the biggest driving force behind my continous improvement.

Above all, your team needs to be able to trust and rely on you – and you need to be comfortable relying on each of them as well. Trust in a team is absolutely essential for creativity and collaboration. In a healthy environment based in trust, you can safely speak your mind, present your ideas, and rely on your team members who can in turn rely on you. Without trust, well…

If you ever visit, you’ll immediately see the following words: “Trust Changes Everything”. As I look back on my professional career, I can point out several opportunities and growth that came out of being trusted by people from all walks of life. A team without trust isn’t much of a team.

Pushing that concept a little further, I like a point raised by the authors of “Yes, And: How Improvisation Reverses ’No, But’ Thinking and Improves Creativity and Collaboration — Lessons from The Second City” (another book club we had last year!) The point they raised is to go from team to ensemble, which is an even more collaborative relationship. In Improv, it’s very easy for one to become very uncomfortable, but a strong ensemble is there to support each other when ramping up skills or going through an off night.

Don’t live with broken windows. Hopelessness can be contagious.

That one makes me think of teams that abandon their automated tests because they have become brittle, hard to maintain, hard to write, hard to fix when they start to fail.

Be a catalyst for change

Nobody else writes tests? You should do it, regardless. Nobody else writes clean code? You do it! Nobody else says “thank you” anymore? You do it. Thank you.

There were many other great things in this book and I strongly recommend it to anyone who’s anywhere near software development. Most of the lessons taught have stood the test of time, and the ones that didn’t (due changes in technology and such) were revised and updated in this 20th Anniversary Edition.

Leave a comment

Refactoring Test Code – Free Virtual Lunch and Learn

I’m giving my “Refactoring Test Code” talk as a Free Virtual Lunch and Learn this Friday, March 12, 12-1pm CDT, as part of the Improving Virtual Events. Register here!

Here’s the talk’s description:

Most developers hear about “Red->Green->Refactor” as part of the TDD process. Some never get to the “refactor” part. Some only refactor the “production” code, but not the test code, after all, that’s “just test code”. Tests become cluttered, hard to maintain, and are abandoned.

In this talk, let’s have a look at some ways to refactor “test” code (C#, JavaScript/TypeScript, unit/integration/end-to-end…), so that they become easier to read and even create opportunities for better collaboration with non-technical people.

Image by GraphicMama-team from Pixabay

Leave a comment

New Talk – “Improving Code: Refactoring Test Code”

After a short hiatus, the Improving Code user group is back. The first talk of the year happens online next week, Feb 3, 6:30pm CDT. RSVP here, will ya?

Refactoring Test Code

Every developer hears about the TDD process as “Red->Green->Refactor”. Some never get to the “refactor” part. Some only refactor the “production” code, but not the test code, after all, that’s “just test code”. Tests become cluttered, hard to maintain, and are abandoned.

In this talk, let’s have a look at some ways to refactor “test” code (C#, JavaScript/TypeScript, unit/integration/end-to-end…).

Refactoring Test Code

Wednesday, Feb 3, 2021, 6:30 PM

Online event

1 Members Attending

Every developer hears about the TDD process as “Red->Green->Refactor”. Some never get to the “refactor” part. Some only refactor the “production” code, but not the test code, after all, that’s “just test code”. Tests become cluttered, hard to maintain, and are abandoned. In this talk, let’s have a look at some ways to refactor “test” code (C#, Ja…

Check out this Meetup →

Leave a comment

There Once Was a Magazine…

I have mentioned about the importance of technical communities for me. This month, I take a moment to reflect upon something I was doing related to communities 20 years ago: in January of 2001, the first issue of RapoZine was released!

Still living in Brazil at the time and participating in a community that craved for content in Portuguese for Visual FoxPro, I got together with two other members of the community to put out this little magazine. Leandro W. and I would each write half of the content, and Nilton P. would take care of the website where people could subscribe.

We’d print out the pages at whichever company we were working at the time, and mail it out to the subscribers. Simple and easy. Nothing fancy needed. The community was craving for content! For that first issue, we also enjoyed an article contributed by Ellen W., from CoDe Magazine.

In its first year, we had about 120+ subscribers.

It was a ton of work to get monthly content written and put out like that. That’s how I got started on technical writing.

The name RapoZine was a combination of “Raposa” (Fox in Portuguese) and “magazine”.

When the printing and mailing costs got too high, we eventually alternated into a digital version. The articles were created in HTML, compiled into a password-protected EXE file, and a download link was sent to the subscribers. I need to dig up some old backup files… I may still find some of those issues here.

With my plans to move to the US in 2002, I didn’t have time to keep the magazine running. Fortunately, the main worldwide FoxPro community at the time, the Universal Thread, which also had their own electronic magazine, UTMag, approached me to join forces, and we merged UTMag/RapoZine for the community. The magazine became free for all, and published in three languags: English, Portuguese, and Spanish! The Universal Thread had a great system to allow translators to collaborate and get the content out. I continued as a co-editor and coordinator for the translation team. About a year later, the Univeral Thread acquired RapoZine, and I stepped away to pursue other goals.

When I was reading Richard Branson’s autobiography last year, and learning about how he started his professional life with Student Magazine, it got me thinking back to RapoZine.

Leave a comment

Work Soundtrack

I enjoy having some music playing while I work; even more so if I’m using the Pomodoro Technique. But I’m very specific about my work soundtrack!

If what I’m doing the requires deep thinking, I need instrumental music. Most often, that’d be classical music (Mozart, Beethoven, Vivaldi, Bach, Chopin, Paganini, are among my favorite), but it may also be World Music (Kitaro is my top favorite). For shallow thinking, I may go with guitar albums by Joe Satriani, Steve Vai, Steve Morse or maybe movie soundtracks.

When I already know what needs to be done (either because I’ve finished the deep thinking mentioned above or because the task is just busy-work), then I crave some high-energy music (usually heavy metal, but it could be some other things I have in my music library).

Here’s an example:

I’m about to implement a user story. I set two Pomodoro sessions: one session to read through the user story and acceptance criteria, review mockups, etc, and another session to write my specs for it (only the Given-When-Then statements). My soundtrack consists of classical music.

Now I’m ready to write the actual tests and just enough code to make them pass. The soundtrack may be some fierce heavy metal, as I blast keystrokes on the keyboard. As I do this, I may practice the “sing and read” speed reading techinique; as I sing my favorite songs, I read through my tests, write code, read what I wrote, and eventually read it again in preparation for some refactoring.

Do you have a soundtrack?

Leave a comment

Building Stronger Online Communities

Challenge times bring us the opportunity to either reinvent ourselves or flex muscles that had been dormant. I’ve talked about the importance of technical communities in my life, how they help us improve our networking skills, how we can use our voice and reach out to others.

The year of 2020 has made us all push the envelope when working with our communities, either creating new ones or keeping existing one engaging to their members. While many of us miss the in-person communities, we have also been learning how to make the best out of online communities.

Tomorrow, Dec 18, I’ll be on a live virtual Lunch and Learn with my good friend, talking about our experiences Building Stronger Online Communities. Join us at 12pm Central Time! Click here to find more information about this FREE event and register.

This is the session description:

User groups are a great way for the community to get together to share, learn and network around specific common interests. This year saw us having to pivot to virtual-only events and uncovering both opportunities and challenges… How can we create great community experiences in a virtual world? In this Lunch and Learn, attendees will hear from two community leaders, Sarah Kim and Claudio Lassala, on how they’ve been growing their online communities and hosting virtual events.

Leave a comment

Communities and Networking

Just a couple of weeks ago, I’ve blogged about The Importance of Technical Communities (the ideas really apply to any community in general, much like what I do with my motorcycle track riding community). In this post, I’ll focus on the networking side of getting involved with communities.

Every week, I share things on the Virtual Brown Bag; I may share an article or book I’ve read, a challenge I’m facing at work, a successful way I’ve found to implement something. Whatever the case might be, once I’ve shared it with the community, I’ve planted a seed in their minds: should they either run into the same challenges or solutions to it, they’ll think of me. They’ll know who to either ask questions or offer help to, or make connections (“Hey, Claudio, last week you mentioned you were having issues with Cypress. I mentioned it to a co-worker and he has the solution. He’ll be reaching out to you!”).

I’ve talked about similar things when I shared my thoughts on “fake until you make/become it”. We don’t need to figure it all out by ourselves. We don’t need to fake it. Others will help, but we need to either ask for their help or let them know that they could possibly help us.

Every month, I update my “Now page”; that’s an easy way for people to know what I’m up to. A few months ago, I mentioned I was starting to work with Angular. Less than half an hour after I’ve posted it, an old co-worker who I hadn’t talked to for a few years reached out to say he’s done a lot of work with Angular and I should keep him in mind if I had any questions. We also took the chance to catch up with life in general.

Last week, I’ve read Derek Sivers’ writing on how you can take a situation that may not be ideal and flip it in your favor. He touches on “it’s all who you know”, and got me thinking about how my professional career started; I walked to my whiteboard and sketched out my career map up to today, calling out every single person somehow responsible to pivotal moments. How did I meet them? How have they helped? Have I been keeping in touch with them? Have I expressed my gratitude to them?

A good book I’ve read on the subjet of networking is The Power of Who.

Our communities and networks can (and should) be connected. People in my technical communities are aware of my involvement with motorcycle track riders; those riders are aware of my involvement with software development. They are all aware of my activities as a musician. These are all opportunities to connect with people, expand my network, offer help, get help, improve, grow.

Leave a comment

All Front-End Development Technologies Will Soon Perish

Front-End development technologies come and go. In my experience, they have been the single most volatile part of software. Their lifespan seems to be very short (5-10 years).

Why are they so volatile?

  • Probably because the devices the users interact with evolve far faster than what they don’t interact with (back-end, databases and such);
  • Users now expect more. Back in the day, users would happily use whatever software they had to automate their work. That has changed over the years as most people have their own personal computers and devices, which they use for way more things than just “boring accounting and payroll systems”. Also, since the first iPhone came out, users have learned to expect software to be more intuitive. And now “there’s an app for everything”, and for each app, there are likely multiple options to choose from.

Since the late ’90s, I’ve worked on a huge number of software “rewrites”. Most of them were really painful and time-consuming. Why so?

Main reasons:

  • Developers put way too much code on the front-end;
  • In most “rewrites”, people simply want to replace the old with the new, making the new one look and behave like the old one, but on a different platform

Every time a new front-end toy comes out, I’m mostly interested in seeing how developers are writing code in it. More often than not, I see the same pattern over and over: a TON of code put right there in the front-end. Knowing that these frameworks and libraries aren’t like to last more than 5-10 years (by last I mean to be continuous developed), I know that a rewrite for such software means, well, rewriting all of that code!!

For the most part, the front-end part of software should simply allow the user to ask questions to the system and see responses. That’s it. Present the users with what they need to formulate questions, and then show them the answers in the best way possible (which could mean, fast, or illustrated with charts, or whatever it takes to give users the insight they need in that moment of time). In certain scenarios, it may be crytical to have most of the processing happening on the front-end, but those are the exception, not the rule.

Don’t get me wrong: I used to jump at every new shiny toy, too. There was a time when Microsoft put out a new toy called LightSwitch. That was probably the first time I looked at a new toy and thought “hmm, I don’t think that thing will last long”.

I didn’t quite recall when it went away, but found out on a quick search that its lifecycle started on Oct 30, 2011, and it’s mainstream support ended on Jan 1, 2017. The official death announcement states that “the landscape has changed significantly from the time when we first thought about LightSwitch”.

Such a shame. I had worked so hard on adding LightSwitch to my resume. I had even documented my proficiency with it on this short 45-second video!