Best 31 quotes of Joel Spolsky on MyQuotes

Beware of Methodologies. They are a great way to bring everyone up to a dismal, but passable, level of performance, but at the same time, they are aggravating to more talented people who chafe at the restrictions that are placed on them.

Common programmer thought pattern: there are only three numbers: 0, 1, and n.

Design adds value faster than it adds cost.

Entrepreneurship boils down to the simple fact that a team of really smart people who can get things done are going to get smart, useful things done.

Every day that we spent not improving our products was a wasted day.

Full service brokers, in this day and age of low cost mutual funds and discount brokers, are really nothing more than machines for ripping off retail investors.

Good software, like wine, takes time.

If something seems possible, that's probably because someone is already doing it. When something seems that it can't possibly work, nobody tries it. Real innovation happens when someone tries anyway, overlooking an obvious flaw, and finds a way to make an idea work.

If you are a programmer working in 2006 and you don’t know the basics of characters, character sets, encodings, and Unicode, and I catch you, I’m going to punish you by making you peel onions for six months in a submarine.

If you can't understand the spec for a new technology, don't worry: nobody else will understand it either, and the technology won't be that important.

If your goals is to produce something of permanent value, you start to think differently about you want on the site.

Indeed one of the best ways to deflect attacks is to make it look like they're succeeding. It's the software equivalent of playing dead.

It's harder to read code than to write it.

I've been using Vista on my home laptop since it shipped, and can say with some conviction that nobody should be using it as their primary operating system - it simply has no redeeming merits to overcome the compatibility headaches it causes.

Last week I was listening to a podcast on Hanselminutes, with Robert Martin talking about the SOLID principles... They all sounded to me like extremely bureaucratic programming that came from the mind of somebody that has not written a lot of code, frankly.

Listen to your customers, not your competitors.

Never put yourself in a position that will put yourself at risk if you make the wrong decision. We spent cash on everything. It's fashionable to make 'bet the company' decisions, but don't do it.

Not having a schedule is OK if it's your PhD and you plan to spend 14 years on the thing, or if you're a programmer working on the next Duke Nukem and we'll ship when we're good and ready. But for almost any kind of real business, you just have to know how long things are going to take, because developing a product costs money.

People ridiculously overvalue aesthetics and beauty when evaluating products. It's one of the reasons iPods, and, for that matter, Keanu Reeves, are so successful.

Remember, just because Microsoft can do something, doesn't mean you can. Microsoft makes their own gravity. Normal rules don't apply to them.

Shipping is a feature. A really important feature. Your product must have it.

Software development takes immense intellectual effort. Even the best programmers can rarely sustain that level of effort for more than a few hours a day. Beyond that, they need to rest their brains a bit, which is why they always seem to be surfing the Internet or playing games when you barge in on them.

So if you want to get things done, you positively have to understand at any given point in time what is the most important thing to get done right now and if you're not doing it, you're not making progress at the fastest possible rate.

Talk to your customers. Find out what they need. Don't pay any attention to the competition. They're not relevant to you.

That's another flaw with performance-based rewards: They are easy for one of your competitors to top.

There's a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. [...] The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming: It's harder to read code than to write it.

The secret of Big Macs is that they're not very good, but every one is not very good in exactly the same way.

Usability is not everything. If usability engineers designed a nightclub, it would be clean, quiet, brightly lit, with lots of places to sit down, plenty of bartenders, menus written in 18-point sans-serif, and easy-to-find bathrooms. But nobody would be there. They would all be down the street at Coyote Ugly pouring beer on each other.

Watching nonprogrammers trying to run software companies is like watching someone who doesn’t know how to surf trying to surf. Even if he has great advisers standing on the shore telling him what to do, he still falls off the board again and again.

We just have to come in every morning and somehow, launch the editor.

Writing code is not production, it's not always craftsmanship though it can be, it's design.