Today I worked on maintaining robot code. Since this was mostly uneventful and I didn’t learn much (and communicating learning is the point of this blog) so I’ll talk about some of my stories from competition. Now if anyone who knows me in real life is watching this, you’ll probably be groaning as I’ve told you these stories tons of times, but for my dear anonymous viewers I’ll do it again :-).

Preamble: I participated (and will try to continue to help with) in FIRST robotics, an international competition for high school aged kids where they have six weeks to solve a real engineering challenge by building a robot to perform a particular task in six weeks. Now these tasks are usually sports-like games, and the kids are given no help by the competition organization in developing the robots. For examples of robots our particular team has made, you can look on this page.

So, we were at competition and we were having serious problems with our robot dying every couple matches. Now as you can probably understand, this is a pretty bad situation, and had to be fixed quick. We had to fix this quick. The programming mentor and I began developing strategies before our next match, and I came up with the idea to stick a little print statement at the beginning and the end of every one of our functions to see which one the robot died in. After this, we find out that the problem existed in the code which was sending over the local network back to our robot. We pushed this fix literally as we were walking to our next match, so it was definitely very timely. This is an example of why the oft knocked Printf Debugging can be very useful.

Another story is more recent (this year). During our season (when we were building the robot), we experienced problems with our winch which was run by a wrench. Now, this has become pretty much a legend on our team, but if you ran the winch backwards, it would cause the wrench inside to snap and cause a lot of disassembly to have to occur. So with this explained, I managed to break this winch twice. The reasons for both I will not get into, but it is a prime example of why software developers and engineers in general should not rush while fixing a bug or writing the initial code. In addition, I ended up adding little comments to the top of all of the functions after these incidents which told you exactly what each one assumed.

So there are two stories from my past and present which in my opinion teach important lessons about software development. Thanks for reading, and I promise tomorrow’s post will be about some more current coding! :-)