I recently bumped into this post on reddit. It caught my eye because it is a question that I always ask myself, do I know enough? Do I really understand how things are working under the hood? And if I do, is it enough?
So I went and dive in and took every bullet point and went deeper, went to find out how much do I really know. Let’s start with the first one
Difference between fields, properties and variables
Fields
- Definition: Direct storage in a class or struct.
- Syntax: 
private int _age;
 - Access: Usually private, sometimes public in DTOs.
Properties
- Definition: Encapsulated access to fields via get/set.
- Syntax: 
public int Age { get; set; }
 - Access: Can customize get and set logic.
Variables
- Definition: Generic term for any named storage—applies to fields, local variables, parameters.
- Syntax:
- Local variables: Declared inside methods.
- 
var count = 5;
 - Parameters: Declared in methods signatures.
- 
void SetAge(int age)

Usually, I create a model or a DTO with only public properties, these public properties have a correspondent private fields created by the CLR and aren’t visible.
//Model Person
public class Person
{
public int Age { get; set; } // Auto-implemented property
}
//CLR created
private int <Age>k__BackingField;
public int Age
{
get => <Age>k__BackingField;
set => <Age>k__BackingField = value;
}
The common mistake mentioned in the post first section is the fact the this value tuple fields, that seems like properties of a class are in fact fields of a struct and that’s why System.Text.json
 won’t serialize them.
var person = (FirstName: "Moran", Age: 35);
// Access by name
Console.WriteLine(person.FirstName); // Moran
Console.WriteLine(person.Age); // 35
// Access by position
Console.WriteLine(person.Item1); // Moran
Console.WriteLine(person.Item2); // 35
var person = (FirstName: "Moran", Age: 35);
string json = JsonSerializer.Serialize(person); // Results in:
In my latest project I relied heavily on value tuples, They are a great tool to create complex type without the need to define a class of each type and the options to use named elements really make the use of the readable and maintainable.
Final Thoughts
It's easy to dismiss fundamentals as "too basic" — but as this exploration shows, overlooking them can lead to subtle and frustrating bugs. Whether you're using auto-properties, designing DTOs, or relying on value tuples for clean, expressive code, understanding the underlying differences between fields, properties, and variables matters.
Next time you hit an unexpected behavior — like an empty JSON object or an untracked property in your model — take a moment to question: Am I dealing with a field or a property? That awareness alone can save hours of debugging.
Thanks for reading! If this post helped you or sparked a new insight, feel free to share it or drop your thoughts in the comments. I'd love to hear how you approach the basics in your own work.