Search the Blog

Thanks for visiting the blog. Here you will find random musings about user experience design, business, productivity, project development, a few 2x2 grids drafted late at night, and some pop-culture references to things like the Karate Kid and American Idol (which is to stay I often watch bad TV and occasionally read an interesting book).


Blog Archive



This Week's Lesson: It's not about code



This is an installment of A Liberal Arts Grad Learns How to Program, a series of ultra-beginner thoughts and lessons on computer programming and the Ruby language more specifically. This is not for people who know programming, or who studied computer science in school. As the title implies - this is for non-programmers who think they'd like to get into programming. For the record, I studied Modern and Contemporary European Philosophy in College and started programming almost a year ago. Because of this, take everything I write, especially the code, with a large grain of salt

One of the problems I first encountered when starting to program was the panic attack a computer screen full of code induced. This made it very difficult to get anything done, as you can imagine. There is, of course, a reason they call them programming languages; and trying to read (much less write) a screen of Ruby, or Pearl, or C, or even HTML if you don't understand the language is like listening to the radio in a language you don't speak - you know there's meaning to what you're hearing, but that meaning is not for you.

And so, what's your way in? Assuming you are a skill-less liberal arts grad like me, how do you start programming; how do you learn a language?


I suggest this: forget about the code, at least initially. Don't worry about writing code, that skill comes later. Instead, remember that programming is problem solving; before code comes the problem, and while code is eventually how you will get the computer to solve your problem, train your brain to first understand the problem in English (or whatever your primary language is). The code you will eventually write is simply the instructions you give to the computer that allow it to solve your problems. But, if you haven't solved them as a human first, good luck getting the computer to do it.

A SIMPLE, BUT INSTRUCTIVE EXAMPLE: Let's say you want to write a program that allows a user to enter their age into a form on the computer and have the computer tell them whether or not they are old enough to vote. Forgetting for a moment how to write the form, the basic program would look like this:


age = params[:age]


if age >= 18
puts "You are #{age}, and old enough to vote."
elsif age < 18
puts "You are #{age}, and not old enough to vote."


OK, maybe that makes sense to you, maybe you are starting to get dizzy; but either way: forget about the code. Let's first understand the problems we want our program to solve.

First, we want people to be able to enter their age into the computer.

Second, we need to somehow have the computer remember or capture that age.

Third, we need to take the captured age and compare it to the legal voting age - 18. If it's less than 18, then we want the computer to do one thing (Tell them they are too young to vote); if it's 18 or greater, we want the computer to do something else (Tell them they are old enough to vote and that they should vote for Obama).

Each of these could then be further broken down as needed. (i.e. for people to be able to enter their age into the computer, we need to display a box for them to enter their text, and a button that will submit that information, etc.)

Once we understand, in English, the components of what we are trying to do, we can use those pieces to help us find/write the appropriate code which the computer will understand. Put another way, it's much easier to figure out how to say "I would like more wine" in French if you first understand how and why you would say it in English. The same with programming; it's much easier to write code if you first try and understand the problem you are trying to solve in your primary language.


Painting a House, The Karate Kid and Running a Business

As I reflect on painting my house, I am reminded of a quote by Mr. Miyagi in the movie The Karate Kid... "Wax on, wax off". The most mundane activities like polishing a car, or painting a house, are actually great opportunities to think about basic business principles; being truly effective, feeling satisfied with the work, and removing barriers. Here are some reflections:

1. Hire Someone and Delegate

Okay sure...sometimes this isn't an option, so grab a brush and get to work.

2. 80/20 Principle Applied to Scraping

If you scrape every clapboard bare you will get a perfect finish sure, but will anyone really see the difference? Probably not. And the amount of energy needed to scrape 100% just isn't worth it. So scrape the bad stuff and be okay with the rest. Imperfection in other cultures is called "character", like the Japanese aesthetic of Wabi-sabi.

3. Only Do One Side

Do the entire front of the house first -- wash, scrape, prime, paint -- so you can see results quickly and it will inspire you to keep going. Then move to another side. The task will be more manageable and rewarding. What can you do in an afternoon and still see results?

4. Buy Paint in 1 Gallon Containers

Sure it seems financially smarter to buy paint in 5 gallon drums, you might save $10. But have you ever tried to stir, let alone lift 5 gallons of paint? Its a huge barrier. Instead, buy 1 gallon buckets and go back to the paint store as needed. Remove barriers so you can get to work.

5. Get the Right Ladder

You have to believe in the foundation that supports you. And you have to be able to move the ladder. Don't buy tools that are bigger than you. Trust and maneuverability are everything.

6. Leaning Too Far

You know the feeling when you are near the top of the ladder and stretch to something just beyond your reach? You feel uneasy. You know you probably should just go one step higher or readjust the ladder? Yeah, that feeling applies to business too.

7. Finishing is the Hardest Part

There is one small corner on my house that is still the old red paint color. I spend a significant amount of energy worrying about when I will finish it. But at this point I am so bored with the project I have moved on to the next exciting thing, like tearing down walls in the house. So this brings me to the last insight: Bribery. Yes, you can bribe yourself when all other strategies have been exhausted. Start planning the next project and let that energy help you finish the first project.

Apply these principles and you will be surprised by your accomplishments. In the meantime..."Wax on!"


My Toolkit

I am always curious about the applications people use or, more importantly, their secrets. So here is my list shared with you:

Adobe Fireworks CS3

Hands-down the best, and fastest, application for web design layout. The "Pages" feature allows you to create a master file and share layers (like headers, footers, ad units) across similar pages. And it lets you create libraries of shared assets like buttons, font styles, and other design details. I know there are die-hard Photoshop users out there, and don't get me wrong, Photoshop is great for some things. But for web layout you can vastly increase your productivity with Fireworks.

Adobe Acrobat Shared PDFs

When we present designs for review we create a shared PDF so the team can add notes, copy changes, and comments. You can see which person on the team made the note, and you can mark notes as complete. This gets people on the same page and reduces communication gaps.

Google Docs

For big projects with many pages and stages of development, Google Docs can greatly improve team communication, especially with virtual teams. We create a shared spreadsheet listing the pages and status (IA, Design, Development, Approved, etc...) for tracking the project. And because it lets you edit real time, a virtual team can see and discuss page status during a meeting. Last year we managed an inventory of 80 pages in design during a two month period, with extremely tight deadlines, and never missed a date or a page. That's what I consider great technology.


Where would we be without Basecamp? I have a lot to say about this application. Basecamp is a great online tool for managing projects and group communication. The message board style discussion area creates a conversation trail that makes email look like the antiquated beast that it is. (If you've ever had a client email a project request as a forward of a forward, and their note to you said 'See below...' you know why email doesn't work as a management tool.)

We also rely heavily on the file sharing/upload feature in Basecamp, which allows clients to post files so everyone on the team has access. No more loosing files to email inboxes, or bounced emails because the attachment was too big. When working with many clients or many people on one project, Basecamp centralizes discussion, assets and deadlines. Most importantly, it's so simple any client can use it (and believe me we have tested this theory).

Quickbooks/Quicken (on the Mac through Parallels)

If you are running a business, or for personal use, Quicken and Quickbooks will save you more time and peace of mind than you can ever imagine. That said, they are not the easiest programs to learn out of the box, but totally worth the effort. Quicken has a much better interface than Quickbooks, but Quicken is really for home use, whereas Quickbooks is for Business. If you get really ninja, you can setup all your bills to automatically get processed each month at two intervals. I do the 1st and the 15th, and just round up to the whole dollar so I am paying enough. And I have reminders set 5 days ahead so I can be certain money is my account to cover it. My computer now does the worrying for me.


A great application Matthew found for editing CSS. Its great for the non-ninja (me), or ninja-in-training CSS folks out there. CSSEdit lets you preview any html page and see what exactly the CSS controls. It also lets you edit the CSS in a test mode environment so you can tame the CSS.


Also one of Matthew's finds. OmniFocus is to-do list manager based on the GTD methodology. People seem to either love or hate this application. It definitely takes some fine-tuning to get OmniFocus working the way you want, but it does a good job organizing your list into next actions and reminding you to review your projects. There might be better tools on the market, but so far this one is my favorite for GTD.

If I think of more I will add to the list. Anyone else have a great application they want to share?


The Personality of a Web App

A great post from Creating Passionate Users blog.

(My favorite: The Paper Hat Guy)


Freedom (the software)

While I am not one of those who decry our multi-tasking lifestyle - or wait, yes, actually, I am one of those guys: screw our multi-tasking lifestyle - but I guess I decry it from the inside, I decry it while saying that I'm decrying it on Facebook and on Twitter. You know the drill. But I come from a time, of course, when long three hour blocks of focused attention were the norm. I read some pretty darn confusing books in college, for instance, and needed a good long quiet time to understand them even the littlest bit.

Fast-forward to now and I am designer/liberal arts fru-fru learning my first programming language. (More on this later.) As it turns out, reading books about Ruby is also darn confusing, and to understand them, I need a good long quiet time to focus on reading and thinking.

AND SO: just as an alcoholic will pour his booze down the drain in a moment of dramatic clarity and willpower, I have started using Freedom on my computer.

Freedom is a very simple and very dramatic piece of software - it disables the Network capabilities on your Mac for the amount of time you specify and it does not let you back on no matter what you freaking junkie. You launch it, and it asks:


And that's it. For however long you specify, you are in that room with nothing else to do except read the damn book. Which I am just about to go do. Right now. Just as soon as I stop blogging and start up Freedom.

WHICH IS TO SAY: Your chains will set you free.


Why Small Budgets Can Lead to Good Decisions, and What to Learn from Project Runway

Having  a small budget means you need to make effective choices (in fact I would say this is true for any budget).  When there is plenty of money available it is easy to build features that aren't necessarily needed (and users may not even want).  This is not a new idea, but I see this pattern repeated often enough that its worth noting.  And as a sanity check for times when I have a great idea and then diverge.

If there are constraints (time, money, resources) effective choices will follow. Sometimes those choices are hourly or daily, but more important is to make small decisions quickly.  Fail often, fail early.  When starting a new project its natural to brainstorm and get excited about all the possibilities (or perhaps trying to solve every problem up front).  But brainstorming is the beginning of the journey.  In fact, sometimes I exhaust myself trying to solve every scenario, or dream up more features than I can develop. The second half of the journey is converging on the idea (or editing down to its purest form). 

On Project Runway, you can clearly see when a designer had a great vision but didn't know how to edit.  The design looks heavy-handed, was over accessorized, missed the goal for the challenge, or was poorly constructed because the vision was too big. The beautiful, perfectly executed design pushes to the edge of the creative challenge and then pulls back (or edits) until the point of refinement.  This is why editing is Yin to the brainstorm Yang (Yin and Yang).   And why great products can happen with small budgets.

As Tim Gunn would advise on Project Runway, trim every loose thread, tighten every seem, get rid of the stuff that does not relate. Start your project with a vision and budget that are manageable, then edit every detail along the way until you have reached the essence of the idea. Your product will be pure and show disciplined restraint.


Pressing the Pause Button on Work and Learning Something from Doing Nothing

So after the launch of PleaseBringIt two weeks ago (here is our story), we decided to do something totally different at the office. We paused.

We have a mountain of work still to do on the project, so it wasn't for lack of to-do items. But we figured...we worked very hard to get to this point, the site isn't broken, people can actually use the product. So it was simply time pause. And we thought, by doing nothing, maybe we will learn something.

Many companies would say this idea is crazy. Understandably. We don't have tons of money in the bank, the product is new to the market, and we have huge tasks ahead like adding more features and promoting. But sometimes the best thing to do is stop, look around...then take a deep breath before submerging again. It felt crazy, but also totally right.

And somehow during this pause time we still accomplished quite a lot. Not the work we thought mattered, but other work, like thinking about which features are really, truly necessary. And perhaps two weeks taken now will save months of time later.

For company morale, for our personal experience, being able to reflect on the journey before moving on to the next stage was cathartic. Which makes me wonder why do so few companies schedule pauses into their workflow? In the past, much of our client work was like a never-ending relay race with little time to have lunch, let alone reflect on the journey and think about better ways to work. By pausing we were able to listen and learn. It was a luxury, definitely. And a great experiment that will become part of our company culture, now that we have identified its value.


Our Story

We’ll start with the announcement.... It is August 18, 2008 and we at Cognomen just launched our first web application called PleaseBringIt. PleaseBringIt is like a really smart, really convenient online sign up sheet. It helps people organize events, specifically it helps coordinate things and people for an event. At PleaseBringIt, you create lists of stuff you need and then people come to that page and sign up for those things. We hope that people like it and use it – it's perfect for folks organizing dinner parties, teachers organizing parent conferences or classroom wish lists, churches organizing volunteers for a community event, etc.

OK SO: that’s the product. Our company developed PleaseBringIt over the course of five months from an idea we had about 1 year ago. Our company is two people; and as of last year, neither of us had ever built an entire web application, ever.

THE EXPOSITION: About 10 months ago, my boss Liza Cunningham, and I traveled to Chicago to attend the first SEED Conference - a joint effort by 37Signals, Coudal Partners, and Segura, Inc. We read about it on Signal vs. Noise (the very popular 37Signals blog) and hoped it would be a great opportunity to expand our thinking as a company. At the time (and still today), we were a small web design company that used a number of 37Signals products – most especially their project collaboration tool called Basecamp. 37Signals represented to us the kind of business and design thinking we both appreciated and emulated. Well encapsulated in their book Getting Real, 37Signals employs a kind of “Emperor has no clothes” approach to conventional design and business wisdom: "Getting Real," they write, "is about skipping all the stuff that represents real (charts, graphs, boxes, arrows, schematics, wireframes, etc.) and actually building the real thing.”

Often, with our clients, we suffered through the conventional wisdom, inflated processes and long meetings. Influenced by Getting Real, but also by David Allen’s Getting Things Done, Timothy Ferriss's Four-Hour Workweek, Merlin Mann's 43Folders and, of course, by our own experiences, we began to question and look at our own business: what we were doing and why we were doing it? We designed websites for other people and were (and still are) pretty good at it; but we questioned how our clients approached their products and the process they used to get ideas into the world. In response, we started forming practices that fit how we thought about design and how to get our own ideas into the world. And that’s when we read about the SEED Conference.

THE LIGHTBULB: I won’t go into depth about the content of the SEED Conference – you should go, you should read Getting Real, you should check out Coudal’s site and Segura’s work – it’s all pretty amazing and inspiring. What I want to get across here is how much the conference fired us up. They really championed the idea of the creative entrepreneur, the person who develops business opportunities out of their own ideas with very little compromise. Starting a business, developing a product or an idea, these things can be done they said; and within the web world, they can be done very well with limited time and money. All the speakers shared their processes for pursuing and then infusing creativity and passion into their own ideas. For Jason Fried, aphorisms like "avoid meetings", "stay small", and "build less" helped 37Signals move from client work to building their own products. Coudal shared stories illustrating how ideas (sometimes bad) always lead to other ideas (sometimes really very good) if you allow yourself to actually act on your ideas. If you have an idea, make time to work on it and then actually work on it. Simple as that – stop wasting time; stop making excuses. Have ideas; work on your ideas; don’t have a meeting about it; do it; go.

THE IDEA: Liza had an idea. From her experiences as the parent of a young child in school, she constantly received messages from the school about things for which they wanted her to sign up: volunteer at the fundraiser; donate school supplies; sign up for a parent conference; give these certain books to the library. Often these notes got lost, resent, tacked to a bulletin board, and possibly acted on. It took extraordinary coordinating power on behalf of the school – getting the notes to parents, following up, coordinating the often overlapping replies – to do something very simple: ask people to sign up for stuff. Sign up sheets are a great piece of technology when everyone shares the same space; not so great when they don’t. The web is a great way for disparate people to coordinate and communicate, but while there are lots of list-making tools on the web, we couldn’t find a tool that worked like a sign-up sheet. We had the entrepreneurial spark: That’s a good idea, we thought. That’s our idea. We should work on that, do it, go.

THE WORK: Like I said earlier, neither of us had ever programmed a web application before this. We designed sites and then sent them to any one of a team of developers with whom we worked. For the PleaseBringIt idea, we thought about contracting out the development work, but eventually realized that for logistical, creative, and financial reasons, we needed to develop it in house. I had always had an interest in development, and so while Liza took over concept and design work, I improbably became lead developer.

We didn’t start work right away, we were too busy with client work. Several months passed before we could carve out time for our idea. In retrospect, there was no other way, of course – as the character Jerry says in Edward Albee’s The Zoo Story, "Sometimes you have to go a long distance out of your way to come back a short distance, correctly." At the time, however, it felt as if our great idea would go the way of most ideas – unrealized, undone, oh well it would have been cool but oh well.

THE LEAP: To her credit, Liza is a believer in stuff. She believes in the philosophy behind the Getting Real aphorisms – stay small, avoid meetings, don’t do functional specs – and because she actually believes in them, she is not afraid to change or even drop things that don’t fit her philosophy. After a few months delaying our new idea, spending time on projects with big companies, lots of meetings, weapons-grade spec sheets, that’s exactly what she did.

In early spring, Liza said "Let's clear our schedules and work on Please Bring It full-time. For the next couple months, we are going to say 'No'." We moved anything that wasn't critical to a "Stop-doing list". (Just as important as your to-do list; also this ties in with Merlin Mann’s Qualified Yes.) The company had just enough money in the bank for 3 months of focused time. We needed to give full attention to our idea if we were going to get anywhere on it.

This is perhaps the most challenging thing any small business-owner can do and it’s what, I think, defines the entrepreneur from the rest of us: turn away from the more steady cash flow towards the path of the great idea. By removing the net, we forced our hand and solidified a goal: Do whatever it takes to get the product out in a couple of months.

WHAT IT TAKES TO GET THE PRODUCT OUT IN A COUPLE OF MONTHS: development is a process of filling in holes, of working backwards. We had our goal – the product – but were unsure of how to get to that goal. Which is to say, we had a bunch of holes in our knowledge and experience that needed filling. Some holes we could see, most holes we could not see. We simply picked the largest hole at the time and started shoveling stuff into it.

Our largest hole was quite clearly the development. While I had spent the winter reading up on PHP and even had a couple of simple sites under my belt, we knew this wouldn’t be enough. While I had grown somewhat confident doing front-end development (HTML, CSS, and the like), the back-end was more opaque. After doing some research, and reflecting on my experience picking through those PHP thickets, we decided to build the application in Ruby on Rails. (Obviously, our decision was influenced by the fact that Ruby on Rails came out of 37Signals and is a development framework imbued with the Getting Real philosophy.) Once we had identified the name of our first hole – Ruby on Rails – we had to find someone to fill it.

We went to a friend of ours with whom we had worked in the past, a real database whiz. He had recently started working with Rails and was willing to spend some time working with us. With him on board, it seemed like we had all the bases confidently covered (design, back-end, front-end) and our goal of getting the product out in a few months felt realistic and close.

After a few weeks, however, our friend had to bow out – he was already over-committed and he simply couldn’t give us the amount of time he originally thought. He had created a basic skeleton for the application, but it needed to be fleshed out, exercised, put together. We faced a decision: do we look for another developer? Do we back-burner the project (where it would most likely stay forever)? Here, we made what I think is another essential entrepreneurial move: put your head down, ignore your doubts, go. We decided to figure it out ourselves.

Liza signed me up to take a five-day intensive Ruby on Rails course at the Big Nerd Ranch just outside of Atlanta. I’ll spare you the details of the course; suffice it to say here that the instructor, Charles Brian Quinn of Highgroove Studios, stuffed a lot of information into our brains. And while a lot of it jumped right back out, enough stuck so that when I returned, Liza and I could keep moving forward.

Holes filled, more opened up. We moved forward by moving backward, filling in the holes on the path to our goal. We honed our vision, getting clear on the really important user-experience questions, on just what our product did: users create lists; they send those lists to people; those people sign up for things. Within each action, we discussed all the small details that either made the product work or made it confusing.

All the while, we worked in a circle: Liza sent me a rough design, I would create a crude working model, she would rethink the design based on how the model worked, and so on. Where my Rails skills stumbled, Liza shored them up with executable design solutions. We kept the development moving quickly, allowing design and development to grow parallel to each other.

About a month after I returned from Big Nerd Ranch, we were given a gift that highlights another important part of the entrepreneurial experience: don’t be afraid to get lucky. Through a friend, we learned that two extremely skilled developers worked just around the corner from us, and that we should call on them when we had questions. We developed a work trade relationship (we would design their project, they would help with ours); when things got too hairy for me (i.e. SSL integration, credit-card processing, CRON jobs), I called on them; each time they pulled me up out of the weeds with a generosity that can only be called angelic.

LAUNCH: Chalk it up to inexperience, but we didn’t really have a launch day. Instead, we seemed to launch slowly over a couple of weeks. We had a working copy roughly tested and ready to go live, but deployment was the not sweet snapping tape at the finish line. Instead, it was as if we reached where the finish line was supposed to be and told we had to build it ourselves. It came with it’s own set of holes (and time delays we couldn't have anticipated). So we filled them just as we had the previous ones: Head down, figure it out, just go.

And then, one day recently, there weren’t any immediate holes to fill. PleaseBringIt had launched and it wasn't broken. There were plenty of divots definitely, but nothing you couldn’t walk on without twisting an ankle. And so, after many months of head down shoveling, we stopped, looked up, and realized we were on the other side of the gate. We had developed our idea; it was in the world, and other people could actually use it.

It was nearly a year ago that Liza and I attended the SEED conference. That sounds so recent when I write it. It has not very felt short – as no intense time period does – but I realize that it is really short. And that’s what I want to say to you: it’s not unrealistic to do what they say at the SEED conference, and it’s not that far off. We started with little knowledge and no experience doing what we ended up doing: if you have an idea, and you like that idea, make time to work on it and then actually work on it. Simple as that – stop wasting time; have ideas; work on ideas; fill in holes; don’t have a meeting about it; do it; go.


The 3 of You

Typically when I hear people talk about their work its from one perspective (i.e, I do this, but love that...) which made me think, when it comes to work there are actually three yous:

1. What you do for work

2. What you are good at/passionate about

3. The romantic idea of you

I suspect its rare for any of us to operate from all three places. For example, here are my three:

1. What I do... I am a designer

2. What I love... business development

3. Romantic idea of myself... either a software developer or a Tomato Farmer (depending on the day).

Upon reflection I realized the dangers of You #1 and #3! Even if you are reasonably good at what you do, I suspect You #1 leads to boredom. And I presume You #3 leads to the poor-house because romance alone is never a practical guide... ergo, I will never be a good tomato farmer. Although You #3 probably makes for some great adventures!

You #2 is the most logical and attainable because if you love it, you can become good at it and make money at it.

But this raises the question, which you do you follow?


Is Good Enough Bad?

In a recent conversation, two competing theories emerged leaving me with a big question... "Is Good Enough Bad?".

The theories go like this:

Good is the Enemy of Great

Meaning, If we settle for just being "good" at something we will never become great. To be great is to be revolutionary.

Best is the Enemy of Good

Meaning, if we always try to be "The Best" we are missing the opportunity to be "Good". Further, setting a goal of being "The Best" can be daunting and insurmountable.

Is it more important to be "The Best" at the risk of setting an unreachable goal? Or is being "Good" an acceptable goal if means getting something done? The only answer I can come up with is that we should be best at the things that matter to us personally. And then break down each obstacle into the smallest bits so we can navigate without getting overwhelmed...