I've definitely had self doubt, and have turned down projects because of it. However, as I got more and more experience, I realized, I probably should have taken on those projects. The project owners (sometimes) would have been better off had I taken the project instead of them going with somebody unreliable who thought they new it all.
What I would suggest, which is pretty much what I did, is to take projects where you 1) feel like you can add more than just your code 2) pick projects you think you'll learn from, 3) pad your deadline significantly.
There is no shame in letting the project manager know that you want to take some extra time to make sure you're doing the best job, or getting the most benefit of learning from the project. If the project is with a larger company, maybe you can even get feedback from a more senior dev as you go along.
I had one contract with a larger company, where I really thought I was in over my head, and I thought their CTO would either give me helpful advice when he reviewed my code, or would dump all over it. He took a look at the code, and basically just said "yeah, looks fine", which didn't really help me at all. Looking back on that project only months later, I know I would have done it differently, but they were happy with the end result, and that is really the most important thing. Can you make them happy with what you can do, and can you grow from it.
I also think a bit of self-doubt is healthy, I think the sign of a bad developer is one who thinks they are at the top of their game.
What I would suggest, which is pretty much what I did, is to take projects where you 1) feel like you can add more than just your code 2) pick projects you think you'll learn from, 3) pad your deadline significantly.
There is no shame in letting the project manager know that you want to take some extra time to make sure you're doing the best job, or getting the most benefit of learning from the project. If the project is with a larger company, maybe you can even get feedback from a more senior dev as you go along.
I had one contract with a larger company, where I really thought I was in over my head, and I thought their CTO would either give me helpful advice when he reviewed my code, or would dump all over it. He took a look at the code, and basically just said "yeah, looks fine", which didn't really help me at all. Looking back on that project only months later, I know I would have done it differently, but they were happy with the end result, and that is really the most important thing. Can you make them happy with what you can do, and can you grow from it.
I also think a bit of self-doubt is healthy, I think the sign of a bad developer is one who thinks they are at the top of their game.