Language is all about nouns

When humans talk about things, we always talk about specific nouns. Nouns have names. We may not know the name, but there is a name.

When you go on a trip, and you need to pack your clothes. You go to a shop and buy a suitcase. You know it is a suitcase. You don’t go there and ask for “the thing you use to transport clothes.” If you did that you would probably end up with a cardboard box. Imagine checking-in a cardboard box at an airport.


Unfortunately, programmers are afraid of nouns.We tend to use descriptions instead of names.

Picture this situation in your mind. You sit in front of your computer, and you need to write some code which sends a marketing newsletter to your customer. What do you see? Is this an EmailAddress type or a String called “emailAddress”? How do you know it is the email address? You have a validator, you can call it. Great. How do you know the person wants to receive the email? You store verified email addresses and all the newsletter subscriptions in your database.

Not only you don’t have a noun. You have just a description and some assumptions you must verify every time you want to use it.

Would you like to help fight youth unemployment while getting mentoring experience?

Develhope is looking for tutors (part-time, freelancers) for their upcoming Data Engineer Courses.

The role of a tutor is to be the point of contact for students, guiding them throughout the 6-month learning program. The mentor supports learners through 1:1 meetings, giving feedback on assignments, and responding to messages in Discord channels—no live teaching sessions.

Expected availability: 15h/week. You can schedule the 1:1 sessions whenever you want, but the sessions must happen between 9 - 18 (9 am - 6 pm) CEST Monday-Friday.

Check out their job description.

(free advertisement, no affiliate links)

Too long

Why don’t you call the customer’s email address a MarketingNewsletterRecipientAddress? Too long? Do you want to know what is too long? Your code.

You have to check whether the email address has been verified. You have to check whether the person wants to receive this type of newsletter. You did it once. Maybe you wrote a database query which returns only such recipients.

Can you trust it? What if someone modified the code, and you don’t even know it? You end up with a lot of repetitive code just to check all the preconditions. A lot of defensive programming.


If you encode your assumptions in the type, the code gets self-documenting. You look at the class name and instantly know everything you need. What else? During meetings with the business, you talk about things which exist in the code. You don’t need to translate the requirements from human language to “programmer speech.”

You don’t need to strip nouns from their meaning and replace it with poorly written descriptions. Yes! Those descriptions are poorly written. You have a generic type (a String, an Integer), some name that hopefully tells you something about the role of the variable, and assumptions scattered around in many places.

Don’t try to be clever. Just call it what it really is.

Remember to share on social media!
If you like this text, please share it on Facebook/Twitter/LinkedIn/Reddit or other social media.

If you want to contact me, send me a message on LinkedIn or Twitter.

Bartosz Mikulski
Bartosz Mikulski * MLOps Engineer / data engineer * conference speaker * co-founder of Software Craft Poznan & Poznan Scala User Group

Subscribe to the newsletter and get access to my free email course on building trustworthy data pipelines.