> I also like people who get things done. If you’ve been working on your startup for two years and have nothing to show, that’s a pretty bad sign. I’ve discove

> I also like people who get things done. If you’ve been working on your startup for two years and have nothing to show, that’s a pretty bad sign. I’ve discovered that most people are really good at finding obstacles. "Obstacles"? Okay: I tried to install the Express (free but limited in the amount of data it would handle) version of Microsoft's SQL Server. After all the clicking for the install, which seemed to go well, the program would not run. Nor would it repair, uninstall, or reinstall. I had to reinstall the operating system on that bootable drive partition. Eventually I got SQL Server to install and run, wrote code for it, put data into it, etc. > Just get started and deliver now. ... An extreme example of this is, I wrote the first version of Gmail in a day! Write code quickly? Okay, I've done some of that: Back on OS/2, the e-mail program put one icon on my desktop for each e-mail message sent or received. It was also very slow for doing anything. Bummer. But I'd long since learned and used Rexx (the elegant IBM scripting language by IBM's Mike Cowlishaw in England) and C and had used both for TCP/IP. So, I got and read the basic IETF (Internet Engineering Task Force) RFC (Request for Comments) documents for e-mail and right away wrote my own Rexx code to receive e-mail. Less than a day. The next day I got a copy of a simple version of Sendmail and for sending e-mail had some Rexx code running in a few hours. For the sending, I also implemented, again with Rexx, a simple feature for nicknames for individual people and also for groups of people. I liked it. Since it was all command line driven, sending to a long mailing list was easy. Soon I found that I really should be able to handle base 64 en/decoding so wrote some C code for that. Less than a day. Worked fine for years. The user interface was my then and still favorite text editor, KEdit, a PC version of IBM's XEdit. But recently my motherboard got sick, and I have parts on the way for a nice, new computer. In the meanwhile, on my computer, dozens of times a day a Web browser at a site with a lot of JavaScript fails and a few times a day the operating system reboots. A few times a week I have to run the Windows CHKDSK on my boot partition. And the computer is so sick that Outlook won't install. Very sick computer: Problem seems to be on the motherboard between main memory and the processor. So, I got my old Rexx-C based e-mail going again for sending. My computer is so sick I can't run the C compiler for my old C base 64 code so found some clever, nicely fast Rexx code for that and am using it. But now also need to decode "quoted-printable" so I wrote some code for that in Rexx in about an hour -- works great! I don't have a copy of Sendmail, so for sending have started to use Gmail. Sorry, Paul, I don't like Gmail! At this point, I'm so close to having my new computer up and running, I'm reluctant to write my own code from the simpler RFCs for sending e-mail so will stay with Gmail for sending. I've written other code quickly: (A) FedEx was about to die due to the BoD afraid of the challenges of being able to schedule the fleet when the growth got up to the plans. I was consulting and teaching computing and computer science at Georgetown University so got a time-sharing terminal to IBM's VM/CMS, and, in addition to the teaching, learned CMS and its editor and scripting language, designed and wrote some PL/I (which I was already good at), joined FedEx, all in eight weeks. Soon VP Roger Frock and I ran the code, pleased the founder F. Smith and the BoD, and saved the company. (B) While in grad school, on a part-time job in applied math and computing, at one point the US Navy wanted an evaluation of the survivability of the US SSBN fleet under a special scenario of global nuclear war limited to sea. They wanted their results in two weeks. I worked out some applied math, designed, wrote, and ran the software, and delivered in the two weeks, exactly. Some of the math was some Poisson process encounter rate work from the B. O. Koopman, OEG-56 Search and Screening and some of the rest was on continuous time, discrete state space Markov processes subordinated to a Poisson process from Erhan Çinlar, Introduction to Stochastic Processes, ISBN 0-13-498089-1. from which I'd recently had a course. (C) For my startup, I wanted a good way to handle user session state. So, I wrote a session state server. Sure, Redis could have been used for that. What I wrote was so simple that it was less work than even reading the Redis documentation! So, I used de/serialization of class instances from/to a byte array sent/received via simple TCP/IP sockets and two instances of a Microsoft .NET collection class. The program is single threaded and uses the TCP/IP (first in, first out) FIFO input queue for synchronization. Works fine. That was about two days. Hmm ... If I have 10 Web servers but just one session state server, then I won't need user session affinity to the Web servers. But if I have 200 Web servers and one session state server for each 10 Web servers, then I will need user session state affinity to each of the 20 session state servers. Hmm, what to do? Ah, to each user HTTP GET request, in my HTTP POST response am sending an encrypted GUID value and get GUID value back as the key in the session state server. So, ..., maybe I should bury in the GUID an ID of the relevant session state server. Then let each of the 200 Web servers go for each user to the session state server being used for the session for that user. Then for load leveling of the 20 session state servers, if usage data shows that that is worthwhile, then once a minute or so broadcast new assignments of session state servers to the Web servers? (D) There was a sudden change in some banking laws, and a guy found a valuable optimization problem. He used simulated annealing, ran for days, and quit when tired maybe without a feasible solution or maybe with one but with no idea how close it was to optimality. I got involved. The first problem was 0-1 integer linear programming with 40,000 constraints and 600,000 variables. I did some Lagrangian relaxation derivations, wrote some Fortran code, called the IBM Optimization Subroutine Library (OSL), and in less than an hour on a 90 MHz PC got a feasible solution guaranteed to be within 0.025% of optimality, all in two weeks. But I can't always do things quickly: To learn Microsoft's .NET, I started with Jim Buyens, Web Database Development, Step by Step: .NET Edition, ISBN 0-7356-1637-X. which is beautifully done technical writing. Then for the rest I went to Microsoft's MSDN and started finding, downloading, reading, abstracting, and indexing Web pages. It took a while, longer than an hour, week, or month, but I got about 5000 such from MSDN and about 1000 more from elsewhere. That was about enough for my use of the .NET Framework, Visual Basic .NET (not the old Visual Basic 6.0 but close to equivalent to C# but with a different favor of syntactic sugar), ASP.NET for writing Web pages, and ADO.NET for communicating with SQL Server. That was an "obstacle". Sorry, Paul, such "obstacles" are just part of the work. For my startup, all the work uniquely mine has been fast, fun, and easy. I saw the problem, thought of a very different, new solution with new data and some original applied math for getting the results for the users from the new data, and designed and wrote the code. The code is several programs communicating over TCP/IP with 24,000 statements in Visual Basic .NET in 100,000 lines of typing (lots of documentation with the code). It all runs as designed and appears ready for production. The code does not need refactoring, and there was no prototype code or "minimum viable product" code. And, yes, the problem is one with no good solution but which essentially every user of the Internet in the world would like a solution on average a few times a week. So to a user, my solution is just a Web site. The monetization is via ads. So, sure, if people like my work, my little effort will be worth many times the $10 billion in the OP. Summary So, sometimes things are fast; and sometimes there are unavoidable obstacles.