Working Ninja


You should name a variable using the same care with which you name a first-born child (xxi).

Quality is the result of a million selfless acts of care--not just of any great method that descends from the heavens. That these acts are simple doesn't mean that they are simplistic, and it hardly means that they are easy. They are nonetheless the fabric of greatness and, more so, of beauty, in any endeavor. To ignore them is not yet to be fully human (xxii).

Chapter 2: Meaningful Names

Clarity is king (25).

Our goal, as authors, is to make our code as easy as possible to understand. We want our code to be a quick skim, not an intense study. We want to use the popular paperback model whereby the author is responsible for making himself clear and not the academic model where it is the scholar's job to dig the meaning out of the paper (27).

Chapter 3: Functions

Functions are the first line of organization in any program (31).

The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that (34).


So, another way to know that a function is doing more than "one thing" is if you can extract another function from it with a name that is not merely a restatement of its implementation (36).

Master programmers think of systems as stories to be told rather than programs to be written (49).

Chapter 4: Comments

The proper use of comments is to compensate for our failure to express ourself in code. Note that I used the word failure. I meant it. Comments are always failures. We must have them because we cannot always figure out how to express ourselves without them, but their use is not a cause for celebration (54).

The older a comment is, and the farther away it is from the code it describes, the more likely it is to be just plain wrong. The reason is simple. Programmers can't realistically maintain them (54).

Truth can only be found in one place: the code (54).

It takes only a few seconds of thought to explain most of your intent in code. In many cases it's simply a matter of creating a function that says the same thing as the comment you want to write (55).

Plopping in a comment just because you feel you should or because the process requires it, is a hack (59).

Any comment that forces you to look in another module for the meaning of that comment has failed to communicate to you and is not worth the bits it consumes (60).

Others who see that commented-out code won't have the courage to delete it (68).

Chapter 5 - Formatting

Each line represents an expression or a clause, and each group of lines represents a complete thought. Those thoughts should be separated from each other with blank lines (78).

Have you ever hunted up the chain of inheritance for the definition of a variable or function? This is frustrating because you are trying to understand what the system does, but you are spending your time and mental energy on trying to locate and remember where the peices are. Concepts that are closely related should be kept vertically close to each other. Clearly this rule doesn't work for concepts that belong in separate files. But then closely related concepts should not be separated into different files unless you have a very good reason.  Indeed, this is one of the reasons that protected variables should be avoided (80).

All quotes from Clean Code: A Handbook of Agile Software Craftsmanship by Robert C Martin.


Getting Real by 37signals (available online) is a good mind stretcher. It provided much of the content for Rework (also by 37signals). Both books provided a lot of counter-intuitive business and development advice that works rather well in the software industry. Rework is one of my favorite business books with great illustrations (also available online).

Favorite chapters (from Getting Real):

Maybe just read it all =)

Programming as an intellectual activity is the only art form that allows you to create interactive art. You can create projects that other people can play with, and you can talk to them indirectly. No other art form is quite this interactive. Movies flow to the audience in one direction. Paintings do not move. Code goes both ways.

Zed A. Shaw, Learn Python The Hard Way


Why is programming fun? What delights may its practitioner expect as his reward?

First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. I think this delight must be an image of God's delight in making things, a delight shown in the distinctness and newness of each leaf and each snowflake.

Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful. In this respect the programming system is not essentially different from the child's first clay pencil holder "for Daddy's office."

Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning. The programmed computer has all the fascination of the pinball machine or the jukebox mechanism, carried to the ultimate.

Fourth is the joy of always learning, which springs from the nonrepeating nature of the task. In one way or another the problem is ever new, and its solver learns something: sometimes practical, sometimes theoretical, and sometimes both.

Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. (...)

Yet the program construct, unlike the poet's words, is real in the sense that it moves and works, producing visible outputs separately from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.

Programming then is fun because it gratifies creative longings built deep within us and delights sensibilities we have in common with all men.

The Mythical Man-Month: Essays on Software Engineering by Frederick Brooks


Here is a quote I just now came across that wonderfully sums up why I enjoy programming.

The goal of this book is to teach you to think like a computer scientist. This way of thinking combines some of the best features of mathematics, engineering, and natural science. Like mathematicians, computer scientists use formal languages to denote ideas (specifically computations). Like engineers, they design things, assembling components into systems and evaluating tradeoffs among alternatives. Like scientists, they observe the behavior of complex systems, form hypotheses, and test predictions.

The single most important skill for a computer scientist is problem solving. Problem solving means the ability to formulate problems, think creatively about solutions, and express a solution clearly and accurately.

How to Think Like a Computer Scientist by Peter Wentworth, Jeffrey Elkner, Allen B. Downey, and Chris Meyers


"All of us are smarter than any of us, and adding people can, if we do it right, make us smarter and faster and better at serving our customers." -Seth Godin



I’ve enjoyed building websites for over a decade and have never kept a log of what I’ve learned. There are three reasons for wanting to start this blog.

  1. To share what I have been learning with others.
  2. To have a reference to go back to.
  3. To show a future client or employer what I have experience doing.

Also, since I worked a non-web-related job the past few years, I feel like I have lost touch with a lot of the changes HTML5, CSS3, mobile devices and responsive design have brought along. I’m pretty excited to blog about what I find (or shown to me by friends) and how I’m using that in my projects.