Virtue is its own reward, and so is writing. Anne Lamott’s Bird by Bird: Some Instructions on Writing and Life is full of beautiful prose, characters, and personal anecdotes, and while her advice is tuned to the creative writer, there are three useful lessons that can be applied to all writing.

  1. write short assignments
  2. write only what you can see through a 1-inch picture frame
  3. write a terrible first draft

Blogging about what I am learning and reading forces me to think about what I experience. Almost every day I learn another 1-inch picture frame of programming, and writing it down helps me understand it better. My ugly first drafts usually consist of a question, a few links to resources, and some console output — not Pulitzer Prize winning prose, but an awesome personal resource and record of growth.

All you can give us is what life is about from your point of view. You are not going to be able to give us the plans to the submarine. Life is not a submarine. There are no plans.

In Everybody Writes1, Ann Handley teaches content marketers how to generate “ridiculously good” content. Anyone who has recently enjoyed the pain of the job hunt will notice that much of the advice can be adapted to self-marketing. In my recent code school experience, developing an online presence was as important as learning web development, and since it is hard to market yourself as a web developer without developing anything for the web, a blog is a great place to start. You have picked a career where your ability to learn is one of your most marketable skills, as well as your ability to communicate — both of which you can showcase in your blog. You don’t have to worry about having something original to say: treat it as an opportunity to organize your thoughts and to teach a beginner what you know. Handley gives great advice for people learning to blog and how to generally optimize your online presence — both are great ways to market yourself as a fresh code-school alum.

Read on →

The book club I belong to has a two-fold mission: the first is to inspire through peer pressure to read (and finish) technical books, and the second is to improve our ability to write quality, maintainable code. We started with Practical Object Oriented Design in Ruby (Sandi Metz), and are now on to Refactoring (Martin Fowler and Kent Beck). Along the way, I found a copy of Clean Code by Robert C. Martin in our work library, and dove right in. These three books tout many of the the same principles but focus on different aspects of writing quality code: POODR teaches how to identify abstractions, and to design decoupled objects; Refactoring is a deep dive into the techniques and heuristics for eliminating common code smells; and Clean Code is the intersection between them. It is a style guide, a call to action, and a cautionary tale from the voices of experience. I had several aha moments while reading Clean Code, and here are a few Read on →

If you work in a code base with many other contributors, you may have learned the scouting philosophy to “leave the campground cleaner than you found it.” Sometimes the code you are working in can seem so entangled and complex that it is hard to know where to begin, but Robert C. Martin’s foundational book, *Clean Code*, tells us that very small changes can improve the readability and maintainability of a piece of code.

“It is not enough to write the code well. The code has to be kept clean over time.”

Read on →

Many developers embrace test-driven development (TDD) as an ideal but rarely put it into practice. I often find myself writing code that works and then writing tests that exercise it to ensure that its behaviour doesn’t break when changes are made. Writing tests first is a great way to organize your approach to solving a problem, and in The Senior Software Engineer, David Copeland describes how TDD will help you grow your career as well.

Read on →

“Nothing is miserable unless you think it so; and on the other hand, nothing brings happiness unless you are content with it.” —Buddha

In The Happiness Hypothesis: Finding Modern Truth in Ancient Wisdom, Jonathan Haidt provides an extensive overview of the state of positive psychology today.

Read on →

Situations Matter by Sam Sommers is an eye-opening study of the influence of context on human interactions. Social psychologists call it “fundamental attribution error”, which is a tendency to interpret someone else’s behavior as stemming from their core characteristics, rather than to external circumstances. A simplistic example of attribution error is assuming that the person driving the speeding car is a reckless speed-freak rather than someone rushing a woman in labor to the hospital. Sommers has studied the power of situations over human interactions and how the attribution error interferes with our ability to empathize with the unfamiliar. I have read similar studies of how bias infiltrates our relationships, but what surprised me the most is how it also influences our perception of the self. Read on →

I may be a little late to the game, but I am finally reading Sheryl Sandberg’s “Lean In”, and right from the introduction I can understand why it caused such a stir when it came out in 2012. Sandberg addresses the issue of why there are relatively few women in leadership roles, and ways that women have held themselves back. Read on →

The Why

From Object Constancy by Mike Bostock:

Animated transitions are pretty, but they also serve a purpose: they make it easier to follow the data. This is known as object constancy: a graphical element that represents a particular data point… can be tracked visually through the transition. This lessens the cognitive burden by using preattentive processing of motion rather than sequential scanning of labels.

(The emphasis is mine)

The How

Object constancy is achieved through object identity: the data is bound to it’s object by a shared unique identifier. This allows D3 to reuse the object when the data set is updated. Object identity is achieved by passing a key function to the data() method at the time of data binding:

var data = [ // <-A
        {id: 0, value: "foo"},
        {id: 1, value: "bar"},
        {id: 2, value: "foo"},
        {id: 3, value: "baz"},
        {id: 4, value: "bar"}
    .data(data, function(d){return;});

A Technique for Producing Ideas by James Webb Young (1965)

Young proposes that all ideas are the result of five identifiable stages of rumination, whether they are followed consciously or not:

  1. Gather information, and not just what is specific to your problem domain. Novelty comes from mashing seemingly unrelated concepts together.
  2. Review the information — collate your information in some fashion and go over it. A lot.
  3. Do something else. Get distracted from whatever problem you are trying to solve.
  4. “Eureka! I have it!”
  5. Refine your idea — first drafts are never perfect, so keep polishing.

Scientists Begin Looking at Programmers’ Brains: The Neuroscience of Programming from The Huffington Post.

A new study provides new evidence that programmers are using language regions of the brain when understanding code and found little activation in other regions of the brain devoted to mathematical thinking.

  • Each programming language you learn requires expressing abstract concepts with a different syntax — and in the case of punctuation (~>, =>, :, {}, [], etc) an augmented alphabet. How is a programming language NOT like linguistics?

Besides a mathematical inclination, an exceptionally good mastery of one’s native tongue is the most vital asset of a competent programmer. —Djikstra

How to Live on 24 Hours a Day, by Arnold Bennett (published in 1910)

Arnold Bennett’s recommendations for leading a full and happy life:

  1. Wake up earlier
  2. Practice concentrating your mind on a single task.
  3. Don’t try to change too much too quickly.
  4. Spend time each day reflecting on how closely your life aligns with your principles.
  5. Study the performing arts.
  6. Read poetry.
  7. Failing that, read anything except novels, and think about what you read.
  8. Don’t be smug about it.
Read on →

The Passionate Programmer: Creating a Remarkable Career in Software Development (Pragmatic Life), by Chad Fowler (affiliate link)

This book is aptly titled, and an awesome read. It consists of a series of tips — strategies Fowler has employed to build his own remarkable career. The most important tip is one that can’t really be crossed off a list, and that is to build a successful career in software development one must be passionate about software development.


Unbeknownst to me when I was finishing this book, but knownst to me now is that there has been a vibrant conversation occurring on the interweb about passion and programming. Check out Avdi Grimm’s latest, The Passion Gospel.

Slack: Getting Past Burnout, Busywork and the Myth of Total Efficiency, by Tom DeMarco

Trimming the slack from an organization in an effort to reduce overhead will leave a company with an increased profit margin at the cost of becoming inflexible. “Slack is the natural enemy of efficiency, and efficiency is the natural enemy of slack.” Knowledge work cannot be optimized in the same manner as manufacturing because it is creative by nature, and creative work is requires immersion, experimentation, and… well.. slack.

Team Geek: A Software Developer’s Guide to Working Well with Others by Brian W. Fitzpatrick and Ben Collins-Sussman.

With decades of collective experience, these two authors distill the essential philosophy required to be part of a healthy development team: HRT — humility, respect, and trust. These values are covered in the first chapter and the remainder of the book describes how to best use them as an engineer and as a manager. Some techniques particularly resonated with my world view. Read on →