Properly communicating in engineering is often a tradeoff between being concise and being accurate. A common tool to remain concise while remaining specific is to use metonymies. A metonymy is a figure of speech in which a specific concept is referred by another very close word.

A common type of metonymy used is to designate a concept by a specific implementation it. For example, when one means "We should use Redis to solve problem A" do they mean:

• We need an key value store?
• We need an in-memory database?
• We need a distributed database?
• We need a (distributed) cache?
• We need a database with feature x (sets, hyperloglog…)

Redis is arguably all of those concepts at the same time. If you are sure your co-worker (or blog reader) understands which capacity of this technology you refer to, go ahead, use the word Redis. However, be sure to insist which aspect of Redis solves problem A.

This is mostly a problem in the following situations:

• Some junior engineers use metonymies by lack of exposure of multiple implementations of a concept.
• Confusion within the team of what the engineer exactly mean (do they refer to a key/value store or a in-memory database?)
• Using a specific technology name to often can corner one's mental model into this specific technology instead of the more general concept.

Some other examples of common metonymies that might cause confusion:

• Hashmap for a Map
• DynamoDB for a document database
• PostgreSQL for SQL database
• ReactJS for Javascript

• Github Actions for CI/CD

Overall, when the concept is properly understood there is little harm to refer to it by using a specific implementation, but be aware of the mental model your listeners might have of this concept, and more importantly, question your assumptions to makes sure you don't corner your thoughts into a specific implementation.