[Mr. Lim]

I really don't think you're a very good programmer then.

Good programmers always find a better way to do something, especially when it's not obvious where those improvements can be found.

In 2012 we wrote hundreds of lines of code for CAN error recovery. This allowed our robot to run very reliably, and recover from nearly every CAN failure mode possible. I saw this as a far greater achievement than any of our camera vision tracking, which was quite good I might add. The CAN error recovery was way more important however.

In 2013, or programmers spent crazy hours optimizing the speed recovery algorithm of our shooter and speed control in general. We could shoot all four discs in well under a second, with all disc exit speeds within 1% of our target RPMs. Again, not a glamorous achievement but really hard, and beneficial.

In 2014, the ability to drive back and score a second ball in autonomous will be nice. I expect your team will be able to do that 100% of the time, since it's such a trivial challenge for you . But an even bigger challenge will be to figure out how to make your robot release a ball of if/when you lose comm, power or encounter any other countless failure. A good programmer will take ownership of this problem, and instruct the rest of the team on how best to do this, since programmers have the best understanding of how things behave when those types of problems occur. Bad programmers walk away and exclaim it's someone else's problem.

Of course you probably already have that problem figured out....

Or have you?

No offence, but as a programming mentor on my team, if anyone came up to me and exclaimed that there were no worthwhile programming challenges this year, I'd promptly ask them to leave the team, and give my time to someone who's got a different perspective towards what it takes to build a world class robot...