Tweak: Growing Up on Methamphetamines by Nic Sheff

As part of the memoir writing class I took last fall, we read David Sheff’s book, Beautiful Boy, which tells the story of watching his promising young son struggle with drug and alcohol addiction. His son’s book, Tweak, tells his own wrenching story. When I read American Psycho a few years ago there were times I was so disturbed I sort of held the book at arm’s length and read through squinted eyes. I had the same experience with Tweak, amplified by knowing what I read was true. Tweak is not a perfect memoir — Sheff acknowledges some mistakes and missteps in the afterword — but it manages to convey the roller coaster of insanity Sheff went through as an addict, a recovering addict, and a relapsing addict. Unlike his father’s book (also very good) which mingles person narrative with facts in a journalistic memoir, Tweak is all raw emotion and craving.

The Liars’ Club: A Memoir by Mary Karr

You think your mom was crazy? No. Not at all. Mary Karr’s mom? Crazy. As in “let me set your shit on fire and come at you with a knife” crazy. And yet Karr somehow still renders her with empathy and tenderness, describing her childhood in East Texas in this, her first, memoir.

Lit: A Memoir (P.S.) by Mary Karr

If The Liar’s Club let me peer into Mary Karr’s east Texas childhood, Lit, her third memoir, dropped me into her development as an adult and a poet. And consequently into her development as an alcoholic, a recovery alcoholic, and a Catholic (albeit one she describes as “not the Pope’s favorite”). I checked out Lit from the library, read it in a couple days, and then ordered my own copy. So much of the story resonated for me, and Karr’s phrasing and ear for dialogue make it a joy to read.

The Death of American Virtue: Clinton vs. Starr by Ken Gormley

A massive tome at 800 pages, Gormley’s account of Clinton’s legal troubles, beginning with Paula Jones and morphing into the Office of the Independent Council investigation, reads like a novel. Contrary to what I believed in high school, when it was all going on (and I was a Young Republican), as well as what I hear today from some more left-ist friends (that Starr was a rapid attack dog out for blood), Gormley tells a very human story. That is, a story where everyone is flawed, imperfect, and probably underestimating their own flaws. Was Clinton an incorrigible womanizer who caused massive wreckage to his life and the lives of those around him by lying? Yes. Did Starr and his office operate at the edge of their charter, with little oversight or control? Yes. Should you read this? Yes.

Django 1.1. Testing and Debugging is split, as the title implies, into two halves: Testing, followed by Debugging. It uses a narrative approach, following the development of a survey application throughout. The book starts with an overview of the stock unittest and doctest facilities in Python. Most of chapters 1 through 3 are devoted to the basics of unit testing, specifically for Model classes. Tracey provides information about Django-specific nuances along with way. For example, I didn’t realize Django ships with a customized doctest module to enabled ELLIPSES support in Python 2.3. Chapter 3 also provides information about how to use fixtures for providing test data, and how to specify those apart from the initial data fixtures developers may already be aware of. Chapter 4 mirrors some of the information found in Django’s testing documentation: the Django TestCase, and how you use it to do basic view testing.

Chapter 5 describes integrating Django with other tools, primarily by example. Tracey discusses how to replace the default Django test runner, and what interface the replacement needs to implement. She also provides a stub example of more “invasive” integration, crafting a new management command that could (possibly) handle code coverage reporting while running the tests. This stub was interesting, but didn’t feel particularly testing related to me. Chapter 5 closes with examples of using the excellent coverage package with django-coverage, and integrating twill into Django tests.

Chapter 6 begins the section on debugging with an overview of the Django settings that impact debugging, and how the development server supports debugging of applications. Chapter 7 follows with a thorough analysis of the development server’s error page, as well as examples of debugging based on the information given. The examples continue to develop the survey application, and introduces what Tracey describes as “typical mistakes”, then describes how to fix them.

Chapter 8 begins to dig a little deeper, and I was happy to see mention of Rob Hudson’s Django Debug Toolbar, an indispensable tool. Chapter 8 also includes details on using the logging module, and how to develop a decorator that marks function entry and exit. I know that I’m all too guilty of using print instead of logging, and it was nice to be reminded of how easy this is.

Chapter 9 was my favorite part of the book. It gives a good overview of using pdb, and then goes on to demonstrate how to use pdb and a shell session to test a race condition and deal with it.

Overall Django 1.1 Testing and Debugging seems like a good introductory book for Django developers who are new to testing (or Django). While many of the debugging examples seemed obvious to me, I suspect that someone new to Django could use this book as an introduction to development and debugging.

My script for converting maildir to mbox continues to be one of the most popular pages on yergler.net (according to Google Analytics). Of course, even after I updated it slightly in February, it still had a couple of bugs, likely introduced when I converted the page from MoinMoin to WordPress. This afternoon I finally decided to clear out the pending comments about those bugs, and update it.

While looking at the Python documentation for the mailbox package included in the standard library, I realized it could probably be simplified even further by using the library’s native mbox support. I’m also more comfortable using the standard library’s implementation of mbox rather than my hacked up raw file implementation (who knows, the standard library may do exactly what my script did: I’m not an mbox expert by any stretch of the imagination).

The new script is below. I should note that it’s received very little testing, and I make no guarantees. I also should note that there is nothing creative or original about this. It just uses Python’s excellent standard library. As they say, “batteries included”.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

# -*- coding: utf-8 -*-
 
"""
maildir2mbox.py
Nathan R. Yergler, 6 June 2010
 
This file does not contain sufficient creative expression to invoke
assertion of copyright.  No warranty is expressed or implied; use at
your own risk.
 
---
 
Uses Python's included mailbox library to convert mail archives from
maildir [http://en.wikipedia.org/wiki/Maildir] to 
mbox [http://en.wikipedia.org/wiki/Mbox] format.
 
See http://docs.python.org/library/mailbox.html#mailbox.Mailbox for 
full documentation on this library.
 
---
 
To run, save as maildir2mbox.py and run:
 
$ python maildir2mbox.py [maildir_path] [mbox_filename]
 
[maildir_path] should be the the path to the actual maildir (containing new, cur, tmp);
 
[mbox_filename] will be newly created.
"""
 
import mailbox
import sys
import email
 
# open the existing maildir and the target mbox file
maildir = mailbox.Maildir(sys.argv [-2], email.message_from_file)
mbox = mailbox.mbox(sys.argv[-1])
 
# lock the mbox
mbox.lock()
 
# iterate over messages in the maildir and add to the mbox
for msg in maildir:
    mbox.add(msg)
 
# close and unlock
mbox.close()
maildir.close()

The PDF preview of chapter 3 (basic unit testing) looks good, and the table of contents looks like a good overview of basic tools and techniques. I’m particularly looking forward to reading about integrating Django with other testing tools (chapter 5), and using Django with pdb (chapter 9). I’m looking forward to learning more about testing my Django applications — and hopefully how I can form better habits around testing.

I believe Apple will announce that you’ll be able to run iPhone OS applications on Mac OS X. Why? Well, it just seems like it fits.

• Apple is obviously investing heavily in iPhone OS. One indication of its importance is that the Apple Design Awards are limited to iPhone OS applications this year.
• As the iPad has launched, and developers have been crafting applications to watch video, read news, and listen to public radio, the question has been raised: why weren’t people creating applications that looked this good for laptops? I’m sure people using Macbooks would love to have some of those apps. (I really don’t believe iPhone OS has any secret ingredient that suddenly enables ABC to create a video player.)
• Apple’s restrictions to the iPhone SDK agreement, prohibiting the use of third party development tools, will allow Apple to easily switch hardware platforms, ala PPC to x86 — or support an additional architecture if needed. You know, an additional architecture like x86.
• Apple has experience with compatibility virtual machines (see: Rosetta), as well as LLVM. You can imagine these experiences informing support for running iPhone OS applications in a sandbox on Mac OS X, or re-targeting the application at compilation time.
• Finally, and perhaps most importantly, it inserts Apple into the middle of additional software purchases, enables them to leverage the App Store further, and exert additional control.

So that’s my WAG for WWDC. I think it’ll be sold to developers as a way to reach new users, and provide an end-to-end, mobile to desktop experience (I won’t be surprised if they launch improved, wireless sync between your iPad and Mac at the same time — syncing documents between iWork for iPad and your Mac sounds like hell). I think it’ll be sold to users on security and stability: iPhone OS applications would almost certainly have limited privileges on the desktop, and if you replace your laptop, logging into your iTunes account would sync your apps back to the machine.

If I’m right, users will undoubtedly begin to see [beautiful] software stream onto their desktops from a single, tightly controlled pool, and developers will devote hours crafting tools with the hope they’ll pass muster, and make it into that pool. If I’m wrong, well, I’ve been wrong before. And this is just a wild ass guess.

Grok 1.0 Web Development takes what as I think of as a customary approach to framework introductions, instructing the user on the basic features of the framework by building an application (in this case a to do list manager) and adding features and refining the code as it goes. This works well for Grok — the amount of boilerplate code is kept to a minimum, by design, so the text can focus on first implementing the feature, then delving deeper to discuss the “best practice” around that tool if needed. For example, Chapter 6 covers ZODB Catalogs (index). It starts by defining the search view and user interface so that the reader has a functioning search tool to work with, then takes a diversion to discuss how one best structures their application to support search. These detailed drill downs are one of the most valuable parts of Grok 1.0 Web Development: they help the reader expand their understand beyond just implementing a feature, to implementing in a way that will be flexible and easy to support in the future. The [somewhat brief] advice on when to use the ZODB versus a relational database is another example of practical advice that I appreciated in the book.

Grok 1.0 Web Development is not perfect. In particular I wish the chapter on testing were earlier (the author’s admonition that it “should not be treated as an afterthought” doesn’t seem to jibe with its placement among the advanced topics towards the end of the book. I suppose I’m also a little sensitive to slogging on Zope 3 and it’s “lack” of agility. I can probably be described as a Zope 3 / Zope component architecture apologist, but it seems the type of agility described is a rather narrow, specific definition. The sprints I did on Zope 3 at PyCon several years contributed more to my understanding and appreciation of test driven development and agile planning than just about anything. Yes, Grok gets it done without the ZCML; I think it’s an exercise for the reader as to whether that’s better or worse for your application.

I think that the Zope derived frameworks such as Grok and repoze.bfg are some of the most interesting in development today. Grok 1.0 Web Development does a great job of introducing Grok to developers who are new to web programming, or who already have some familiarity with another framework. I recommend it to anyone interested in building extensible web applications with a minimum of boilerplate.

Good morning. I am incredibly happy to be here talking to you this morning. I’m excited to be here because CiviCRM has been and continues to be a very important part of our infrastructure at Creative Commons. Beyond CC, I think it’s an important piece of software for non-profit and grassroots organizations, one that should not be ignored when evaluating donor and constituent management applications. This morning I want to tell you about my experience with it, and why I think it’s so very, very important.

I’ve been at Creative Commons about six years now. I started working as an engineer, which basically meant I wrote code, deployed code, and babysat the server — there was only one then — when it got cranky. We started using Civi in 2006. Creative Commons is a 501c3, which means we have to work towards passing the IRS’s public support test: 30% of our operating budget from “the public”, in our case. In 2005 we had a rather unpleasant realization: we hadn’t done shit, and we were getting close to the end of our five year grace period. I hacked together a contribution page, wired up PayPal for donation processing, and put together a terrible looking Plone backend that allowed people in the office to enter offline checks, promised contributions, etc, and to make the all important thermometer work on the front page. And we started begging. Creative Commons is fortunate to have a generous, passionate community, and they responded to our call. After the dust had settled and we realized we were going to have to do this again, we knew we needed something better than what I could write in between other projects. It was clear that we didn’t have the resources to build something complete, and still fulfill our mission, so we started looking around. Mike Linksvayer, then our CTO, asked me if I’d used Raiser’s Edge before, and if so, what I thought of it. Raiser’s Edge had — perhaps has — the mindshare, and our development director at the time was certain Raiser’s Edge was the essential piece of technology to make the jump to the big leagues. If I recall correctly, my response is not suitable for mixed company.

Before working at CC, I worked for a very different kind of non-profit. Canterbury School is a private, K-12, college prep school. With small classes, dedicated teachers, and a commitment to education that includes computer programming for *every* student, they are they best game in private education in northeast Indiana. The faculty and staff there do an amazing job. Every year Canterbury holds an annual campaign, which raises funds to support the school operating budget. Part of my job there was supporting the development office and Raiser’s Edge. Our Raiser Edge installation had one primary user, Barbara. I am convinced Barbara is the direct descendant of the bearded UNIX sysadmin wizards. Unlike her ancestors, she does not keep mainframes online, but rather has her own special wizard-like skills: comprehensive knowledge of the Raiser’s Edge query language and interface. So you can imagine that days when Barbara called my office were not my favorite days at work. “The database is locked” “My labels template won’t print right” “The query isn’t returning data I know is in there.”

Now in all fairness, this was almost ten years ago, and we were running Raiser’s Edge on Sybase SQLAnywhere. But I’d also like to point out that we were paying about $3000 a year for a support contract, a contract sold with a statement along the lines of, “You want updates when they come out, don’t you?” These updates and improvements, when they did come out, were usually accompanied by new system requirements, indirect costs, and lots of time spent making sure the upgrade went correctly. And bugs fixes? What bugs?

This, my friends, is what we call a protection racket.

I also had enough experience to know that expecting to deploy a CRM package out of the box with no customization was probably unreasonable. I had worked on a CRM and ERP deployment in 2003 for an international manufacturer that took the better part of a year, and whose customization costs were almost as high as the software licensing costs. I was lucky on that project: I got to write C++ DLLs to handle custom accounting information from pricing tables. And this was a product sold on how open and customizable it was. “Look, we have an API, you can write a DLL.” Gee, thanks.

So back to Creative Commons: after some consideration, CiviCRM was selected as a platform. When we started out with Civi, we paid for CivicActions’ development, customization, and hosting services. We also paid for updates, improvements, and upgrades, just like we would have with Raiser’s Edge. It’s a couple years later, in 2007, when the difference between the two really becomes apparent. because

In 2007, we had been been using Civi for a couple of years, and while we weren’t unhappy with it, it still wasn’t really a piece of software any of us looked forward to using. I personally tried to ignore it as much as possible except during the lead up to the annual campaign. It worked, it did it’s job, but it felt quirky and a little clunky, sort of like I was working against it sometimes. But there was hope. The 3.0 release was going to be a big upgrade. Lots of new features, improved user interface, and lots of attention paid to usability. We talked to CiviActions about a 3.0 upgrade and some additional customization we wanted to do. The quotes we got back were, well, expensive. Now I don’t think they were out of line, but it was more than we had budgeted at the time. Our situation internally had changed, as well. We were up to a handful of servers, two full time engineers, and a graphic designer with great technical chops. Instead of quoting out every change and upgrade, it started to feel like we might be ready to walk on our own.

So we checked out the source code — including all the custom code CivicActions built for us — and installed it on our own server.

I think this bears repeating. We downloaded the source code — the same source code our vendor was using — and installed it with our own tools. We didn’t have to ask for permission, pay a fee, or “upgrade” our license; it was already available to us.

You see, unlike the protection racket I lived under at Canterbury, at Creative Commons we’ve been paying for something that we own. That the community owns. We’re paying for value that we retain, that we can take elsewhere when we’re ready. This is huge.

Now, for those of you who are open source and free software developers, those of us who run Linux on our laptops, who build applications using open source tools, this sounds like business as usual. But CiviCRM is very special software: it is not software for Geeks, it’s software for Humans.

At Creative Commons, we build legal tools that help people share their creative works with the permissions that they choose, the some rights reserved that work best for them. But we also recognize that most of the time, those creators are not lawyers. They’re coming to us because they’re not lawyers, and our job is to reduce the number of hoops they have jump through to share their work. So we make our tools available for two different audiences, which we jokingly refer to as Lawyers and Humans. Today I’d like to posit that we have a similar divide when it comes to free software. Apache, Linux, MySQL, CouchDB — these are all examples of software for Geeks. CiviCRM is software for Humans. And it’s really important software for Humans.

A friend of mine, Asheeesh Laroia, runs Open Hatch, a website dedicated to helping people get involved with open source software. Talking about software like CiviCRM, he made the comment, “It’s important that we give communities tools that they can use and that they can control. Otherwise how do we expect them to be independent and self sustaining?” Fundraising and constituent management is a critical part of any non-profit’s life cycle. Why do we think it’s OK for these organizations — many of which we personally contribute to — to enrich the coffers of a for profit businesses with no real long term return?

Please don’t misunderstand me: I am not saying that paying money for support is wrong, misguided, or unncessary. I am saying that we — non-profits — can do a lot better than investing in a protection racket. We can pay for support, and at the same time invest in our
tools. And when we’re ready to move to the next level, there is no upgrade fee. We already own it all.

Creative Commons’ story did not end by simply installing CiviCRM onto our server and moving on. And putting it on our own server has not resulted in the cost of Civi going to zero. In fact, we still “pay” for support, but we do it differently these days. Maintenance and support for Civi is a core responsibility for the technical team today. When our development team has questions, wants to run new reports, or wants to do something new like personal campaigns, they sit down with Chris, John, and Nathan, and figure out what we’ll need to do to Civi to make it work.

Last year we decided that the contribution workflow was too long. We were demanding information from our donors that we didn’t necessarily need, and duplicating information they might give PayPal when processing their payment. We wanted to streamline the process,
reducing the number of clicks between us and a donor’s money. We invested the time to implement some custom code on Civi to make this happen. Right now we want to offer tighter integration between CiviCRM and CC Network accounts, a premium we offer donors. So we’re writing code to do that.

The click-streamline code is available to anyone who wants to use it. We’re writing our integration code with the hope we can contribute it to the CiviCRM core. It’s tempting to say that we’re no longer customers, that we’ve moved up to become partners. But the truth is that we were never just customers: with CiviCRM, we were partners from day one, we just didn’t necessarily realize it.

Now I know that lots of commercial vendors talk about partnering with customers. I’d like to call bullshit on that. If you don’t have the source code, you are not a partner. If you can’t be trusted to inspect the software you rely on, you are not a respected equal in that relationship. Companies go out of business. Companies are acquired. Management changes. This is the reality of business.

Let’s go back and look at Canterbury again. I sent Vern, Canterbury’s Director of Technology and a man who can really only be called my mentor, an email to fact check my memory about what we were working with in 2001. Vern told me he’s part of a Google Group formed for schools to exchange SQL Server queries for accessing their data. Why SQL Server queries and not an API — seems a little crude to me. Turns out, if you want to write your own code to access your data through their API, there’s a toll: $10000 and another $1000 per year in support.

If a customer want to access their data in the safest, sanest manner, they have to pay. Again. If that were the reality for CiviCRM, we would not have been able to streamline our contribution process. We would not be integrating CC Network memberships as a premium for donating. Hell, I’m not even sure we’d be able to show the beloved thermometer on the front page. The cost is too high.

Let me wrap up with some thoughts about the future. If you work for a non-profit or grassroots organization, I believe it is incumbent upon you to think about things in terms of fiscal stewardship. Where is your money going today, and what value are you getting? Are you a customer, or are you a partner? As an officer at a non-profit, I see fundraising and development as critical to our ability to execute our core mission. Our mission at Creative Commons is not to make money, but if we can’t keep the lights on, we can’t help people share their work online.

If you’re using CiviCRM today, it’s time to start talking about it. I find that lots of non-profits I talk to are unaware that there’s a different way. They haven’t thought about the fact that they have a choice. We need to work to increase the mind share that CiviCRM has. If you think Civi is only good for small organizations, that you can’t really recommend it for large scale installations, I’d like to challenge that misconception. Mozilla Foundation. Wikimedia Foundation. Creative Commons. We’re all using CiviCRM for all or part of our constituent management solution. And if you’re a user or integrator who’s customizing it, it’s time to start thinking about how you give back. The AGPL already requires that you make your changes available. I think it’s worth your while to consider how you’re making those changes. Is this a customization someone else might want? If so, I encourage you to take a few minutes, talk to the developers on IRC or the forums, and think about how you might build your solution in a general way. The CiviCRM developers are some of the most available and responsive I’ve ever encountered. They can give you guidance about how to think about a problem. It may take some extra time to build a general solution. But if you can contribute that back to the core codebase, you’re going to make upgrades much easier. And the great thing is that at the same time you’re making things easy for yourself in the future, you’re also helping to sustain the community and the development process.

Finally, if you’re evaluating CiviCRM today, I have some advice for you. Do not think to yourself, “oh, I can download this for free, this isn’t going to cost me anything.” Do not look at CiviCRM as a zero cost solution. My experience is that there is no such thing in CRM, and I’d argue you wouldn’t want there to be: we all need experts we can call upon in an emergency, and paying for a tool enables the developers to improve it. Instead, do your checkbox evaluation and realize that Civi is competitive with commercial packages. Talk to people who are using CiviCRM and tell them how you plan to use it, ask them about their experience. Then ask yourself, “how much am I going to spend year over year, and what am I getting from that? How is my investment going to grow? Am I paying for protection, or am I
investing in my organizations future stability?” I think the answer is self evident.

Working at Creative Commons has been an amazing opportunity for me, and I’m proud of a lot that I’ve accomplished over the past six years. But I’m especially proud of how we’ve used and contributed to CiviCRM. I’m proud to be a user, and I feel good every time I talk to my team about Civi and hear, “Oh, yeah, I just jumped on IRC and got an answer from one of the core developers.” You can not buy that sort of dedication and support.

The talk reminded of a blog post I saw late last year and never got around to commenting on, Ruby for Desktop Applications? Yes we can. Now I’m only a year late in commenting on it. This post caught my eye for two reasons. First, the software they discuss was commissioned by the AGI Goldratt Institute. I had heard about Goldratt from my father, whose employer, Trusted Manufacturing, was working on implementing constraints-based manufacturing as a way to reduce costs and distinguish themselves from the rest of the market. More interesting, though, was their discussion of how they built the application, and how it seemed to resonate with some of the work I did in my early days at CC.

Atomic wrote three blog posts (at least that I saw), and the one with the most text (as determined by my highly unscientific “page down” method) was all about how they “rolled” the JRuby application: how they laid out the source tree, how they compile Ruby source into Java JARs, and how they distribute a single JAR file with their application and its dependencies. I thought this was interesting because even though it uses a different language (Python instead of Ruby), GUI framework (wx instead of Swing/Batik), and runtime strategy (bundled interpreter instead of bytecode archive), the thing I spent the most time on when I was developing CC Publisher was deployment.

Like Atomic and Phatch, we had a single code base that we wanted to work across the major platforms (Windows, Linux, and Mac OS X in our case). The presentation about Phatch has some great information about making desktop-specific idioms work in Python, so I’ll let them cover that. Packaging and deployment was the biggest challenge, one we never quite got right.

On Windows, we used py2exe to bundle our Python runtime with the source code and dependencies. This worked most of the time, unless we forget to specify a sub-package in our manifest, in which case it blew up in amazing and spectacular ways (not really). Like Atomic, we used NSIS for the Windows installer portion. On Mac OS X, we used py2app to do something similar, and distributed a disk image. On Linux… well, on Linux, we punted. We experimented with a cx-freeze and flirted with autopackage. But nothing ever worked quite right [enough], so we would up shipping tarballs.

The really appealing thing about Atomic’s approach is that by using a single JAR, you get to leverage a much bigger ecosystem of tools: the Java community has either solved, or has well defined idioms for, launching Java applications from JARs. You get launch4j and izpack, which look like great additions to a the desktop developer’s toolbox.

For better or for worse, we [Creative Commons] decided CC Publisher wasn’t the best place to put our energy and time. This was probably the right decision, but it was a fun project to work on. (We do have rebooting CC Publisher listed as a suggested project for Google Summer of Code, if someone else is interested in helping out.) Given the maturity of Java’s desktop tool chain, and the vast improvements in Jython over the past year or two, I can imagine considering an approach very much like Atomic’s were I working on it today. Even though it seems like the majority of people’s attention is on web applications these days, I like seeing examples of interesting desktop applications being built with dynamic languages.

“I realized that I don’t have time to fix everything I want to fix this time around. I need to fix the big things, get it in front of actors, and let the little things take care of themselves. I can’t afford to wait around for it to be perfect.”

Perfection is not an option.

How many projects do I have in some sort of blocked state right now because I need to find the time to do them right? How many ideas are only half-executed because I haven’t figured out how to finish them the “right” way? I have friends who agreed to read some of my writing in December, whom I haven’t followed up with because I haven’t “finished” revising. And I never will, at least not as long as I hang onto a belief in perfection.

This should sound familiar to anyone who’s worked on a software project using one of the agile methodologies. You don’t try to perfect — finish — the software, and then show it to the users. You take care of the big stuff, and get in front of users. And then the big stuff changes, and you can take care of it again. Rinse and repeat.

Perfection is not an option.

Perfection is, of course, quite alluring. I know that I want to be recognized for my work, want to be seen as someone who has intellectual authority and gets things done. At the same time, I’m afraid that I’ll be seen as less than that: as a failure, a poser, someone who just doesn’t get it. So I hold onto this belief that if I do it perfectly, I can somehow control how people see my work. This is a lie. I can not control how people see my work, and can not control their reactions. If someone reacts negatively, it’s possible they’re reacting to the quality of my work (I am not for one moment arguing I shouldn’t care about doing my best), but it could also be something else entirely. The way I present myself. Their own concerns and fears about their work. Things I can not control. So I remind myself of the truth.

Perfection is not an option.

Just like I’ve tried to stop worrying about having the perfect tools, I want to let go of believing the output has to be perfect before I share it with others. [Reading this blog, you can be forgiven believing that I let go of that belief long ago; I do better here, but there are still drafts from 2006 that I've never published because they weren't "right".] By definition what I put out, no matter how much time I put into it, is not going to be perfect. If I can accept that, embrace it, I can spend my time and energy actually doing the work, instead of worrying about the output.

Perfection is not an option.

[Warning, the following may contain spoilers, although I don't think they would degrade the actual reading experience.]

Invisible begins in 1967, when the protagonist, Adam Walker, meets a visiting college professor, Born, and his girlfriend, Margot, at a party. This chance meeting gives rise to a business deal, the celebration of which is marred by a mugging that turns violent. It isn’t until the second section of the book that we realize the narrator is not Adam, but a college friend, James, now a successful author. James has received the preceding section from Adam much later in their lives, as the first part of a book Adam hopes to write. This book, like Invisible, will have four sections — spring, summer, fall, winter. The sending of pages, the recipients admiration for the original author (James believed Adam would go on to greatness), and the eventual responsibility for publication all echo the story of Fanshawe in The Locked Room, part of The New York Trilogy, one of Auster’s earlier works.

Invisible depicts a progression, both mechanically and for its characters. The characters deal with a push-pull of good (intellect) and evil. The book describes an interesting tension between sex and justice, how they interlock and how we distance ourselves from our actions seeking both. Auster uses different voices to emphasize the distance, telling each part of the story in a different voice. The first section is told in the first person, second in the second person, etc. The fourth and final section is told from the perspective of another person through a diary, with Adam, the protagonist, absent except in reference. As the story progresses, the details fall away in another reflection of this distancing.

Invisible works for me on many levels: as a story, as moralistic exposition, as a demonstration of using the mechanics of writing to further a story. Most importantly, it was enjoyable to read and drew me into a world where the line of what I know and what I think I know is never quite clear.