? Old in Art School

( )

I finished reading “Old in Art School”, by Nell Painter, this afternoon on my commute home. I felt a little sad: grief that I had to come back to the “real world”; which I’ve learned is a sign I truly loved the book. It’s also a little funny, since “Old in Art School” is a memoir.

If I had to sum up the theme of Painter’s writing, I’d say “authenticity”. Stories of pursuing authenticity, personally and artistically, weave throughout the book. And Painter wrestles with questions of authenticity and whether she answers intrinsically or extrinsically. Painter stretches for something she wants, something just beyond (or sometimes well beyond) her current mastery, and when she finds success wrestles with questions on authenticity: “am I An Artist artist?”

That push/pull (or perhaps leap/fall) dynamic is something I’ve felt in my vocation and avocation.

I feel like I gained a better understanding of my own artistic practice by reading about the development of hers.

Dear Poet, To Survival

I had no answer except I love Frank O’Hara which I didn’t voice because I knew it was not the answer. — Dear Poet, To Survival, Melissa Fondakowski

I read this poem weekly, reminding me to get outside myself1.

1 I also love that Melissa uses links in the poem, taking advantage of the medium to open additional paths.

date:2012-09-03 16:00:46

Book Report: “The No Asshole Rule”, by Robert Sutton

My annual review at Creative Commons took place at the end of July, and like last year, the emphasis was on the growing area of focus for me: management. I consider myself an accidental manager, but the anecdotal evidence is that I’m not terrible at it. The conversation during my review, and a prior conversation with a consultant from Teleos, led me to believe that I could improve my performance by learning more about “best practices” or “first principles”. So I’m trying to read some of the “literature”. While it’s not all directly applicable (or interesting), I think of it sort of like x86 assembler: I don’t want to write software in assembler, but I’m convinced that having some understanding of it helps me do better a better job at the work I do want to do.

The first book I chose to read was “The No Asshole Rule”, by Robert Sutton, a professor at Stanford University. Mike recommended Sutton generally, and this seemed like a good starting point. The entire book is an easy, enjoyable read, but there were a few pages I dog eared because they seemed particularly relevant or useful.

Sutton begins by defining an “asshole” as someone who meets two criteria: interactions with the subject leave you feeling oppressed, humiliated, de-energized, or belittled, and the subject specifically targets those less powerful than themselves. I think Sutton’s definition is useful because it distinguishes between people who are sharp-edged or anti-social, and those who leave others feeling like they’re less-than. I can’t think of a single job I’ve had that’s been completely asshole free by this definition, although the degree (and whether they’re colleagues, clients, or board members) has varied widely over the years. As my dad says, “you have all kinds of people, in all kinds of places.” All of that is to say that after reading The No Asshole Rule, I have a better idea what sort of people I want to minimize interaction with, and what sort of behavior I want to eliminate in myself.

In his discussion on how to build an asshole-free workplace, Sutton describes the need to teach people how and when to fight: a team needs to be able to “disagree and then commit”. The second guessing, criticism of the decision, complaining, and arguing stops being productive as soon as a decision has been made. I have worked with people who, as soon as things are less than perfect, constantly remind others that they disagreed with a decision. In my experience, those reminders are demoralizing and saps energy from everyone around them (whether or not their co-workers or supervisors deign to respond).

Does this mean that you don’t evaluate whether a decision was correct so you can improve your decision making skills? Absolutely not. My interpretation is that to be successful (and avoid being an asshole), your decision needs to include what the definition of success is (metrics). That allows you to come back to the decision later and say, “You know, this decision was made assuming X, Y, and Z would happen; we see now X didn’t, so let’s remember that in mind next time.”

The No Asshole Rule doesn’t just talk about how to identify and protect against assholes; Sutton also discusses how to prevent your own inner asshole from getting out. One thing I found interesting was the discussion about how seeing your co-workers as competition is a sure fire way to ensure you’re an asshole. I know that I’m guilty of this. The joke, “It’s not enough to succeed, others must fail,” used to sound like a plausible approach to me. Sutton talks about why public shaming of under-performers is not useful, and how simple word choices (“mutual”, “share”, “fair”, vs. “enemy”, “battle”, “lawyer”) can help people cooperate better. When I worked at Canterbury, there were times I thought of meetings with the Technology Subcommittee of the Board as “battles” to be “survived”. While not without reason, this probably influenced the way I presented information and responded to questions. I’m sure it’s happened since then, too.

Sutton also includes suggestions on how to deal with assholes, if you’re not able to escape them. Two suggestions are looking for incremental wins, and not stooping to their level. The latter seems like a variation on my mother’s advice to “kill ‘em with kindness” and “turn the other cheek.” I still have a hard time with both, and my experience growing up was that neither is a guarantee that the asshole will stop asshole-ing.

Overall “The No Asshole Rule” helped me think about what kind of environment I want to be working in, what sort of people I like to work with, and how I can be a better co-worker and manager.

As Sutton points out, most of us are assholes every now and then. Reading this helped me identify things I have done in the past and think about how I might approach the situation differently today.

date:2010-09-06 14:50:46
tags:business, reading

Reading Update: Short Reviews

I’ve been delinquent in posting about what I’ve been reading. Rather than continue with the charade that I’ll eventually write full reviews for each book, I present a set of short reviews that should get me more or less caught up.

Tweak: Growing Up on Methamphetaminesimage0 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 Memoirimage1 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.)image2 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. Starrimage3 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.

date:2010-06-06 18:14:22

Read: “Django 1.1 Testing and Debugging”, by Karen M. Tracey

Packt Publishing sent me a copy of `Django 1.1 Testing and Debugging <http://www.packtpub.com/django-1-1-testing-and-debugging/book?utm_source=yergler.net&utm_medium=bookrev&utm_content=blog&utm_campaign=mdb_003267>`_ for review. I was particularly interested in reading this title, as testing is something I know makes my code better, but don’t feel like I do enough of, and because I work on a couple of Django-based projects in my spare time, with varying degrees of test coverage. While I consider myself comfortable with Python’s stock `unittest <http://docs.python.org/library/unittest.html>`_ and `doctest <http://docs.python.org/library/doctest.html>`_ modules, I was curious to learn about how you can integrate Django with other Python testing tools.

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 <http://www.packtpub.com/django-1-1-testing-and-debugging/book?utm_source=yergler.net&utm_medium=bookrev&utm_content=blog&utm_campaign=mdb_003267>`_ 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.

date:2010-06-06 17:42:47
tags:2010, nonfiction, read, review

Preread: “Django 1.1 Testing and Debugging”, by Karen M. Tracey

Another Packt Publishing title is on the way for review, `Django 1.1 Testing and Debugging <http://www.packtpub.com/django-1-1-testing-and-debugging/book?utm_source=yergler.net&utm_medium=bookrev&utm_content=blog&utm_campaign=mdb_003267>`_, by Karen M. Tracey. Django 1.2 ships tomorrow, and I’m looking forward to the book: testing is one of the things that helps software evolve, but it’s also one of the things that’s easiest to ignore on a project. I say this to myself as much as anyone: even though I know tests will make my life better in the long run, when I start hacking, sometimes they’re the furthest thing from my mind. Books about how to test, and how to do it effectively, are definitely a good thing for me.

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.

date:2010-05-16 21:39:04
tags:django, pre-read, python

Read: “Grok 1.0 Web Development”, by Carlos de la Guardia

A month and a half ago I posted a pre-review of `Grok 1.0 Web Development <http://www.packtpub.com/grok-1-0-web-development/book?utm_source=yergler.net&utm_medium=bookrev&utm_content=blog&utm_campaign=mdb_002632>`_, a new title from Packt Publishing (disclosure: I received a complimentary copy of the book for review). I recently completed a spate of travel that took me across the Atlantic and across North America (with another trip across the Atlantic aborted due to the volcanic ash cloud), and have turned my attention back to the book. My initial impression remains: this is exactly the sort of documentation I wish I’d had when I ported the Creative Commons license chooser from “pure” Zope 3 to Grok. Grok 1.0 Web Development is a great introduction to Grok, Python web development, and the Zope Component Architecture.

|image0|`Grok 1.0 Web Development <http://www.packtpub.com/grok-1-0-web-development/book?utm_source=yergler.net&utm_medium=bookrev&utm_content=blog&utm_campaign=mdb_002632>`_ 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.

date:2010-05-02 15:36:19
tags:2010, nonfiction, read, review

Read: “Invisible”, by Paul Auster

There are a few authors who I’ll follow just about anywhere; Paul Auster is one of them. Over the past couple years as I’ve read his catalog, I’ve enjoyed his description of even the darkest and bleakest situations. Leah described his work as “primarily meta-fiction” when she first introduced me to Auster — and he definitely excels at that — but that’s only part of the appeal. In works like `Invisible <http://en.wikipedia.org/wiki/Invisible_(2009_novel)>`_, Auster uses creates a fictional world that he then uses to explore how we think about identity, shared experience, and stories.

[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.

date:2010-03-28 20:04:26
tags:2009, fiction, read

Pre-read: Grok 1.0 Web Development

|image0|Late last month I received an email from Packt Publishing (en.wp), asking if I’d be interested in reviewing one of their new titles, `Grok 1.0 Web Development <http://www.packtpub.com/grok-1-0-web-development/book?utm_source=yergler.net&utm_medium=bookrev&utm_content=blog&utm_campaign=mdb_002632>`_, by Carlos de la Guardia. I immediately said yes, with the caveat that I’m traveling a lot over the next 30 days, so the review will be a little delayed (hence this pre-review). I said “yes” because Grok is one of the Python web frameworks that’s most interesting to me these days. It’s interesting because one of its underlying goals is to take concepts from [STRIKEOUT:Zope 3]Zope Toolkit, and make them more accessible and less daunting. These concepts — the component model, pluggable utilities, and graph-based traversal — are some of the most powerful tools I’ve worked with during my career. And of course, they can also be daunting, even to people with lots of experience; making them more accessible is a good thing.

I’ve read the first four chapters of Grok 1.0 Web Development, and so far there’s a lot to like. It’s the sort of documentation I wish I’d had when I ported the Creative Commons license chooser to Grok1. I’m looking forward to reading the rest, and will post a proper review when I return from Nairobi. In the mean time, check out Grok, Zope 3 for cavemen.

You can download a preview from Grok 1.0 Web Development, `Chapter 5: Forms </media/2010/03/7481-grok-1-0-Web-development-sample-chapter-5-forms.pdf>`_.

1 The CC license chooser has evolved a lot over the years; shortly after Grok was launched we adopted many of its features as a way to streamline the code. Grok’s simplified support for custom traversal, in particular, was worth the effort.

date:2010-03-16 09:14:50
tags:cc, grok, pre-read, python, reading, zope

Meta: What’s up with all the Reading?

So far this year, I’ve published seven posts with the tag “reading“. Of 24 posts this year (already more than all of 2009!), that’s almost a third of my blogging. Put another way, in the first five years of blogging I wrote four book-related posts; I’ve almost doubled that in the first quarter of 2010.

I’ve always loved reading. In middle school, I’d sit with a novel in my lap, trying to read during class without getting caught. Going into this year, I wanted to try things that I hypothesized would make me a better writer. One of these things is reading, specifically reading and thinking about what makes a book or story work or not for me. Another of the things is blogging1, so it made sense to me that I would start to blog what I read. I also wanted to keep track of what I read a little better. Instead of using this as another excuse to build a tool that I’m not sure I’ll actually use, I’m just using tags on the posts: sfpl for books I check-out from the the San Francisco Public Library, fiction for works of fiction, etc. I’d like to use something more structured for this (probably RDFa), but right now I have enough half finished software projects, so tags it is.

And that’s why my blog seems like a book report lately.

1 I see blogging as a practice: something that I do with regularity, which has immediate and cumulative benefits.

date:2010-03-10 07:04:26
category:reading, yergler.net
tags:meta, reading