DEV Community: Jacob O'Bryant

What I've learned since quitting my job

Jacob O'Bryant — Fri, 15 Nov 2019 17:11:27 +0000

I got my bachelor's degree in 2017 and then worked for a year as a software engineer. Last January I quit and began working on a startup full-time with a friend I met while in school. I realized after a few months that we weren't a good fit as cofounders, so I bailed. I then spent some time trying to figure out what to do with my life. In June I decided to go all-in on my current startup, Lagukan.

Several days ago, I discovered a potentially critical flaw in my startup idea. I might need to take a major change of direction (though I'm thinking of moving to an idea that will still solve some of the same problems). This kind of thing has happened to me quite a lot in the past year, so I thought I'd take this opportunity to do some introspection before I go head-down coding again.

So, here are a few of the things I've been thinking about.

Spotify is actually pretty good

I've been in love with music since I was about 12. I started using Pandora while in high school. I discovered a lot of new music that way, but it was far from perfect. It was never able to fully adapt to my preferences (e.g. I love melodic hard rock and hate metal, a distinction that was utterly beyond Pandora), and it tended to play the same things over and over.

I started doing music recommendation research while in college, culminating in a prototype that played from Spotify and my MP3 collection but used my own custom algorithm. It was nice, although it left a lot to be desired. I later tried using vanilla Spotify for a while and wasn't super impressed.

Hence, I eventually decided to pursue my recommender system project as a startup (Lagukan). It seemed like a natural choice. I was encouraged by the response on Hacker News to my first prototype. Here's a snippet from one of my favorite comments:

Oh man... I haven't been able to find any recommendation algorithms that recommended songs I liked even 1% of. Spotify's is a trash fire. Last.fm's wasn't great. Pandora is okay.

Pulling off a successful music company has been historically pretty difficult, but I was alright with that since I was working on something that was deeply meaningful to me.

One of the most important issues in music recommendation (and more generally, in reinforcement learning) is balancing exploration (trying out new songs) with exploitation (playing songs you've listened to before). Lagukan has two separate algorithms for these tasks plus a parent algorithm that decides which sub-algorithm to use at any given moment. It's a delicate balance. Back when I was a Pandora user, they only really addressed exploration. Spotify seemed to have the opposite problem of doing too much exploitation.

However, I've slowly realized that I was likely just using Spotify wrong. I've always had the assumption that a music player should be totally automatic: just hit play, skip what you don't want to hear right now, then the algorithm should do everything else. That's how I've built Lagukan, and that's how I tried to use Spotify—I almost exclusively listened to Daily Mix.

This is a long-winded way of saying "I should've been using Discover Weekly."

I had read several comments on HN saying that Spotify performed much better if you listen to Discover Weekly consistently. It makes sense—that's their solution for those who want automated exploration, and Daily Mix is for exploitation. Sure, it's not all wrapped up into a single totally automatic algorithm, but the overhead is pretty low.

I've been using Spotify directly for the past few days, and it's been disturbingly effective. It's been seeded by Lagukan's exploration from the past month or so, but I'm going to try using just Spotify for several weeks and see how well it does. I'm open to the possibility of not needing Lagukan personally.

Even if Spotify turns out to work well for me, there likely are other people for whom a better recommendation algorithm would still be valuable. But if I'm not one of those people, then I don't think I'll be able to generate the insights needed to help them.

You should be comfortable with cutting your losses

It sucks to put five months into a startup built on a false hypothesis, but it's better than sticking with it and running out of savings. I'd say it's also better than never taking the leap at all, because the losses often aren't.

For one, my skills have grown far faster than they ever did while I was a student or an employee. I've been able to learn everything I wanted to in college but (ironically) never had the time for due to coursework, and I've discovered plenty of things that I'd like to dive into more. It's the most freeing educational experience I've had since I was a homeschooled teenager. I've also learned quite a bit about the industries I've been trying to enter, not to mention the emotional dynamics of not having any external validation from being an employee or a student.

Despite failing over and over in the past year, I don't see any of it as a waste. It feels more like do-it-yourself grad school (minus the degree at the end). I don't think any other path would have been as good of an investment in myself.

About three months ago, I started to get another idea for a recommender system startup that I actually think is more promising than what I've been doing. I stuck with Lagukan because I didn't want to get whipsawed, constantly switching ideas before getting traction. Even if I do ultimately decide to relegate Lagukan to side project status, maybe my work will turn out to have been optimal: I wouldn't have had this second idea if I hadn't dug into music recommendation.

What about giving up too easily? You certainly shouldn't do that, but if you, in your heart, no longer believe in the idea, I think that's a pretty good indication that it's time to switch. I've been through many discouraging experiences with Lagukan, but this is the first time I've seriously doubted the validity of my core value proposition.

It helps to articulate what you want to get out of your career

I'm a huge fan of Paul Graham. I stumbled on his essays while in high school; it was the first time I ever heard about startups (and Lisp!). I like to think I'm still as ambitious as 15-year-old me reading his essays for the first time, but actually trying to start my own business without giving up requires that I understand why it's worth my time.

First of all, I have to be a startup founder because right now there are certain things about the world that I'd like to fix, and it would kill me to spend my hours at a day job instead. But what else is important to me?

Working on my own projects. Even if I don't do it as a startup, I have to at least have lots of time for side projects. I love exploring and I'm a very self-motivated learner. I can't give up my freedom.
Working in Clojure. I was more language-agnostic when I graduated, but after a year each of doing Clojure and non-Clojure full-time, this is important to me.
Playing clarinet. I'd like to join an orchestra again, though I've put it on hold while I try to build a business. At some point I need to have at least an hour a day for practicing.
Teaching. This is another thing I love doing, and it's high-impact. At a minimum, I need time to write guides and tutorials regularly. (On the other extreme, some kind of education startup is my backup-backup-plan for Lagukan).

With all these demands, you can probably see another reason why doing a startup is so appealing to me: it'd be great to just make a lot of money all at once so I have freedom to work on whatever I want, regardless of if it's profitable or not.

But if I get through all my startup ideas and fail each time, what's next? If Stripe offered me a 30-hour-per-week position writing Clojure, I'd probably take it. Barring that, I think consulting is the most likely way to hit all the bullet points. I would be fine alternating between my own projects and clients' projects. (I've also thought seriously about grad school... but I've decided against it because I'm interested in design, not research.)

The result of all this pondering is that my decision to continue being a startup founder is based on careful reason, not emotion alone (I'm not a fan of burn-the-ships). I'm confident that if I come to a point where the rational thing is to no longer be a startup founder, then I'll do something else and still be happy. That understanding helps me to not get so depressed when bad things happen, which is important since startups run on morale. Knowing that there are other good career alternatives also helps with cutting losses.

Coming up

I've also developed my own opinions about cofounders, networking, idea validation, bootstrapping vs. VC... so let me know if you'd like to read a "part 2" of this article. Meanwhile I'll be building a prototype for my next idea. Fortunately, I should be able to release this one within a week or two. And if it works, Lagukan will likely make a good complementary product down the rode. I'll keep my fingers crossed.

A Brief History of Agile

Jacob O'Bryant — Mon, 04 Nov 2019 15:37:27 +0000

Originally posted on jacobobryant.com

"Agile" development was a peculiar sport played by "software engineers," a type of indentured servant who made their living by tapping buttons all day instead of taking up a real career as a doctor, a lawyer or an actual engineer. Agile was created as a form of entertainment for Scrum Masters, software engineers who had been given special privileges in return for keeping the others in line.

Like other sports of the time, Agile was divided into various phases of game play. Due to the indoor nature of button-tapping and the relatively low amount of energy required to do so, Agile was played year round. A 12-month season was separated into 4 quarters, each composed of 6 "sprints." Whoever scored the most points won the sprint, so each engineer's goal was to maximize the points they earned per day while minimizing the same ratio for their coworkers.

Engineers could score points by completing grueling tasks. These tasks were called "stories" to make them sound more fun. Each story was assigned a certain number of points at the beginning of each sprint through a ritual called "estimation." Each engineer would vote on a number of points for the story, and then based on the votes, the group would decide how many points each story would ultimately be worth. Before deciding on a number of points, each engineer would have to consider:

How hard the story was (both for them and for their coworkers)
Who the story would likely to be assigned to
How many points they thought the other engineers would vote on

Each engineer hoped to receive stories that were easy for them but still worth a lot of points.

This voting process was called "planning poker," so named because of the highly psychological nature of estimation and the large amount of bluffing involved. After the Scrum Master gave a countdown, each engineer would hold up a number of fingers equal to the number of points they thought the story should be worth. After removing outliers, the story was worth the average of the votes.

A basic strategy was:

Decide if you want the story to be worth many or few points.
Gauge how many points the other engineers will vote on.
Vote on a number of points that pulls the average in your desired direction without turning your vote into an outlier.

Being an outlier was very bad because it nullified your vote. In addition to eliminating your influence on the final worth of the story, nulls were considered unclean by many engineers. Nullified engineers were required to work from home for three days.

In order to further humiliate outlying voters, they had to give an impromptu explanation for why they voted so ridiculously. These reasons were expected to be related only to the difficulty of the story, providing outsiders with the illusion that estimation was simply part of getting the job done. But for insiders, the humiliation damaged their ability to influence other engineers in future estimations.

To heighten amusement for the Scrum Master, engineers were restricted to choosing votes that fell in a certain set of numbers called the "Fibonacci sequence," so called because the estimations were really just fibs.

There were many intricacies in planning poker strategy, most of which fall outside the scope of this article. But there was at least one trick taken from professional rock-paper-scissors tournaments: an engineer could pretend to vote at the same time as the other engineers but really wait a split second longer; thus they could see what the other votes were and respond accordingly. Only those with more experience employed this tactic, as penalties for being caught were severe.

After estimation was finished, it was a race (hence the term "sprint") to finish as many stories as possible while subtly hindering coworkers. One common tactic was to bring up "tests" right before a co-worker was about to finish a story. If the other engineers agreed, the co-worker would be forced to spend a day "testing" before marking the story as complete. During the test, engineers were buffeted by a series of impossible-to-answer questions such as "When will the current project be completed?"

Like the gladiatorial games, Agile was high stakes. Engineers who won the most sprints would be promoted to "Senior Engineer," "Epic Engineer," and finally "Manager." Promotions came with respectable pay increases but also tougher competition. On the other end of the spectrum, a chart was used to keep track of engineers who didn't finish all the stories they were assigned each sprint. This was called a burndown chart because if the line on the chart reached the upper-right corner, the engineer with the highest point deficit would be burned.

Eventually, engineers started to revolt and Agile fell out of practice. It was replaced by a new movement, the name of which was chosen to represent the end of the Agile burndowns: "Waterfall."

Learn Clojure with Web Dev

Jacob O'Bryant — Mon, 28 Oct 2019 17:17:04 +0000

Originally posted on jacobobryant.com

I've created this document so that I have a single link I can give people for learning Clojure. It is:

a work in progress
not meant to be comprehensive
opinionated/a reflection of how I do web development

I'm trying to help people get started without being overwhelmed by all the different options. I'll link to existing resources when possible, adding my own as needed.

Prerequisites:

basic terminal experience
comfortable with HTML and CSS
know a different programming language already

Hello world

First, install Clojure. Then type clj to get an interactive prompt ("repl," short for read-eval-print-loop). In the repl, type (println "hello world"):

$ clj
Clojure 1.10.0
user=> (println "hello world")
hello world
nil
user=>

Instead of using the default repl, you can get an enhanced repl like so:

$ clojure -Sdeps "{:deps {com.bhauman/rebel-readline {:mvn/version \"0.1.4\"}}}" -m rebel-readline.main
[Rebel readline] Type :repl/help for online help info
user=> (println "hello world")
hello world
nil
user=>

I recommend saving this as an alias, e.g. put the following in your .bashrc:

alias repl='clojure -Sdeps "{:deps {com.bhauman/rebel-readline {:mvn/version \"0.1.4\"}}}" -m rebel-readline.main'

Run from a file

I recommend starting out with the Atom text editor.[1] After you install it, create a new project folder. Within that folder, edit a new file src/web/core.clj with Atom. So your project folder should look like this:

$ tree myproject/
myproject/
└── src
    └── web
        └── core.clj

Put the following inside core.clj:

(ns web.core)

(defn hello []
  (println "hello world"))

(defn -main []
  (hello))

From the terminal, you can run the file like so:

$ cd myproject
$ clj -m web.core
hello world

Start learning Clojure

For actually learning the language, I recommend Clojure for the Brave and True. (It's available online for free at that link, though I liked having a hard copy).

You can skip chapters 1 and 2. Work through chapter 3 before going on to the next section in this document. Fairly soon, make sure you also understand everything in chapters 4 and 5. These three chapters contain the fundamentals of the language.

All of the remaining chapters are useful too. Make sure you understand them eventually. But for now, you can just skim them a bit and refer back as needed.

Start doing web dev

I'll now show you the first fundamental of web development: how to generate HTML and CSS. We'll create a static landing page. This is a great first project because it's pretty simple, and generating HTML + CSS is much nicer in Clojure than in any other language. You could even extend this project into a personal blog/website if you like.[3]

We need to add a library to your project. Create a file myproject/deps.edn with the following contents:

{:deps
 {trident/staticweb {:mvn/version "0.1.18"}}}

Change the contents of core.clj to this:

(ns web.core
  (:require [trident.staticweb :as tsweb]))

(def landing-page
  [:p "hello world"])

(defn -main []
  (println (tsweb/html landing-page)))

The tsweb/html function[2] takes a data structure that represents HTML:

$ clj -m web.core
<p>hello world</p>

We can add inline css like so:

(def landing-page
  [:p {:style {:color "red"}} "hello world"])

$ clj -m web.core
<p style="color:red">hello world</p>

Because we're using plain data structures for both HTML and CSS, we can use functional abstraction and other standard programming techniques instead of dealing with templating languages or preprocessors. (Hallelujah).

(defn p [color text]
  [:p {:style {:color color}} text])

(def landing-page
  [:div
   (p "red" "hello world")
   (p "blue" "goodnight moon")])

$ clj -m web.core
<div>
  <p style="color:red">hello world</p>
  <p style="color:blue">goodnight moon</p>
</div>

(Indentation added).

Let's make this a little more complete, and let's have it write the HTML to a file for us.

(def landing-page
  [:html
   [:head
    [:meta {:charset "utf-8"}]]
   [:body
    [:div
     (p "red" "hello world")
     (p "blue" "goodnight moon")]]])

(defn -main []
  (spit "public/index.html" (tsweb/html landing-page)))

Before running this, you'll need to create the public directory.

$ mkdir public
$ clj -m web.core
$ cat public/index.html
<html>
  <head>
    <meta charset="utf-8" />
  </head>
  <body>
    <div>
      <p style="color:red">hello world</p>
      <p style="color:blue">goodnight moon</p>
    </div>
  </body>
</html>

You can open index.html in a web browser now.

For interactivity, we'll add some plain Javascript. We could use Clojurescript, but it's overkill for simple things (in addition to increasing your payload size, using Clojurescript can be quite complex). You can switch to Clojurescript later when the time is right.

Add a button to the div element:

[:div
 (p "red" "hello world")
 (p "blue" "goodnight moon")
 [:button {:onclick "alert(\"spam eggs\")"} "click me"]]

Regenerate the HTML and test out the button before we move on.

Let's separate the Javascript into a separate file.

(def landing-page
  [:html
   [:head
    [:meta {:charset "utf-8"}]
    [:script {:src "index.js"}]]
   [:body
    [:div
     (p "red" "hello world")
     (p "blue" "goodnight moon")
     [:button {:onclick "doSomething()"} "click me"]]]])

Create a file myproject/public/index.js with the following contents:

function doSomething() {
  alert("spam eggs");
}

Regenerate and test it out.

Next, let's add some Bootstrap to make CSS easier.

(def bootstrap-4
  [:link {:rel "stylesheet"
          :href "https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/css/bootstrap.min.css"
          :integrity "sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T"
          :crossorigin "anonymous"}])

(def landing-page
  [:html
   [:head
    [:meta {:charset "utf-8"}]
    [:script {:src "index.js"}]
    bootstrap-4]
   [:body
    [:div.container
     (p "red" "hello world")
     (p "blue" "goodnight moon")
     [:button.btn.btn-primary {:onclick "doSomething()"} "click me"]]]])

Boom. Now you're all set to make a sweet landing page for your new product/consulting business/dog. I'll let you finish that on your own, but you can take a look at the code for my startup's landing page for inspiration (yes, this whole document is just an advertisement). You can put the public directory on any static website host. I use Firebase, but Github Pages and Netlify are other popular options.

The road ahead

I'll write more in the future, but next you should learn about Clojurescript and Reagent. (Re-frame is also common, but don't worry about that for now). Reagent is a wrapper over React that lets you use the same syntax for HTML and CSS that we've used here.

After that, it'll be time to get into backend development. I'll write about simple ways to get started with that, and I'll cover getting started with Datomic as well, a database that embraces functional programming concepts (made by the creators of Clojure).

I'll also give some tips for using the available Clojure tooling. For one thing, you should install the parinfer plugin for Atom (apm install parinfer). With parinfer, you don't need to type any closing parentheses. Just indent your code properly, and parinfer will infer the parentheses for you.

Notes

[1] I don't actually use Atom myself, but I recommend it here because it's a mouse-friendly editor that has working autoindent for Clojure out of the box.

[2] trident/staticweb is a simple library I've made that wraps Hiccup and Garden, allowing you to write inline CSS à la Reagent.

[3] This website is made with Hugo, but I've found it to be too inflexible. Eventually I'd like to do a rewrite with Clojure.