Rule 14. Code Comes in Four Flavors
Here’s an incredibly oversimplified but still useful model for thinking about code. Imagine that there are two kinds of programming problems to be solved—Easy and Hard.
You’ve already got an idea of what an Easy problem is, but let me give you some generic examples: Finding the largest and smallest values in an array of numbers. Inserting a node into a sorted binary tree. Removing odd values from an array.
Hard problems are also easy to identify: memory allocation, for instance—implementing the C standard library’s malloc and free. Parsing a scripting language. Writing a linear-constraints problem solver.
Now, Easy and Hard, as I’ve defined them here, are really only two points on a spectrum, and they aren’t even the extreme points. Some problems are trivial, even easier than the Easy examples—summing two numbers, say. And there are problems much harder than the Hard examples, like creating a journaling filesystem from scratch.
But they’re two useful points. Between Easy and Hard lie most of the problems programmers solve every day. For what it’s worth, I’ve written solutions to all of these examples—except building a journaling filesystem from scratch, although that sounds like fun.
It seems obvious that you’re going to need to write more code to solve a Hard problem than to solve an Easy one, and that the code you’ll write will be more complicated. This is often the case. Solutions to Hard problems are usually more difficult to write, and ...