Taking a Page from the Programming Competitions

Having done a few programming competitions, I know firsthand how it's important when developing software solutions that the developer utilizes a sound approach. A lot of times a brute force approach will suffice, but issues arise when the software is put through the torture test of a large set of data.

In a university setting, Computer Science students are asked to come up with solutions for fairly trivial problems, at least in my experience. Coming up with the first 50 prime numbers isn't that challenging. Coming up with the first 500 or 5,000 might be more difficult. The first 50 primes might take seconds, if that. But try your code with an order of magnitude larger of a value and you might sit. With as powerful as even the cheapest machines are these days, sitting for more than 10 seconds, depending on your computation, might suggest that your approach is poorly designed or executed.

In my program, many of the projects are one-off assignments where the goal is to do X objective. Students have generally been punished, grade-wise, for uncommented code, but that has been the extent of the requirements in most cases. A brute force approach will work most times, but the code isn't well designed.

A possible solution to this is to treat the assignments more like those problems assigned at programming competitions: use a large, varied set of data when computations are being performed, and require a reasonable amount of time to finish the computation. Build a decent approach and your computation is done lickity split, but attempt to do things in a brute force manner and you just might sit and wait for seconds, minutes, or hours.

There are few things more satisfying in this discipline than coming up with a great solution for a problem that has  given you fits. I've found a good resource in the Project Euler questions. Working on problems that require a good approach gets you thinking about how to keep your algorithms lean, and it'll help you know the limitations of the language you're working in (i.e. limitations with using integers vs. floats vs. longs, rounding errors, etc.)