View Single Post
  #40   Spotlight this post!  
Unread 13-06-2015, 10:43
Greg McKaskle Greg McKaskle is offline
Registered User
FRC #2468 (Team NI & Appreciate)
 
Join Date: Apr 2008
Rookie Year: 2008
Location: Austin, TX
Posts: 4,753
Greg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond repute
Re: On the quality and complexity of software within FRC

I have two pennies.

I do not think that FRC code is bad across the board. I think the range of code quality is similar to that of wiring and mechanical construction. In other words it ranges from impressively good to -- "are you actively trying to sabotage your team" -- bad.

To me, much more important than the code on the robot is the knowledge gained by the students on the team. If students wrote code that has issues, but learned how to identify the issues and improve their performance the next time, then FRC has provided a successful challenge. If they have learned how to communicate and write SW as part of a team, how to break down a problem, complete their solution, meet a deadline, evaluate their results, ask questions, and accept mentoring, then they are well prepared for college, training, and career.

To paraphrase, it isn't really about the robot code. That is only the campfire ...

And by the way, communication with nonprogrammers is super important. Most programmers don't write code for themselves or for people like them. They write code as part of a product team that includes EEs, MEs, business and marketing, writers, perhaps even doctors or physicist. When you learn to explain what your code does and doesn't do to a nonprogrammer, when you learn to understand someone else requirements, expectations, resources, tolerances, and deadlines in a common domain language, you are better prepared to become a successful programmer. This goes for all engineering disciplines, not just programmers.

Finally, I see FRC as a multidisciplinary engineering challenge. It incorporates strategic decision making, logistical efficiency, interaction with real-world materials and tolerances, and interaction with five other robots (most years). And it isn't just a controlled demonstration of capabilities. It is a timed sport-like competition that incorporates human drivers and players , and it also places value on presentation, aesthetics, and outreach.

What I'm getting at is that FRC is BIG and complex and really challenging. Code is but one part of the robot. It is necessary for teams to make decisions as to what they will spend time on. There are many many ways to successfully navigate the big FRC ocean. I'd highly encourage the programmers to enter other contests and take on additional challenges. I'd also encourage everyone on the team to learn more about programming. While CS/CE specialists may always be needed, you may also find it very useful as an ME/EE/whatever. I think computers are here to stay.

Greg McKaskle
Reply With Quote