Writing and Coding, Part 2: Self-Discovery

One reason people create things, art generally, but I'm arguing here that creation in itself of anything is an act of self-discovery. People say that writing is an act of self-discovery. Journaling is writing for no purpose other than self-discovery. But even writing that is meant for public consumption also often helps the writer learn about herself. Of course, the act of self-discovery—like creativity—is usually messy, and writers rarely let it out in public. I remember that for one class I wrote a lot of personal essays, a form that I really enjoy (hmm, a blog?). I would pick a topic to write on. I'd get started, heading in one direction. About half way through, I'd discover something about myself or about the topic I was writing on. Because of that revelation, the essay would take a sudden turn and head off in another direction. That was good; I counted on it, hoped for it. But it made more work for me, because then I would have to fix the first half, make the whole essay go in the direction the last half did. Part of the essay would be thrown away, but in the end, I'd learned something, and the essay was much better. I've heard about others who draft novels by throwing away the first, the second, and even the third drafts. That astounds me. Knowing how much work goes into a novel, I have trouble imagining throwing a draft away. On the other hand, it would probably make a better final product. I just wonder if more planning up front could take the place of making such drastic edits. So when I write for self-discovery, I don't know where the work is headed, and I have to be willing to cut drastically, even throw out whole drafts. How does this apply to programming? Supposedly, Richard Feynman had written on his chalkboard, "What I cannot create I do not understand." Part of the programming I do is to help me understand problems. I'm not by nature a detailed thinker. I prefer to stay in the clouds, thinking about things in an abstract way. Programming requires me to be specific, however, and to think problems through thoroughly. In solving a problem in code, I learn something about the problem and what it takes to solve it. In learning to solve a problem this way, I often work my way to a solution gradually. I open up a REPL (lisp read-eval-print loop) or Python interactive interpreter. I open up a text editor. I go back and forth between the two, feeling my way to a solution. Working this way is fun, but it is wasteful. As I'm doing it, I may attempt several solutions that have to be thrown away. And often, the code that results is a mess and has to be thrown away anyway. But at that point, I understand the problem and what it takes to solve it, and I can quickly write something much better. That process sounds like what I did with the personal essays. But I am learning something about myself on this? After all, I'm talking about self discovery in this posting, not problem understanding. It can be. I should probably write another post focusing on this assertion, arguing just it, but the act of creating anything teaches us about ourselves, if we're listening. How do we interact with the environment we're changing? How is our approach different than other people's? Why is this problem interesting, not that one?