Do you know how to fix your bike? Of course not (unless you’re a biker).
If someone would tell you to fix your bike today, would you be able to do it? I don’t think so.

But if you started learning how to fix it, reading, working each and every day in perfecting the skill and the craft, would you be able to do it in a year? Probably yes.
In a month? Still probably yes.

In a day? It depends.

I’ve often wondered what’s different when it comes to problem solving and tasks. Some people are able to fix their own problems, some are not.
Some stops right away at the first barricade, the first bridge to cross, the bug they don’t understand, the software they don’t know.

It could be a developer, a designer, a marketer. It’s not the job, it’s the mentality.

Why is that some people do find a way to fix bugs they weren’t aware of, in softwares they didn’t develop, while others can’t fix a bug they know in a software they created?

I think it boils down to 2 things: Questions and surrender.
And while you might think you’re not in this group of people, think again.
Because you are. I didn’t find a person in this world, myself included, that at least once in a while didn’t surrender to a seemingly unfixable issue.

So, whhy Questions and Surrender?
We tend to surrender too fast. To accept failure as an immutable condition. We can’t simply go forward. We don’t have the information, the skills, the knowledge, enough practice, you name it.

 What we don’t say to ourselves is how. How could we get more information? More skill, more knowledge?

I had people come to me because they never used a software and didn’t know how to use it.
I didn’t either, yet I used it. Was it because I had some magic powers? Of course not. I simply tried, tested, learned.

The difference was not in the skill, but in the ability to question: How do I get from here (where I am) to there?

In case of learning how to use a software an answer could be something like

• Read the damn guide
• Read closely each text.
• Push some random buttons and explore the whole set of features until I find something that resemble what I want to do
• etc

In case of a bug (as a developer) the questions are still there but in a different form
* Can I isolate the source? 
* Can I remove code that removes the bug?

Even if I don’t have the skills, I can isolate the bug, find the cause and then think about how to fix it.
It might seem like an impossible task but I can guarantee this by experience: I once fixed a bug in a software I didn’t develop, that I didn’t ever see nor used, developed by people that I didn’t know and the only difference between me and them is that I isolated the problem by remove code (in a logaritmic way, but still code removal is).

We seek help too fast for problems that are too littles. It should always sound alarming when you reach out to someone, he/her doesn’t reply you and in the minutes you wait for their answers you fix the problem.
It means you asked for help too fast. 
You were lazy maybe, maybe you didn’t were confident enough.

Whatever the case, you surrender too fast. And the only way to fix this is to not surrender at all. At first you’ll fail and it might be disarming but there’s no way to learn without some trial and error.