I use them indirectly like I use design patterns. I'm not thinking "Oh, I'm using 3rd NF" or "I'm using Singleton" at work. Instead, when designing databases I'm thinking about removing duplication (which is the crux of normal forms). However, like proofreading, you can go too far and normalize your database too much, making it hard to work with, so you allow duplication of some fields (hence denormalization).

Hope this helps.

Agree. Any database design over two tables should include review of NF.

Similar to you, sometimes my coworkers and I will use the terms 'normalized' and 'denormalized' when talking about databases. It is usually in reference to and ideal schema versus a performant schema. We don't actually use the precise definitions of the various forms, or verify our schemas satisfy the various laws. Maybe there would be value in actually formally normalizing a schema.