ndl

I'm just starting now. I'm glad you posted this. There's much survivor bias in the startup community.

It's not the sound but the silence that bothers me. Constantly wondering whether a lack of responses indicates that something is wrong (requiring a pivot), or that I haven't stayed the course long enough for my current strategy to pay off.

Ever since "losing" to Microsoft on the desktop, Apple have slowly perfected their strategy for being the smaller alternative. They find the most lucrative niche and design to the point where they can own that piece of the market. Built into Apple products is a sense of superiority, the feeling that the rest of the world is jealous and frustrated. It's in their ads, and its in their users. This has shown its effectiveness in the computer market, and it will probably make them a ton of money on the mobile scene as well.

But Apple didn't have to do this in the mobile world. The iPhone was the default smartphone. I was once talking with a rather avid iPhone user who he asked me "what's the market for Android?" I fina;ly convinced him that it could be everyone when I replied, "what's the market for Windows?"

The iPhone is a product. It has a target niche, a company behind it, a list of features, and everything else one expects. Android is not - it's a platform. The Droid is a product. The Nexus one is a different product. Like Windows, Android twists and bends to the offerings of each vendor. Android has the more scalable long tail strategy - instead of trying to please your customers directly, let the market mold your product into as many forms as it will pay for.

I don't think that Apple have necessarily screwed up. They may have given up the big fish, and they may have had a reason. For one, Apple are doing what they're best at. They also may have a strategy that integrates with the Mac. They may also be right. Maybe the mobile phone isn't the next computer. Maybe it's like the iPod, best at doing one thing very well.

I think Apple is making a mistake in breaking developer trust. As long as they keep market dominance, people will keep coming back to them, but as the numbers show, Android is poised to surpass. When there are many more Androids out there than iPhones, iPhone dev is gonna be a tough sell.

I'd advise branching out in the beginning. I learned too much Java in the beginning and wish I'd tried Python earlier. I also think that some languages (especially Lisp) will teach you things about other languages.

Definitely give C and Scheme a try. Both are simple, compact languages with strong philosophy and history. I think that most of the languages we have today compromise between C style and Lisp style.

One of my favourite books is called, "Write Great Code: Volume 1: Understanding the Machine". This book gave me a real intuition for why the computer behaves the way it does given a piece of code. If like that kind of stuff, you might also take compiler design to see what happens on the low level.

On the higher level, "Code Complete" is a classic. Once you've started, the "Dive Into" series is pretty good for picking up more languages.

I think the best way to really learn a language is to do something weird with it. I once tried to use Python in as purely functional a style as it would allow. I got far better at C by learning GPGPU and CUDA. I learned the motivations for C++ by implementing vtables in C. Doing odd things that push the limits of a language can reveal deep truths about how the pieces really fit together.

I disagree with, "Note 1: If your idea is to build something truly technically challenging, then scratch my advice." If you want to build something technically challenging, you absolutely must learn the basics of whatever field it's in. You will not make a prototype this way, but you will be able to talk to someone who can without sounding like an idiot. You should study until you can prove that your idea is "challenging" rather than infeasible.

As a corollary, be weary of AI. If you are solving a problem with AI that you don't understand, assume the AI won't work.

On another note, maybe the real advice should just be "pick an easier project." I have a technical background but consider myself a hybrid business/hacker going forward. My current project is highly technical; I don't think I'd consider taking on a co-founder who didn't have some tech background.

From my personal experience:

The "business" person should learn a little about computability and feasibility. You don't necessarily have to understand the theory and mathematics of it all but should have a sense of when a problem is intractable. I had one startup try to recruit me as an intern to build an AI that would pass the Turing test and generate their marketing content for them. I had another "business guy" push strongly for an idea based on AI that could predict the future, then quit when it finally got through to him that I was not going to spend my life researching an intractable problem. I've had marketing people try to explain that solving the traveling salesman problem is an easy opportunity.

I'd like to see a business person who really understands market research, especially pricing. Make sure you're finding stuff that the programmer wouldn't have found himself. Avoid making premature statements of strategy - many quantitative people will (rightly) see this as a weak attempt to appear decisive.

Legal and accounting are great things to take off the programmers' shoulders.

Let the engineers handle at least half of the "idea" phase. Let them take some support as well, since they'll be able to answer technical support queries best. Don't jump to grab "all the networking" unless you've been asked to - programmers who found companies often rebel against being shoved into the backroom.

A big theme in programming is to get as much complexity out of one's head and into the computer as possible. In this regard, I consider the IDE an extension of the high level language. Whether I use one depends on what I'm coding in. I'm usually fine with gedit when coding Python. In Java, the IDE helps cut through the verbosity.

There is some truth to this article - humans are much worse than machines at simple, regular processes. Manufacturing eventually figured out how to divide up labor along the assembly line and automate as much as possible to make the process regular. Software is comparatively in its infancy. Maybe we will see a similar progression as companies replace the artistry of software with more standardized, repeatable processes. I probably won't be coding then.

Kind of reminds me of http://xkcd.com/378/

John Mullins describes a lightweight technique called the "long interview" in The New Business Road Test. I've only used this seriously once. The results of my trial provided good insights but were not as definite as I'd hoped.

Another method I heard from a startup marketing guru is that if you have a large number of users running a free or pre-release version, you should ask them, "how disappointed would you be if this product were discontinued?" You have product-market fit when a significant portion answer that they would be "very disappointed."

I've also had the impression that feature requests are not a particularly useful metric by themselves. The fact that you have conflicting feature requests probably indicates that your market is highly subsegmented. It might be useful to try to map these subsegments demographically and need-wise.

Google is aiming into the future. Targeting legacy systems can be a great way to solve customer pain and get easy users, but it's usually not a long term growth strategy.

"To build a business, you need to understand subjects like finance, marketing, intellectual property and corporate law."

Many colleges, especially small ones, have absolutely nothing in these subjects. As for the ones that do, many successful founders and MBA holders tell me to be suspicious of said programs' ability to prepare one for actual entrepreneurship (as opposed to writing academic papers about entrepreneurship).

I personally did finish college (this year), majoring in physics with minors in math and computer science. I attended a small liberal arts college with no practical business classes, of which I took 3 by hacking around the system. The physics major taught me how to get projects done, work efficiently and endure recurring high-stress situations. The math minor taught me that I suffocate in a room with too many mathematicians. The CS minor was really a collection of "X cool research area has Y," which is occasionally relevant. I definitely learned in a college, though I've yet to reach a conclusion on whether it was "worthwhile." I wish I'd taken more theatre and had more fun.

I'm much more weary of grad school. As far as I can tell, college is more about exploring and learning general life lessons, while grad school buys you specialization. Specialization has power; most tech companies recognize this and hire PhDs as soon as they can afford to. But I currently have every reason to think that great founders are better off as generalists. Specialists get pulled in to support specific areas. Furthermore, while I admire those who were born to do one thing and do it well, I'm not one of them. I have very little idea what I would study. I certainly don't intend to spend my life researching a narrow subfield of physics. Unlike in college, I couldn't spend the 1st 2 years of a PhD or masters program field hopping. Occasionally someone tempts me with an interdisciplinary program; maybe I'll try one of these someday. Part of the draw of entrepreneurship is how multifaceted it appears.

I have every reason to believe that for recent college grads dreaming of startups, the best way to get experience is by trying it. That's exactly what I'm doing at the moment. I also tried to form a startup in college. That didn't go too well. Now I'm starting up full time.

Investors frequently look to others for votes of confidence in a potential deal, whether it's PG wanting multiple-person teams or VCs who close when other VCs take an interest. The "vote of no confidence" argument is for why having multiple founders is an indicator of success but does not directly imply causality.

There are plenty of actual reasons why multiple founders would be a cause of success, but they rest entirely on having the right cofounder:

* Having a cofounder keeps you committed, if your cofounder is committed.

* A startup is a ton of work. Make sure your cofounder understands this from the beginning. Especially watch out for the chicken/pig situation.

* A startup is an emotional roller coaster, so make sure you surround yourself with people who will hold you up. Actively avoid anyone who creates excess negativity or drama.

This all seems obvious now, but I made the mistake of being too careless/lax with all three of these points. The temptation is to assume that you will work things out. Trust, but verify, preferably before you put in time and money.

Now I'm a single founder. I'm looking for a cofounder but am rather picky. If I miss my chance at YC funding due to lack of partner, I have other options. If I were to rush the process and take on a bad relationship, it would probably doom the venture.

One side effect of canned themes is that you will look similar to other startups doing the same thing. This could be an advantage in the beginning, because the site will feel familiar to new customers who are used to the theme. You will want to differentiate if distinctive branding becomes part of your strategy.

This also applies when choosing partners. Being a lone founder is vastly better than throwing together a group that is all friction and no teamwork.

If I were signing up for said free trial and saw a credit card request upfront, I would be suspicious. Many subscription services promise such a "free" trial and then make it difficult to back out. It also violates my model of how "free" should work to ask for credit card info, so I suspect hidden charges.

That's my experience. Maybe your users are more trusting.

In the long term, you often have to aim where the market is going to be, even at the expense of where it is now. I believe this reasoning favors HTML5.

Consider using a library such as Sproutcore to develop an HTML5 app with desktop look and feel.

This "team" ambition depends equally on the environment as the candidate. I agreed strongly with this article until I realized that I was assuming an equity-for-all startup, rather than the much maligned office job.

There is definitely a personal component too. I've seen people co-found a company only to wreck it for personal convenience, and others who will work well beyond their contract with seemingly no incentive.

Years of research and countless dollars have gone into making programming a systematic, controllable process. Old school managers frequently wish that a dev team would output like an assembly line.

Simultaneously, we're expected to be into the newest and coolest technologies.

Put these together, and we're supposed to systematically glue everything that's new.

Seriously, it's not all bad, though. I like being able to generate a test UI in under an hour or a basic web spider in one python file. The art's just different. It's no longer packing your entire logic into beautiful lines of BASIC. It's now more about choosing the right platform to do something that the user will appreciate.

If you're into the pre-library styles, I recommend looking at alternative hardware. When I wrote my first CUDA project, I had to figure out how to get random numbers with sufficient randomness for our physics simulation. You might also look at robots or embedded devices. There's plenty to tinker with on devices that don't have libraries available.

There's a difference between results that come from people who we think to be generally bad but do not have any incentive to do anything but a reasonable study, versus people we suspect desire to directly tamper with the research.

I wouldn't ignore any results that have strong evidence, but I would read much more carefully the papers of those who start with an agenda.

According to the clang home page as of March 7th 2010, "Clang's C++ support is currently alpha quality at best, but is evolving rapidly."

Obviously, clang does not mean to attract C++ developers. For a while, I'd been adamant about developing in C and not C++. One day I discovered that I'd hand-coded a vtable in order to allow polymorphism in structures of function pointers. The next day, I halved the project complexity by writing 3 classes and changing a flag in the make configuration.

I use Gnu make through the Eclipse CDT on Ubuntu. It's a clunky and ugly toolchain/IDE combo that took days to configure. It compiles C, C++, CUDA and Brook+ in the same project across 3 different computers. A better C frontend would be nice, but I do not look forward to getting that working with everyone else in this chain.

I at least somewhat believe that ad-blocking is a symptom rather than a problem. Some advertising legitimately alerts me to things I find interesting, and I avoid blocking ads in general for this reason. Most, however, are repulsive and inconveniencing - I rarely watch enough of an advertisement to see what it actually sells. I generally like ad-supported content models, however, and usually am willing to let the banners ads have their place if it keeps a valuable site in business.

What offends me is the new class of ad that comes with built-in audio. I may add your site to my blocklist/spamlist for doing this. This kind of ad causes awkward social situations and trouble in the office - someone's computer randomly starts blaring out noise in what should be a quiet and focused environment. This is not a social contract - this is a trap.

I think this debate exists for stupid reasons. Advertisers and webmasters have apparently forgotten that ads are supposed to sell something to a customer. If potential customers run away from your ad, then it's time to fire the ad agency and question product-market fit.

The idea of a typist pool intrigues me. It reminds me of the concept of a thread pool or connection pool, the idea being that one has many instances of a certain resource to share distribute over requests. Rudimentary parallelism and task scheduling seem to have existed since the dawn of history, when humans congregated in sufficient numbers to organize labor en masse.

I've heard from many people on this, in the publishing industry, in the music industry, in the software industry...

The funny thing is how not worried about it some people are. Maybe they're just in denial. I hear from one talk that textbook publishing is dead (since it no longer costs ridiculous amounts of money to typeset and print equations - I can do this with the school printer now). Six months later, a senior editor tells me that hard covers are here to stay.

I must point out that the publishers are at least a little bit right when they claim their function encompasses much more than printing discs. The entire engine of marketing and distribution, including the parts with industry connections, will have to be relocated before old publishing can rest in peace.

My guess is that no matter what they say in speeches, everyone is watching the Internet right now for some sign of the great new business model. I like this article, because it suggests the beginnings of a solution. Most merely state that we have a problem.

Apple's taking a real gamble these days.

On one hand, I'm sure they understand well the market that doesn't want to deal with customization. Ever since the iMac and maybe even before then, Apple has catered to people who want their computer to just work (for Apple's definition of "just work") with no hard thinking on the buyer's part.

As Apple now continues this philosophy into devices over which it has even greater control (a Mac is, after all, a Unix box, if you need one), we see the other side of Apple philosophy more clearly. Techies don't like it when a device has been locked down to reduce its functionality. It feels arbitrary to prevent use of technology that could trivially work. The app store really draws this into the open. No porn, no hacks, no Macs, no mention of competing platforms... the list goes on. Arbitrary restrictions - we'll see just how much developers will put up with.

I read an article in the Harvard Business Review relating to this some time ago. The author basically argued that social interaction comes from the limbic brain, so trying to learn it the way one would mathematics is awkward and misguided. The complex, inconsistent world of social cues simply has too many variables for logical processing, but each human is equipped with an older, instinctual understanding of this world that sometimes goes ignored or even repressed. Maybe the key to success here really is learning to stop thinking too hard and trusting one's instincts.

A good example is how we tell people they're being rude. Many nerds want an explicit, clear answer, maybe even a right/wrong mark or a grade. In reality, we respond to body language with body language. If everyone's avoiding your eyes or shooting you dirty looks, you've probably said a bad word. Sometimes it's more subtle, such as with the many meanings of crossed arms and angled stances.

I dealt with these challenges by studying acting. The practice of theater collects and refines centuries of study in body language, emotion and personal interaction. Even more importantly, it is a practice rather than a knowledge base, which matters if one believes that one physically cannot learn certain things from a book.

My impression (as it might be wrong) is that the words "I think" are contextually appropriate depending on what you're trying to accomplish. If you want to voice an opinion for consideration but not push for it, then "I think" demonstrates your openness. If you are trying to argue for something directly and expect opposition, then you should state your case as directly and strongly as possible. A third option is when you are expected to be a voice of authority (ie. you're a tech and someone just asked you what Linux is). Authorities are supposed to know, and people will think you're BSing if you say "I think..." what you really know. I personally would prefer you admit if you're unsure, but some people would rather you act confident than disclaim.

Months ago, I attended an entrepreneurship talk at which the speaker argued that the textbook and journalism industries would die as the scarcity of these media ended.

One week ago, I attended a talk by an editor at one of the major US publishers. He said they'd been searching for a way to modernize but didn't have a response to my mention of the previous event.

Looks like the type of problem with plenty of money for new models, much like the music industry today.

Reminds me of the Paypal story, in which the original plan was to build a secure way to transfer money between handheld devices. They realized their destiny was on the Internet after a demo web page started gaining serious traction among users.