cwilbur

A beautiful theory.

However, the bean counters and glad-handers who stand between you and a paycheck often ask difficult but irrelevant question, and if you don't worry about explaining yourself to them, you make it much harder to get that paycheck.

You get a lot farther with the ability to solve real-world problems and MBA-appropriate skills than with just the ability to solve real-world problems, if only because there is such high demand for technically inclined people with people skills and business skills.

I have two experiences here that may be relevant.

Some years ago I was in a comparable position, only I was working full-time at a salaried job when I was approached to be a partner in a new startup. The elevator pitch and cocktail-napkin numbers were engaging, and it looked like we could bootstrap it with resources we already had on hand and be profitable within a year.

Except that six months in, we had no business plan. Now, I am not an MBA type, and I think that the value of the business plan is more that it's a self-check: if you say "Based on our projections, we should have 100,000 users and be realizing $10,000 a month in subscription fees and ad revenues by December 2012," and in December you have 35 users you know something is wrong; and if in December you see $1.2 million in revenues then you know you're doing something right and you'd better start doing more of it quickly.

Without a business plan on paper, we had no way of gauging even that the founders were on the same page as to what "success" meant, let alone whether we were succeeding or not. After six months of asking for this, I said, "I can't work a second full-time job on spec, and my business questions are not being taken seriously because I'm just the guy who knows web servers and streaming video." And I walked.

You might try an approach like that: pick up a basic business textbook and ask questions. When do they expect to see revenues? Do they have an exit strategy where they make themselves attractive to a large company and get bought for kerjillions of dollars? Do they have a non-exit strategy where they bootstrap themselves to profitability? If they can't answer that question, get out before the paychecks start bouncing.

My other experience was with a startup. It was five non-technical people - three who had lots of experience in the problem domain, one who had experience in business development, and one who had experience in data processing software development for insurance companies and bill collectors. And the goal of the startup was to put a certain experience online. The three experts in the problem domain were full of (and I say this without irony) excellent ideas as to what the software should do.

The principal structural problem that we ran into over and over again is that the only partner (and thus the only voice that was taken seriously) who had any experience in software development came from a domain where the business analysts would issue a mostly-clear set of rules and it was the job of the programmers to turn that into COBOL. So their first approach was to hire a consulting company to build the product for them. That was an almost completely unmitigated disaster: the only real benefit was that it let them get a product off the ground and start realizing some revenue. This was offset by the fast realization that the consulting company was milking them for all they were worth because the consulting company didn't expect them to last, which then led to a very acrimonious parting of the ways followed by lawsuits. And then they hired their own developers.

So the pattern we fell into, which you will probably find strangely familiar, was that the five partners would gather in the conference room once a month and come out with with two or three good solid ideas. They would then instruct the developers (two coders, a web designer, and a database analyst) to make it happen. We would start on it, hampered by the horrendous infrastructure that the consultants had left (but there was no time to address technical debt). We would get maybe halfway through implementing one of the ideas, while putting out fires and serving as tier 3 tech support, and then the next monthly meeting would happen.

That was the job where I learned to give development estimates in person-days on task, rather than in calendar days, and where I picked up the habit of automatically appending "assuming you don't change the requirements in the interim, because that will make it take longer" to estimates.

So what happened there? Well, I was the first developer to leave. Within a year, all of the developers had left, the partner in charge of software development had also left (no doubt with a massive golden handshake for her efforts) and the company had been folded into one of the CEO-partner's other companies, possibly with the recognition that it would never be fully profitable.

Based on my experience: if there is no technical person competent in the development style you're working in among the partners, if the only technical people are employees rather than partners, stay away. There may be exceptions, but generally partners have a lot more credibility with other partners than employees do, and if you as an employee are saying "this will take X person-days to implement and will not be profitable" and a partner is saying "this will be trivial to implement and I read in Infoworld about a company that did this and made ten billion dollars a day!" then the partner will be believed and you will not. No matter how many times you are right and that partner (and Infoworld) are wrong.

Summary of the summary: no technical partner means you shouldn't have signed on in the first place; no path to profitability and no exit strategy means you should get out while you can.

A good programmer who can find a job in an urban market can earn $120K a year. But there are a lot of programmers who can't find jobs, and that puts significant downward pressure on salaries; and there are a lot of programmers in more rural markets who are willing to telecommute, and that puts significant downward pressure on salaries as well.

I've taught introductory computer programming in Scheme and Pascal. (I think I just dated myself.) And I find myself concurring with this.

People who taught themselves to program often have a hard time understanding what novices find difficult. The one that gobsmacked me -- and I only ever ran into this when teaching Pascal -- was twofold: one, that the computer does things in the order they are in the program, and two, that the definition of a function or procedure does NOT execute the function or procedure. Something about Scheme made the distinction between "we are defining a function" and "we are executing a function" much easier to understand.

And I concur about the terseness of Python. I've been using Perl professionally for, um, 15 years now (and I just dated myself again). I've written a few toy programs in Python, enough to establish that it's a worthy programming language.

But the pedagogical problem is that there's a lot of depth under the surface of Python (Perl, PHP, Visual Basic) - a lot of things going on that the experienced programmer understands and that the novice programmer needs to. It's often easier to learn in languages that have less going on, because the programmer needs to do more explicitly.

Bzzzt. Bad use of statistics, because it's not a matter of chance. The ideas that fit best with YC's ideas of what a Y Combinator startup should look like and look like they have the best shot at succeeding win.

This is not a matter of chance. If your idea lines up perfectly with YC's vision, you get in, no matter how many other people apply. If your idea is completely unworkable for YC's goals (such as: you have a single founder, you're planning to run the startup indefinitely rather than sell it ), you may as well not apply, because even if there are 25 slots and 20 applicants you'll probably be rejected.

If your lawyer okays it, then it's fine. If you don't have a lawyer, why are you asking us? Ask your lawyer.

Honestly, the questin is like asking "Is it okay to copy code from another project?" And the answer is the same: if it works the way you want it to work, and you won't get in trouble for using it, then go for it. The way to determine if it works the way you want it to work is to consult a lawyer.

Don't think of legalese as if it were just marketing BS; think of it as an odd programming language for the legal system. When you need Python code written or evaluated, you become or hire a Python programmer; when you need legalese written or evalauted, you become or hire a lawyer. It's as simple as that.

No, it means that building the site is not sufficient, no matter how wonderful it is, and no matter how much people who use it love it -- you also need to find a way to tell people about it.

One of the most brilliant examples I've seen is ravelry.com -- there's an existing online community of knitters, and the people behind ravelry.com invited a few people to test, and gave them invitations to share, much like gmail did. Shortly thereafter they built a registration queue so that they could scale up gradually. Word of mouth did the rest, and twenty thousand people signed up, either for accounts or on the waiting list.

If you think you'll be unhappy doing the actual work that you'll be doing when you take the job, the job isn't worth it. There's no difference between being employee #9 or being employee #99999 in that regard.

Also, if they're successful enough with their current languages, you will not change them. Taking a job saying "I know they use X, but I'll talk them into using Y instead, and then I'll be happy!" is like entering a relationship saying "I know she does X that drives me nuts, but I know if I pester her enough, she'll stop it, and then I'll be happy!" Doesn't work that way.

One of the things you must realize to make sense of a lot of PG's advice is that the default business model for YC companies is to build a promising product so that venture capitalists will give you money or that a Yahoo/Google/Microsoft will buy your company.

For those two goals, which are based as much on impressing investors as on anything else, your chances are much better if you're not a single founder. Investors are much happier investing in a team than they are investing in a single person. To that end, PG's advice against single founders is spot on.

Right, but stupid business types don't distinguish between "web startup" and "non-web startup." You might be able to make headway by talking about core competencies and business expertise.

Outsourcing programming tasks is a very reasonable thing to do when the core of your business is something else and the programming is just supporting that. If your business's core expertise and value proposition is that you have highly skilled plumbers on call 24/7, then insisting on developing the website and billing software in-house is a waste of effort. But when the core of your business is the software, outsourcing it is foolish. If your business's core expertise and value proposition is that you have a location and scheduling algorithm that will guarantee you get an affiliated plumber at your house within 30 minutes of your request, then the software to support that should be developed in-house.

This is something that good business guys will understand.

Even then! I've seen programmers read the code, get it wrong, and rewrite it in a way that introduces bugs. Hell, I've been that programmer. It's clear, it's readable, it's concise, and it's wrong.

Readability and correctness are orthogonal concepts.

I'm talking about the ability to go to the doctor routinely, to get things like vaccinations and annual checkups. The government doesn't make you do sensible things elsewhere, but the cost of doing sensible things if you're in the US and don't have health insurance is prohibitive.

To take an example from dentistry: getting a biennial checkup, finding an early-stage developing cavity, and getting it fixed will most likely cost you under $200. Not getting the checkup and waiting until the tooth is abscessed and requires extraction, a root canal, or oral surgery can cost you $2000 or more. But if you don't have the $50 for the initial checkup, what are you supposed to do?

The core of your business should be in-house. If the technology sits at the core of your business -- as it does for most web companies -- then outsourcing it is foolish. If your business is actually something else, like plumbing, and the tech just supports it, then you may as well outsource it; it's a decision for a cost-benefit analysis.

If I wanted to be called by strangers from YC, I'd put my phone number in my profile.

No, a hacker would implement someone else's ideas if the ideas were interesting to implement and possible.

If a business guy has a vision that he shares with the hacker, the hacker will want to build it, though the hacker may want to build other things more and thus decline the partnership. The equity should be divided according to what each brings to the relationship; if all the business guy brings is the vision, he ought to be paid a flat fee for it, probably no more than $50, and thanked kindly. If he brings funding, it depends on how badly he needs the hacker.

I'm a really good programmer. I want to implement my vision. I have several visions that I want to implement right now, as a matter of fact, and they're all vying for time with each other and with things like my day job and sleep.

If you want me to implement your vision, you can pay me (preferably more than my current employer does, with at least as much job security and at least a good quality of work-life balance), or you can convince me that your vision should be my vision, and is so much better than any of my visions that I need to start working on it at once.

Paying me is a heck of a lot easier.

Well, I've been talking to a couple business people about various startup stuff.

One major thing I've noticed is that business people who don't have hacking experience do not have any experience to judge what's simple and what's hard. If you're in a startup mode where you're trying to leverage the least amount of work for the most profit, this is the kiss of death.

Hackers have heard "I can't hack, but I have this brilliant idea..." a million times, and hackers realize that the idea is easy and the execution is hard -- so by making that kind of a pitch, you're offering to the hacker the proposition that you're going to do 1% of the work and take 50% of the credit. That just isn't an attractive deal.

And I do not agree with your statement in the the fourth paragraph: "But there are many others, beyond the realm of hackers, that have great ideas, possess creativity, and who can use his/her creativity to make something successful." Creativity is not sufficient, or you wouldn't be upset that no hacker will listen to your pitch.

Honestly, if you want hackers to take you seriously, if you are as brilliant and motivated as you claim, learn to program.

There's no evidence that reading the code and trying to make sure it is simple and straightforward improves the quality code, for that matter.

The quality of the code is a combination of the quality of the programmers and the quality of the processes they use to produce the code. If you have really good programmers, they can use a shoddy process (write, compile, ship) and still produce reasonable quality code; if you have average programmers with a good process (write test, write code, compile, fix warnings, compile, run test suite, fix errors, compile, run test suite, ship), you can produce good code.

What I've found is that whether a test will be useful or not depends on the nature of the code. If I'm writing logic code or building a domain-specific language, an automated test suite means the difference between getting it right quickly and taking a long time to get it hopefully probably mostly right.

Readability is only one aspect of code quality, and code that does something complex and convoluted will never be simple and straightforward. For that matter, complex, convoluted, and correct is preferable to simple, straightforward, and wrong, and that's the sort of thing that a test suite will tell you.

If you only count the initial development time as "development," writing tests will increase your development time. If you take a longer view, and consider maintenance and later development, having a good test suite makes it easier to find bugs and makes it possible to add features and improve code with confidence that you aren't breaking code that relies on your test suite.

Seconded. In the past year I've wound up visiting the hospital twice for things that were, in the words of my doctor, "total random flukes" -- not lifestyle related, could have happened to anyone. Fortunately, they were fairly easy to fix. Total cost, $75 per visit. If I had had no health insurance and went to the hospital anyway, I'd have been looking at a five figure bill, and probably bankruptcy, for either of them; if I had no health insurance and did not go to the hospital for either, I'd probably be dead now. Or the ambulance would have taken me to the hospital, and I'd be that much more in debt.

You need health insurance. Bad things happen. Flukes happen. It's not about having the balls to face the risk of no health insurance and stare it in the face; it's about careful planning - the same kind of planning that means you incorporate instead of trusting the chance that nobody will sue you.

What the lack of socialized health care in the United States means is that instead of the government paying a little bit for preventative and maintenance care, the government pays a lot as elderly and poor people who have lived a life with no preventative or maintenance care need expensive prescriptions and expensive treatments.

This might be a slight advantage in the short run for those whose startups are successful.

Depends on what the monthly plan is like.

$100 is more than I've spent on my current cell phone in the year I've had it. The iPhone would have to be really sweet to justify spending that much each month on top of its purchase price.

Here's your fundamental problem. It's a logical fallacy.

You observe that a good employee is likely to have a high IQ. From this, you conclude that a bad employee is likely to have a low IQ, and that a person with a high IQ is likely to be a good employee.

The truth of a proposition does not imply the truth of the converse of the proposition (A - B does not imply B - A) or of the contrapositive of the proposition (A - B does not imply !B - !A).

Further, no company has a verifiable screening program, because they can't evaluate how good the people they screened out were. Suppose a company has a screening program that rejects 90% of candidates completely at random. They then choose their hires from the other 10%, using other means. As long as they get good hires in sufficient quality and quantity, they will believe that the screening program is effective. They have no way of evaluating the people rejected by the screening program.

Because they realize that there's more to happiness than money, especially in a job where you spend at least 1/3 of your waking time?

There's no evidence one way or another, because there's no clear objective definition of "a good employee."

For some of the jobs I've had, a willingness to think independently and critically -- far more important in a lot of cases than a high IQ -- was an active detriment.

If you can define objectively what makes a person good, you can probably, after a decade or so of research, put together a statistically significant test that will allow you to objectively determine whether a candidate is good or not. That's probably longer than your schedule allows, so you'll have to fudge it.

First, you want people who are analytical and can figure things out. I went to an interview once where the interviewer had a binary clock on the table. It wasn't immediately obvious to me what it was, never having seen one. He left me in the room for a minute while he went to fetch something, and while he was out I figured out what the clock was and that it was off by about a quarter of an hour. Later on in the interview he asked if I had any idea what it was, and I told him that it was off. Apparently I passed the test.

Second, you want people who know their stuff, and who, if they don't know some bit of their stuff, can take a reasonable guess or know where to find the answer. If the candidate submitted a portfolio, you can ask leading questions about the candidate's work: why did you do it this way? What were the tradeoffs if you had done it this other way? You also want to make sure the candidate does something small right there in your office: write code for a merge sort, for instance.

Third, you want someone who fits with your company culture. If you're dominant and want people to follow your instructions, you don't want to hire someone who's always questioning authority. No matter who's right and who's wrong, you'll both have an unpleasant time of it. If you expect people to wear business casual clothes and be punctual, you don't want to hire someone who's the most brilliant programmer in the world but who never gets in before 10:30 am and only owns one shirt with a collar. If the candidate is a poor fit for the culture, the candidate won't perform anywhere near his capacity.

In particular, the difference between a supremely productive programmer and a loafer is often the environment the person is in. Put someone who isn't punctual or a sharp dresser in a culture where he is expected to be at his desk every morning by 8:30 in a jacket and tie, and he'll turn into a loafer out of frustration within a year. No test will identify that.

If you take a serious look at the constraints under which C was developed, the systems it was to be used on, and the problems it was intended as a solution to, you will see that it is most excellently designed.

Unfortunately for C, the constraints have changed, systems are orders of magnitude more powerful, and people have attempted to use C for many things it was not well-suited to.

I agree with this list - completely in spirit, though I'd probably recommend different languages in a few places - but I'd also recommend at least playing with a couple of "industry-standard" programming languages.

Playing with C++, for instance, especially after having used C and Java, will give you a better understanding of what not to do. And if you play with Objective-C for a while too, you'll see two ways of handling object orientation that are dramatically different: what seems like a minor difference makes for drastically different expressiveness and flexibility.

I'd also recommend picking up Perl, for a different understanding of what not to do. Ruby is at its core a reimplementation of the good parts of Perl, with inspiration from Python and Lisp, and it hits a very sweet spot as a result; Perl has a lot of good parts, but it has a lot of warts that seemed like a good idea at the time and have been preserved for backwards compatibility.

And one of the things that I've noticed is that Real Programming focuses on interfaces in a way that toy programs don't: in web programming, for instance, you're more constrained by the browser-CGI-server interface than anything else. In programming for platforms with GUIs, the learning curve is not the language you use but the API to the window system.

The value of learning all those different languages is not that they're immediately and obviously useful. The value is that each one has a different set of tradeoffs and assumptions, and being fluent in all of them will teach you how to think more flexibly.

Sure, a beginner should use a language where he gets feedback and support. But a beginner who aspires to be a real programmer rather than a 9 to 5 coder will need a much broader base of experience than he can get by only working in one or two languages, and understanding that sooner rather than later is key.

There are two fundamental problems here.

One is that the customer can't easily discern between a good company and an evil company without doing business with them. Once they hit a certain size and have a large enough customer base, reputation helps.

But companies that act in their own short-term interests without regard to integrity are likely to out-compete companies that try to behave ethically -- so all other things being equal, if a large company doesn't make a fuss about ethics and integrity, odds are it's evil.

The ethical company has the long-term advantage, but the unethical company has the short-term advantage. If the unethical company can use the short-term advantage to its benefit, it can build up enough of a business that it's hard to topple despite being unethical.

The second point is that the larger the company, the more its inherent trend towards self-serving (probably evil) behavior. Bureaucracies are inhuman, because the responsibility for the evil act or evil policy can always be passed on elsewhere or euphemized away, and a large number of problems turns into a statistic. One person screwed over by the company is a real problem; ten thousand screwed over by the company justifies the budget for the complaints department.

It takes a very principled, very public stand to avoid both of these problems.