CLEAN CODE, ROBERT C. MARTIN
       
       I sought out /Clean Code/ by Robert C. Martin with
       purpose. At work, I'd been feeling defeated, like the
       intelligence and skill required to create a truly expert
       website was beyond my grasp. Sure, I'd been proficient at
       using the Roots/Sage WordPress framework to develop an
       impressive website. Yes, the website worked well and didn't
       break (that). But "under the hood" I felt like things could
       be better: fewer string literals, more concise functions,
       better organization of code. These improvements--if I could
       make them--would increase the speed and ease of implementing
       new features and debugging existing functionality. I'd no
       longer find myself fighting against myself. I'd become an
       author of the code I loved to see--orthogonal, decoupled,
       predictable.
       
       So I picked up /Clean Code/ with a rather poor sense of self-worth. On
       that day, I wasn't feeling like the best coder. Certainly, I wasn't
       the coder I /wish I were/. And the more I read about what good code is
       supposed to look like, the more I felt like the code I wrote was
       absolute and utter crap: chaotic, confused, entropic. I was feeling
       fatalistic, like I'd forever be a "programmer". I'd never reach my
       goal of becoming a "software engineer".[1] I wondered if I even
       belonged in this field. To begin with, my entrance into programming
       was unintentional. Leaving high school and entering into the New Media
       program at Ryerson University, I had no notion of what programming was
       or that it even existed--I took the workings of technology as
       magic.[2] Naturally, I was quite surprised to find myself in a
       programming class in my first year[3], and when the instructor
       demonstrated how a `for' loop could be used to display a row of dots on
       a screen I asked with some certainty: "what's the point of this and
       why would I want to learn it?". Now I can't recall what he said, but I do
       remember the instructor was entirely bewildered by the question.
       
   IMG Same bear, different duds
       
       Fast forward to now. I'm sipping my saturday coffee and
       reading through the book. I feel a little bit better about
       myself because I spent yesterday evening working on a press,
       learning a bit of EmacsLisp, and watching a folk-horror
       documentary. I've also read through the first few sections
       of /Clean Code/ and stumbled across a palliative bit of
       prose:
       
         Writing software is like any other kind of
         writing... you get your thoughts down first, then you
         massage it until it reads well. When I write functions,
         they come out long and complicated. They have lots of
         indenting and nested loops. They have long argument
         lists. The names are arbitrary, and there is duplicated
         code... then I massage and refine the code. I shrink
         methods and reorder them... In the end, I wind up with
         functions that follow the rules I've laid down in this
         chapter. I don't write them that way to start. I don't
         think anyone could.
       
       My partner and I often talk about how writing software and
       writing novels uses similar processes and methodologies. So
       it was assuring to read that same sentiment expressed in a
       highly regarded book like /Clean Code/. It was also a cogent
       reminder that first drafts are seldom final. Improvements
       come from returning again and again to the text. Variables
       need to be clarified, files need to be organized, repetition
       reduced. As I continue to read /Clean Code/ I hope to gather
       more insights into how, specifically, to turn order out of
       chaos. Stay tuned!
       
       
       Footnotes
       ------------------------------------------------------------
       
       
       
       Footnotes
       _________
       
       [1] I care about the title insofar as it implies a certain
       achievement in terms of gathering, understanding, and using an array
       of concepts, tools, etc., to complete a coding task.
       
       [2] And yet, during High School I wrote HTML web pages, installed
       Linux on my iPod (via iPod Linux), coordinated LAN parties with
       friends, and built a computer. Somehow, programming had evaded me
       through all of this.
       
       [3] My introduction was a course at Ryerson taught by in the New Media program. I learned how to write code for .