There are an infinite number of ways of solving the same problem. I have dozens of tools with which I can solve most of my problems; and I can choose to do it i

There are an infinite number of ways of solving the same problem. I have dozens of tools with which I can solve most of my problems; and I can choose to do it in many ways. Sure, there are only so many ways you can write binary search, in a given language. But that doesn't mean there is only one way to solve an actual problem. For example, if your problem is looking up elements in a dictionary (key-value) structure, there are many ways to do it. A hash table? Binary tree? B-tree? Sorted array? Trie? Patricia trie? Linear search in a linked list? Linear search in an array? Are the arrays fixed sized, or variable sized vectors? All of these solutions may be correct, depending on other factors, and all of them have many variants. And that, of course, assumes that you know that a dictionary structure is what you need. Maybe your problem actually would call better for a table with GiST indexes, or a quadree dividing up a two-dimensional space. Above that level, even if your data structure needs are fairly simple or fairly well determined, there's how you structure and organize your code to minimize the chance of bugs, make it extensible, and make it understandable to future programmers. Most of my work isn't writing fresh code. It's finding and fixing bugs in existing code, and extending it to do new things it was never intended to do. Depending on how well organized it is, and how expressive the code is of its intent, that job can be much more difficult or much easier. That's where a lot of the creativity comes in. Finding the write way to structure and express your code to fit the problem at hand. Writing code that will be adaptable to the future, easy to extend without introducing new bugs, easy to fix bugs in, but without including a lot of extra machinery for features that you will never need. It is easy to write code that does a single task, but will be fragile if someone ever tries to extend it to do something else. It is also easy to spend all of your time writing AbstractFactoryIteratorFunctionFactoryAbastractGenerators which are infinitely modular and extensible but don't actually solve any problems. Great code is code which solves a real problem, and can be used tomorrow to solve five more problems that you didn't even know about today, but which doesn't suffer under the weight of being designed to be extended in ways that you thought might be useful later, but wind up never being so. And writing such software, and modifying in those five ways, takes a substantial amount of creativity.