Autobiography: As Problems Arise

Fri, 23 Dec 2022 21:47:40 GMT

Early Years
I became interested in natural language processing (without really knowing what the field entailed) in elementary school when I tried out AOL Instant Messenger (AIM), shortly after it was released circa 1997.

I was quite introverted and asocial growing up (ok, this is an understatement) and the idea of being able to cherry-pick friends based on the types of conversations I liked to have and being able to leave a conversation at any time (and for this to be commonplace and socially acceptable) were attractive to me.

But what I really loved was the idea of chat rooms. Watching how people interacted, what conversations worked, which caused people to get upset, which caused people to laugh.

For any who remember how AIM's early chat feature worked, you clicked a button to start a chat, it pre-populated a unique room ID, and you had the option either to rename the room, or enter the chat. I remember thinking this was odd and vividly remember one (entire) day making it a priority to type in all the common room names I could think of to see what happened. One of the first I tried was "friends". Low and behold, I was in a room with a handful of people who were very confused as to why I had just intruded on their private chat. But amazingly, it seemed almost okay. Some thought it was weird and bailed. But many others were intrigued to meet a digital pen-pal. It's almost as if we were occupying public domain together. After a great conversation, I had suggested we keep the chat open and check back every few days.

or months, I more or less lived in that "friends" chat room and started inviting what few other friends I had to it. I looked for other ephemeral rooms on AIM and invited the people I found to join the "friends" room as well. We quickly hit a limit of ~32 people. When one room filled, a few of us would create another one: There was "hi", "hello", "hey", "chat", "chat2"... and so on. Over the few years, the use of these unofficial AIM chat rooms really took off, many with themes and unique micro-cultures. It was like a mini-revolution; gosh it was exciting.

Middle School

But nothing as exciting as when I saw the first “scrambler bot” -- an AIM account controlled by a robot -- which initiated a game of word unscramble in the "friends" chat room. I had been learning qbasic, html, and introductory java at the time and I immediately asked the chat how the thing was working and who programmed it.

The whole scene exploded into a massive game of augmentation and creativity. People who write bots to flood chat rooms and take them over so people couldn't organize with their friends. People who write tools to ban users. Instead of video games, it was its own version of war games. I remember being especially inspired by a friend "Mike311211" (a Disturbed (band) fan) who created his own complete instant message client called Disturbed AIM.

Around middle school, it became instantly obvious to me that there was an unparalleled opportunity to bend and augment the very fabric of the medium through which communication was occurring. There was a "magic" middleware in between me and them and an opportunity to optimize the very idea of communication, to enhance it.

Up to this point, programming had mostly been a curiosity to me, but this got me serious about programming. I wanted the ability to protect the chat rooms I was in. To enhance them with features. To fundamentally push communication to the limit and redefine the paradigm beyond chat messages. AIM, Google, and then Wikipedia quickly became my favorite tools on the web and I started learning how to write bots to combine them using the TOC/2 protocol, which I learned from others in AIM chat rooms. I started writing a bot (much like the ones on IRC) to automatically save logs of various chat rooms so I could read them later. There was an "ego" log which listened to all the chats for when my name or screen name was mentioned. The bot responded to simple queries, like, "when was I last mentioned". It was like social network notifications before such a feature was mainstream. Of course the bot allowed me to evaluate simple math expressions and programs by forwarding them to Java.

Every summer for years, I would spend weeks at a time at Fairfield University for National Computer Camp to learn how to use new programming languages. I met all sorts of interesting and smart people like Katherine McCusker, this awesome dude named Tal (someone should help me re-discover) who had a shaved head but for an epic front-facing rat tail. I spent my next five or so summers this way, learning c++, Unix, A+ certification type hardware stuff.

I quickly became infatuated with the ideas of chat systems, search engines, human-computer interfaces, computer-assisted experiences (e.g. artificial intelligence), free software & hacker culture, and platforms for mass-collaboration. Around this time I learned of IRC and was becoming aware of what others were programming bots to do in more sophisticated settings and what was possible. What I wanted was a bot which could enable advanced search. The ability to research collaboratively with friends and to integrate chat with search. To create something like IBMs Watson.

By freshman year of high school, I was convinced I wanted to try two things: to do graduate research at a university and to try starting a company.

GNUAsk

I began turning my chat bot scripts into a conversational search engine called GNUAsk. GNUAsk was intended to be a free, open & privacy-centric, experimental/alternative search engine (like Duck Duck Go). One could GNUAsk questions like, “When did Michael Jackson die?” and then (kind of like clippy) GNUAsk would provide answers but also ask/predict clarifying questions based on how similar conversations had proceeded, like: “I think you mean Michael Jackson the singer, who died on June 25, 2009. Did you mean Michael Jackson the actor?”. It excelled at helping one refine the accuracy of one’s current search (during a time when people had to be “good at Googling”) and even guide one deeper in new unexpected directions. The path of your conversation would then help strengthen the path, experience, and recommendations of other researchers. In its simplest form, GNUAsk was a question answer system like Quora.


To set the stage, at the time Google search didn’t have zero-click Now cards powered by its Knowledge Graph or contextual hysteresis (i.e. you had to be good at searching because Google couldn’t yet predict your intent from previous queries). That is to say, Google search didn't have hysteresis/context-sensitivity, so one had to tune searches dozens of times in order to get a right answer. Also, searching only seemed to happen on a single website. I believed web searching should happen anywhere – within a microsoft document, in a chat with a friend, even in a text file or the command line. I believed that everyone’s search history should be able to be anonymously combined to help carve paths through the information landscape like a stream corrodes paths through bedrock. I also believed that searching shouldn’t be a discrete 1-off event, but a process, a trail, or a conversation that builds understanding over time. And that everyone’s conversations or paths through knowledge should work together to help beat trails and navigate problems as we think together. I didn’t want someone to share a website or a google search term which dumps me into a sprawling list of unvetted websites, I wanted someone to share a journey with me (which I called a GNUrl) which showed which directed route they took, which questions they asked, which landmarks/pages they stopped at, which were most useful, and what conclusions they reached. That is to say, I found (and still find) dozens of aspects inadequate about Google’s search experience

 

How did it work? GNUAsk (the aspirational, mostly unreleased search engine UI) relied on hundreds of bots, running as daemons, and listening in on conversations within AOL AIM, IRC, Skype, and Yahoo public chat rooms and recording all the textual conversations. The bots listened for questions, tried to provide answers when asked, and even inferred answers from other participants in the chat room. It relied heavily on dozens of APIs or scraping web pages like Answers.com, Wikipedia, (eventually Duck Duck Go).


I started to write primitive algorithms to determine which sentences typed by users were questions and, much trickier, if users were writing answers in the chat room. The approach that seemed most reasonable to me was prompting chat room users with additional validation questions like, "did what user X say answer your question Y, Z?". Of course this was abused and error prone.


By the time I went to college, I had gigabytes worth of associated textual questions and answers, a good number of which were flagged as “verified” based on feedback from people in chats. By now, Wikipedia had become a thriving and invaluable resource and I was starting to learn about markov chains and methods for generating text based on corpra. The pieces of GNUAsk would become the focus of my graduate school application. It would be another five years before I’d learn of Vannevar Bush’s landmark 1945 Atlantic essay, “As We May Think”.


College

I loved my college experience. Because I spent so much of my high school learning independently and avoiding the people in my school, my grades were quite average. I went to the University of Vermont (UVM), a lower-stress school which I didn’t find super demanding. This was perfect for me because I learned when I feel free, I love rising to the occasion and feeling like a big fish in a smaller pond, gobbling up unconventional ways of learning. I helped Peter Hurd write a Lego Mindstorm Robot called BRIAN (Basic Reconnaissance Independent Accurate Navigator) which uses genetic algorithms to find and pick-up trash. I took a special topics class with Jeanne Douglas where I saw this tech talk by Luis Von Ahn (co-creator of recaptcha) and learned about the idea of harnessing human computation, which completely changed how I thought about computer science. I participated in a team which helped build a UVMonopoly game. I did independent basic neural net research with one of my favorite researchers, Dr. Josh Bongard. I learned a lot in classes, and learned even more outside of classes from world class graduate students like my mentor Dr. Gary Johnson and professors who I’d spend time with during office hours. I even helped create this incredibly embarrassing UVM hacker spoof of Lord of the Rings.


I spent the vast majority of my time helping build a hackerspace with Robin Wilke, Jonathan Godbout, Dillan, Chris Tucci, Andrew Guertin, Gary Johnson (who has been a life long mentor of mine, and one of the most brilliant people I know), Stephen Balaban, Alex Munkelwitz, Abe Barth-Werb, Jacob Beauregard, Evan Yandell, Zack Ney, Evan FlynnTenzin, Phelan VendevilleEthan EldridgeMike TorchioLeif K-Brooks, and a handful of other amazing personalities. Our student-run hackerspace, the CSSA (Computer Science Student Association), became so popular (~10% of the department) that students began skipping classes to hear grad students talk or to work on independent projects in our lab (building beowulf clusters, debugging x11 intel graphics chip problems, linux from scratch). The department ended up letting me and Dr. Gary Johnson co-teach a class for 3 semesters (we donated our proceeds to buy pizza for every class and it was insanely popular) and we arranged guest speakers from industry, had professors and grad students talk about their research, arranged hands-on projects, and taught less covered material, like version control, tail call optimization, and recursive trampolining in clojure. During my summers I worked for a small wireless sensor company called Microstrain, building configuration web dashboards using Aaron Swartz’s web.py and helping design secure initialization/pairing handshake sequences between devices. I met quite a few local people from the industry. Throughout my four years at UVM I learned a lot, felt like we were helping the community, and got positive feedback from professors (I received the department ACM faculty award some 3 times and was asked to be part of a committee which helps inform the university’s curriculum).


I did almost get expelled on five separate occasions, by accidentally kicking Xindong Wu the head of the CS department off his static IP (what are the chances), accidentally taking down uvm.edu’s edora web server by using a grad student’s directory permissibly set to 777, getting caught up in another CSSA (Computer Science Student Association) member’s rainbow table experiment (he was taking Ling’s security class with me) which discovered a network on campus was truncating DES CBC passwords to 8-characters, noticing that local make alt-installs were allowing students to bypass many of the university’s security policies, and helping reverse engineering the business school’s Trans-Lux stock ticker to print, “Zombie alert in effect”. In each of these cases I worked incredibly hard with an abundance of good will to remedy the situations, detail vulnerabilities, propose solutions, and offer apologies. Thank you for these learning experiences and letting me graduate.


From Research to Entrepreneurship

I applied and got in to UDel and Cornell with an application essay about my search engine. In 2010 I started a PhD program at the University of Delaware hoping to continue working on my search engine. I love learning, researching, and teaching, so in some ways grad school was a dream. But my experience ended up being a slog for two reasons, one circumstantial and the other fundamental to the industry. Circumstantially, one of the reasons I chose UDel over Cornell is I found a semantic web professor who seemed excited to help me continue my high school research. But when I joined the program, I learned the professor had decided to go on prolonged sabbatical, leaving me without an advisor to sponsor my work. So instead, I took an offer to help the Software Verification Lab, which had a great advisory team but was a complete departure from my passions of AI/NLP. The second problem though was fundamental: for me, research requires a certain type of patience for theory – an indefinite gritting of one’s teeth and biding of one's time, bound by the open-ended processes of discovery and not market need.


With markets, one may collect more data, talk to patrons, refine a toolkit of tactics, grow a distribution channel, and pivot in any number of directions and magnitudes until there’s a fit. In research, one has no guarantee of achieving a positive result. And if one does, one may discover an amazing, true, positive result and still not usefully manifest the concepts until someone discovers the right application and takes the idea to market. My ideal research lab experience would have been one like Louis Von Ahn’s (recaptcha, ESP, duolingo) which develops at the intersection of theory and application and becomes stronger over time (e.g. grows distribution channels), even when one experiment flops.


Aside from the circumstantial subject matter and the indeterminism, there was also a matter of the process and inequity. As a researcher, I was typically working by myself, in a sterile cubicle, working on fairly demanding math and software architectures, with no carrot at the end of the stick: researchers often receive hardly more than a stipend as compensation, researchers are typically pressured to hand over copyright of their papers to prominent (exploitative) research journals, and (because the lab cared more about the means than the ends, the implications of the research were unclear to me and so) I personally was given few reasons (other than presumed intrinsic drive) to care if my solutions worked. I care more for collaboration and seeing solutions help people in practice than I do the glory of solving an obscure problem. So after months of my dear undergrad friend Stephen Balaban encouraging me to join him on an entrepreneurial journey, I put my PhD research on hold to explore entrepreneurship, to grow as a software engineer, and to gain experience managing projects.


What was wrong with research?


On Being a Co-founder

The opportunities in entrepreneurship seemed so much more real. There were customers, competitors, venture capitalists, the media, lawyers, prospective talent, and potential business partners all playing different roles and offering their own perspectives on the same game. Research remains an important part of this process, but a much smaller piece of a larger stakeholder pie. Experiencing this zoom-out was refreshing.


The company that Stephen and I worked on in 2011 solved a real problem which Gumroad (our main competitor), Shopify, and others now predominate today. Leading up to 2010, selling digital merchandise online (e.g. self publishing, art, music, courses – today may include NFTs) was non-trivial for the layman. One needed to know how to build a website, which means one needed a domain and hosting. One likely needed a way to securely store and fulfill the digital products, a shopping cart for managing the customer experience, and payment integration. And then of course, there were affiliate systems, newsletters, and other aspects which were integral to distribution and sales. This likely meant one was dealing with paypal/stripe, clickbank, ejunkie, godaddy, linode, and wordpress. Because the process was so technical and involved, it was only accessible to people who both had digital products and the technical know-how to string these technologies together into an online storefront. In our case, that was Stephen.


Something that was great about this business is (a) Stephen already had self publications he was selling elsewhere online and (b) others like him who already had existing products and storefronts were willing to try something new if it meant more sales. So we spent about six months building the basics of a marketplace which would allow any customer to manage their own storefront, complete with a shopping cart, checkout & fulfillment process, and affiliate system. Then we started finding existing sellers with followers who wanted to dominate this new marketplace. We made it turn-key – as easy as dropping a file onto your browser – to create a new store.


Technically, the platform was good and solved a real problem. Our experience and service design were not great, especially compared to Gumroad which launched the same day as us. Looking back, it’s obvious we should have kept it simple and developed features in response to problems as they arose (which is how we knew to focus on payment integration). We probably could have gotten away with not having shopping carts (or bags, as we called them) at first, too. Gumroad was smart because they focused on a much easier vision, making the storefront possible and then letting store owners self-promote. We on the other hand had committed to a marketplace rather than recognizing sellers intrinsically had incentive to promote their content; they just needed the technology.


During this time, Stephen and I built technology, spoke with and onboarded content creators, drafted terms of service, spoke to lawyers, incorporated our business, handled our accounting, presented at events, pitched incubators and VCs, and tried to recruit others at hackathons to help us build. Hindsight is 20-20; we may have benefited from more design input, keeping things simpler and building only what was needed very well, more time speaking to sellers, more focus on specific domains, and likely being more flexible to secure early opportunities that came along. I’d describe our project management style as, “flying by the seat of our pants”. We built what we knew we had to build and then built the things we thought would have impact, before trying to test our hypotheses and seeing how good our core technology was at solving sellers' pain points. By working six days a week or more, fourteen hours a day, teaming up on skype video calls and pair programming using gnu screen and tmux (and then eventually living together), we got an incredible amount done. We both seemed to have a shared sense of what needed to be done and how, we had so many different hats to wear and responsibilities to cover, and we were so in-sync, that we rarely had anything like a roadmap meeting for tech or features.


On Being Engineer #1

About six months in, we got rejected by YCombinator, got provisionally accepted into Angelpad and received interest from WIN (both which ended up not panning out), and then got a chance to meet with Paul Graham. PG suggested we talk to Hyperink.com, a Winter YC 2011 high-tech publishing company that had a track record for producing great content and a need for scaling their process with technology. A few months later, Hyperink acquired our company and I went on to build out Hyperink’s online platform, hyperink.com, based on my previous learnings. Several things were good about working for Hyperink. Kevin Gao was good at making deals happen, coming up with vision, and including me and Stephen in planning and advisory meetings. I had a lot more time to focus on product and learned from Matt Lee about how to engage with designers. I continued to work way too hard (especially given the incentives) and ended up getting really sick on several occasions. But I also gained experience proposing and conceptualizing features, growing an engineering team, and making decisions with people who had spent more time in industry. Soon Hyperink was up and running, with simple and beautiful designs by Holger and others, and before I knew it we were generating ~$1M a year in revenue. We had a “cha-ching” bell that rang every time a sale was made and we eventually had to turn it off because it was happening too frequently. I learned the importance of targeting content whales as partners (who already have strong distribution channels), the critical importance of appearing organized and on the same team during advisory meetings, how to organize a recruiting pipeline and interview, how important division of labor is (being able to rely on others who are very good at their parts of the puzzle), and what’s possible with the extra bandwidth of not having to do everything alone.


At the same time, experience is what you get when you don’t get what you want and I got a taste of being both a founder and a founding-first engineer with little compensation to show for incredibly hard work.


3 More Years in Early Stage

As Hyperink struggled to raise a Series-A which the founders felt okay with, I was looking for an opportunity to join an early stage company at the next phase of its journey, to see what it was like to grow a team from ten to fifty. I spent a short stint as the VPE and then, shortly after when the just-hired CTO left, as the interim CTO (which may tell you something) at Ark.com which I’ve decided to skip from the story. Needless to say, both from my experience at Ark & Hyperink, I noticed a trend towards online-first work and remote teams. We had spent hundreds of thousands of dollars both on remote engineers and content creators, editors, and designers. So in 2013 I started a second company, Hackerlist. If Amazon’s Web Services was a dashboard for spinning up compute resources on demand, the Hackerlist network (and its platform Upscale) was a way of spinning up elastic teams of expert AI researchers and software engineers. We were about five years and a pandemic too early, but still in the first six months of operation me and my co-founder Andrew Valish had pulled in a quarter of a million dollars in revenue, with almost a million dollars worth of job postings in the marketplace.


Lots of things went right. Lots of things went wrong. We went through many, many iterations of products. The products were too futuristic and not focused enough. We prototyped at least 5 different experiences which could have been completely different companies and even tried to connect some of these prototypes rather than just choosing one. We also underestimated how long it takes to vet talent, how important sales is to a business like ours (we hired our sales lead way too late), and by far most importantly, neither Andrew nor I were in love with the idea. We just knew it was the future. Each month I would review our finances, amortize our victories, and we had legitimate 30%+ month over month growth. We were finding amazing clients, including a handful of YC companies, and we were earning enough money to grow our team to six people. Because we were bootstrapping and looked like a consultancy, VCs seemed to want us to stay that way and didn’t want to fund us to build the forward-looking developer experiences that github and upwork are starting to provide today. When we finally got funding offers, I think Andrew had hit his limit and our bank account was close to the wire because we had been re-investing our revenue paying our teammates and building the product alongside coordinating (and even participating in) contracts. The platform is still (maybe even especially) a good idea today, but it was early at the time, should have been more focused, and needed to be funded as a venture backed effort rather than on the back of a consultancy.


One of the problems with startups is they move so quickly and, early on, are so dependent on either a source of revenue or funding, that it’s incredibly hard (and actually even more important) to build a (focused) roadmap. Experience really makes a difference once you’re in the racecar and start seeing problems fly at you. Having seen the obstacles before shock you into knowing when you’re losing focus, when you may need to pivot, when danger is coming, or how to handle a difficult situation. Having a good roadmap may give you a chance to premeditate, stay focused, and avoid some of these risks, but eventually (if what you’re doing is working) the car will begin to move so fast that you’ll need some type of intuition or experience (or be surrounded by people who can contribute these things) in order to stay on the track. Otherwise, you’ll spend as much time trying not to burn through money, addressing customer complaints, and dealing with retention than growing a culture and building a product that people love.


During this period, my personal hero Aaron Swartz had paced away. And I was forced to reflect on the fact that someone who stood for my values was no longer around, and paradoxically, no one seemed to be filling his place. And I had just spent several years working on yet another startup that didn’t align with my passions, in the pursuit of gaining experience and confidence that I was capable. I spent most of 2015 reading, writing, and working on side projects to figure out how I could reconnect with my values, fill the gap in my heart, and do something I felt mattered. This included fostering a community called Archive Labs to help increase communication among open source folks & volunteering at the Internet Archive on Aaron’s Open Library.


What’s wrong with entrepreneurship?

  • The customers (or profits) are always right

  • Winner takes all

  • Sociopaths win

  • Fundraising pitches

  • Exploits customers and staff rather than researchers

  • Does what’s possible, not necessarily what’s right

  • Produces externalities, reaps commons


What are the alternatives? Galen Mancino recommended Reinventing Organizations (2014 edition) | Open Library.


Nonprofits & Growing Pains

This brings us to 2015 where I'll continue my story when I have time. For the impatient, one may read my notes here.



Tags: Phelan Vendeville, DES, Paul Graham, tmux, java, 1945, Evan Yandell, Autobiography, Kevin Gao, markov chains, Robin Wilke, Chris Tucci, Angelpad, Google, qbasic, CSSA (Computer Science Student Association), Vannevar Bush, IBMs Watson, Xindong Wu, 1997, Atlantic, VCs, recursive trampolining, Stephen Balaban, free software, Evan Flynn, GNUAsk, artificial intelligence, Leif K-Brooks, IRC, Louis Von Ahn, Zack Ney, Dr. Gary Johnson, Trans-Lux stock ticker, human-computer interfaces, Alex Munkelwitz, Disturbed (band), Mike Torchio, Gary Johnson, Ethan Eldridge, Gumroad, Skype, Yahoo, Andrew Guertin, recaptcha, GNUrl, c++, hackerspace, Jacob Beauregard, Duck Duck Go, tail call optimization, Wikipedia, web.py, University of Delaware, duolingo, Dr. Josh Bongard, Microstrain, Aaron Swartz, YCombinator, clojure, Quora, Hyperink.com, NFTs, Unix, A+ certification, Jonathan Godbout, natural language processing, Abe Barth-Werb, AOL Instant Messenger (AIM)