Read chapter 25 from Programming: Principles and Practice Using C++ (2nd edition) for an introduction to embedded systems software development.
When writing robot code, one should be mindful about how much work a given thread is doing relative to its perceived priority. A robot typically has the following tasks running in different processes or threads, which will be addressed in order of priority.
Their effective priority can be maintained by either adjusting their real-time priority (if they are set as real-time threads or processes) or adding waits to the ends of their loops to reduce the rate at which they execute.
This process handles communication between the robot and the driver station. If other tasks starve this process for CPU time or network bandwidth, robot connectivity during competition will be affected.
These run as threads and are typically executed at between 20Hz and 200hz (periods of 50ms and 5ms respectively). Given that they are digital feedback controllers, they should be run as fast as possible, without starving other processes, to limit phase loss in the controller implementation (see the modern control theory module for more).
This includes joystick axis movements, button presses, and other control actions originating from the driver via the driver station. These can run at lower sample rates since a human's response time to stimuli is much slower than the tasks previously mentioned. That is, responding immediately is less important.
A good sample rate for user input is 20ms. See robot software design patterns for examples.
Information like graph data, print statements, and event logging are the least important from a real-time perspective. Their impact should be minimized in this regard, but they definitely help for feedback controller tuning, assessing robot performance, and debugging.
Its effect on network bandwidth utilization should also be monitored.