Quote:
Originally Posted by 1075guy
Do you think the increasing amount of pre-canned code (in the form of WPILib and all its flavours) is helping or hurting the effectiveness of young teams?
I've seen quite a few teams this year, asking for help with LabVIEW, and specifically the Holonomic.vi. I think what has started to happen, is that these teams are seeing both the veterans, and the code that makes such drive systems seem easy, and jumping on the bandwagon before really understanding how these systems work.
A similar effect has happened with the cameras.
If you hand teams code on a silver platter, they often don't understand WHY it works. Which causes problems when something breaks and it stops working, because they can't know how to fix it if they don't understand how it works.
|
This is a pretty interesting topic. My post here may wander a bit, but I hope I'll get to the point before too long.
From a standpoint of simulating what a real-world controls/embedded software engineer experiences, having the WPI Library make the FIRST experience much more real-world-like.
While at some point each company has to start from scratch, that work has usually been done and incorporated into the company software library many years ago. It's the job of each engineer to utilize the tried and true library and not to reinvent the wheel.
While at first glance using a library seems too easy, libraries present of a lot of challenges of their own. The post that started this topic brought up a lot of good points. I just started a new job recently (I'm a controls engineer working with embedded software), and getting up to speed on all of the library code is quite a challenge. Like 1075guy pointed out, you really should know what the library is doing before using it, or else you may not know how to fix some problems.
As someone else pointed out, it can often be difficult to figure out what some libraries are actually doing. As software becomes more complex, deciphering what the software engineer was trying to do can be difficult at times. I'll admit that there have been times where I said to myself, "I can re-write this to do the same thing in less time than it would take for me to figure out what going on in this code." However, actually re-writing it is usually a pretty bad idea since there are usually a lot of lessons learned in the code that you're looking through, and you probably don't know all of them. That being said, it's often very helpful just to give it a go re-writing it. After that exercise, you can usually get through the library code pretty easily since you went through the thought process yourself. (Just be sure not to use your own code - you'll probably get fired.

)
I said I'd get to the point eventually, so here it goes. In the real world, you're more likely to faced with a problem like we have now in FIRST. You have a new challenge and you have some good code on the bookshelf. You have to determine how to make the best use of the library code and then fill in the gaps. But just keep in mind that if you use code that you don't understand, you're playing with fire - and don't expect the insurance company to bail you out if you burn down your house playing with fire.