In Weinberg on Writing: The Fieldstone Method, Gerry Weinberg (author of Are Your Lights On? and Secrets of Consulting) discusses his main writing workflow. Weinberg primarily collects ideas and words with energy behind them, which he refers to as “fieldstones”. He then analogizes writing to building a wall with stones. Overall I thought this book was fantastic, with many ways of generating ideas and working with them in an original manner.

Weinberg always seeks to move writing forward, and keeps a list of things to do depending on his energy level and state of mind. If he feels high in spirit, he might develop fieldstones into new sections. If he feels drained, he might reword a section that needs fine-tuning or perhaps take a break.

Weinberg’s technique seems to produce a volume of writing: he has published over forty books and numerous articles and other writings.

When reading through his description of the Fieldstone Method, I was struck by the similarity to my own writing technique. I tend to collect insights, thoughts, quotes, and articles that I find interesting and repurpose them in later work. I call these nuggets instead of fieldstones, but the concept is generally the same. They are raw materials for writing, things that strike me as useful but need explication. Typically when I write for other people I use these as a basis and then expand upon that until it likely makes sense for my audience. Parsimony and unambiguity are criteria to consider, with preference for the former for blogging (long posts don’t get read.)

This method significantly increases work in progress. My current blog draft count is half that of my published posts. Many of these are just plain nuggets, like a hyperlink or a sentence. Some have a few quick arguments or thoughts. A few are probably politically unpublishable. Still others are nearly done or completed. Hence, I need to strike a balance between writing what I feel energetic about and finishing articles that I have worked on. Weinberg recommends not writing about things that you are not interested in. This is different from sharing things that you have already learned and believe that others will be interested in.

I think the real power here comes because subconscious creative juices are not consistent. I only get one morning shower per day where inspiration hits. The key seems to be writing down nuggets whenever they strike, and then consistently fleshing them out afterwards. Keeping a journal or log of thoughts helps.

This method also works well with limited time constraints. If you have an hour a day to write or you commit to one hundred words, it’s nice to be able to write about something that interests you that day. Longer periods of time might be necessary for harder sections or cleaning up tough spots.

I found these quotes helpful:

The stone itself is not the key to effective writing. The key to effective writing is the human emotional response to the stone. As a writer, if I respond to a particular stone with tears of joy or sadness, I know that others will, too.

If I don’t respond, my readers probably won’t either. That’s the secret of the Fieldstone Method: Always be guided by emotional responses, or, as Fieldstone writers say, by the energy-the heat that coal provides when it burns inside of you.

I’ll have more to write about energy in the near future. For now, finishing this post.

The most important book you’ll ever have for your writing is the blank book, or the scrap of paper, or the card, or some modern electronic capture device that you have ready for writing down this reference.

Always be ready to capture. Inspiration strikes at strange times. You will forget insights that you have if you don’t immediately write them down. In the field, I email myself and star it for adding later to a permanent file.

Getting Real: The smarter, faster, easier way to build a successful web application Author: 37signals Published: 2006 Pages: 177

This book describes the philosophy of development at 37signals when they created five successful web applications while taking no venture capital.

The biggest theme that I can see with this book is that you should do a few things exceptionally well as opposed to doing many things, only some of which are done well. I see this theme repeated in many works that I read. You don’t want to be good at several things, you want to be world-class at whatever you choose to do.

I really liked the firm’s approach to taking venture capital. They are big fans of bootstrapping by keeping functionality at a bare minimum to what is required. Having less features means a firm can spend time on the very most important features and ensures that they are agile enough to change plans once a page is actually out there. Every single feature that goes into your software is a liability, and users will not want it taken out. So think carefully about every feature. Be ready to say “no” a hundred times. If you keep hearing about something, you will know that users really need it. This comes back to designing something based on the actual underlying needs of users and doing continuous usability testing and getting continual feedback to ensure that designs work as desired.

Simplifying your app simplifies your code, which means that you can do more with less. Each line of code takes time and maintenance, and code complexity increases exponentially. Build half an app, not a half-assed app.

One of the best pages of the books is talking about designing for a three-state solution. Regular operation, blank, and error. You need to invest time in the blank state to give your user an idea of what they can do with this page. I think that this should also apply to testing and running through things. Do it once with everything blank, and then do it for normal, fully populated data.

I was also a big fan of using real text instead of “lorum ipsum” text. When you fill out forms, use real data. If you are annoyed at having to fill something out, your users will also be annoyed. This helps you to get a better feel of your application and will improve the interface.

Ignore details early on. I would equate this with deferring commitment until the last responsible moment. In most cases, you are making decisions before they need to be made, and there is a cost associated with this decision. 37signals emphasizes not solving problems you don’t have yet. The best example is how they launched a product without a billing system because they knew that they billed in thirty day intervals so they had thirty days to code that functionality! “Create a great app and then worry about what to do when it’s wildly successful.”

There are other controversial-sounding lines. Not everyone will be a customer, because if you try to please everyone, you will end up pleasing no one. Decide details instead of giving preferences or choices. This makes things simpler to code and test, and makes your app more usable for 95% of users. Hire programmers that can write well.

Get something working as soon as possible. Instead of endlessly worrying about decisions, take your best guess them and then if things should be changed, change them.

Focus on giving developers stretches of uninterrupted time so they can have maximal effectiveness. Choose tools that keep your team excited and motivated. I think that this is important.

The book also discusses how to launch successfully, which seems to be tough if you haven’t done it before.

I recently started a new supplementary coding technique that I have not heard about anywhere else. I’m not sure what to call it, although internally I’ve been calling it streaming, an abbreviation for stream of consciousness programming. It works by writing out how you are solving a problem.

Here’s a real-life example that likely took place over the course of a couple of hours:

control_parsing
 Go through documents and figure out what appropriate values would be for the metadata and the control data to get it out
  Given a standard document, the ability to correctly parse out the fields
   Given a patient identifier, find the matching patient
    What API call do I use for this?
     Where is the system id of 387 coming from?  I could swear I've seen that before
      I don't think it's actually used, I think that we just use the patient identifier and the user's institution id
       Pretend we are calling the API call with the known patient identifier and user's institution id to ensure that I have the right mental model

Process

I use vim to type out my thoughts and save them a text file. I could see marking things off by putting ’#’ at the beginning of the line, which for me would gray the line out, but normally I just delete things when I get done. This results in a nice feeling of crossing things off of the list. If I’m in the heat of solving a problem, I often don’t write or delete lines. But when I come to a stopping point or am considering what next to do, I usually write out what I am thinking. This minimizes overhead and preserves flow.

A Tangent

The subject in the first line is the git branch that I am currently working with (I typically use description-datetime-created as the branch format.) If there is a need to switch branches, then I keep this stream around to remind me of the current state of the problem.

A script named cb (create branch) is how I usually create branches now with git:

#!/usr/bin/zsh
zmodload zsh/datetime
git checkout -b $1-`strftime "%Y%m%d-%H%M" $EPOCHSECONDS`

Then cb branch_name results in a new branch called branch_name-YYYYMMDD-HHMM. If there is an easier way to query the time a branch was created, I’d be interested to hear it.

Benefits

Constantly specifying the next thing that I need to do or resolve has the benefit of keeping me conscious about what I am doing. While I saw this with the pomodoro technique (“how does what I’m doing relate to the current pomodoro?”), this makes the process more explicit. I can easily track my problem-solving process and see where I might have gotten into some rabbit holes. Sometimes I just find myself looking at a file and realizing that I have no idea how I got there. Whenever I find myself in that situation, I immediately switch to the stream file and reorient myself to the problem I’m currently trying to solve.

Another benefit of the streaming technique is being able to jump back into problem solving after breaks and interruptions. There are times when I can come back to the computer and see where the cursor is in the file and know the next thing to do, but it normally takes awhile to load the problem into my head. Reading through my thought process seems to decrease this ramp up time. Perhaps just writing down how I am approaching the problem makes things clearer for me the next time.

It seems like the problem solving process can generally be best represented as a stack, so I try to reflect this with indentation. Sometimes it forms a bit of a tree structure, but this is likely a problem-solving smell. If a new line does not fit cleanly under the main heading, then I examine the new direction carefully. As a result, I tend to be more aware of when I am considering something that might increase work in progress. Perhaps this task should be considered later, or maybe I should create a new branch before trying to implement this change. Seeing a very long chain of things might indicate that I have too many questions or am not breaking work up effectively.

Like I said, it’s new, so I haven’t worked out all the kinks. But so far it has been well worth any trouble. Let me know what you think if you try it out for a day!

Awhile back I did a thought exercise. The exercise was a way of seeing what you valued most in life. It goes like this:

Every day for a week, write down the following snippet and answer it ten times:

Something I really want out of life is…

It seemed interesting, and I like it when things are spread out over a period of time so that you can see yourself in different ways. So I did this off and on for a few weeks. I expected that depending on the time of the day and my mood that this would fluctuate quite a bit, but I was surprised to see some recurring themes and a strong direction.

One of the things that struck me was “Something I really want out of life is to have meaningful conversations”. I put this down a few times, but I never really defined “meaningful conversation.” Perhaps I knew what I meant, but perhaps I didn’t and was just being vague. So I thought about it for a bit.

Meaningful conversations are one of the most desirable events that I can think of. If I knew that I would have a great conversation but I had to miss something else to have it, there are few things that I would rather do with that time. Of course, this rarely happens in practice because there is a certain degree of spontaneity, it just so happens that two people are walking along similar paths in life, considering the same problems or running into the same obstacles. It is, of course, possible to be too analytical, and thereby spoil things. As with anything that is desirable, it is advisable to not become too attached to previous experiences and expectations.

Sure, there are standard conversations that people have, but how many conversations do you have that change your life? That change your way of thinking? Is there a limit to how many meaningful conversations a person can have in a lifetime, or is this capacity without limit for someone that has a certain perspective or skill set?

Perhaps this is a high bar, but it is something to strive for. There will inevitably be conversations that are merely transactional in nature. “I’ll have that.” “Two dollars.” “Thanks.” “Thanks.”

And, of course, to get to a level where you can converse deeply with someone, there has to be a degree of rapport.

So with that in mind, what are the qualities of a good conversation? I have come up with a few indicators, mostly dealing with the sum total of the conversation. Seeing the whole for what it is and the synergy is the most important. For now I’ll just address conversations that have two people involved.

The very highest value that can come of a conversation is when two people discuss something and both understand each other’s perspective more clearly than when they began, and even come to a new understanding together. You don’t necessarily have to agree at the end of the conversation. There is a give and take with the conversation, mutual respect and a sense of discovery, acceptance.

There needs to be a sense of space, which is important to feeling comfortable and being able to explore thoughts and ideas without fear of judgment. This can take physical space in terms of environment and natural pauses, as well as emotional space. You don’t feel like your conversation partner is going to talk over you or that you have to rush to say what you would like to say. Space means you are listening. A conversation where one party isn’t listening isn’t a conversation. Periods of silence give time to internalize what is being talked about.

Good conversations are recursive (you can also view this as a stack.) A question or topic is raised, and tangents occur along the way, but at least one of the people is composed enough to steer the conversation back to the previous topic. This allows the conversation to flow but still explore all thoughts on the subject so both people feel validated. While the conclusions of the discussion cannot likely be foreseen by either party, in retrospect the conversation will have an orderly structure.

You are likely to be surprised by good conversations more often than you will anticipate them. However, I think that there are ways to attract them. Probably the best way is to have more and deeper relationships. I probably have some work to do on this front. See each interaction you have as a way of exploring reality, to see what others hold as their mental models and find interest in their beliefs. Time constraints seem to be inimical to exploring thoughts. Another way to attract meaningful conversations is to be serious and yet playful at the same time. It’s hard to open up around the permanent philosopher, and tough to interrogate reality with someone who always kids around. If something is on your mind, someone else has thought about it before.

Perhaps the most aggressive way is to talk to people that you don’t already agree with, to read books that you believe advocate an untenable position. What do you know to be true? Those are the thoughts that must be explored, that must be compared with reality and other interpretations of events. What if these beliefs were not true? What would it mean if you could set aside your beliefs long enough to entertain another beliefs, and thereby gain another useful way of looking at the world? The point isn’t to shoot down, the point is to understand. It’s not a zero-sum game.

Understanding fully another person’s position takes listening and an open mind, both of which are sometimes difficult for me depending on my state of mind and the immediate environment. Again, this doesn’t mean that you have to agree with the other person wholeheartedly, just that you are able to hear what they have to say and explore the ramifications of that world view. To be self-confident and flexible enough (understanding your own defense mechanisms and self-imposed limitations) to explore someone else’s views without negative emotions can be difficult, but it represents a growth opportunity.

When I was growing up, my relatives always seemed to ask me the same questions. “How is school going?”, “Do you have any girlfriends?” and, of course, the time-honored classic: “What do you want to be when you grow up?”

While the second question usually flustered me, it was the third question that seemed to evoke the most interest from my relatives. They would say ominous things like, “If you want to be happy in life and make a lot of money, you had better figure out what you want to do.” I usually said something like be a doctor or lawyer, and they seemed mollified and the conversation changed to adult topics.

I remember entering a balloon launch contest at our library where you let go of a helium balloon with some identifying information attached. The person whose balloon went the furthest and was recovered by a person got a prize. I’m not sure how many penguins or baby seals were killed with this environmental disaster of a contest. But because I’m telling the story, it shouldn’t be a surprise that my balloon averted disaster and floated the furthest.

The first place prize was a new computer. To this day I still have no idea what brand it was. I was really excited because I might get to play games on it. At the time I was pretty much obsessed with video games. However, we couldn’t get the darn thing working and ended up selling it at a garage sale.

Then one day my parents got an Apple ][ computer from my uncle who used it for word processing. I played with some of the programs that came with the computer and then realized that I could actually create games on my own. My head spun with possibilities. Could I make the next Super Mario Brothers? The next Zelda?

I had some magazines in my possession that happened to have some programs that you could input to the computer. I can still remember the overall look of the program on the pages. I painstakingly keyed in the runes. They were words, but I didn’t understand what the program actually did. I think someone had spilled soda on the keyboard, so the task of typing in this three-hundred line gargantuan was made even more difficult. I finished it up, and ran it. The game was kind of lame, just a small text game with about two paths. I thought to myself, “I can do better than this.”

So I got some books from the library and started experimenting. I made some small games and demos in text and using the graphics mode, all of which were pretty small and simple. But it was fun–enough that I knew that this was what I wanted to do for a living. From then on, my answer to the “What do you want to be when you grow up?” was going to be a computer programmer.

In all, it is pretty lucky that I found something that interested me greatly when I was ten years old and I explored it and am still interested in it. Many people in college don’t even know where they will focus their life’s work.