Owning concepts

The 22 Immutable Laws of Marketing by Al Ries and Jack Trout contain a few laws that I’d like to highlight:

• The Law of Exclusivity: Two companies cannot own the same word in the concept’s mind.
• The Law of Leadership: It’s better to be first than it is to be better.
• The Law of the Mind: It’s better to be first in the mind than to be first in the marketplace.

Now consider the following categories and who pops into your mind:

• a giving person
• a great programmer
• a do-it-yourself mechanic
• a politically liberal or conservative person
• a talented artist
• someone who sells things online
• someone who is in fantastic shape

My experiences

Generally I can think of only a person or two for any given category. I don’t know why this is the case. But not knowing the reason does not stop it from being a useful thing to know about.

I notice that I associate people with a concept and believe them to be knowledgeable in a certain area when they are the first person I heard about the concept from. Until I have evidence to the contrary or find a more knowledgeable person, this is the working assumption. Whether they are really the most qualified people on these subjects, I would go to them first with questions. Their face pops up when I think about the category. I try to be more open-minded than believing that my mental model of them is accurate, but I am fallible.

When a consultant came into work and wound up a Pomodoro clock, several people glanced at me and I guessed that they were thinking about the Pomodoro Technique article that I wrote. I did it at work for a month or two, and it elicited some strong responses. It must be that when people think of the Pomodoro Technique, they think of me. While it was not my idea, it was one of the earlier published descriptions of using the technique. I don’t think this is egotistical or out of left field–it is just the way the mind works. We associate concepts with specific people.

In my own mind, for example, one or more people “own” the following words:

• Windows Azure
• dependency injection
• exploratory testing
• Stoicism
• jQuery

So what should you do about it?

Ask people what they know you for. Does their response mesh with what you think they know you for and what you want them to know you for? This understanding is critical in developing your personal narrative. You are the stories you can convincingly tell. Who would not want to be first in the mind for something they care about? Who wants to be first in the mind for something that they don’t like or identify with?

Do you associate yourself with positive or negative concepts? Being early is risky, because the concept’s associations might change or be run into the ground. But you could be first in the mind if you are early.

Do you read about new concepts and breathe life into existing ones? By writing about things that already exist, you reach people that have not heard of them.

Generally it’s hard to disassociate yourself with concepts, even if they are value neutral. Robby Slaughter writes about this and more in the excellent (and quite relevant) The Tyranny of the Niche:

The worst part about switching your major in junior year is not the administrative paperwork or the additional coursework. Rather, bailing on art history and heading to journalism means you will spend the next few years of your life reminding every acquaintance and distant family member that you no longer plan to work in museums. Your assertions will grow more firm and flustered as you repeat them to the same people. Our tidy stereotypes cannot weather the complex nuances of individual choice. Change is hard; getting others to actually remember that you’ve changed is often more work than the initial reinvention.

What words or phrases or terms do you own? The rewards of being first in the mind are disproportionately large. There’s only so many slots one typically lumps a person into. Consider what concepts you mention in passing that people might begin associating you with. What do you need to drop to be first in the thing you care most about? Consciously manage these perceptions. They are real.

This post generally relates to using meta-information, although that is a bit theoretical.

Feedback

Have you seen the principle of owning concepts in life? Am I full of crap?! Post a comment!

Original article: What Does Everyone Know You For?

Life is suffering.
The origin of suffering is attachment, due to ignorance.
The cessation of suffering is attainable.
The eight-fold path leads to liberation.

I was coding happily along, and realized in a flash of insight that this applied to what I was working on.

In coding, suffering comes from:

• not being comfortable making a change because you don’t quite understand how the system works
• working hard but realizing your code is still buggy
• a client being less than impressed by “a change that couldn’t break anything”, but did
• not being able to refactor because you can’t see all of the implications
• wondering if this ever really worked at all
• having that bug pop up again, although we thought it was fixed
• not delivering with quality and on time

The Four Noble Truths of Coding

Coding is suffering.
The origin of suffering is attachment, due to ignorance.
The cessation of suffering is attainable.
The path of executable specifications leads to liberation.

This is a bold statement to make. By using automated means of capturing the assumptions present in code, one breaks the painful cycle that comes from ignorance about the code base. Coding then becomes not suffering, nor not-not suffering, but just coding. Instead of coding in fear, it again becomes a creative process that encourages working with others in harmony. With automated tests of some sort, instead of having the law of cause and effect operating over the course of months, weeks, or days, feedback operates instead in terms of minutes.

However, there is a middle path to take here. If one is entirely safe, one loses the creative edge that makes the project exciting and lessens nimbleness with too much process and boilerplate. If one is too loose, one stands to let some quality slip. Experience seems to be the best guide.

This thought probably emerged from reading philosophy and Working Effectively With Legacy Code.

Original article: The Four Noble Truths of Coding

Earlier this year I started a new near-weekly ritual. I used a tool that I found useful in college for busy weeks. The fold calendar is a way of quickly visualizing a week and using it effectively. Here’s what the daily entries might look like:

Basically, it lists the events of the day in chronological order, with times if I have them. It lists the main project that I want to advance this week and a couple of smaller tasks that I’d like to get done. For context, I list the big things that are happening next week as well.

Why is this useful?

This tool is useful because it:

• helps visualize and use chunks of time
• helps with being spontaneous
• helps with being organized
• helps budget time and energy

Skip down to the last section to learn how to build your own calendar, or keep reading for more context.

Be productive (or not!)

The key to the fold calendar is identifying blocks of time that are prime for doing things, and listing the important things that I want to do.

I then look at the week and see how many blocks I have, what I need to get done, and what I want to get done. I estimate how long things will take and tentatively schedule some of the “must” items. For example, if I know that I have a small milestone due on Thursday, I will need to use one of the blocks before then to complete the milestone.

Sometimes I only have a few blocks during the week after scheduling everything else. When I realize this, I make better use of these blocks. “I won’t have another chance to work on this until next week, so let’s try to focus for the next hour and see what I can do.” It’s really motivating to me to know how many hours I have in the week to really devote to side projects. Typically there are fewer hours than I would have thought. If I’m not aware of how little time I actually have, I tend to squander this time or become despondent because I feel that I should be achieving more with my life. If something is going to get done this week, it probably needs to fit in the buckets I identified by making and using the calendar. I know how much time each bucket has, and so will start something that I think I can finish in the time and energy I have. This technique respects the spirit of GTD and could be useful with a personal kanban as well.

Balance

On the flip side, when I am aware the things that really matter this week, I can leave blocks unscheduled and then am free to relax without worrying about getting things done. It’s definitely important to have recreation, and having a large block of guilt-free, uninterrupted relaxation is great. It’s purposeful recreation—re-creation. Being aware of the time and using it to restore balance and energy.

Also, I think that this is useful in consciously deciding how to spend time. If I see a free concert go to, I need to decide whether it will be worth my time and energy to go. Having the fold calendar might allow me to see that I should do it because the second half of the week is pretty full and I will need to rest. It could instead indicate that the concert cuts up a huge six hour block that I could instead use productively.

It might be one of the most important tools for me to advance side projects. Most of the time, side projects don’t have a deadline. There will always be other things to fill up the time. If you don’t believe this, read the big rocks story. Zen Habits also has an article that is along these lines. So the fold calendar helps prevent the seemingly-urgent from nibbling away at the core time. The “week-as-an-integrated-whole” mindset is what separates the fold calendar from normal calendars. Daily planning is useful, but it’s easy to find excuses. If I don’t get something done today, there’s always “someday soon”. But if I commit to doing something this week and it still does not get done, there is probably a more systemic problem that I need to address.

Clearly the calendar is useful for remembering meetings and engagements. The “next week” field gives a little more context and frees the mind from worrying about things that are coming up.

Your turn

Ready to create your own flip-fold calendar? It’s easy and inexpensive to make with things you already have on hand. Here are some things to consider.

• Take a piece of letter-sized paper and fold it into eight sections.
• Label the first seven sections with the day of the week and date of Monday through Sunday
• In the eighth pane, list ‘Key Project’, ‘Smaller Items’, and ‘Next Week’ as sections
• Go through your calendars (work, personal, shared, etc.) and write down scheduled events as they happen throughout the day
• Schedule exercise, grocery shopping, laundry, significant other engagements, and weekly planning time
• Identify energy-sapping periods, try to minimize them, and budget pre- and post-recovery time
• Identify blocks of time that you can devote to projects, cutting smaller things

It doesn’t need to be perfect, it’s just a tool. Hope you find it as useful as I have!

Have you used a system or tool like this? What were your results?

Original article: A Tool for Your Toolbox: Fold Calendar

My biggest accomplishment of the year so far has been creating a new website for Ultimate (Frisbee) in the Indianapolis area. I got a basic concept going one Saturday morning, took feedback and talked to stakeholders, and then made a final version with the help of others in Indy. Notable improvements include:

• pictures from Zach Dobson, an professional photographer in Indianapolis, on the front page
• maps of all the fields that are used for pickup games, with up-to-date information about when they are played
• integration with a league manager that has online signups, payments, and Google Maps support to show where fields are
• live streaming of the 2010 Indiana Ultimate high school championships on June 20th

For comparison, you can check out the old site. I’m really happy that people helped out and offered suggestions and improvements to the site. This project is on autopilot now.

Other projects

A few months ago I created an eight-session class about developer testing that I taught to people at work. I was surprised at how much work it was, but it seemed like the participants got a lot out of it, and I learned a ton putting it together.

I recently made a simple Rails app that tracks personal events. I started this to keep track of soda consumption, but use it for many things now (showering, wake and sleep times, work transit times, standup lengths, etc.) It’s handy to be able to do this from anywhere, so I created a bare-bones Android app that can send events. I’d like to put together some neat graphs and histograms. I plan on implementing some basic parsing to override the dates and times that things were submitted (think: ‘soda 12oz at 12:30′ or ‘exercised yesterday afternoon’). Right now the app would at least be useful for tracking how many days in a row I’ve flossed or exercised.

Lately I’ve been reading feverishly. Recent books have mostly been from the Personal MBA program. I have read 22 read out of 100 and expect to get to 30 within a few months. I’ve found this undertaking to be helpful in understanding how businesses work. I supplement this reading with blogs to ensure I’m not only consuming out of date material. Reading marketing and sales books is useful because I do not believe that merely creating a superior product is enough to be successful.

Finally, I am organizing a Code Jam at my place of work on Saturday morning. Basically it’s a time for people at work to come together and hack on whatever cool ideas they have or learn about interesting things. If anything cool happens, I’ll post some pictures.

Original article: So what have I been doing the past few months?

I have a large backlog of post ideas and musings that I write about, but there’s really no priority to the backlog. Any suggestions? Please leave them in the comments section of this post. I will reciprocate this offer if you wish.

Thanks for your time, I appreciate it.

Original article: Help Me Figure Out What I Should Write About

// connect to database
code
code
code

This might be an indicator that you can extract the code under the comment into a separate method to make things clearer and more modular.

For example:

public Connection connectToDatabase(necessary parameters) {
    code
    code
    code
}

This is nice because it is just as readable, and it’s harder for the description of the code block to get out of sync with what the code actually does.

Between when I thought of this and when I actually published it, I read a similar blog post that confirmed this thought pattern. Fowler also talks about this in Refactoring.

Original article: Refactoring Tip

I forgot to mention the GTK+ UVC Viewer, which is what I used to record using the webcam on Ubuntu. It was excellent.

With Kaltura (open source version), you can host it on their CDN, or host it yourself. It seems like that is pretty flexible.

From watching it once, I see that I should probably talk slower. Mostly the video seemed in-sync with the audio. What did you think about the quality and/or the idea?

Original article: Open Source for Retired People

This book analyzes product development processes from a lean perspective. The
author starts by introducing the concept of a “design factory”, which shows the
differences between lean principles applied to manufacturing and lean principles
applied to creating new innovations. The key differences include information
arrival processes and the repeatable versus non-repeatable.

One key takeaway from reading this book is that the goal of creating new things
is not to reduce the variability of creating them. Having waste is actually
often the most effective way to create something new because the “waste”
generates information, which has value. If you are doing something that has a
known problem statement and a known solution, you are essentially turning the
design crank. Seek to increase throughput and increase flow before eliminating
waste.

Much like Goldratt’s book, The Goal, Reinertsen focuses on viewing the company
profitability as the lens to view business decisions through. He advocates
modeling of projects and their intended ROI, preferring simple and useful models
over opaque ones. He discusses many subjects from the perspective of how to
optimize for development expense, unit costs, performance, or speed of
development, which are mostly at odds with each other.

He has an interesting explication of queueing and information theory, and how
these impact product development. One takeaway from the information theory
topic is that information is inversely proportionate to the probability of an
event occurring. This coincides with my views on generating models (similar to
Popper’s views on the subject.) Essentially, tests should be written to have
the maximum value if they fail. I believe Reinertsen would be a proponent of
high level tests. He also contends that if your tests would cause a
competitor’s product to fail, you are likely testing too much.

Overall, I found this book to be a compelling read with insights clearly stated
and a strong overall theme.

Full outline

Original article: Review: Managing The Design Factory

Let us start with the first source of technical risk, the high-risk subsystem. Which subsystems have high technical risk? To assess this we must perform our project-level analysis to determine how each program objective (expense, cost, performance, and speed) will impact profits. Then we assess each subsystem to determine how it might impact each of these factors. The easiest way to do this is to use a team meeting in which members estimate the downside risk for each subsystem in terms of magnitude and probability. This can be done by having each member assess risks independently, having a discussion on why different team members have rated risk differently, and then having team members reassess risks. The output of such a meeting is a surprisingly good understanding of project risk. Contrary to the common view that unknown risks are most important, most teams are surprisingly aware of where they are likely to fail in a program.

This reminds me so much of the Agile practice of planning poker that I’m dubbing it “risk poker”. Both practices make sense to me because they use crowdsourcing to solve the problem. I think software teams are more aware of the risks on the project than they typically give themselves credit for, leading to the paradoxical value of this practice. By doing this practice, teams make explicit the knowledge that they already have but are often hesitant to act on for one reason or another.

While doing some basic research to see if this term had been employed yet, I also stumbled across protection poker, which deals more with security risks.

Perhaps I’m reinventing the wheel and risk poker is a well-known concept with a different name. Has anyone employed something like this on a project?

Original article: A Tool For Your Toolbox: Risk Poker

On a long enough time line, the survival rate for everyone drops to zero.
— Chuck Palahniuk, Fight Club

In the long run, every signal dies. Paper rots, genes mutate, forests burn, files corrupt. Error correcting codes help, but they aren’t enough. Perfect preservation of effort is not the way of the universe. Human languages evolve and break down meaning.

Will my personal journal be lost in an accident following the poisson distribution within my lifetime? Will my grandchildren care enough to translate my life’s work to the technology of the day before it is unreadable? There is a difference between preservation and the ability to understand, as Robert Scoble points out.

Software is a signal. It stops when the cost of maintaining it exceeds the value derived. Strangely, software has a longer signal than usually envisioned.

Some signals stay stronger longer. I know more about Plato than I do about most of the people on my street. Millions of people have come before me that I will never know anything about, billions living right now that I will never hear about. Does this imply a mediocre life? People are still riveted by JFK. Elvis lives. Surely there is a high signal strength for them. Much replication, remarkable, revelatory about the human condition. But most people will not be remembered outside of their family tree.

Spawning children spreads gene and life information with some lossiness.

Linus Torvalds said “Only wimps use tape backup: real men just upload their important stuff on ftp, and let the rest of the world mirror it.” In the long run, though, all signals are lossy.

Before a signal starts, I imagine it looks like this:

From nothing comes something, if only briefly. Most signals looks something like this:

A typical blog has a few posts, topical, uninteresting, no replication. The typical newsletter has a few editions and then fades to nothing. The signal returns to zero quickly.

Some signals, however, look more like this, and they are rather exceptional:

Over the span of the universe, though, all signals that we can comprehend look like this:

The strength and length of any signal is too small to stand out from the nothingness and noise. It’s on that line somewhere, but too short to be meaningful.

My thoughts on what to do about this:

Spread signals. Great ideas will replicate faster, great works will be preserved longer.

Start signals. The best measure of effectiveness is how long that signal lasts. Writing, music, software, companies, groups, buildings. Life is inherently a signal, something finite, an exception to entropy. One’s life might be definable by the signals started, the external manifestation of internal capacities.

Original article: Signal and Meaning