I’ve been so GRIM in approaching the mountain of tasks, plodding onward without any sense of joy, telling myself that once it was finished, then I’d be in a better position to have fun. After a three week stay by my cousin Jason, however, I have rediscovered the fun of shared projects and activities. I just dropped him off at the airport this morning, and now it’s time to return my full attention to the monstrous queue of work that I’ve made for myself.

The problem I’ve been facing this year (and perhaps for most of my freelance career) has been having enough juice and motivation to maintain progress on my own projects. These are the projects that will grant me “creative independence”. To date, it’s involved figuring out what I like to do that other people also like, figuring out how “business” works, and then creating the supporting business machinery that generates enough income to live on. At times, it’s seemed like the business side of my life has overshadowed the creative side, and I’ve found this demoralizing.

The last time I looked at how I was approaching the work, I theorized that it was a lack of ZING in my day-to-day; that is, I was not consistently able to maintain momentum because of lack-of-interest in parts of the work. Rather than berate myself and call myself a lazy person, I postulated that the “dull parts” of my work could perhaps be turned into experiments. I love experiments that involve comparing experiences, and this interest has helped me approach many a difficult project in the past. I’ve since come up with some new ideas based on riding roller coasters and teaching programming concepts with my cousin. I think they’ll be useful process improvements.

A Review of Zing

As I last wrote, I was going to track the following aspects of zingy-ness:

• ZING levels – qualitatively speaking, how much excitement or engagement am I feeling when starting a task?
• Number of different tasks started / completed – what am I actually doing, and where am I not doing?
• Adherence to the “creative entrepreneur” role – how aligned with my mission is my work? am I even remembering to stay aligned?
• Informal thoughts on quality and timeliness achieve – whether my work meets a standard of personal excellence

I didn’t track the numbers, though, after immediately succumbing to the mountain of tasks. Perhaps this was destined to fail because it felt like I already had too many things to do; adding an experiment on top of a huge mountain of tasks was perhaps unwise. I didn’t realize this until, wanting to see exactly how big this mountain was, itemized 200 tasks that were weighing on my mind every week.

Augmenting Zing with New Insights

This weekend, I’m doing another mental alignment that combines the lessons of the past few weeks into new directives. ZING is still important, but I’m now starting to see the value of having an UNCLUTTERED MIND and SEEKING DATA-COLLECTING EXPERIENCE. Also, remembering that LEARNING TAKES TIME, even for experienced folk.

Uncluttering the Mind

I think a lot, which leads to a lot of writing to get the thoughts out of my head. I like knowing what the overall patterns of the world are, and the activity of thinking + writing is a large part of my day.

There’s a downside of all this thinking, though: it tends to be distracting. It’s hard for me to keep on any one train of thought unless I’m writing it down, which is while writing is so much part of my creative process. If I’m not writing, teaching, or demonstrating, I tend to lose focus and operate less efficiently (or so I believe).

I don’t think I have ADHD, but I may have unwittingly developed something like it. Back in the 10th grade, after having read The Hitchhiker’s Guide to the Galaxy for the first time, I made a vow to myself to expand the scope of my associative thinking beyond what I normally thought as normal, as I saw this as one of Douglas Adams’ strengths. A side effect was an expansion of interest into seeing greater patterns in all aspects of experience, particularly ones that existed in multiple frames of reference. A tangible example from THHGttG is the opening scene when Arthur Dent is trying to keep his house from being destroyed by an uncaring bureaucracy to make way for a new highway; the relationship between the shadowed forces of the bureaucracy and its minions are sharply yet humorously drawn in a way to create visceral outrage on the reader’s part. While the local bureaucracy wins, everyone ultimately loses when the same forces of government dis-service is applied on a galactic scale. It’s absurd yet plausible, because human nature (or sentient nature, in the case of Adams’ book) tends to produce the same patterns of behavior.

While being able to do this is very entertaining, it does have a tendency to get in the way of getting things done effectively. In one case, the same ability to project absurd possibilities can amplify uncertainty, creating situations where the fear of something that might not even happen keeps me from acting. To me, almost anything is possible no matter how improbable, and it’s my ability to richly-imagine it anyway that is doing me a dis-service. I have a counter-acting principle that helps break through this type of paralysis: knowing that most things won’t actually kill me. Embarrass? Yes. But kill? No. I happen to believe that a certain amount of embarrassment is good for me too; if I’m unwilling to risk it, then I am not living as richly or creatively as I could.

Learning Takes Time

One of the projects my cousin and I tackled was some web development using Node.js and CouchDB. These are web server components that allow you to write cool web applications, and Jason was interested in using them to create some interactive math quiz programs that would help in the classroom (he’s a math teacher). The challenge is that neither Jason or I were familiar with these two technologies. I’m more experienced with programming in general, so it fell to me to outline an approach where we could both learn.

There was a lot of basics understanding that we could not find on the popular web tutorials. That’s because most of them are written to demonstrate how to make something produce a result. There are very few tutorials that teach you how to architect a web application from a systems perspective. As an analogy, let’s say that you want to learn how to build an actual house, and you’ve heard that two cool technologies you’ve heard about are “nails” and “two-by-fours”. You take a few tutorials, which teach you about nails and various kinds of hammers. You are shown how you can hammer nails into the two-by-fours, which is exciting. You end your tutorial by creating a complete frame made of two-by-fours that you can cover with “sheet rock” and fill with “insulation”. As an advanced example, you learn how you can inset a “window” so you can look through the wall of your completed house! This is exciting because you can see how the pieces go together in a way that you can recognize as part of a house as you’ve experienced it. At the end of the tutorial series, you know something about hammers, nails, two-by-fours, and vaguely how they interact with other elements of housebuilding.

However, you have not learned how to build a house. You haven’t learned about designing spaces, electricity, plumbing, air conditioning, labor-saving tools, standards of practice, regulations, standards, or any of a hundred things you need to know at some point to build a complete house. You have read about a concept called “sheetrock”, but haven’t quite figured out what it looks like or why you would want sheets of rock until you realize that it’s the stuff that makes up the inner walls of a typical home. Cool! But how do you buy the stuff? Is it poisonous? How do you attach it to your frame? That’s the way most software tutorials work, at least when you’re mucking about with Google looking for examples. This is the kind of material you’re more likely to find in software development books, but even then quite a lot of the accessible material is highly focused on tool use, not the software design and feature planning that dictates how your tools will be used to create a complete building.

And so, Jason and I embarked on a journey to create our version of a house using web-based tutorials. I already had a notion of how to build a web app from previous explorations, so I made something up that would fulfill the functions we anticipated. Even then, it took days to put together a simple framework with which we tested our understanding of how web applications are technically deployed. There are a lot of moving pieces behind the scenes, with different code running on different machines. Invisible concepts like the http protocol had to be researched and understood before Node.js even started to make sense. At the end of two weeks, we had a working prototype that I think Jason will be able to expand upon, but it was NOT SIMPLE OR OBVIOUS. If we hadn’t been working on it together, we probably wouldn’t have gotten very far at all.

The takeaway from this is that learning takes time when doing anything uncertain or new. I had an idea of what Jason would be facing since I’ve been through the “new language” rigamarole more than a few times, and could help identify gaps in our knowledge where before we fell into them.

I think people who don’t use computers intensively every day have the notion that computers are supposed to make sense. They do not have any intrinsic logic that an average person can make sense of. Even the internal binary logic of computers make no sense until you learn what conventions that ordinary humans have assigned to them. By comparison, long-time developers know that they have to sort through a lot of undocumented concepts that use arbitrary naming conventions, and learn to find the conceptual anchors that help them orienteer themselves effectively in uncertain lands with different customs. Soon enough, they learn the terrain and can start being effective, but it’s a skill that developers are long used-to practicing. Still, it takes time.

It was good to remember this.

Roller Coasters and Data Collection

As useful as this principle is, it isn’t always enough to get me out of the procrastinatory doldrums. I have to be feeling good and absolutely fresh. During a trip to the nearby amusement park, though, I think I’ve found a fresher approach from riding roller coasters.

When I was younger, I disliked roller coasters and refused to ride them. Later in life, I applied the “it probably won’t kill me” rule and have come to enjoy the feeling of extreme physical experience that I otherwise don’t seek out. Still, I had never had the courage to ride the REALLY scary-looking rides. During my cousin’s visit, I found that Jason loves scary rides, and will ride anything. With his attitude as an example, I decided that I would go on types of rides that I have long avoided at nearby Canobie Lake Park in Salem, New Hampshire. Here’s what I rode:

• The Zero Gravity – An open disc that spins while swinging upward to a 60-degree angle, subjecting its riders to G-forces that shift direction as you whirl over the park.
• The Turkish Twist – An enclosed room that spins so fast that you stick to the wall as the floor drops.
• The Yankee Cannonball – A wooden roller coaster built in the 1930s, which seemed tame because of its age, but is actually surprisingly terrifying because of the unexpected speed, rough ride, and negative Gs on the two-minute ride.
• The Starblaster – An 80′ tower that accelerates an open chair ring straight up at 3Gs, then drops in free fall. Repeats twice.
• The XTreme Frisbee – A ring like the Zero Gravity that also swings back and forth as it spins 60′ over the ground. Looked tame, but its speed and size produce significant disorienting Gs.
• Untamed – A roller coaster that features a 90-degree straight climb, followed by a negative-inclined drop straight down before barraging through a series of loops and corkscrews over 30 seconds.

I decided to skip the most extreme ride there—the three-degrees of spinning Equinox—as I had come to some conclusions about ride preference:

• I liked speed and turns, and also acceleration.
• I didn’t like rides that just made me dizzy. I disliked the Turkish Twist because it gave me a headache for not much thrill.

It was fascinating also how each ride drained me mentally as well as physically. At the end of the day, I didn’t know if I’d have the fortitude to ride the Untamed, which looked like the scariest ride in the park with its straight-up-and-down drops and multiple tight loops, but it actually wasn’t bad because the ride felt very solidly-built. The wooden coaster, by comparison, felt like it was on the edge of control. The Xtreme Frisbee, which is quite large, is deceptively powerful. Seeing it at a distance, the big swings looks pretty slow and stately. When you’re IN the damn thing, though, the speed and noises it makes as it swings HIGH INTO THE SKY are nearly vomit inducing. It was this ride that made me think that I wouldn’t be able to take the Equinox. At least, not at the end of a day of pushing my comfort zone!

The big takeaways were this:

• I couldn’t predict if I would like a ride or not. Only experience would tell.
• I didn’t die or throw up. Though I did get dizzy and had to buy some Aleve.
• I could control my visceral response to the ride with regular breathing and focus on riding out the experience, even when I felt a bit queasy. This allowed me to experience the ride without losing control.
• Even better: I could control my emotional response by choosing to embrace, rather than endure, the experience. This attitude came in handy for Untamed, which I was viewing with increasing anxiety about getting sick. I stuck it out because I wanted to ride it as the capping experience of the day.

That latter takeaway was a pleasant surprise, and came to me after the Starblaster, which is set up like you’re an astronaut about to launch into space. I was a bit anxious at first. However, I then imagined that I was an astronaut; what would that launch experience be like? I needed to train myself! So I adopted a sort of role-play astronaut role, imaging myself preparing for the final launch countdown and hoping that I didn’t have a stroke. I blessed the 10 weeks of cardio I’d been doing at the gym, and remembering to breath slowly and regularly. Afterwards, it occurred to me that I hadn’t so much enjoyed the Starblaster as I had gritted my teeth through it; the same experience repeated itself when I was on the Xtreme Frisbee, which at times was intense enough that I had to close my eyes and meditate for a few seconds at a time.

When it came to ride Untamed, which Jason and I thought would be the ultimate coaster experience available at this park, I was in the process of mentally calming myself down through measured relaxation breathing. I wasn’t afraid of it being scary after having ridden the other rides, but I was concerned that I wouldn’t be able to hold control of my visceral fear reaction. I had felt it under the layers of control I’d exerted before, squirming to get loose.

As I watched the ride cycle over and over while waiting in line, it reminded me a bit of a launch sequence from Battlestar Galactica, and I remembered some of the early lore from it: how Viper pilots had to have tremendous physical conditioning to handle the extreme maneuvers that their fighter was capable of. If you made a mistake, it would kill you. So I decided to try something different on this ride: instead of merely enduring it until it was over, I would try to throw myself INTO the experience as if I was a Viper pilot in-training, making tight turns and evasive rolls that would be typical of space combat. That meant looking forward at the track, anticipating turns, then mentally executing precisely. I’m really glad I thought of this before getting on the ride, because we were in the front seats and could see everything up close. It was a far better experience, and I impressed myself by how much I screamed and laughed afterwards. A significant breakthrough!

Expanding the Rules

Building upon the insights of my previous ZING post and this one, here’s a revised set of principles I want to use in the coming weeks. They all apply at the same time:

• Completing uncertain tasks takes time. No sense in making myself feel anxious about how much time it takes. Uncertainty means unpredictability. As much as I’d like things to be instantly gratifying, the reality of the creative experience is that the only certainty is that you won’t know how long it will take. Therefore, one must merely continue to apply creative effort in service of discovering the completion when the final solution reveals itself.

• Doing a task WELL takes a lot of time. No sense in trying to rush myself through a process to completion if it means taking shortcuts that lessen the final outcome. In some cases, the reduction in quality that results in a shortcut may be (as my CPA likes to say), “materially insignificant”; that is, you get the result you need and there are no long-term repercussions. How well I can discern and balance both material and immaterial approaches is the metric for my tasks, not how little time it takes.

• Thinking all the time is not necessary. I never thought I’d say that, because I like thinking through complicated scenarios. However, when it comes to getting some of those big tasks down, it’s a lot more effective to turn off the brainstorming+analysis parts of my brain that loves to work with distant possibilities that hint at new patterns of understanding. I’m not sure exactly how this will work, since it’s such an automatic process for me, so we’ll see.

• When uncertainty creates paralysis, creates surety through testing. While thinking through an old problem with a fresh perspective can break through barriers, in many cases the barriers I’m facing are due to just a discomfort with choosing a less-than-optimal option. In the past, less-than-optimal meant “time consuming”, but with this new set of rules I’m making here that’s no longer a recognized factor. The remaining forms of less-than-optimal are “poorly-designed” and “of questionable effectiveness”; I still get caught up in this, not choosing one software library over another because I suspect it might suck, but the only way to know is to try it out and see how it goes. The appropriate action, I have found, is just to accept that it’s going to take time and implement some kind of solution to find out. As with my recent experience with roller coasters, I really am bad at predicting how I’ll respond to any particular ride. A fresh experience yields fresh data, which helps me make better choices. It’s the responsible way to do it, no matter what your manager says.

• Worry about one task at a time. Worrying about them all is a distraction. There’s nothing much I can do about the backlog except get more tasks to the completion point. Instead of fretting about how fast I am (or am not) when it comes to completing tasks, I need to keep my focus on one or two at at time. The true measure of progress can be seen by maintaining daily continuity on what I’m doing. How to measure it is another story…still thinking about how to do that.

• Pick anything to do. It doesn’t matter what it is. I have so many things going on right now that to sequence it all into a schedule would probably take several days, and then it would be out of date. I don’t have to select the optimal task that yields the biggest bang for my time block. I just need to apply a time block to something that fits within one of my mission profiles as a creative entrepreneur, blogger. That moves me forward. Likewise, maintain momentum on my community and client work until I am able to outsource it.

<

p>I think the hardest thing for me will be picking the things to do. There are so many things to do for so many people, and I am feeling the burden of responsibility from that. I am also feeling the urgency of working on my own creative pursuits so much that it gives me a stomachache. Realizing that it’s going to take time and accepting that fact will help alleviate the stress I feel over it, but the only true reliever of that stress will be getting the big tasks done. I have to learn to accept incremental progress.

Concluding Thoughts

So far I’m still being very abstract with these rules, so let me make it into a methodology:

1. Don’t worry about the other tasks.
2. Pick the first one that pops into my mind that fits the mission profile.
3. Turn off brainstorm+analysis portion of the brain, give it a rest.
4. Apply a block of time to the problem.
5. Embrace the challenge, and chip away at the problem.
6. Take the time to learn if you need it.
7. Note progress in appropriate notebook for later reference.
8. See if there’s a next step that may help close the task as “done”
9. But don’t super stress about it.

I’ll pick this up on Monday and see where it goes.

[xpr-2013b]