Reading the Lines, Not Between Them (PG & Coding Horror)

There’s quite a flap over Paul Graham’s recent essay.

The attacking author quotes a comment on Reddit (always a good sign) as a good summary of the essay of why we should all be terribly offended.

“I work with young startup founders in their twenties. They’re geniuses, and play by their own rules. Oh… you haven’t founded a company? You suck.”

I kinda feel like there is a reading comprehension problem here. Paul added a “Cliff’s Notes” version of the article to clarify, but I’m going to boil down what I got.

The point I got from the essay is:

“I work with young startup founders in their twenties [note: he works with me and a mess of other founders who are also in their thirties... at least 1 or 2 are in their forties]. They seem stressed, but they seem happier and more alive. I think it might be a socio-biological thing– human beings are meant to be working in smaller groups, with clearer goals, and more ‘on the line’. Small businesses and startups seem like the best place to find this environment.”

Period.

Saying stuff like “happier and more alive” (which PG did not– I’m paraphrasing) does not mean that everyone else is miserable and dead inside.

Anyways, this isn’t a wild idea. There are piles of studies out there that have found a correlation between self-employment and satisfaction/happiness. Incidentally, there’s also a strong correlation between self-employment and making less money (but that’s good news, because there are ALSO studies that show that money doesn’t do much for happiness once you manage to have enough coming in to cover the necessities)

#1 Mistake by Coders who Are Doing UI Design

I think that common sense goes a long ways in UI design… But not all the way. It’s a learned skill like any other. I was reading up on calendar controls today (which I’m obsessed with, by the way) and caught a great post by the curmudgeonly Jakob Nielsen. Here’s the snippet I like best (he’s describing the top application design mistakes):

“Affordance” means what you can do to an object. For example, a checkbox affords turning on and off, and a slider affords moving up or down. “Perceived affordances” are actions you understand just by looking at the object, before you start using it (or feeling it, if it’s a physical device rather than an on-screen UI element). All of this is discussed in Don Norman’s book The Design of Everyday Things.

Perceived affordances are especially important in UI design, because all screen pixels afford clicking — even though nothing usually happens if you click. There are so many visible things on a computer screen that users don’t have time for a mine sweeping game, clicking around hoping to find something actionable. (Exception: small children sometimes like to explore screens by clicking around.)

Drag-and-drop designs are often the worst offenders when it’s not apparent that something can be dragged or where something can be dropped. (Or what will happen if you do drag or drop.) In contrast, simple checkboxes and command buttons usually make it painfully obvious what you can click.

Common symptoms of the lack of perceived affordances are:

  • * Users say, “What do I do here?”
  • * Users don’t go near a feature that would help them.
  • * A profusion of screen text tries to overcome these two problems. (Even worse are verbose, multi-stage instructions that disappear after you perform the first of several actions.)

When I tested some of the first Macintosh applications in the mid-1980s, users were often stumped by the empty screen that appeared when they launched, say, MacWrite. What do I do here, indeed. The first step was supposed to be to create a new document, but that command was not shown anywhere in the otherwise highly visible Macintosh UI unless you happened to pull down the File menu. Later application releases opened up with a blank document on the screen, complete with an inviting, blinking insertion point that provided the perceived affordance for “start typing.”

Come See me Speak at the Churchill Club

This Wednesday, I’ll be participating in a really interesting panel discussion entitled “Silicon Valley Fights Back Against the (Information) Monster it Created”. The panel is moderated by Matt Richtel (New York Times Correspondent). Here’s the description:

Intel launched no email Fridays. So did US Cellular. Some managers at Genentech urge employees to check email only twice a day. The Valley and its denizens are trying to combat a problem of their own making: information overload. Everyone knows the issue. The very tools spurring your productivity are also undermining it. This is not merely a question of personal organization. Information overload is spawning industries. New businesses and new products are being created from the likes of Microsoft and Google, and numerous start-ups, too, to help people manage and mute the cacophony and onslaught of information. The question: what can you do to avoid becoming overwhelmed? Even further, can you capitalize or build or enhance your business around helping others to regain productivity? Or have we created a monster here destined to eat us alive (please forgive the hyperbole…we wrote the end quickly because we have incoming email and need to get to it right away).

- Registration: 06:00 PM
- Buffet: 06:00 PM
- Program: 07:00 PM

Location:
Crowne Plaza Cabana Hotel
4290 El Camino Real
Palo Alto, CA

You can register for the event here. I have two guest invites– so holler if you’d like to go.

Exactly Why 37Signals is So Arrogant

Don Norman recently wrote a fine piece entitled “Why is 37Signals So Arrogant?“. As a student of link/click bait, I have to applaud him. Bravo! It’s right up there with Jason Calacanis’ post about firing anyone who isn’t a workaholic (his followup is a bit more measured).

So I’m going to do one better than Don Norman, and tell you exactly why 37Signals is so arrogant.

But, first I’m going to tell you that they’re not. At least not in the way that Norman is saying. 37Signals listens VERY HARD to their users. It’s amazing to note that up until recently (correct me if I’m wrong) Jason Fried read (and sometimes responded to) every single support email. In light of this, to say that 37Signals doesn’t listen to their users is absurd.

Norman and Nielsen have always argued that the best way to understand users is to watch them use your product. I tend to agree- but dealing with support yourself as a product developer is a close second– it’s an amazing way to feel the pain and confusion of your users. Most product developers hire a cheap support staff as soon as they can manage– to get themselves out of the muck. These guys didn’t.

But, come on. Read their blog. Take a look at DHH’s (in)famous “Fuck You” Slide. These guys are clearly arrogant.

Here’s why.

Take a look at the people that most people envy. Hell, start in high school and work your way up. How many times have you said, “why is that girl dating that absolute JERK?” Look at all of the people who are successful in this world and you’ll find a fairly common theme. There is a decided absence of humble and self-deprecating people. There aren’t a lot of people on top who are frequently saying, “I am wrong and you are right”.

So it’s easy to say that as software geeks we are above that. We grew up on the wrong end of “nice guys finish last” and we’re going to be bigger than that. But look at the giants of our world. Steve Jobs. Linus Torvalds. Paul Graham. Joel Spolsky. Bill Gates. Jakob Neilsen. There are certainly degrees of it in this collection of stars, but every single one of them speaks and acts with near-absolute assurance and authority. They embrace controversy and sometimes provoke it. Every single one of ‘em has been called arrogant.

As masters of marketing, the fellas at 37Signals are (either consciously or unconsciously) lumping themselves in with the guys at the top of the food chain. They are the high school equivalent of the insensitive guy in the letterman’s jacket who always gets the girl. They are talking the talk, stirring the pot, saying surprising things, pissing people off, and daring the world to prove them wrong.

You might not like them, but you’re looking at them and listening to them– which is more than you can say for the thousands of other 10-person profitable software companies out there.

I would like to finish by saying that I’m better than you. I’m right. You’re wrong. My [insert language/platform/dev tool] is better than your [insert language/platform/dev tool].

Thanks for listening.

Every Piece of Startup Advice is a Lie (including mine)

Well, not all of it. That title was blatant click-bait. You’re here and I’ve won. Nyah!

I’ve long been passionate about reading and digesting every tidbit of information about what it takes to build a successful startup. I’m an avid reader of people like Seth Godin, Paul Graham, Guy Kawasaki, the fellas at VentureHacks, Fred Wilson, Josh Kopelman, Andrew Chen, and more. As a participant in the YCombinator program, I have weekly dinners with entrepreneurs who have “hit it big” (Marc Andreessen, Ev Williams, Paul Buchheit, Chris Sacca, & Joe Kraus, to name a few).

All of the things I’ve learned are incredibly useful and all of it (paradoxically) can be incredibly wrong.

Let me explain my thinking here. Human beings love formulas. Human beings who succeed naturally think that they’ve stumbled onto a magical step-by-step guide on how other people can succeed, too. They blog about it, speak about it, and generally spread their wisdom far and wide.

The funny thing is that when you read/hear enough of this stuff, you start hearing brilliant and successful people presenting advice that directly conflicts with the advice from other brilliant and successful people.

Here are a few examples:

The list goes on. Find me a startup truism and I’ll find you a successful startup which is a living and breathing counter-example. All of the advice that you read and hear is incredibly valuable– but it’s very situational. Add it to your “startup utility belt” and whip it out when you hit a bump in the road that looks familiar. “Andreessen ran into this and solved the problem thusly. That’s what I’ll try!” But don’t think that you can arm yourself with a list of platitudes and expect to build a startup.

The Two Truisms that Aren’t Lies

Now that I’ve finished saying that there’s no formula, I’m going to give you the two pieces of advice that (near as I can tell) EVERY successful founder has followed. Zero exceptions.

  1. Build something people want. This will make or break you. Period. The success of your idea is a function of how much people want it and how many people want it. Make your product better on this front every single week. Every single DAY, if you can. Everything else is a distraction. If you can’t say, “What I’m doing RIGHT NOW will make [people want what we have more] or [more people want what we have]” you should seriously question how you’re spending your time. (Which begs the question, what the hell am I doing writing this blog post?!). FWIW, I think you should exhaust the former (increase the how much your users love you) before the latter (increase how many users love you)
  2. Don’t stop. Persist. Keep going. The idea of an overnight success is largely ridiculous, even if the press loves to tell you otherwise. (just ask Matt Mullenweg of WordPress). You’ll think you are on the verge of death early and often, but you aren’t– and you can make it through if you start with an idea that people want and keep working on #1. Read Paul’s Essay, “How Not to Die“– it’ll help!

I can’t think of a single startup that has died from an over-emphasis on these two points. Can you?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25  Scroll to top