> Wait, what? I mean, you can argue that they are
really bad and maybe you are right; I disagree, but
maybe I am wrong.

I need to get some code written and typed too
quickly, but basically I'm correct. So, need to
fill in dates on a resume. So, if have years in
grad school and some more years in a Ph.D.-only slot
as a prof, then how to account for that time on the
resume? If put in the truth, then won't get hired.
If just leave a gap, then won't get hired. If fill
in the gap with the jobs before and/or after the gap
or something else, then that's resume fraud.
Likely if just omit the Ph.D. in the section on
"education", then that's resume fraud much the
same as claiming a degree don't actually have.

> But until it's in the bag, guessing what is in the
mind of VC is... not something I'd bet money on.

It took me a while, but eventually I got a
reasonably good view of what VCs want.

For how I learned to do projects for the US DoD and
in grad school, the VCs know essentially nothing:
E.g., at one time I was programming in the group
that did the orbit determination for the Navy's
version of the later USAF GPS (my work was in
processing data for passive sonar), and I heard the
stories for how the Navy's system was developed.
Heavily the plan was a dressed up version of
something on the back of an envelope. The work got
funded, and has been a great success, from a
proposal just on paper. Good for the Navy and US
national security.

But VCs essentially won't invest in projects
described just on paper if only because they don't
even want to read the paper -- it may be possible to
get some VC seed funding just from paper, but that
seems to be recent. NSF and DARPA will read project
designs on paper, but the VCs won't.

What the VCs want for a Series A round is
essentially in one word, traction. Or traction
significant and growing rapidly.

At one point Menlo Ventures wrote me that the level
of traction they want to see is at least 100,000
uniques a month, that is, for a Web site project
100,000 unique visitors. Okay, consider 100,000
uniques, on average: Considering what my site does,
100,000 uniques would mean about 500,000 visits;
each visit sees 6 Web pages, with 4 ads per page;
and I get paid, in effect, $2 per 1000 ads displayed
(drawing from the Mary Meeker data at KPCB). Then
my monthly revenue would be

500,000 * 6 * 4 * 2 / 1000 = 24,000

dollars at which time no thanks seed or series A and
welcome some new computers and a new car! If the
site keeps growing, and once it gets to 100,000
uniques it should, start hiring and grow just
organically.

> Of course, you don't always need VC to run a
company.

Yup. My first server might be an 8 core AMD
processor at 4.0 GHz with maybe 32 GB of ECC main
memory and 12 TB of hard disk in a mid-tower case
for about $1500 and software, Windows Server and SQL
Server, from the Microsoft BizSpark program. From
my software timings, that server might be enough for
the $24,000 a month in revenue at which time I can
get a $100 wire rack from Sam's Club, put maybe 12
such servers on it.

My software is written for such
scalability now -- e.g., so far I'm using SQL
Server essentially only as a key-value store so that
each SQL Server table (there are only a few tables
in the SQL Server schema) can be in its own running
instance of SQL Server with no communications among
the instances; for the various servers, there can be
a lot of parallelism via sharding, etc.

E.g., I wrote my own session state store; the
timings indicate that on a single core running at
4.0 GHz I should be able to do the work needed to
send 2000 Web pages a second; such a store is easy
to parallelize (partition the collection of
possible keys and have one server for each
partition); and a few racks of such servers could do
enough for session state to serve the world and
build a big company.

For a seed round, that now can be as high as a few
million dollars and no longer limited just to, say,
$200,000, the VCs want to see the running software
and "play with it".

So, soon, maybe later today, more likely before next
Sunday, my software should be ready to be played
with over the Internet.

This software development has taken a while as I
learned enough about essentially system
administration and Microsoft's .NET Framework to
get good with such infrastructure. For the .NET
Framework, I found, downloaded, indexed, and studied
about 5000 Web pages from Microsoft's MSDN Web site.
Yes, my code is awash in comments with tree names on
my file system of such Web pages. So, when I'm
reviewing code and have a question, e.g., a TCP/IP
timeout parameter, one keystroke in my favorite
editor pops up the relevant MSDN Web page. In the
end, I have found the .NET Framework to be nice, but
the 5000 pages took a while.

I actually studied all those 5000 pages; at 10 pages
a day, that's 500 days just for the MSDN Web pages,
and in the end I spent more than that.

Heck, I did the research for my Ph.D. dissertation
independently in my first summer in graduate school,
about 12 weeks, did a second pass later in about 2
months, wrote and ran some illustrative software in
about 2 months, and did the final writing and typing
in about six weeks. Those 5000 Web pages from MSDN
mean that at times I have been known to scream to
the point of a sore throat at what I regard as some
really poor technical writing at MSDN.

In the end, once understood, the .NET Framework is
nice and not very difficult to use, but going from
the first day with .NET, through 5000 Web pages and
maybe a cubic foot of books to some good facility
can be a bit much.

My whole project is now a surprisingly large number
of lines of code (maybe I will add them up
tomorrow), but the work unique to my project was
easy once the system administration independent of
my project was done. E.g., SQL Server installation
was an unanesthetized root-canal procedure (once
wiped out my boot partition). My software
installation got wiped out by a virus in an Akamai
download manager I used to get a PDF file from an
Asus Web site. There were more such problems, all
independent of my work.

For my project, I created and derived the basic core
applied math in a few days and typed it into Knuth's
TeX in a few more days; the software unique to my
project has been easy for me; but the routine
software part has been grim.

The last thing I did, as of last night, was finish
the code to have the code of a Web page communicate
with a server, in my architecture, a Compute
Server, for the core work. So, it's a simple
TCP/IP socket application. .NET streams over
TCP/IP might have been easier; maybe I rewrote some
of that functionality.

I avoided such streams because the MSDN
documentation seemed too sparse to give me good
confidence in what I really might encounter and have
to consider, and I didn't want to write and run test
cases to clarify just what such streams would and
wouldn't do. For what I did write, based just on
the basics of TCP/IP sockets, "the workhorse of the
Internet", that I've had experience with for a long
time, there was little question about how to write
the software or what it would do. So, it was easier
just to stand on basic TCP/IP than to make sense of
Microsoft's documentation of the streams they
wrote to use TCP/IP.

I put the data to be sent to/from the server code
for a Web page and one of my compute servers in an
instance of a class, serialize the instance to a
byte array, and send the byte array via TCP/IP.

> It was actually easier for me to get another
well-paid SysAdmin job than to get a job at wal-mart
or the coffee shop, even at the depth of the dot-com
crash in 2001.

Wow, but I can believe it.