Nobody starts out as an expert at their chosen profession
It takes around 10 years to gain real competency in a professional discipline; not just in IT/Software engineering, but just about any complex field (e.g. Medicine, Economics, Particle Physics, Structural Engineering, etc).
If you are receiving positive feedback about your technical ability but still feel like you're struggling against the expectations of your employer in order to deliver results "on time", or you feel that you are unable to complete the tasks set by your boss or hit a deadline imposed by a customer then the most likely problem isn't with your technical skill but your communication skill.
Your boss and employer may have expectations of what you're able to deliver and when. The person responsible for managing those expectations is you. If you don't manage peoples' expectations of the work you're doing, then those people will make up their own assumptions (If on important subjects like estimates and workload, they may also hold you to those assumptions).
In general, you can take off a lot of pressure by communicating often with your boss and/or your team - especially when you hit an unexpectedly time-consuming problem, or when you feel an estimate is wrong, or some information is inaccurate, or a requirement is wrong, etc.
- Firstly, when you don't communicate, everybody in a professional environment assumes that nothing is wrong (Because, surely, if there was something wrong, you'd talk about it - right? Don't just wait for somebody to ask you...).
- Secondly, if you involve others in difficult technical problems, then you'll be drawing on a greater pool of ideas and knowledge where you may learn something new, or you might at least rule out a few options.
- Lastly, communication is a sign of maturity and competence. The best developers collaborate, discuss problems and share knowledge with others; they also check their assumptions because assumptions are BAD.
If you find yourself spending a lot of time on a single technical problem, people around you will feel more confident in your ability if you are able to provide more substantial detail about it. For example, consider some of the information that your boss/co-workers might find useful (Hint: it's similar to the kind of information that you'd hope to find in a highly-rated question on StackOverflow):
- What do you understand about the problem so far?
- How have you been analysing the problem? which method/tools?
- What assumptions are you making about it?
- Which solutions did you try that sent you down the wrong path or hit a dead end?
- What are the impediments to your progress or blocking issues? - e.g. tools which are hard to use, documentation which is wrong or hard to understand, tests which are very time-consuming, faults which are hard to reproduce, etc.
- Also, make sure you keep an eye on whatever solution(s) you're trying; sometimes all you need to keep a customer happy is a quick-n-dirty hack.
Software development can sometimes be an endless quest for knowledge, whether you're at the start of your career or a seasoned expert. (That is, unless you end up pigeonholed into some long-term maintenance job for years without ever picking up new tools/technologies/etc.)
Sometimes you'll spend 3 weeks understanding an obscure bug or "impossible" problem only to fix it with one line of code. Those 3 weeks aren't wasted - they're spent learning some new tool(s), technique(s), understanding a new technology, or even picking apart your team's codebase to better understand how everything fits together.
Time spent on problems which are 'difficult' for you may be frustrating at the time, but there's nearly always something to learn which is beneficial in the long-run. At the beginning of your career, this is even more true; most employers don't expect junior developers to know everything - they expect junior developers to spend longer getting things 'done', while learning new things along the way.
