skysight-inc/HackerNews huggingface dataset:
The article gets the spirit of your questions. "Without strong product and market vision, a startup will burn through cash as its team collectively struggles to define its position."
But yes, your words are more direct and should be asked, constantly, when you start your start up.
Personally I always liked:

http://tabularasa.org/
This video is aimed at mature organizations. Pretty much everything he says should be obvious by now to anyone seriously involved in internet startups. It may be worth watching if you are a middle manager at a large company, especially one outside the field of software.
Every mathematical model is a false representation of reality. The predictive accuracy must be validated by experiment. And using the link I reference, you'll see there's actually some pretty strong data to start from in this case.
Entrepreneurs are defined by their characteristics: Willing to take risks, able and willing to learn and execute on multiple areas of business starting, and most of all, adaptable: able to change course based on what he or she sees in the market.

All entrepreneurs are builders. They build both the idea and the business. What separates them from builders is their ability to adapt and their willingness to branch out into a lot of different areas
Fabric - Simple Pythonic Deployment Tool
Burger King in Tokyo !
Burger King, home of the whopper, an American hamburger fast food chain, has expanded its reach into the heart of sushi loving Japan in the very epicenter of Tokyo’s urbanite community, so move over McDonalds and make way for the King
Nope, at least in my case the HTML is not Lisp-generated, but hand-written. I use the templating way where occasionally I insert server-side Lisp code in what is otherwise mostly mark-up.

Of course it is not "something about Lisp". The HTML is always generated by a human, either "manually" (as in my template library) or automatically (as in CL-WHO or home-grown s-expression-to-HTML macros).

But you're right, it's not a big deal. What matters is the browser and the user, not the W3C :)
The Last Samurai Who Died in 1970
The last samurai’s belly that kissed the tip of a sword was Mishima Yukio on November 25, 1970 in downtown Tokyo at 8:35am. And as quickly as he was able to split his belly his head was severed from his body in one fell swoop by his long time lover and friend. In fact, it took several swoops before his head fell. It was an enormous undertaking but it took two men to completely sever Mishima's head !
The site is ok, although the number of video interviews on the site are not much, but i dont see the sense in displaying all of them as full windows. Make the most recent interview a full window, then older interviews to be in the form of an expandable menu tree, for people who do not have fast Internet access. i.e. to reduce loading time. just my 2 cents
Sirius' online service does this as well.
Ha.

Right this minute (~12PM EDT) this article is one spot below an old link to a very old XKCD strip about hanging on to your idealism.

(America's Paper of Record) < (paint-program stick figures)
Blood Orange Juice
Finally, blood orange juice has arrived in Japan from Sicily, the largest island in the Mediterranean Sea, Southern Italy. I never thought the day would come when safety conscious Japan would open its doors to not only a very rare and delicious fruit drink, but one that was banned from export some years ago due to the scourge of the Mediterranean Fruit fly or medfly, for short.
I can pass this on to my non-geek friends and griends (short for girl friends). Writing is an art.
As with everything else that I can remember reading by you, I guess it's the fact that you write the way I'd advise people how to talk to me: don't be pedantic [don't treat me like I'm an idiot or just a "child"], and don't speak as though trying to impress me [don't waste time using big words when small ones will do; don't use many words when a few will do].

I like the way you share ideas and concepts with me, the reader and message receiver.

Obviously, Paul, the whole is greater or less than the sum of the parts. You some how manage to make points that others couldn't with many more words. It's how you use the English language.

It's how you reason and think.

I think.

I think you annoy the hell out of insecure little twits whose "authority" they cling to like little kids afraid as hell that somebody (a "bully," perhaps?) is going to pry their "binky" (or toy or some other thingy [sic]) out of their sweaty little hands.

Or something like that.
This is awesome. My mind replaced XYZ and ABC with names I know. And...

Normally, I can't bear to read such poor English, but this time it was just the perfect touch.
OpenBSD; it runs GNU/Linux binaries too.
Even after your patent issues, enforcing it is horrifically expensive. In addition to the 7 year delay from filing to issuance, expect another 1-2 years, much of it billable, before a legal action based on your patent sees any action.

For a startup, is there any point in pursuing software patents at all?
I think what you are proposing is a false choice but I understand why you want to frame it this way.

Having been an entrepreneur for the last fifteen years, I have come to learn that my job description as an entrepreneur is simple, "if I could describe it, it ain't my job".

In other words, in the beginning of the startup, you have to do whatever it takes (be an engineer, be a salesman, be a negotiator, etc.) but once the company gets off the ground, then you need to give that responsibility to someone else. But by then, there will be other tasks that are not well defined that require your attention. And the cycle continues until the company is no longer a startup and the entrepreneur has lost his/her place in the company (or he/she matures into a manager).

At the end of the day, an entrepreneur's job is to connect the dots. It is a deceptively simple description of what we do.
I'm not sure I see the problem that demands a solution here.
I think that's a really good question. There are (at least) two distinctly different skill sets or personality types essential for a successful entrepreneurial business - one is the thinking-of-new-ideas-and-making-them-work track and the other is the bookkeeping-and-keeping-up-with-routine track. I'm not very good at the second; switching back and forth between coding and bookkeeping makes me want to sit in a corner of a dark room and rock back and forth slowly while reciting Kipling. Some people, though, are really good at the second. I know a few people who manage both and I'm rather in awe of them.

Perhaps there's a third type, too - the guy who goes out and sells the idea, like Jobs to Woz.

How do you solve this problem? What am I doing wrong?
I think I have a slightly different spin on the difference. I tend to see, rightly or wrongly, a Builder as someone who is going to see a job through to the finish - a details person, in essence. A Hacker, in YC parlance.

I see Entrepreneurs as those that create the ideas, or see the vision of how an idea could be used, implemented (on a broad level), or sold. I feel an Entrepreneur's skillset lends itself to creating the team, inspiring the vision and making the deals necessary to establish the company as a viable entity.

I also tend to see Entrepreneurs as quickly bored (perhaps that is just how I see myself) and eager to move onto the next thing.

I guess that's why I feel a startup generally needs two co-founders - a business person and a techie person. Ideally, they'll each have a degree of appreciation for the other's domain.
Parallels between Twitter and Friendster
Twitter seems at exactly the same point Friendster was when it found itself deciding between a Kleiner round or an acquisition by Google.
Charlie Rose with Steve Jobs and John Lasseter in 1996
http://video.google.com/videoplay?docid=4952557933657865919

For some context: this is shortly after Toy Story, and before Jobs returned to Apple.
Jobs is not the "builder" in any technical sense of the word. But he's a brilliant entrepreneur nonetheless.
Want $500?  Help Us Fix Jabberd2!
I believe the free option is to use the carrier supplied email gateways (which is what something like Google Maps uses to send addresses). If you want a full two-way messaging system like Twitter, you have to pay up. You can find open source software, but you need access to the networks and that's going to cost money.

It's quite a racket, they often charge both the sender and the receiver.
I'll be giving a talk on Git on Saturday morning. Looking forward to meeting everybody.
I really disagree with the premise of the article.

Famously, Feynman stated that “Science is the belief in the ignorance of the experts”.

When his sweetheart Arlene Greenbaum became sick, he found himself shuttered away, studying her ailment with as much intensity as he could spare. Eventually he thought, based on the evidence, that it was most probably tuberculosis. But this was, at the time, a common disease. He reasoned that her doctors (of which there were many) would have known if it was. So he discounted his own diagnosis, and placed his faith in the opinion of the experts, who, if I recall correctly, believed it to be some sort of rare cancer.

But it was tuberculosis. She died from it.

Doing science isn't about applying some particular professional method. Fundamentally it's about using everything at your disposal to find out the truth of things. So called non-scientists can do that, if only they try. As an ethos, science, at least as it's seen by some, couldn't be more anti-expertise.
(You know that you used "queue" when you meant "cue" right? Not trying to make fun of you, just pointing out that they're homophones with different meanings and it's kind of jarring to read the wrong one)
For our internal projects, we use CentOS. Externally we use a mixture of CentOS, FreeBSD boxes and one OpenBSD box.
Can somebody who upvoted this tell me why? It doesn't make any sense to me, other than that it points out that Knuth is mathy (holy cow!)
Yep. Good catch. I know the difference, but don't always catch myself before the wrong word gets to my fingertips.
OpenID: A Contrarian View
Ubuntu server is pretty slick -- all the goodness of Debian with up-to-date packages.

The best Linux distro is probably a BSD variant.

Fail -- I'm a huge FreeBSD fan but did you consider that perhaps this app is written in Java, which to this day has second rate support in FreeBSD (largely due to Sun).
There's a new peepcode pdf about this that looks interesting.
https://peepcode.com/products/mms2r-pdf

I'm sure the carrier negotiations in order to use shortcodes are different in countries outside the US. I have heard that docomo in Japan actually makes this sort of stuff really easy for developers (and that Japan has a burgeoning diy market of cool phone-based services as a result).

What country are you in?

I've done work using the email2sms gateways for both sms and mms. For sms it's kind of a pain because the gateways can't always be inferred just from carrier and number (T-mobile for instance, sometimes uses a nickname that you set up rather than your phone number, so your phone's sms email address ends up something like coolguy@tmomail.net instead of 2125551234@tmomail.net). Receiving MMS is a HUGE pain because the carriers all include the attachments differently. Some carriers include multiple attachments -- some of them are spacer gifs and things like that -- and you have to figure out the correct one. Other carriers, like Sprint, don't even include an attachment, they have a link in the MMS email that takes you to a page, and that page has another link to the picture. I had to use come complicated regex's and multiple wget calls to download the picture. The whole thing was very fragile as a result. But, to Sprint's credit, they are so bloated and slow to change that in 9 months they never modified the way those messages were structured so nothing broke.

I haven't worked on this stuff in over a year, so it may be out of date, but given the glacial rate of change in telco's (esp in the US), I'd be surprised if the situation has changed much.

Again, though, could be a very different story depending on where you're actually located.
Want to see how efficient your code is? Have it refactored.
People who can run the day-to-day operations, dealing with many dept. (sales, marketing, technology, HR etc.) may or may not be an entrepreneur because my understanding is entrepreneurs are builders because they create something from scratch.

Many people start their career with 9 to 5 job and keep getting promoted to the CEO level, but they may not have ability and courage (at least in the beginning of their career) to build a new business right from the scratch.

While entrepreneurs/builders are the people who start and build something (or help others to build something) from nothing.

Serial entrepreneurs (and builders) are always on the move - from one project to another as they are not interested in doing the same thing over and over again on daily basis - they get excited to build something from scratch and once it is built they find the right person to run it (or they help others to build it and move on to the next project).

Serial entrepreneurs (and builders) to me are like King-makers, they are not interested in becoming a king them self and run daily operations. They are like a Guru who has many disciples (kings) who achieve success with his/her skills and knowledge. It is well known saying that a Guru is equal to a 1000 libraries - they know which book is for whom, and when and how to use it.
I doubt I agree. Knuth covers the fundamental, distilled algorithms very comprehensively. I really don't think covering VM, cache issues/width of cache lines, as well as virtues of pinning pages in memory is completely in his scope. If he did that, he'd have to talk about architectural issues such as out of order execution and depth of pipe-lines, which he obviously has no interest in since he developed his own `ideal' (M)MIX architecture specifically for the books.

I feel that the best way to approach actual algorithm implementation is to see what Knuth has to say about it in terms of virtues of some algorithms vs others and then to study the environment it will be running on to tweak the general algorithm.
Intro Article on FreeBSD kernel modules
I believe that there's an inverse relationship between "building" and "wheeling and dealing". The more and better you build, the less you need to wheel and deal.

I've always noticed that commodity type products needed great promotion people. Examples: insurance, real estate, some industrial products.

I think this happens less with great products that address a real need and have captured their place in the market. You don't see many telemarketers for Apple, Volvo, or Google.

I focus on building so I won't have to wheel and deal as much. Might not be a bad idea for most people here, too.
Unit testing hast it's own use, but I never really drunk the kool-aid.

In my experience with unit testing:

1. It doesn't help much if you are working in client side enginering. No matter how clever your unit test is, it can't help on detected ui rendering errors, animations, or multithreading programming.

2. Java + unit test, means you have to throw away all encapsulation, and good OO design to apease your unit tests, exposing your program to your coworkers to create havock by calling methods that shouldn't be visible to them.

3.Unit tests can give you a false sense of security. Oh, look, it passed the unit tests, my code must be good. Well, most of the time unit tests != real world scenarios.

4. TDD (test driven design) of software, can be slow. I would recommend it to all my competitors. In a startup, I'd rather release something fast, that might be still little buggy, than something that works well, but it took forever to get there. Plus TDD is constraining, as you are programming around your tests, and not around what the user will see. I found often, that my final design on a functionality, is different from how I thought it would be at the beginning. When working in large systems, you don't have the luxury to know how your final design will be.

5. Unit testing stiffles creativity in design, goes against "Exploratory programming". If you already know the answer on what you are building when you start, then you probably are not exploring around.

6. Unit testing != fun. Honestly, I'd rather be implementing features, than testing them.

Where unit testing is good:

1. When building an api that will be used by other people amd that is more static, less fluid. As oposed to UI enginering, something like geoCoding api's, have simple and clear results. That is very easy to unit test, as the value returned by the api is within a determined range, and the unit tests can be few, simple, and clear.

2. Scripting languages. Unit testing helps on detecting errors, where in a static language they would have been caught earlier. Plus it is much more easier to unit test on something like Python, then something like Java, or god forbid C/C++.

3. Coorporate enviroment. If you are waiting for something form a different group/department, you can build some unit tests to test if this group's code is meeting minimum standards.

Overrall Unit testing has its place, but be careful not to rely on it too much. It can't be substitue to real testing.
Sounds like a slightly-more-real-time blog search to me.
The word "scientist" needs to be banned. There are physicists who have expertise in physics, much as there are plumbers who know a lot about plumbing. But there is no such special class of human beings called "scientists."
Pandora does this too. Drives me NUTS.
I really want to play with this, one of the main problems that I'm having is that if you don't know which direction the object was moving, say it was going up, and you're dragging down would it do anything?

And in one frame you could be holding on to something whilst in the next you're holding nothing... I guess we'll have to play with it to see how the interface works.

I kind of get the feeling that it will be like placing the OS X dock on the right or left side of your desktop, you instinctively want to resize by moving up or down, but you have to move left or right.
Tumblr and SEO: A Case Study in Rapid Response.
I've worked for three well-funded startups that failed for another reason, though all of them ended up making the same mistake: they couldn't develop software.

All three made some of the most common mistakes in software development, and tried to hide those mistakes behind a sweatshop.

1) Hire lots of people. Silly... hiring people doesn't get work done if you can't actually tell those people what you want their product to do.

2) Assume that hours = productivity. In every case, the competent folks among us spent a lot of time cleaning up problems caused by the folks working the extremely long hours. That contributed to my departure in every case... I hate cleaning up other people's messes, as it prevents me from doing worthwhile work. Firing those folks would have gotten us to market MORE quickly rather than less.

3) Deadlines set in stone... that just doesn't work. If you can't adjust your scope, you'll never actually hit the deadline.

4) Marketing based on the deadline... duh.

5) Perpetual crisis mode... when the requirements are poorly defined (if they're defined at all) as well as late, you have to be willing to delay launch or trim scope, or both. If instead you go into crisis mode and assume that your sweatshop will churn out a working product, you've already failed, and most of your best people will start jumping ship, leaving you with your burnouts who's primary contribution ends up being technical debt rather than working products.

I could go on, of course; I'm sure most people here have had similar experiences. So far, what I've seen of startups that made it big, they succeeded because they were either smart and did things well (e.g. 37signals), or because their software wasn't what they made their money on. Where I work now, we have hundreds of developers whose job is to pay the technical debt of the sweatshop, and one side effect of this is high turnover and low tribal knowledge. Most of our systems are in perpetual triage, and it's pretty obvious that if they were the source of our revenue, we'd be history. Fortunately, they only support the core business, so we're still around and profitable... but very inefficient.

Several government contractors I've worked for clearly survive based on the contacts within the government, because their software in many cases doesn't even meet the requirements it was developed for.

That's quite a bit more than I'd intended :)
I live in Nigeria, i.e. West Africa, I will like to talk to you and see what we can work out. my email address is aitoehigie [at] gmail [dot] com
I think it totally depends on the business, and the core problems that need to be solved for the business to win. Some businesses require only technical genius. Some really just need an innovative UI. Some need dealmakers.

A lot of builders attack problems whose core problems aren't technical... Which often leads to failure.

Either way, in the earliest stages, specialization is oftentimes a really bad thing. If you can't sell your product to co-founders, employees, partners, and customers, then you might be too specialized to be a successful entrepreneur.

Entrepreneurs (whether they are builders or not) get shit done. PG did sales. When he was starting up, he aggressively recruited great team members. Great entrepreneurs don't silo themselves... They stack rank the most important problems they should tackle (whether they are building-related or not) and then they try to destroy 'em with whatever means necessary.

So, in short: Make sure your teams' skills match the core issues of the product you're attacking, but know that every team member is going to have to get out of their comfort zone and attack stuff that needs attacking.
>Fundamentally it's about using everything at your disposal to find out the truth of things.

Nice statement.

Also, great story. It's not just Feynman either. I've seen the same thing (family members getting the diagnosis before doctors because they care more and take the time to get it right) several times in my own family.

As a graduate student I find myself continually astonished by the fact that narrow expertise comes quickly. That is, if you start out with a specific question it will not take too long before you understand it better than your adviser and then better than anyone you can find and finally better than anyone in the world, as far as you can discern.

Basically, the world is so broad that if you specialize on a specific, well formed question (as Feynman did) you can probably become a world expert on that question if you put in the time and are actually looking to learn.
I understand that. It was a serious question, though. How worthwhile are extensive unit tests if your end product is still broken?
We already saw the original -- and it's still on the front page! Why this submission-- essentially a duplicate?

"TechCrunch runs a story we already saw via my tip!" is not itself a story.
Ask YC: How do you project web traffic?
As I raise funding for my startup, investors want to see pro forma financial projections. I think I can estimate our expenses fairly well for a year or two, and some of our revenue assumptions (e.g. subscription cost, ad CPMs). But our revenue depends on two unpredictable things:

-- traffic
-- conversion rates

This is crystal ball territory, and everyone knows it. But we still need to make claims and substantiate them.

Has anyone seen a good model for estimating traffic based on assumptions? Any insight into what to give our investors?