You know two things: the robot has to move, and you are very hungry. That means you can jump straight into things and start coding, right? WRONG. Well, I guess you can go grab a snack if you want, but that’s besides the point.

The fundamental flaw of many VEX participants is how they underestimate the task at hand. We need a chassis to move, we need to program the robot so it works, and we need to attach our V5 Brain: these are ideas that teams will have at first, but then they tell themselves that that is enough. They become impatient, tell themselves that they know what to do, and then jump into things without planning; they waste time later rebuilding, redesigning, and redoing simply because they didn’t take a few hours to simply plan ahead. One simple oversight can lead to a cascade of failures that ultimately wastes much time due to the troubleshooting needed to overcome them. Not planning leads to worse outcomes (or at least lesser outcomes than if you did plan). This holds true in both the physical and nonphysical aspects of VEX (building and programming). 

Instead of jumping straight into coding, ask yourself the important questions first. What subsystems will I need to program? How should each one function? How can I organize and implement my code such that each subsystem can perform to the best of its capabilities? These are just a few of the many questions you will need to answer by the time you have a finished program. 

It can seem overwhelming at first with all the code you have to write to make everything work; to start off, break your code down into “subsections” for each system you’re programming, then write down what needs to be accomplished for each system to work. This doesn’t happen in just a few minutes, you should really be digging deep and asking yourself “how will this work?” and “what else can I do to ensure that this functions properly?” 

At some point, maybe after a few hours of thought, you should have a good idea of how your program should be written. So, start writing your code according to the plan. If your plan was thought out fully, you shouldn’t need to change any part of it. However, if there was an oversight then it’s back to the drawing board. Make sure your change doesn’t drastically affect major parts of your program. If you do need to completely redesign your plan, then think it fully through again. Once you finish writing each major subsection of the program, test it and ensure that it functions properly. If not, go back and debug it (reference your plan and what specifically is going wrong). Then, it’s the same process all over again for all other systems.

Google

This may seem funny to you, but Google is going to be your best friend when learning how to program. Unfortunately, many people don’t understand how to take advantage of this tool. They’ll type in some oddly specific question like “Why do my pink and fuzzy socks keep getting stuck in the very back of my laundry dryer machine made by Samsung?”... and then they wonder why they get no search results. The same goes for programming, when trying to find a resource, error on the side of less specific search queries in order to find more general results on the topic you’re searching for.