Pocket Revolutionary

I write status reports. At times, I write great status reports. My status reports inspire envy, and I send a new one out every single week. Unfortunately, my well-thought-out, expository reports only appease my bosses for 2-3 days. At some point during the week, at the most inopportune time available, I’ll hear “what’s the status on… ?” Sometimes it’s right after lunch or a 9am wake-up call after coding until 3am. Either way, it’s not when I have trusty notes at hand and my mind draws a blank. It doesn’t matter how current the information on Basecamp is (Basecamp is 37 Signal’s project management webapp), because that’s for the team. My bosses don’t check Basecamp for status (or need to); they ask their managers (like me) what is going on.

Okay, so I have to give a quick status report, and that should be no big deal. The problem is I unwittingly run a “black box” operation. I’m borrowing this term from Merlin Mann (see the slide), but the idea is that my job is viewed from the outside as thus: requests, deadlines, emails and other stuff people understand go in, I do whatever I’m paid to do, and results come out. Whatever I’m actually doing between the request and the result is in the “black box” where nobody really wants to see exactly what I’m doing or how, they’re just patiently waiting at the other end for the results. This means I can’t just spit out the last thing I was working on (e.g. Refactoring the Authorize.net component to abstract response handling into the main order controller) or give a thirty-minute diatribe on PHP frameworks. I need to say something concise (my boss is busy), meaningful (no jargon), and not over-simplified (he’s not stupid, either).

So, I have created the Elevator Pitch Status Report. The “elevator pitch” is what entrepreneurs like to talk about. It’s what you can say about your current idea in the span of an elevator ride (maybe 30 seconds). For the purpose of my status report, though, that’s about as much information I can instantly recall without Basecamp, OmniFocus, or Moleskine in hand, and it keeps me from ad-libbing into techno-babble.Throwing around technical jargon may work to get me out of a question I don’t want to answer, but it doesn’t make my boss know that everything is under control and all is right with the world. At the same time, I try not talk down to anybody and give the anti-social geek answer: “Fixing stuff”. So, after each major task, I try to update my mental 30-second status report. I just ask myself the four secret questions that are all really behind the status request and memorize the answers.

• What is the current sub-project? (Designing the pages, creating shipping calculations, etc.)
• What is the last task I actually did?
• How did that move us along the timeline?
• Has the timeline changed?

I’m still recovering from my second major brush with burnout, and this last one (quietly) almost took me out completely. Scott Boms has put together a well-researched (and lived) article at A List Apart that I recommend for anyone working in “the industry”. Even if the phases outlined below don’t sound familiar, that just means you can read up on preventing burnout before it’s too late.

The identified phases [of burnout - not in a particular order], several of which I bet sound familiar, are:

• A compulsion to prove oneself
• Working harder
• Neglecting one’s own needs
• Displacement of conflict (the person does not realize the root cause of the distress)
• Revision of values (friends, family, hobbies, etc., are dismissed)
• Denial of emerging problems (cynicism, aggression, and frustration become apparent)
• Withdrawal from social contexts, potential for alcohol or drug abuse
• Behavioral changes become more visible to others
• Inner emptiness
• Depression
• Burnout syndrome (including suicidal thoughts and complete mental and physical collapse)

A List Apart – Burnout

This started out as a review of the new OmniFocus app for the iPhone. I was going to talk about it being the first time I can have powerful task management on my main computer and not abandon it at my desk. I was going to explain that I have always either tied myself to a solution that was too simple, but portable, or an awesome desktop app that was only truly helpful when sitting at my desk. Being too analytical, I started out by thinking out the history of my to-do list, and I realized that explained why I like OmniFocus better than my actual article. So, I present to you my (mostly) chronological evolution of to-do lists.

Day Runner

My first love…

My mom got me my first Day Runner when I was 13 (possibly younger). Really. I begged for it in the office supply store as only a future nerd could. She eventually gave in to my geekiness, and I got my first taste of organization. It seemed infinitely extensible, yet structured in a powerful “business professional” way. You’re thinking there was no way I thought about that when I was 13, but you could not be more wrong. I loved a fully-stocked planner, and I still kind of do. My wife replaced her Palm Pilot with a big planner last year, and she couldn’t be happier (although her iMac is replacing it). My problem? I write down way too much with my whole “ubiquitous capture” obsession, and I can kill many a planner.

Paper

…and then I couldn’t afford the refills.

Inevitably, at some point I wore out multiple planners and went through way too many refills. I realized that I could manage just as well with a good spiral notebook, and then I could stop crying quietly at night thinking about how much I was spending on that specially-formatted-just-because-we-can paper known as “refills”. Yes, I could have just printed my own refills, but that wasn’t nearly as easy/popular/economical in the olden days. I normally just ran out of the to-do list refills and ended up shoving a napkin with a project plan into the pocket.

Palm Pilot

Project management in my pocket.

I have had six different PDAs. I even had a Sharp Zaurus SL-5500, which gives me way too much geek cred. I used little project management apps like “progect” to organize my tasks. The thing I loved was that it was in my pocket all the time (seriously, all the time). I just ran my task list from my pocket, and never cared about syncing issues. This was good because I had Linux in the bad old “can’t-really-support-usb” days that involved modifying and compiling your own drivers (I did), and I tended to like Palm apps that could only talk to the ugliest desktop apps on the planet.

Paper 2.0

I guess I just need paper again.

At some point I realized that the un-sync-ability of my task apps made them about as “powerful” as pen and paper and less extensible. Obviously, my next step was to go back to paper with a vengeance. I mean, at least on paper I could organize things the way I wanted them, and I had started to work out my own GTD-like system with projects on one page, and today’s task list on another. I just had a great big list of tasks, and I narrowed that down to a smaller chunk every morning on a separate piece of paper. It was simple, but it didn’t always scale. Once my “big list” reached two pages, a lot of important projects got lost in the shuffle.

Palm Pilot w/iCal

Okay, I can kind of sync.

I had a brand new Powerbook, and it could sync! This didn’t really solve the scaling issue, but it was a start. I imported everything into iCal, and then I’d flag the top 5-10 tasks to work on each day. It was almost exactly like the paper system, but I could scan it faster and it could easily talk to my Palm Pilot. This worked great until my task list reached 265 (I’m now at 423). At that point, I lost perspective, got depressed, and started going on all-night organizational benders.

Kinkless GTD w/iCal

I can kind of sync, and I’m getting organized about it.

After taking a long weekend to “clear my mind” and “stop screaming at inanimate objects”, I found some great sites like 43folders.com that gave me enough tips to talk me off the ledge. I discovered Kinkless GTD, and then I read “Getting Things Done” by David Allen. I decided that GTD wasn’t “the way” or a cult, but it was a good place to start in actually, you know, getting things done. All of a sudden, life was a little bit easier. I had less stress. I could sync with— no, I could kind of sync with my Palm Pilot. I synced a couple times. One day, my iCal messed up it’s own records, synced with Kinkless, wiped out Kinkless, and then in “data seppuku” wiped itself out. I lost my 265 tasks into oblivion. This happened twice before I buckled down and bought Missing Sync.

iGTD w/iCal

I can kind of sync, and I have a GUI.

Unfortunately, I fiddled too much and got tired of pressing the sync button all the time. I completed something, so I pressed the sync button. I changed something, so I pressed the sync button. I forgot if I had forgotten to sync in a while, so I pressed the sync button. It was a natural result of Kinkless being a script, and you can’t blame Ethan for that. I wanted GUI goodness, though, and I tried iGTD. I used iGTD for quite a while, but I just couldn’t commit to it. I wasn’t managing my projects with the same top-down view I had grown to love. It was just built for people who think differently than me. At least I could still sync, though.

OmniFocus

I love my app, but I’m not mobile.

I joined the alpha testing for OmniFocus, and I loved it. It had more of the “big picture” views that I needed, and it even had some basic iCal syncing to tide me over. It wasn’t perfect, but it worked. It worked, at least, until I got my iPhone. I loved my Palm TX, but I just couldn’t resist the charms of the iPhone. I needed my task list, though, because I still have a few moments every day (maybe not today) that I’m not staring at my computer screen. I like to run errands, fix things around the house, and, yes, even help my wife cleaning the house. My big solution? To print an errands and housework list from OmniFocus or write it down in my notebook. Then, I’d check things off and “sync” it later by checking things off in OmniFocus. I always needed to add to my things to my inbox, and I got really good at emailing myself tasks. OmniFocus handled my emails with ease, but I still couldn’t actually edit tasks or plug my new tasks into just the right spot in the middle of a project. I was just sending myself reminders, basically, of things to organize later.

OmniFocus w/iPhone App

Bliss!

Here I am today, and I’m the happiest I’ve ever been with a total solution. This is sweet, sweet, synced bliss. I do my main organization, weekly reviews, new projects, etc. on my laptop in OmniFocus, and then it’s automatically in my pocket. I can even tweak, rearrange, defer, delegate, and create on my iPhone, and I’ll see it later on my laptop when I get back to work. I basically have a license to fidget with my system all the time, for better or worse. Okay, it’s not technically perfect. Sometimes the syncing is slow (like three-minutes-to-update-my-tasks slow) or I can’t sync at all, but that’s pretty much because of MobileMe’s widely-publicized growing pains. Even then, it’s still the best system I’ve had.

Addendum

Moleskine, you complete me.

Lest my pocket Moleskine and Pilot G-2 be offended, let me assure you that I’ve only abandoned paper for my to-do’s. My wife knows exactly how obsessive I am about my notebooks and pens. As an aside, if you haven’t read The Gel Dilemma on RandsInRepose.com, I highly recommend it. The only part where I differ with him is that he sees the retractable operation as a bad thing (which I know I used to), but I actually think it’s more convenient to getting my pen “ready to write” and never losing another cap.

Update: Thanks to an update in the OmniFocus iPhone app and a more stable iDisk connection, my syncs are nice and fast now. Thanks, Brian!

For those who care to listen, I try to give advice from things I’ve seen done right. Occasionally, I’ve done something right, but normally I like to look at other people doing things I should do better. This is not about doing things right, though. This is my story of what I did completely backwards and wrong in about a week, and how I had to fix it in one day. Maybe you can learn from my mistakes. Or you can laugh at me. Either way, I hope you can get some amusement or education from my five not-so-easy steps to really screwing up software design:

1. Design a Perfect Solution. We had a simple problem. We were going to have our first “virtual conference” where real registrations would be paid for by real credit card transactions for access to a “virtual” online conference with streaming video, forums, and chat. Our problem was that our current online registration system was designed for “real world” conferences. I had hacked it into our shopping cart a long time ago, and it worked great. It could provide us a list of attendees before the conference, and emailed them their conference information. It didn’t however, talk to our website’s backend. Our TYPO3 website already has all of the user management tools, and would take care of granting “attendees” access to the forums, chats, and video features based on group permissions. Our shopping cart just didn’t know how to add or edit users in the database. Now, some of you are already shaking your heads. What was I doing running a website where the content management system was not talking to the shopping cart? Have I not learned anything about “seamless integration” and “smooth user experience”? Well, now I need you to get off your soap box and shut up. I would have loved to integrate these two complex, perfectly independent, working systems before. It wasn’t a priority because no front-end users could tell the databases weren’t talking. It was a larger-than-life project. Seriously, you just need to drop it. Anyway, I immediately set forth working on the perfect solution. I designed the entire thing on a whiteboard. I mapped it’s user interface, functionality, and even the variables I would use. It was perfect. Using only 80% of my development time, I had designed the monster. This left me with –crap– a couple of days to actually build the whole thing. I mean, design is so important, but maybe that’s just too much time out of the total timeline. That’s what I should have thought. I didn’t think that. I thought the design was too important to reduce it down to just a day, and so I had over-designed like there was no tomorrow. Literally.
2. Build for Scalability. What did I design this little bridge for? For the 500 estimated registrants? For this one conference, and maybe the one after? No way. I decided to design a system that would work for the most amount of people and would never have to be changed. I could’ve realistically handled 10,000 registrations, and all we would have had to do for any future conference is create a new instance with a click of the mouse. Obviously, this kind of scale limited my options a little bit. I couldn’t simply modify our current registration system. If I did (and I worked this out), there was no way for the users to be automatically added to the correct group in TYPO3. The problem with designing for 10,000 people was that it all had to be automatic. We couldn’t keep up with manually approving anything, even if it only took one second per user. I also couldn’t make a system that worked just for this conference as a test. No, the entire thing had to customizable to the nth degree considering every conference we host has different demands, and it had to handle all of them (even the ones I can’t think of). The problem with this? There are probably only going to be 500 users at most this time around. If I have to manually touch each of their records for just one second, that’s only 500 seconds in the next month. That’s right, I spent days designing a system that would save me eight minutes and twenty seconds. And future conferences? Yeah, I’ll probably have to tweak the code a little bit no matter what I plan now. In my “perfect solution”, though, that code was an 800 pound gorilla of an extension instead of the 2-3 PHP files that can be edited without worry.
3. Use the Best Tool for the Job. That’s actually a bit dishonest. I didn’t, technically, try to use the best tool for the job. I tried to use the absolute perfect tool for the insane job I had over-designed. What was my tool? To do basic PHP editing on the shopping cart registration forms? No, that’s not scalable. That’s not elegant. No, my tool was going to be a fantastic TYPO3 extension that would bring the whole world together. Now, I ignored some basic facts like (1) I had never written a simple TYPO3 extension and (2) I had successfully written a hundred modifications to the shopping cart. I would not be deterred, though. Like the thousands of PHP developers who dive into a new learning curve because they know that Ruby on Rails is the best way to build a one-off blog in the afternoon, I cracked open the books. I didn’t ask myself if I was going to need this education again in the near future (probably not) or if I truly had the time to add training to the timeline (definitely not). I just started working on the perfect solution that would take me about two days just to train myself on. Don’t get me wrong, though, because I love learning new solutions. I love learning new languages, frameworks, and techniques. Maybe, though, this was a bit too much training for what could have been a half-day project. Once again, that would have been the perfect thought to have a week ago.
4. Commit to Your Decisions. Now that I had only done one complex design and started training on a solution I had never used before, I had to commit. Even when I started to fall behind, I reminded myself (and my boss) that I had to launch all or nothing. Why? Because I had conveniently left myself with no other options. I had nothing right now, and the only way to fix that was with this too-big solution. I couldn’t launch just part of it, because it was a monolith. I couldn’t go back to the easier solution because, well, it wouldn’t have all the same features and it wouldn’t be infinitely scalable and I had already read all the books and… and… I was committed.
5. Fight Through the Pain. Now that I had committed to an over-designed behemoth solution that could scale to twenty times more users than necessary using a system I didn’t know, I had to buckle down. I couldn’t stop for food or sleep. Even when I came back from SXSW exhausted, I started pulling all-nighters. Then, I got sick. So, I muscled through that. Until I got sicker. I muscled through some more. Until my boss made me rest for one day. One whole day. He made me come to our weekly prayer meeting, admonished me for making myself sick instead of asking for a few more days, had everyone pray for me, and then dismissed me to my house to rest. I was not allowed to work on registration. It was horrible. It was the worst thing that he could do. That is, until I rested for a while. I realized that I had designed the wrong solution. What was too hard to realize earlier in the week when I was hungry and sleep-deprived became self-evident. I was being a newbie project manager all over again. So I rested and sub-consciously thought of a whole new solution. I didn’t work on it that day, though. I just napped, watched movies and let it stay in the back of my head for an entire afternoon and evening.

Okay, so that’s everything I did spectacularly wrong. How did I manage to fix it? I gave up on everything I had done. I copied our registration form and modified it slightly for this event. I added in a few quick hooks that added new users to the TYPO3 database by good ol’ MySQL insert. It took me about three hours. What doesn’t it do? Well, it still doesn’t automatically add them to the correct group for approval. But, it marks them using a magical, proprietary system in the user list to show that we need to approve them. Okay, it prepends “1_” to the username. Shut up. It’s great. Once every few hours, we look at the user list in the TYPO3 backend and add everybody with a “1_” to the event group, then delete the “1_”. It takes a little less than a second per person. And now I sleep properly. The wrong design took me about a week of hard work. My next-best design took me a morning. Hopefully I learned my lesson. Maybe I can tattoo my easy steps for designing bad software on my arm for me too look at every day. If you have any more tips that nobody should be taking, you can put them in the comments or email me. Maybe I can tattoo those on my other arm…

Michael Lopp (a senior engineering manager at Apple) gave a great presentation this past weekend at SXSW with John Gruber about the blood, sweat and fear in great design. He talked about the long, hard process they go through at Apple, and it was probably one of my favorite panels. I was so excited by some of the ideas that I recited everything I could remember (without my notes) to our graphic designer at Generals this morning before coffee. I was so excited about it that I was going to post all of my impressions here… until I saw that Helen Walters had already written a better report on it for Business Week here. So, I highly recommend reading the article, and I’ll go back to trying to write my original thoughts about other people’s words later.

[via TUAW]