Let's say we have a method like this (in C#):

int GetCustomerCount()
{
    // some code
}

Now in code we call it like this:

var intStuff = GetCustomerCount();
// lots of code that culminates in adding a customer
intStuff++;

The int doesn't tell us very much. The mere fact that something is an int doesn't tell us what's in it. Now let's suppose, instead, we call it like this:

var customerCount = GetCustomerCount();
// lots of code that culminates in adding a customer
customerCount++;

Now we can see what the purpose of the variable is. Would it matter if we know it's an int?

The original purpose of Hungarian, though, was to have you do something like this:

var cCustomers = GetCustomerCount();
// lots of code that culminates in adding a customer
cCustomers++;

This is fine as long as you know what c stands for. But you'd have to have a standard table of prefixes, and everyone would have to know them, and any new people would have to learn them in order to understand your code. Whereas customerCount or countOfCustomers is pretty obvious at first glance.

Hungarian had some purpose in VB before Option Strict On existed, because in VB6 and prior (and in VB .NET with Option Strict Off) VB would coerce types, so you could do this:

Dim someText As String = "5"
customerCount = customerCount + someText

This is bad, but the compiler wouldn't tell you so. So if you used Hungarian, at least you'd have some indicator of what was happening:

Dim strSomeText As String = "5"
intCustomerCount = intCustomerCount + strSomeText  // that doesn't look right!

In .NET, with static typing, this isn't necessary. And Hungarian was too often used as a substitute for good naming. Forget Hungarian and choose good names instead.