|
Re: Programming dumbed down even more.
I actually can sympathise with OP. When I was a student, I was on the programming team, but as a mentor, I actually interact very little with the programming team, as they are well capable of handling it themselves and the priorities of the team are elsewhere.
I agree with him/her on these points:
1) The game recycles a lot of the challenges from last year. In addition, from a strategic point of view, many teams might (should) elect to only drive forward in autonomous, due to the rule changes this year. So autonomous (in my opinion the crown jewel of robotics programming) could be very limited.
2) Robotics programming is a subset of programming, and a lot of the challenges are very tied to hardware. That might not be your cup of tea. Or the team might not be able to provide the robot to make those challenges real/interesting.
3) Part of robotics is project and time management. Understanding your priorities is key. The simplest solution that meets your standard is the one that should be implemented, until all higher priority tasks are completed or you have the time to do it. So maybe it's not worth your time to improve your code, or find more innovative solutions. That's a personal/team decision depending on how you value your time/those solutions.
The solutions I can offer to you are:
1) Get involved in other aspects of the robot. A lot of our programmers prototype, build and do electronics, and used to do animation.
2) Get involved in other programming projects. They aren't part of the 'base' requirement for a team, but they can go a long way to making your team better. Scouting database, website, setting up better communication channels/workflow etc.
3) Work hard at making your code clean and well-designed. Considering how much code can be recycled every year, refactor your code to follow the right design principles to make it easy to maintain and build off of for subsequent years.
There are also things I disagree with OP about:
1) Robustness is important, and introducing more code to add robustness does not make your system more vulnerable and more likely to fail. 'Premature optimization is the root of all evil' is a valid warning, but error-handling/robustness are real problems in robotics that need to be solved, and are not 'premature'.
2) Attitude is important. FRC is not about 'winning things', it is a learning experience. There is plenty of code I/we have written that never made it to the robot for one reason or another. But writing that code is still valuable. 'Winning things' is only the motivation to keep people learning.
3) Don't deride the creativity of others.
__________________
Team 1884 - The Griffins (2007-2014)
Last edited by George Nishimura : 06-01-2014 at 05:14.
|