Nothing Undone

When I was in high school—in fact, through most of college—I sucked at homework. All homework. Math, writing, science, anything. It’s not that I wasn’t smart enough to do it; most of the homework I completed I did at great speed just before (or just after) it was due. No, I just sucked at doing it. And for years I had no idea what to do about it.

So I did the obvious thing: try harder. That’s what everyone told me to do, that’s what seemed logical, so that’s what I did. I tried harder. Or I tried to try harder. But I wasn’t really sure how to do that. Mostly, I stared harder at the blinking line in my word processor. And then made sure to feel guiltier after spending all night playing Starcraft.

Strangely, none of this helped.

I always assumed I was broken. Why couldn’t I just try harder? If I tried hard enough, surely I’d get through it.

Is there a pen near you? Great. I want you to try this (seriously). Fix your eyes on it. Now, with only your mind, I want you to lift it. Let’s say, three inches. Got it? No? Okay, try harder.

Now?

What happened when you tried to “try harder”? Anything? Did you do anything differently? Is there some “try” muscle you twitched harder?

Sometimes I try to wiggle my ears. It feels a lot like trying harder. I don’t even know where to begin. I mean, what muscle is that?

Here’s my theory: you can’t try harder, you can only try different. I finally figured out how to do my homework. Mostly, it involved finding David Allen’s GTD. I found techniques to get control of everything I had to do, so I knew what I really had to do, and when I could goof off with my friends.

You can’t try harder, because trying harder isn’t anything. It’s syntax without meaning. It’s easy to say and think you’ve said something. It’s easy to decide to do and think you’ve changed something. Don’t be fooled.

Man, is there anything worse than being a hypocrite? Anything worse than telling people to do one thing and then doing another?

Yeah, there is.

I will tell you all about following your passion, and doing your weekly reviews, and keeping your inbox flowing, and speaking your truth. And then I myself will fail. I will put off my reviews for three weeks, fill up my inbox, and not post to the blog for months. And I will not apologize.

Seems to me when you know what’s best, and you know you’re failing, you’ve got two obvious choices:

1. Dumb down your expectations, or
2. Feel guilty about not meeting them.

Or the middle way: do neither. Be a hypocrite.

Hypocrites get to:

• Change their minds
• Be wrong
• Make mistakes
• Speak the truth

So if it’s all the same, I’ll stick with hypocrisy. And then do my damnedest to take my own advice.

Oh, boy. There have been a lot of changes in my plans since November. Here’s the big one:

I’m not quitting software development.

It was a fun exercise, pointing myself in that direction. But it’s not me. I have software in my blood. Not because I’m obsessed with code but because I have the skills to make all sorts of insanely useful tools in software, and I’m obsessed with making my life easier.

For the past year and a half, I’ve been working at a certain software dev shop, and it’s been awesome. But at the end of the day, I just haven’t had the energy to write my own software, which means I haven’t been making the tools which make my life easier. Which means I haven’t been doing the part I’m obsessed with. So I’ve been just letting that part of myself die.

Which is kinda stupid.

I’m making time for my obsessions.

Once I got that, I tried to make time to build the things that my heart’s been crying out to work on. And, what do you know, it worked. I had to ignore a bunch of other stuff on my plate, but who cares? I got to do what I really care about, and it was awesome.

I’ll be releasing a beta version here soon.

I’m not workflow coaching anymore.

The plan was to stop writing software and start coaching people in their workflow process. So I started doing that. The problem was: as soon as I started showing other people how to do GTD and manage their personal workflow, I had to be right a whole lot more. I couldn’t give myself permission to suck. I had to know what I was talking about.

And here comes this obsession, this priority, this awesome project that I ant to drop everything else to work on. That’s exactly what I should be working on. But I didn’t let myself work on it, because it meant dropping everything else, and I couldn’t let myself slip, because I had to be so good at managing my stuff. I couldn’t let my inboxes pile up, or my action lists. I had to get through everything.

Now, really, I didn’t have to. Because that’s part of the process. Shit gets messy. You find something you love, you run after it with a passion, and you try to deal with the mess you leave when you take breaks. GTD and workflow management are the skills to deal with the mess. But while I was coaching, I wasn’t feeling it, so I stopped.

I’m looking for work.

I’m still absolutely moving to Western Mass and out of the NYC. I love the city, but I don’t love living here full time. I miss dirt and trees and grass and reality. And I think it’s impacting my health.

But moving away means leaving the awesomest job I’ve known, working at Pivotal Labs. That’s hard to give up.

I’ve been assuming I’d start freelancing, but now I’m not so sure I’m up for that. I’m not sure I’m ready to learn to do all the business work.

Instead, I’m looking for a development shop I can work with remotely. If you’re interested in a senior Rails developer who’s obsessed with making people’s lives better, drop me a line, won’t you?

Mike R left a great comment on the post Fail fast, fail hard, fail safe. Because it got so big, here’s my response:

Mike, you’re right: this isn’t the way I’d build a house. It’s also not the way I’d build a space shuttle. Or an airplane. But it’s the only way I’ll write software, for the customer’s sake.

When you build a house, two things are true:

1. Planning a house is cheap. Houses are predictable. Architects understand how materials will behave and interact. They know what they can build, and how to build it.

2. Building a house is expensive. It takes a lot of work and materials to build a house. And if you want to try a second time, you don’t get to reuse bits from the first house; you have to build a new house from (literally) the ground up.

When you build software, the opposite is true:

1. Planning software is expensive. Software is unpredictable. Software developers often don’t know for sure how their materials will behave and interact. Software technology evolves much more quickly than house technology, so at any moment our experience with current technology is limited.

2. Building software is cheap. If you have to, you can fail at each step until you succeed, without losing the rest of your progress. If you want to build Twitter integration, but aren’t sure how, you can try things which don’t work without sacrificing your existing, working codebase.

Seems like the software model’s more flexible, doesn’t it. It is. That’s why architects use it too. Architects iterate for months or years on designs and plans build in 3D. A lot of those designs fail, and have to be taken back and tried again. They just wait until those iterations are done before they build the actual house. They can do that cheaply, because the transition from plan to building is a solved problem.

The hidden cost of surety.

Mike, allow me to quote from your comment here, not to pick on you, but to respond to a sentiment that is shared among many opponents of XP:

1. Instead of “fail fast,” don’t do things that “might be worthless.” Figure out whether they will be or not, before you do anything.

2. Instead of “fail hard,” figure out whether your model is going to fail and don’t build it at all if it won’t. Determine whether or not an algorithm can or cannot recommend a movie. Don’t “do” anything until you know whether it can or can’t.

3. Instead of “fail safe,” determine in advance whether failure is likely to occur and do not commence work if so. “Failure is never an option” to the guys who are forking out the dough. Don’t promise anything to anyone until you know you can deliver, and until you know exactly how long it will take.

Absolutely. I would much rather work with someone who knows:

• What will work and what won’t.
• How much everything will cost.
• How long it will take.

But there’s a cost associated with ascertaining each of those pieces of information. It takes time and research. The customer has to pay for all that.

XP makes this claim:

Determining the above facts before beginning development is more expensive than the cost of failures along the way.

If that claim doesn’t hold for your situation, then Waterfall is your best friend. But if it does hold, then XP’s rapid iteration is for you.

Not because developers are lazy. Because it’s cheaper for the customer.

That’s not Agile. That’s bullcrap.

One more thing:

The premise of “Agile” (and “Extreme”) is that you can’t know the results until you try (and fail) to do them, and it is also that the folks who are shelling-out the cash to you are willing to do so indefinitely, even though they still don’t seem to have a house to live in. Trust me: they will start asking you, “HOW do you know?” And you’d better have an answer much better than “Real Soon Now… Trust Me.”

Here’s what I’m hearing. I’m hearing that you got screwed. Or someone you know. Because what you’re describing is not XP at all. But I’ll bet someone told you it was.

This is what’s often called “cowboy coding”. A developer says, “We know what we’re doing, because we’re experienced and Agile. Keep us on retainer for…I don’t know…a few months maybe? And then we’ll probably give you something. Unless it takes longer.”

Good deal.

In XP, we deliver working software at the end of every iteration. At Pivotal, that means every week. You will not go seven days without seeing and approving a working piece of software. It’s not “Real soon now”. It’s “Right now”.

But what about business?

Look, I’ve never run a business myself. But I have written a lot of software in a lot of different ways. And it strikes me that business can be a lot like software. Most of the time, you don’t know how it’s going to behave unless you try. Which means that the cost of planning everything up front is greater than the cost of trying and failing and iterating. Which is why anyone ever invests in a startup. And why the verb “pivot” has so much currency.

My point is just this: All other things being equal, by all means, favor the sure thing over the big risk. But before you do, ask yourself: how much am I paying, before we even get started, just to be sure?

Oh, Lord.

It’s been a while since my last blog post. I feel this need to explain everything that’s happened since then, which in turn makes it harder to write another post. So I’m not going to do that. I’ll fill things in as I go. A lot has happened, though.

Right now, I want to explore something that’s been bothering me. What I do all day.

I do lots of things in a day. Lots of very different things. I write code, I socialize, I design software, I read, I watch various things, I eat food. I like doing lots of different things. I like the way it breaks up my day. I like to find the state of flow, but I don’t like to stay there for too long, or at the end of the day I feel wasted.

The problem is this: as far as my body’s concerned, I’m doing the same thing all day. I sit in a chair looking at a screen. That’s all I do. This disturbs me to a great extent.

And it’s one reason I’m moving to Massachussets this year. I’ll have a chance to be close to the land again, to garden and walk in the woods and not look at a screen all day. But I’ll also probably be working remotely with people on software a lot. Which means I’ll be tied even more to a screen. Good plan.

A treadmill desk would be a start. That would let me keep moving. It would still be a single context, though, that I’d have trouble shifting out of.

The trouble is that everything I want to do is in the same context. This one box. It’s my toy, my office, my newspaper, and my friends. I’m tempted to buy separate computers for each context and put them in different places. Or I would be if I could afford it.

Have you tried any strategies to separate the contexts in which you use your computer? Drop me a comment; I’d love to hear about it.

I have a gas bill I haven’t paid in months. Due to a mixup, we were charged double for our gas over the summer, and it’s been my job to resolve it. But I haven’t, because I just don’t like to think about it.

I have a thank-you card that’s been waiting for months to be sent, but I don’t have the right address. Now I’m so ashamed to admit it to myself that I can’t bring myself to think about it, so I never take action to get the address. So I never send it.

I have a letter I received two years ago which I still haven’t opened. I think I know what’s inside, and it’s important to me. I’ve been waiting for a big moment. But the moment never came, and now, two years later, I can’t imagine a moment big enough to be worth all the wait. When I think about it, my face gets hot, and I push it out of my mind.

These things hold a great deal of power over me. They are fractures in my integrity. Any time I make myself a promise, any time I aspire to do something great, these things remind me that I’m a failure. That I have a terrible secret. That I’m unwhole.

Today, I am taking a stand. I will resolve each of these fractures. I will finish one each week, and in three weeks, I will be healed. To strengthen that commitment, I will begin to resolve this week’s fracture immediately.

I gave these things power. I gave away my power to them, and only I can take it back.

Maybe you can’t wait to do the same.

I’ve been thinking about art lately because I’ve been doing art, very deliberately. I’m talking the Seth Godin kind of art: works performed with humanity. For me, that’s often a piece of software or a video or a blog post.

Here’s something I’ve noticed. Every time I create a piece of art, I encounter three phases:

1. The giddy: I’m deliriously excited, before I start just as I’m beginning. This is going to be great. Everyone will love it! This is going to be. so. cool.

2. The suck: Then it hits. Sometimes it’s right at the beginning, sometimes it’s not for a while in. Suddenly I realize that I’m creating something imperfect. Maybe I make an irrevocable mistake, or maybe I just internalize the fact that if I try to fix it, I will never be done. It will never be quite the way I imagined it. And I’ve still got a lot of work left on this piece of crap.

   This, ordinarily, is where I lose it. This is where I give up, when I give up, which to date is more than I’d like. This is where I get grumpy and tired and disillusioned and just want to go home. But on the off-chance I don’t…

3. The success: I ship, and it’s…it’s incredible. It’s the most wonderful feeling in the world. And yes, it’s not perfect, and yes, there are problems, but I made a deliberate change in the world. I’ve shipped this blog, I’ve shipped music on YouTube, I’ve shipped a career as a workflow coach. Every time it feels like pure bliss, and only ever once I’ve called it done.

Art begins with seeing what isn’t there. It concludes with delivering a rough facsimile of what was seen. Delivering the vision itself is categorically impossible.

In test-driven software development, we write automated tests for all of our code. On a large project, the full test suite might take a while to run, so we run the tests which are most likely to fail earlier. That gives us important feedback sooner. Fail fast.

In Agile development, we plan to build the riskiest parts of the software first. If we’re writing Netflix, we prove that we can recommend movies well and interface with the mail fulfillment center first. If we fail early, we’ve got more time and more budget to try something else. Maybe we even need a different business model. If we fail after we’ve spent months on the login page and picking a shade of red for the background, we’ve wasted time and money.

• Fail fast. Don’t waste time doing things you know are going to succeed but might end up being worthless. Do the riskiest thing first.

• Fail hard. Give it to me straight, doc. If our business is going to fail, let’s really find out. If we break our current model hard enough, we might find a better one. If Netflix couldn’t get algorithms to recommend movies, they might have built a social network to let your friends recommend them.

• Fail safe. Fail while failure is still an option. Fail before you promise people you won’t. Fail while you can get out alive. And always be looking for a backup plan, just in case.

This isn’t just for technology, and it’s not just for business. This is for writing a novel. This is for shooting a movie. This is is for anytime you take a risk with a due date.

Matt Cornell wrote a great post back in 2006 about how GTD is like Extreme Programming for time management. He named a number of ways in which GTD applies core XP idea: if it’s a good way to work, do it as much as possible.

But there are also a lot of direct correspondences between the XP process and GTD. My experience with XP is from working at Pivotal Labs, so I’m thinking specifically of Pivotal’s process when I make these connections:

• We start a project by looking at the purpose of the project and the principles behind it, and from there extrapolate a vision of success (XP’s Inception process; David Allen’s Natural Planning Model).

• We review the project weekly (XP’s Iteration Planning Meeting, Allen’s Weekly Review).

• We don’t plan our the whole project in advance. In XP, we plan out a week’s worth of work at a time because it works best to plan when the whole team’s present, and the course doesn’t change too much in the middle of a week. As individuals, we can plan just the Next Actions for our Projects because we can easily plan the next Next Action when we’re done. In either case, we’re just taking the few steps we can see from where we are and holding a destination in mind, though the destination will change over time.

• We throw all of the steps we’ve committed to into a single list (since there’s only one Context: development) and do the most important thing first. We order things in priority order in advance, but that’s because the person who determines the priority (the product manager) isn’t the person who’s doing the work (the developer). That’s what Doing should look like in GTD: don’t think about whether you should do it, just do it, and then do the next thing. You’ve already set aside time for thinking; this is your time for doing. Work in a state of mind-like-water.

And another correspondence: once XP becomes your development process, or GTD becomes your life process, it’s hard to imagine going back.

If you know me, you probably know that I care a lot about process. Workflow. I’m talking about what you do to make what you really do as painless as it can be. To make the blood, the sweat, and the tears all pour directly into the work you care about in the first place, and not into digging through piles on your floor for the latest copy of your manuscript or sucking up to the HR guy whose email you lost in your inbox for two weeks.

That’s what “organization”, “time management”, and “productivity” are really all about: getting the crap out of your way so you can do the amazing work you were put on this planet to do.