DEV Community: Ricardo Sánchez 👨🏽‍💻 ☕

Don't forget about character casing when comparing strings

Ricardo Sánchez 👨🏽‍💻 ☕ — Wed, 11 Aug 2021 23:27:01 +0000

There are many issues I've experienced during the many, many years I've worked as a software developer. But one of the most recurring issues is, without a doubt, the mismatching of words due to character casing.

There are solutions to the character casing mismatch problem. For example, you can make your strings all lower case or upper case before comparing them. There are also many programming languages that have features to help with string comparisons.

The issue is no longer the lack of solutions to avoid this problem. The problem is that these solutions require that you, the developer, be proactive by being alert and aware of case sensitivity when making string comparisons. For example, in C#, you have the StringComparer class, which includes properties like StringComparer.OrdinalIgnoreCase to help you ignore the character's casing when comparing strings.

As a developer, you have to be alert and know when to ignore character casing. While there are many simple ways and tools built into programming languages, sometimes knowing when to do this might not be obvious.

For example, if you call GroupBy in C# and select the value you want your list to be grouped by, it will consider values such as "Abc" and "ABC" as unique, which might not be what you want to do.

In most cases, if you group a list of items by a specific string value, your intention is probably to treat the same values "Abc" and "ABC" as the same. Therefore, you'll want to ignore the casing as the values are the same in this context.

Issues like the one with GroupBy in C# can go unnoticed until it causes problems. For example, I ran into this issue and didn't realize the mistake until I tried to add the values of that grouped list to a dictionary and failed. The dictionary attempted to use the values "Abc" and "ABC" as the dictionary key, but it failed since these aren't unique.

So what can you do about this? Code defensively. Every time you compare strings, consider character casing sensitivity and avoid it easily by converting all your strings to upper case or lower case before comparing. Second, be aware of the use cases where you are calling a built-in function such as GroupBy or ToDictionary as functions like this might be case-sensitive within your programming language.

With the programming language C#, you can use overloads that explicitly specify the string comparison rules for string comparisons. It works in this language by calling a method overload that has a parameter of type StringComparison.

In the example below, I'll be using StringComparison.OrdinalIgnoreCase for comparisons for culture-agnostic string matching. The example shows you how not ignoring case sensitivity might give you unexpected results.

Examples in C#

Let's declare a list of books with author names written using different casing

var books = new List<Book>() { new Book { Name = "Programa en donde sea", Author = "Ricardo" }, new Book { Name = "Empieza a programar", Author = "ricardo" }, new Book { Name = "Xyz", Author = "Joe" }, new Book { Name = "Despues de la programacion", Author = "RICARDO" }, new Book { Name = "Blah", Author = "Foo" } };

Let's group the list of books by Author, but since we are not doing anything to ignore case sensitivity, the result is not what's expected - It returns five records instead of three as it treats all variations of the name Ricardo as unique values.

var notAUniqueListOfBooks = books.GroupBy(b => b.Author);

Now let's group the same list of books by author, but this time let's add a parameter to make the string comparison case insensitive. The result is only three records, that's because it treats all the variations of the Author name Ricardo as the same value.

var aUniqueListOfBooks = books.GroupBy(b => b.Author, StringComparer.OrdinalIgnoreCase);

Let's now create a dictionary from the list of books. This dictionary will use the Author value as the key, and both the book's name and author as the value. The result is five items in the dictionary, again, because it treats the each instance of the author name Ricardo as a unique value due to the difference in casing.

var notAUniqueBookDictionary = books.ToDictionary(b => b.Author, b => b);

Finally, we'll try to create a dictionary following the same attributes above, but this time, we'll pass the parameter StringComparer.OrdinalIgnoreCase to make sure the comparison is case insensitive.

The result if this last one is an error with the following message:

"An item with the same key has already been added. Key: ricardo"

This is because since we are ignoring the casing in Author, we cannot create a dictionary as the key values are required to be unique and by ignoring the case of the different variations of the value Ricardo, these are no longer unique. They all end up being the same exact value.

var aUniqueBookDictionary = books.ToDictionary(b => b.Author, b => b, StringComparer.OrdinalIgnoreCase);

Finally, using the examples above, if you wanted to group by Author, and then create a list of all of their books including the name and author values then you could try using ToLookup, and pass the StringComparer parameter to make sure the string comparison in case insensitive.

var aUniqueLookup = books.ToLookup(b => b.Author, b => b, StringComparer.OrdinalIgnoreCase);

The above will give you a dictionary where the key is the Author name and the value is a list of books including name and author. Also, by passing the StringComparer.OrdinalIgnoreCase parameter, we are making sure that the result is a unique list of values.

This the result of our book list when converted into a Lookup object in C#. There are three keys, all unique, and under each key we have a list of books that corresponds to the book's author representing the Key value.

I hope this is useful, the code I used to test the examples above is all available here if you want to play with it and explore changing the values, parameters, etc.

Cheers and happy coding!

This post was originally published here: https://rcrdo.com/2021/08/09/dont-forget-about-character-casing-when-comparing-strings/

Enabling software engineering teams for success.

Ricardo Sánchez 👨🏽‍💻 ☕ — Tue, 26 May 2020 15:45:05 +0000

Software development is hard, and it isn’t always the programming language or the framework you use, it’s the people who work on it.

People are an essential part of a team; everything can be easily changed and fixed, but to achieve effective communication and a great culture, you need to make sure people work well together. In my software development career of over 20 years, the critical difference between successful software projects and failed ones has been the way engineering teams are created and how they are allowed to function overtime.

Successful software projects are the result of great teams, and people in these teams always have a history of working together for some time. When people know each other, they understand each other’s weaknesses and strengths. So it’s easier to balance the work, the responsibilities, and the expectations.

Keep people together

When people in a team know each other well, the communication flows smoothly, and it’s often more sincere and competent than when people don’t know each other well. Communication is vital, it’s what makes a difference between successful and productive teams vs. teams who are not.

One of the reasons I believe people who have worked together for a while are more productive is because they are more honest about their mistakes and deficiencies. As humans, we tend to fake our abilities when we meet new people and are often afraid of showing or openly communicating with others about our shortcomings and mistakes. Time is the cure for all of this; just let people work together, allow them to reconcile their differences, and after a while, you’ll have a team capable of doing their work effectively and be very productive.

Company is growing, and employee count is increasing, now what?

Teams in large corporations often suffer from constant changes due to company growth and a steady increase in employee count. A common reaction to this is to split engineering teams and create new ones, with the idea that placing senior employees in separate teams will help support and grow new teams often filled with new hires.

While this idea isn’t bad, it’s also not optimal for the software development process, productivity, and, most importantly, to employees and company culture. By doing this, you are essentially taking a well-functioning team filled with people who have spent months or years adjusting their personalities and experience to maximize their productivity and communication, to then split them up and then start from scratch. Having people work with friends is something that will keep them happy and thus be more productive and resilient. What’s better than that?

What about new employees? What about new teams?

When onboarding new software engineers, they should temporarily join experienced teams to get up to speed and acquire domain knowledge. After that, these new software engineers should be placed with a new cohort of employees to be the beginning of a long-lasting software development team.

Having an onboarding process like the one I described above can help minimize disruption on existing teams and increase the success rate for new employees, new teams, and, subsequently, the entire organization.

What about people who want to join other teams, or be in a new position?

Keeping people together in a team is all about keeping them happy and comfortable so they can do their best work. Keeping them together does not mean that you should force people to stay in a team against their wishes or ignore their desire to move on to a new position or team.

Any employee should have the freedom to move to another team or apply for a new position.

What about new projects or products? Who’s going to work on them?

You want teams with people who work well together, people who already know each other and can take advantage of each other’s skills and experience. Teams with people who have worked together for some time can communicate better. People in these teams know how to complement each other’s skills and experience and thus can produce better work.

If you try to build a new product or work on any other challenging software project, doing so with a newly formed team will cause frustration, delays, and it’ll be more costly, possibly failing.

You can achieve a higher success rate by having your experienced teams with people who have worked together for a while, take on the new challenging projects, and develop new products. These experienced teams can hand over these projects to the less skilled teams created with newer cohorts.

Allowing teams to grow together will increase the speed, the quality, and the success rate of their projects., it will also keep employees in both existing and new teams happy and interested due to the variety of projects and the bonding formed with the people who are part of their team.

How do new software engineers acquire domain knowledge?

You can have the same people work in the same team for as long as they desire, they can work on different projects and challenges, but it’s a good idea to keep these teams working on projects within the same business unit. Enable people in teams to gain experience and domain knowledge by working on the same type of products within the same or similar business unit, but not the same product.

The ultimate goal

The ultimate goal is to have people in teams who can excel at the following skills to increase their chance of success:

Open, honest, and fluid communication
Common goals
Clear roles and responsibilities
Independence

These things can be achieved by any team, but it takes time and effort for people in a new team to get to know each other to accomplish this. People in teams who have worked together for many months or years can achieve all of the above a lot easier; these are all skills learned by working with the same people over time. Every time a team is created, especially when you split an existing team to create a new team, consider all of the above before you proceed.

People are what make companies successful, and for people to accomplish this, they need to learn to work well together, and this takes time. Think of people first, assign projects to teams, and not people to teams to work on projects.

Do you have any other recommendations, suggestions, or feedback? please leave it below in the comments.

Book recommendations

If you want to read detailed and useful information about the topic of software engineering teams, here are two books I recommend:

Peopleware by Tom DeMarco and Timothy Lister

Managing the Unmanageable by Mickey W Mantle

Cheers.

Originally posted here

A note about impostor syndrome

Ricardo Sánchez 👨🏽‍💻 ☕ — Thu, 28 Feb 2019 22:44:43 +0000

Impostor syndrome is when a person doubts their accomplishments, feels that they don’t deserve it, or think that their achievements (a promotion, a raise, etc.) are the result of luck. The impostor syndrome can affect anyone, especially women and minorities who fear they owe their accomplishments to affirmative action.

What if we do the following when the impostor syndrome surround us?

What if we pretended we didn’t feel it?

What if we acted as though we were more confident and more competent?

What if we showed appreciation for what we’ve accomplished and behaved as we thoroughly deserved it?

What if we told our friends and family how happy we are about our accomplishments and how the result was expected due to all of our hard work and persistence?

It takes a lot of work to do this; it takes a lot of effort, more so than any of us can cope with.

But what if we did it every time the impostor syndrome shows up?

It’s possible that after doing the above for a while and acting as if we deserve our accomplishments, perhaps we would teach ourselves to take what we deserve and see the outcome we have always hoped for.

Originally posted here: https://ricardodsanchez.com/2019/02/10/a-note-about-impostor-syndrome/

Are there any rules or suggestions about posting content that has already been posted in a personal blog?

Ricardo Sánchez 👨🏽‍💻 ☕ — Fri, 18 Jan 2019 18:41:54 +0000