A simple view of programming is that you have code, and you have data, and the code operates on the data.

In reality, data is sort of a superset of code.  All code is data, at least in the sense that all code becomes data for the programs that interpet the code.

Data does not always live external to code.  When you "hard code" data, you are putting data right into the code.  Hard coding of data can be quite conspicuous:

   let TAXRATE = 0.05
   let NUM_ITEMS = 5
   let PRICE_PER_ITEM = 0.75
   let TOTAL_CHARGE = (NUM_ITEMS * PRICE_PER_ITEM) * (1 + TAXRATE)

The data/code dichotomy can be more subtle, though.  For example, you might have two web programmers who are designing multi-page web sites.  All pages might require the same look and feel.  One programmer might implement the solution completely in code, composing the HTML from objects and methods.  Another programmer might view a lot of the HTML look-and-feel elements as "data," and use a template-driven solution to implement the web site.  The templates hold the "data," and then the "code" operates on the "data" to create the web pages.

It seems like a no-brainer that extracting "data" components out of "code" will always make for a better solution.  After all, code is inherently more dangerous than data, because code gets executed, whereas data merely gets processed.  But really, what's the difference between being "executed" and being "processed"?  You end up with the original premise--CodeIsData.  In practice, it often works better to keep your data in code, or even to keep your code in data (Excel's a good example).  There's no simple rule.

----
See Also: DataAndCodeAreTheSameThing