Always try to ask at least 5 whys while solving a problem instead of giving up or asking colleagues straightaway.
Instead of saying “I have an error” ask: why?
Example:
What does the error message says?
“Database schema is wrong.”
Why?
Because ORM cannot see the table.
Why?
Because it connects to the wrong database.
Why?
Because connection string is wrong, but is ok at application config file.
Why?
Was it registered properly?
You are a person in charge of technology, AS WELL AS your colleagues, not JUST your supervisor or colleagues.
If you go to your cooworker and say “I have a problem” in 90% of cases he will have to perform the same debugging (5 whys) as you (unless he did it before – we call it experience).
Be proactive about your problems, do not push them on others. They have work to do as well and don’t want to be interrupted by ‘a guy who always has a problem and doesn’t put any effort in solving it’.
And of course there will be times when you will not be able to solve problem by yourself but by providing steps to reproduce the problem and showing that you did what you could to do that (in reasonable time, let’s say 30 minutes to 1 hour) will be greatly appreciated.
EDIT:
The draft of this post was created when individual contributors in our team have been working on tasks alone. You can see the friction which this situation causes in my words: “[…] your problems, do not push them on others”. We’ve tried to soothe this situation by giving ourselves time after which one should ask for help – 30-60 minutes. But it still causes context switching. This slows down the person being asked and may cause irritation. This does not help in teamwork.
Now I believe that pair- or mob-programming (3-5 people) is a better solution not only to resolving errors but to solving problems (thus designing and creating software) in general. Everybody can observe how fast is the problem resolved when two or more people work on it together. Such situation happens especially when there is a critical error which needs to be fixed fast. Why not work that way more if not constantly?
The technologies used in a project or a problem may be so complex that even most experienced teammates can get stuck or choose suboptimal approach to solve them.
A problem shared is a problem halved. And halving the problems are what should happen in software often.