Writing Is Like Coding

Matt wrote that coding is like writing. I came to the inverse, although similar, conclusion in high school. Writing words resembles writing programs for the brain. In both, to communicate your meaning correctly, you need to know your audience and signal based on your representation of the underlying system. This will allow the interpreter to understand what you are saying.

I originally felt this parallel when I constructed arguments for essays. Words and sentences must be read through sequentially and the work needs to make sense. This resembles writing a program and running through it in your head before executing. When writing a paper, I found framing arguments often corresponded to declaring variables. The introduction of a paper lines up with initialization, setting the evaluator's mind in a specific state for later communication. The conclusion is cleanup. Pronouns are abbreviations or aliases to entities. A sentence that could be ambiguous should be expanded out, much like one would use parentheses to clarify a potentially ambiguous expression.

Read on →

Fieldstone Method of Writing

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.

Read on →

Review: Getting Real

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.

Read on →

Problem Solving Stack

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.

Read on →

Meaningful conversations

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.

Read on →