I'll respond and try to
clean up the issue:
Broadly my guess is that the problem is too much advice on how to program, like being told to put your nose to the grindstone, shoulder to the wheel, and ear to the ground and then work in that position!
First, on how we can be "confident", let's make a few very simple points:
In some subjects, we do have some solid information.
E.g.: (1) If you want to be sure of the Pythagorean theorem, then there are many clear, short, rock solid proofs that will remove all doubt. (2) If you want to know when the next solar eclipse is, then basic physics from Newton's laws can give you an astoundingly accurate answer years into the future. (3) If you want to transmit a billion bytes of data over the Internet, then from coding theory there are some codes that can do really well at error detection and correction.
But in some subjects we don't have such clear, solid answers.
E.g.: (1) I recall very well that in high school I didn't know with much confidence what a girl I was dating thought of me, and I suspect, of course don't know for sure, that I was not nearly the first such boy!! (2) Tough to know what the US Federal Reserve will do to interest rates in 2019. We can't predict interest rates nearly as well as solar eclipses. Instead, interest rate predictions are a definite maybe.
Second, as an example, I'll outline how I became a "confident programmer":
I've been programming for a long time, back to Kemeny-Kurtz Basic, assembler, Fortran IV, Algol 60, PL/I F level, C, .... I skimmed through the first three volumes of Knuth's The Art of Computer Programming, paid close attention to radix sort, heap sort, and AVL trees, and learned a lot of applied math and the associated computing. In six weeks while teaching the business school course in computing at Georgetown University, I designed, wrote, and ran some software to schedule the full, planned fleet at FedEx, pleased the BoD and two experts from BoD Member General Dynamics, "solved the most important problem facing the start of FedEx" (F. Smith, founder, COB, CEO), enabled funding, and saved the company.
My Ph.D. dissertation was in stochastic optimal control with computing, e.g., some algorithms to make the computing faster, from about 64 years down to three minutes.
While working in an AI project at IBM's Watson lab, I cooked up some applied math and algorithms to do better than our AI work. I programmed the algorithms and published my work in Information Sciences.
I also taught computing in the MBA program at Ohio State University, was named Chair of the college computing committee, etc.
And there was more.
I was self taught. E.g., while I was teaching computing at Georgetown and saving FedEx, I'd never had any courses or instruction in computing. Taught courses? Yes. Taken courses? No! I still have had essentially no instruction, and have had no meaningful instruction, in computing.
Still, now I'm deep into my startup: The software is 100,000 lines of typing, about 24,000 programming language statements. I've plugged together my first server, based on an ASUS motherboard, an AMD FX-8350 processor (8 cores, 4.0 GHz standard clock speed), 16 GB of ECC main memory, etc.
Third, during this work, I heard about various lessons on how to be a better programmer. So, sure, I read The Mythical Man-Month, read lots of stuff about the challenges of writing and documenting good code, saw the interest in APL programming, Prolog and logic programming, the roles of block structure, exceptional condition handling, and scope of names in PL/I programming, saw the rush for Ada programming, saw structured programming, saw object oriented software design and programming, read about Backus and functional programming, did a lot in AI rule based programming, of course studied SQL programming (there's some of it in the code of my startup), etc.
Once I was flatly told that since I had done some Fortran programming, my brain "was forever damaged" for programming.
Lesson: There is a LOT of advice on programming. Yes, that advice is maybe more solid than predicting interest rates in 2019 or what women's Paris fashions will be next fall but, IMHO, not much more solid. Or, advice on programming is nowhere nearly as solid as, say, proofs of the Pythagorean theorem or using physics to predict solar eclipses.
In particular, it's possible, and maybe the best way, to do well at programming while essentially ignoring all the advice and just being self taught. Sorry 'bout that: Such a remark violates some politically correct norms, calls into question the importance of a lot of revered, respected, and coveted undergraduate teaching in computer science, and will rub some fur the wrong way. Sorry 'bout that, but I'm trying to respond to the OP.
IMHO, the important and really useful parts of programming remain a simple subject. Here are the high points: We (i) look at requirements, inputs, and outputs, (ii) get a high level design, likely exploiting the principle of divide and conquer, (iii) find needed algorithms, (iv) define storage, (v) write expressions to do the data manipulations, (vi) wrap the expressions in If-Then-Else, (vii) as a case of divide and conquer form those lines of code in functions/subroutines, (viii) handle exceptional conditions, (ix) design the code so that it will be easy enough to test, (x) test the code, (xi) document the code following "Given the code, without documentation only the programmer and God understand it; six months later, only God." So, write the documentation to explain, clearly, all the important thinking in the work.
I'm confident you can do (i) - (xi), and in that case you should be a "confident programmer".
My view is that the most difficult part of programming and the worst bottleneck to progress in computing is working with tools, e.g., object oriented programming classes, APIs (application programmer interfaces), USB (universal serial bus), etc. that way too often are not clearly documented. E.g., yesterday I was struggling with lack of documentation of Vcore, one of the motherboard voltages. What devices use Vcore? What Wattage is needed? What parts of the power supply provide that voltage and Wattage? But no way is poor documentation about tools a programmer is to use the fault of the programmer. In response, one approach for a programmer, a "confident programmer", is to stay close to old tools, known to be solid, and with many good examples of usage and maybe even some good documentation. E.g., for my first server for my startup, I deliberately went with a motherboard with an old BIOS instead of the newer UEFI.
Most of these lessons are much the same as or follow closely from lessons in projects going way back. E.g., the technique of divide and conquer is really old. How old? For that technique and more, the art goes back at least to military campaigns, designing ships to travel the oceans, construction of palaces, churches, and monuments, e.g., the Pyramids back 4000+ years.
So, for the OP: If you got started in programming, then there should be no good reason for you not to be a "confident programmer". Maybe all you need is what was passed out in the classic movie The Wizard of Oz. Or, I hereby confirm on you the title of Confident Programmer First Class with all the honors, rights, and privileges thereunto appertaining. Congratulations, and happy confident, programming.