Don't Make Me Think

I loved Don't Make Me Think. It takes you inside the mind of the user (of your website). And it tells you who they are, what they expect and what confuses them. And the golden rule is, of course, don't make them think.

Some videos

Lately, I've been watching some cool videos on software development. Here they are, along with my notes on them:

UI Fundamentals for Programmers, by Ryan Singer.

Base UI on a Model
Be explicit and use a lot of language.
Break screens out w/ REST
Least Effective Difference
Screen -- design from the inside out
Flows - think about actions. Split
every action into 3:
 1. start: how to i get to it?
 2. middle: post note.
 3. end: where do it go afterwards?
Fonts:
Small sizes, < 10px, Verdana. But not so good for larger sizes.
Lucida Grande lot

Why marketing is too important to be left to the marketing department, by Seth Godin.

Ideas that spread, win.
Build marketing into the software.
Make it connect.
TV thinking -- average products for average people.
If you're gonna interrupt everyone, you'll have a product everyone will 
will wanna to buy.
You're solving a problem that most people don't think that they have.
Clutter is not your friend.
You deal with clutter by making more clutter.

Do something totally different.
And people will talk about it.
At the edges, people wait in line.

Don't force new medium, but
build stuff that fits the new medium.

You are in the story telling business.

Hard to make money in the middle.

The new way:
(1) be remarkable -- encourages people to talk about it
(2) tell a story about it
(3) THEY spread the word
(4) and THEY come for another story

Build a tribe: help people connect
with each other.
Build a tribe: stand up for something
remarkable.

Manuel Blum's Advice to new Grad Students

I liked this collection of advice to grad students. Some quotes:

• Books are not scrolls. [...] Permit yourself to open a book and start reading from anywhere. In the case of mathematics or physics or anything especially hard, try to find something anything that you can understand.
• Consider writing what you read as you read it. This is especially true if you're intent on reading something hard.
• I once asked Umesh Vazirani how he was able, as an undergraduate at MIT, to take 6 courses each and every semester. He said that he knew he didn't have the time to work out his answers the hard way. He had to find a shortcut. You see, Umesh understood that problems often have short clever solutions.

37signals on business & software

Lately I've been enjoying these videos by 37signals: 37signals.speaks. So refreshing to see these guys talk about business and what makes good software.

Numbers everyone should know

Numbers everyone should know from Jeff Dean's talk at Stanford:

L1 cache reference 0.5 ns
Branch mispredict 5 ns
L2 cache reference 7 ns
Mutex lock/unlock 100 ns
Main memory reference 100 ns
Compress 1K bytes with Zippy 10,000 ns
Send 2K bytes over 1 Gbps network 20,000 ns [.02 ms]
Read 1 MB sequentially from memory 250,000 ns
Round trip within same datacenter 500,000 ns
Disk seek 10,000,000 ns
Read 1 MB sequentially from network 10,000,000 ns [10 ms]
Read 1 MB sequentially from disk 30,000,000 ns
Send packet CA to Netherlands to CA 150,000,000 ns

From Cuong Do's Youtube Scalability talk:

Page rendering time: keep less than 100 ms

There are also some interesting number on Wikipedia's Google platform page.

from Getting Real, the book

From Getting Real the amazing book by 37signals:

The best designers and the best programmers aren’t the ones with the best skills, or the nimblest fingers, or the ones who can rock and roll with Photoshop or their environment of choice, they are the ones that can determine what just doesn’t matter. That’s where the real gains are made.

Great Paul Graham quote...

Just brilliant:

So we just finished a new round of optimizations as part of our ongoing quest to prove that with sufficient caching you can serve arbitrarily large numbers of requests with arbitrarily slow languages.
-- Paul Graham, on releasing a new version of Hacker News

Quick: my Macbook Pro and Pulley

I got my Macbook Pro on Sunday, December 16 2007. Loving it so far! Still waiting for the David Pogue's Mac OS X Leopard: The Missing Manual, which should arrive tomorrow.

So, I've been kinda annoyed with Google Reader and have been wanting to create my own Reader -- I'm calling it pulley. More details as I start to work on it. I've been doing way too much talking and reading pointless tech news websites, and random stuff and not enough coding, hacking. All that ends today!

The Feyerabend Project & Gerry Sussman

From The Feyerabend Project -- which I think was started by Richard P. Gabriel -- a quote by Gerry Sussman:

Computer Science is in deep trouble. Structured design is a failure. Systems, as currently engineered, are brittle and fragile. They cannot be easily adapted to new situations. Small changes in requirements entail large changes in the structure and configuration. Small errors in the programs that prescribe the behavior of the system can lead to large errors in the desired behavior. Indeed, current computational systems are unreasonably dependent on the correctness of the implementation, and they cannot be easily modified to account for errors in the design, errors in the specifications, or the inevitable evolution of the requirements for which the design was commissioned. (Just imagine what happens if you cut a random wire in your computer!) This problem is structural. This is not a complexity problem. It will not be solved by some form of modularity. We need new ideas. We need a new set of engineering principles that can be applied to effectively build flexible, robust, evolvable, and efficient systems.

In the design of any significant system there are many implementation plans proposed for every component at every level of detail. However, in the system that is finally delivered this diversity of plans is lost and usually only one unified plan is adopted and implemented. As in an ecological system, the loss of diversity in the traditional engineering process has serious consequences for robustness.

This fragility and inflexibility must not be allowed to continue. The systems of the future must be both flexible and reliable. They must be tolerant of bugs and must be adaptable to new conditions. To advance beyond the existing problems we must change, in a fundamental way, the nature of the language we use to describe computational systems. We must develop languages that prescribe the computational system as cooperating combinations of redundant processes.

What programming language should I start with?

Over on news.ycombinator.com, someone asked the question:

What programming language should I start with?

This was my response:

Here are the languages that have big communities: Perl, Python, Ruby, PHP, Javascript, C#/VB.NET and Java.

Subscribe to lots of blogs from each community. (Many of them have planet aggregators like "Planet Python" and "Planet Ruby".) Also visit local user groups, wherever your are.

Read/visit them for a while -- say a month or two. Whichever community makes you go, "wow, that's cool" -- join that community and learn the language. You can also interact with those communities via Google Groups.

Lots of people will say -- "that's easy" or "this is elegant" or "that language sucks". Feel free to ignore them.

And the response to my response, which I really liked :-)

Excellent advice. Non-religious, informative, and true.