Sure I was a newcomer too. And as a newcomer beeing un-experienced I wrote programs this way:
write minimum 100 lines of code and then start testing.
The result was: I had 5 bugs in the code which where influencing each other.
So with trying to correct the first bug this took me a lot of time because there were so many lines of code which caused the bug.
It took looong to find the first bug.
Then I tried to do a "quick fix" without fully understanding my own code.
This caused aditional bugs.
All in all it took 50 hours to make the code work
Today (and as each every experienced and / or professional software-developper) I write code this way:
Write a simple test-program which has only a few lines of code and test it until this testcode works reliable. This took 1 hour time.
Then testing the next small thing
Write a simple test-program for the "second" function which has only a few lines of code and test it until this testcode works reliable. This took 1 hour time.
Putting those two functions together and test again
took 0,5 hours time
repeated this with the next three functions and have the code up and running
after 7 hours. Compared to 50 hours with a lot of head-scratching and frustration.
And additionally doing modifications of the code and test them runs down pretty quick.
You can have "luck" that throwing together parts of other peoples code does work.
Seems to be so in your case. And this might lead to a programming-style of writing many lines then start testing.
Experienced users try to help you with saying: in the long run adding one thing at a time then immitiately test will finish your project faster because searching for the bug will be fast as there are only a few lines to search through!
Trying to be fast will turn out to slow you down.
best regards Stefan