Especially at the beginning, you read here how often big clients can put you under at the beginning because you're not ready to deal with them.

After four years in which I frequently worked in a 6h/1h work/sleep rhythm for weeks at a time, I just left town and decided to never again have any customer that I couldn't fire and forget about on the spot if I wanted.

Big clients and projects were, at least for me, a complete nightmare. Worst were the lawsuits which, even when we ultimately won, would basically ruin whole years at a time.

Now I'm working for a few thousand customers at maybe $50/year average. When some technology or idea seems interesting, I'll spend 48h straight trying to get it working. When the weather starts to get warm, I'll spend the day in the sun with a bottle of white wine and no appointments until November.

A few big jobs > many small jobs

Low-paying jobs will consume more time than you expect. Be careful when quoting these. Always charge more than you think you need to cover your time.

Beautiful is better than ugly.

Explicit is better than implicit.

Simple is better than complex.

Complex is better than complicated.

Flat is better than nested.

Sparse is better than dense.

Readability counts.

Special cases aren't special enough to break the rules.

Although practicality beats purity.

Errors should never pass silently.

Unless explicitly silenced.

In the face of ambiguity, refuse the temptation to guess.

There should be one-- and preferably only one --obvious way to do it.

Although that way may not be obvious at first unless you're Dutch.

Now is better than never.

Although never is often better than right now.

If the implementation is hard to explain, it's a bad idea.

If the implementation is easy to explain, it may be a good idea.

Namespaces are one honking great idea -- let's do more of those!

> Simple products that do one thing well > Complex products

It has been my experience that business people constantly make this mistake. They feel a product has to satisfy all needs. The engineers I have met have consistently argued to remove features that are expensive to develop and add little value.

Both of those are anecdotes. Your milage may vary.

* Doing something you're interested in > all the self-help and motivational quotes in the world

* Doing something potentially meaningful and failing > doing something you don't care about and muddling through

Listen to people, figure out what 90% is bullshit or irrelevant and what 10% is interesting business opportunity.

2009 post, but still one of my favorite distillations of the issues around b2b customer types. Particular impactful if you read it when you end up going above and beyond with support, feature development, and contract negotiations with both rabbits and whales and you're running out of money.

Sorry, what did you mean by "in 21 days route"? Also, do you have any MOOC on doing business to recommend?

> * Sleep, exercise & healthy food > late night coding

Looks like it's against other points. I have a full-time job and I'd like to create a brand, too. Thus. I have to do late night coding.

Sounds like someone doesn't have kids.

Mostly tongue in cheek, but also slightly serious. There are plenty of life circumstances that preclude all those things.

Do you work more than 40hrs a week? Why? Sounds like you're creating someone else's brand if so.

If it is, it means you're probably working too much for someone else!

This isn't exactly olympian conditioning, but I do notice a benefit and the time investment is low.

I think late-night coding is a near-constant because of our brains automatically optimize us onto what pg describes as "the Maker's Schedule". Context switching is anathema to effective coding, so people automatically go to the time when they'll be least-interrupted, which is when the rest of the world is asleep.

Any chance you could expand a bit on this one?

But trying to solve the world's problems vs. trying to solve your own is another matter. You probably better understand your own problems.

If the problem affects the whole world, including yourself, then it falls in the left bucket.

In my case that means knowing the major datapoints about competitors in my space (public vs private companies, who's making/losing money, appannie stats), knowing everything available about cost of user acquisition, and looking at psych studies on user motivations.

These are things I would have benefited from knowing on day 0 but instead only learned after building a prototype that I had to scrap.

If your business is enterprise focused rather than consumer focused, understanding one or two customers is probably good enough for a start.

This is true for many things. I'm the best developer as long as I don't compare myself to a better developer.

Some of the craziest and successful startup ideas come from people who don't understand the industry at all and if they had they probably would have never tried to do what they did.

You can't understand your customers if you don't understand their industry. Picking customers is like investing: if you pick a bunch of customers that are not going to win their industry, you won't thrive either.