Algorithm complexity is one thing that college courses in computer science do well. Alas, many high school kids haven't picked this up while teaching themselves Ruby or CoffeeScript in a weekend. Complexity analysis may seem abstruse and theoretical, but it can make a big difference as projects scale. Everything looks great when n is small. Exactly as code can run quickly when there's enough memory, bad algorithms can look zippy in testing. But when the users multiply, it's a nightmare to wait on an algorithm that takes O(n^2) or, even worse, O(n^3).
When I asked our boy genius whether he meant to turn the matching process into a quadratic algorithm, he scratched his head. He wasn't sure what we were talking about. After we replaced his list with a hash table, all was well again. He's probably old enough to understand by now.
Libraries can suck
The people who write libraries don't always have your best interest at heart. They're trying to help, but they're often building something for the world, not your pesky little problem. They often end up building a Swiss Army knife that can handle many different versions of the problem, not something optimized for your issue. That's good engineering and great coding, but it can be slow.
If you're not paying attention, libraries can drag your code into a slow swamp and you won't even know it. I once had a young programmer mock my code because I wrote 10 lines to pick characters out of a string.
"I can do that with a regular expression and one line of code," he boasted. "Ten-to-one improvement." He didn't consider the way that his one line of code would parse and reparse that regular expression every single time it was called. He simply thought he was writing one line of code and I was writing 10.
Libraries and APIs can be great when used appropriately. But if they're used in the inner loops, they can have a devastating effect on speed and you won't know why.
Sign up for Computerworld eNewsletters.