The third day of observing fogginess in my daily process. I have already forgotten why I originally started doing this…oh, right, it’s part of the research for creating a better workflow with “creative support”. Previously, I had a “productivity stack” of apps and processes that helped me manage time and tasks, but this did nothing to help me in the ACTUAL MOMENT of creativity, which remains foggy and difficult.

It was a scattered day, which shows up in my ETP for the day:

Here’s what happened on Day 3 of my research week, for which I’m journaling the day.

The Morning

I got off to a late start, finally settling in to work around 10:30AM after frittering away the best hour of the day answering emails and twittering. I then spent 30 minutes replying to neglected comments on my blog and investigating some productivity tools that were mentioned.

There’s a meeting at noon, and I can’t help but be distracted by it.

OBSERVATION: Any meeting makes it difficult for me to focus. I need to learn to put them out of my mind, but the anticipation is hard to suppress even if I am not looking forward to it. A general goal is to have fewer meetings. A great day is a day without any meeting at all, and I haven’t had that this week yet.

I am feeling very fuzzy-headed, and it’s an ACTUAL headache where the fuzz is building up pressure behind my eyeballs. I force myself to do the “review ritual” of checking Trello, Google Calendar, Email, and yesterday’s ETP. I write down 5 or 6 things. It’s quite a pile, and I am somewhat stressed by it. Although, remembering yesterday, it’s likely that many of them aren’t really that much effort.

OBSERVATION: The mere act of making a task list by looking through Trello, etc, makes the day seem more more packed than it really is. I have about 5 hours to work before my evening meeting at 7:15PM. Why am I feeling such pressure? Is it just that each task is (1) a responsibility and (2) an unknown drain on my time that (3) I am reluctant to give up? It is the feeling, perhaps, of losing my freedom to small tasks I would rather not do.

I become aware that my feet are freezing AND my fuzzy headache has increased to a kind of strained tiredness. This feeling is familiar: it’s the feeling of not really wanting to do something unpleasant. There are many small things to followup on, and it feels like death by a million tiny cuts. I am over-dramatizing it in my head. How to shake it? I make some peppermint tea and pull on some wool socks. I set a goal: GATHER PROGRAMMING MATERIALS necessary for doing work on the project.

OBSERVATION: Productivity is difficult outside the temperature zone of 65 degrees to 75 degrees.

OBSERVATION: The ability to deliberately NOT think about anything is a powerful focusing tool. I live in my head alot, and the thought loops are sometimes self-defeating. By deliberately turning off my brain when it is harping on small things, I gain clarity. My eyes literally see what is right in front of them (like a sock I’m putting on) and an inner calm becomes accessible. I really need to do this more often.

Noon Meeting

I got a huge cup of tea and took pictures of it. I processed them, and tried to stay awake. I really want to take a nap, but it’s time for the conference call with Ben. We’re doing SCRUM for this project, so it’s time to gather our goals for the next week. This takes about 30 minutes (it is our first scrum meeting of this leg of the project), and I have my immediate goal set: implement UDP socket connection from our Node webserver, and provide realtime WebSocket connectivity between the webserver and our webapp. Easy enough, except I’ve never done any of this before, and I’m new to both Node, Express, and HTML5 Web Sockets. This means today will be a day of reading, hopefully with some implementation at the end of it. This is where that need for creative support comes in! Let’s see what happens.

Afternoon Grind

WHERE TO BEGIN. I am so totally SCATTER BRAINED at the moment. I force myself to go through the motions, looking for the ExpressJS documentation online. I force myself to read it over the next 45 minutes to try to get a feel for it. It is tortuous, because the Express documentation is written based on the assumption that you already know how it’s different from NodeJS (which I don’t, really, because I haven’t looked at the Node docs yet).

I am feeling foggier and foggier. Maybe I need food? But I had just eaten a sandwich about an hour ago. Perhaps it’s information overload + innate disinterest in the subject?

I take a break to do some additional photo processing for my blog posts, and while I’m doing this I have a plan: instead of just reading the Express documentation, I should just do a quick browse of the API Reference and try to discern its overall patterns of function. This doesn’t quite work, because the Express documentation introduces and uses several terms (e.g. “middleware”) without defining how they fit into a conceptual model of operation. This is the sad state of most software documentation I come across.

QUESTION: What is it about reading technical documentation that is so mind numbing? Is it the question after question after question that builds up? Reading the ExpressJS docs, I am trying to piece together a model of operation, and there is no definition at all. It doesn’t help that I am not that familiar with the inner workings of web server design. I am going to have to make a second pass and make some intelligent guesses.

I’ve only been at this for an hour, and I feel like I’m doing. I give the Express documentation a punt after having figured a few patterns out, but I need to confirm my understanding. I find a decent overview of Express that tells me EXACTLY what I wanted to know in about 5 minutes.

With that out of the way, I decide to look at NodeJS documentation, and it has ZERO system design description. Or perhaps it doesn’t need any, since Node conceptually is very simple. The tricky part is knowing what a web server DOES, which is understand the http protocol and support it. I know a bit about this already, so I can see I just need to go through some of the API libraries to see what capabilities are available.

OBSERVATION: Pushing through documentation to find the model takes a lot of guesswork, and it’s incredibly tiring. Now that I think about it, I get this same headache a lot, and have been for a long time. It happens when I am confused by the material, unable to find anchoring concepts that build straightforwardly from each other. Perhaps it’s being in this state of constant unknowing and uncertainty that is tiring? I am forced to try to process a lot of details that don’t yet have an obvious conceptual anchor. I can’t tell a story about how A relates to B; I just know there is A and B and I don’t know which is more important.

OBSERVATION: Where the software documentation fails, seeing the example code helps fill-in the gaps. Working code has a pattern to it, and this helps build a working mental model of the system.

At this point, I tried something new: I assumed I knew everything I needed to know. I wrote down what I knew in story form:

Express builds on Connect, which builds on Node’s basic server connectivity. Express adds some easy ways to add webserver capabilities to a Node installation by expanding on Connect. Node itself hands http request and responses, and has a number of modules to help process them.

Then I conked out until 5PM. I couldn’t hold my eyes open any longer.

OBSERVATION: Reading mediocre documentation about a technology to “grok” its system essence is one of the hardest challenges for me. It involves inferring concepts, models, and intentions and piecing them together on the fly. It involves a lot of reading and filtering to figure out what does what, and why it even exists, to place the right functions with the right components, while maintaining the distinction between it and other stuff that’s going on.

OBSERVATION: I’ve had this same feeling ever since I was a kid. Hard subjects, which are ones that don’t make sense to me, create this headache, which I’ll call a “confusion headache”. Learning to cope with it might be an important life skill.

Somewhat refreshed, I had the energy to go hunt for the actual node server code that existed in our project. It is a default one provided by the web application framework we’re using. I’m not even sure where it is, but I find it. The code in server.js now makes a little more sense, because I have seen the commands mentioned in it on the Express documentation. I’m not sure how the system knows where to find this file, but after a bit of digging through the Mimosa build tool docs (which are very good) I’m told what I need to know. Everything has clicked together. What’s left, now, is the actually implementation proof of concept.

OBSERVATION: I like to work by acquiring a complete “route of understanding” on my “system map” of the problem. That is, a set of concepts that relate to each other in a systematic way. Then, acquiring “recipes” (pre-built approaches) and “patterns” (common strategies for dealing with common problems) becomes important. And after that, debugging.

I technically should be able to write my own node server modules now, and I know where to put them. Deployment should be straightforward too, but that is a whole ‘nother discussion. It’s nice to finally have a billable hour, as most of the previous headachy work was basic research.

The Evening

At 6:30PM, I snarfed some cold beans and toast and headed downtown to attend an Arts organization board meeting. It went well. I got home at 1015PM, after getting groceries and making a late dinner. I added tasks to TRELLO.

Rest of the day I just vegged and then got ready to sleep. Before going to sleep, though, I decided to write up this blog post from the notes I kept. It’s now 2AM…wow. I thought this would go a lot faster, but apparently it still took an hour.

Takeaways

When I hit the moment of creative challenge, that’s when the headache begins. It’s a confusion headache more than a frustration headache. I knew what I wanted to accomplish, goal-wise:

• write a UDP socket interface in a NodeJS server to read data from a remote server
• write a TCP socket listener in the same server to talk with a web app
• write a WebSocket interface in the web app that talks to the server

The hard part is understanding how to do this within a specific set of software frameworks that I don’t fully understand. In the case of NodeJS-based web servers, I have a notion of the kinds of actions it does, but not any practical experience in configuring, writing, and running such a server. On top of that, we’re using a new build environment that is deploying the web server for us, and it was unknown to me how it was accomplishing that. Oh, and on top of that is my unfamiliarity with ExpressJS, which is built on top of NodeJS.

When I need to learn something, I naturally seem to want to understand a few key things:

• Why does this subject/object/product exist in the first place? Why was it needed? What is the history?
• What is the strategy that this thing uses to overcome the problem?
• What is the model of the underlying problem it solves? What are the names of the parts?
• What are the architectural principles? What is the system approach taken to solve the problem, and what are the subcomponents?
• What is the syntax or a step-by-step breakdown of this in the real world, with simple but real-world constraints?
• What are the critical algorithms, limits, and ranges of operation?
• What does a complete problem-solving cycle look like? Show me when each part of the system engages, and how they connect to the next step.
• What is the output? What happens?
• What are the historical or accepted patterns of use today that are popular?
• Where can I see a complete listing of features and their corresponding inner guts?

This is how I write documentation, because it’s the way I think, but it seems to be a rare approach. The best pieces of software documentation I’ve seen online recently are the LeapJS and the Durandal “getting started” sections. They’re laudable because not only are they presented systematically, but there is continual reinforcement of important concepts throughout the writing, answering questions and providing the context that help build system understanding.

But I digress. Since most instruction is written to either (1) memory-jogging for people who already know the system or (2) present simple recipes without underlying principles, I have to answer all those questions by doing a review before I start writing code. At least, that is my DESIRE.

I think the headache I get comes from:

• My own internal conflict and impatience. I don’t particularly want to learn anything about NodeJS. I just need to know enough to get things done. However, I can’t just follow a recipe and hope for the best because I’m WIRED to absorb and understand systems in their entirety. The combination of emotional disinterest and obsessive need for rational system understanding…this might create resistance, no?
• Having to deal with dozens of deferred answers to immediate questions. I read through the entire ExpressJS documentation suite, wondering what the hell “middleware” meant. To me, middleware means something specific when using digital creative tools. I did not understand what that might mean in the context of a web server, and not once was it actually defined. It just got used a lot. I ended up writing down all the ExpressJS functions in a notebook as I read, looking for patterns, and then I found another article that explained it. Neither were many functions truly explained; it was assumed you knew what they were good for. Eventually I combined my own knowledge of what a web server is supposed to do with my knowledge of the http protocol, which I had studied some time ago for another project, and came to believe that ExpressJS was indeed pretty cool. But the journey to get there? I was struggling to make the correct connections and never sure if I was right. This, I think, creates enormous mental fatigue, because my brain is denied closure until…well, until it happens. This is a sucky feeling.

Making connections, synthesizing systems, identifying key principles and codifying them…this is hard work for me, almost physically difficult. It’s the mental equivalent of weight training at the very limit of my strength so muscles will develop. The fuzziness headache, I think, is how it manifests. And it has happened for as long as I remember. I just didn’t make the connection until now that maybe this is part of the creative struggle and can be mediated.

So that is what I’ll be mindful of today, Thursday. It’s now 10:30AM.