I can’t quite say I know enough about C++ to be helpful, but I do know something about teaching FRC software.
There’s fundamentally two steps:
First is learning how to program. We’re talking basic data types, control flow operations, data structures, etc. Usually this is learned through a particular language. Interactive online courses tend to be a good method if you don’t have a person available.
Second is learning how to program a robot. This can get really deep - there are lots of robot-related coding practices that would make no sense if you were doing something like making a webserver. For understanding this aspect, I would heavily lean on the example code from wpilib or other hardware vendors. Also, the simpler you keep the software, the less the “robot-specific” aspects will matter.
General beginner advice:
Again, keep it simple and small. If you can’t easily describe, with great detail, exactly what you expect your software to do, you’ll have very very little chance of getting it to actually work.
Have a plan of attack before you start typing. Every good piece of software I’ve ever written started on a whiteboard, not in a text editor.
Be careful of coding by “guess-and-check”. If you do, approach it scientifically. Change only one thing at a time, observe and record its effect. Validate your hypothesis. Choose answers based on facts, not on guesses or hunches.
Remember that fixing one error will often lead to another one. This is ok. “A different error” is still progress. Address each error as it comes up, you’ll eventually get the code to build.
Keep in mind that lines of code are not independent, and behavior is not always “additive”. Just because one line of code made the robot appear to work better, doesn’t mean it needs to be in the code, nor that the line is any particular flavor of “correct”.
Most of the “Code Bootcamp” online resources will describe what to do, but very rarely describe why to do it. The why is largely driven by the robot itself - specifically, from the requirements on how the robot should work. Creating the why is not actually a software exercise, no more than crafting a story is a penmanship exercise.
Code is a tool, like pen and paper. Its job is to make the robot work, and is therefor not an end unto itself.
The hard part is usually deciding what to write, not how to write it. Both will seem hard at first. The latter gets easier with time, but the former usually remains hard.
Also, the Compass Alliance is a lifesaver. Ask precise questions, and don’t be afraid to say “I don’t know what to ask”. They can help with that too.