Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Save jesperfj/d2bfcb5b68e8b356c1e380692a5f9d1e to your computer and use it in GitHub Desktop.
Save jesperfj/d2bfcb5b68e8b356c1e380692a5f9d1e to your computer and use it in GitHub Desktop.
My Heroku values

Do it with style

Just because we're building bad-ass infrastructure and tools doesn't mean it can't be cool, stylish, and fun. Aesthetic matters. See The Substance of Style

Slick and fun meets powerful and serious.

Before Heroku (and a few others, like Github and Atlassian), developer-facing products were almost always stodgy, ugly, and completely lacking in style or fun.

We're part of the consumerization of IT.

Intuition-driven balances data-driven

Hunches guide you to places to create new value in the product. Users don't really know what they want. Creating products people loves requires treating product development as an art, not a science; but products have to solve real user problems. Understanding impact of product changes to existing product is best done by mining the data. When you have a mature product and many users you have lots of data on how they are using it. Use that data to make evidence-based decisions.

See: Inspired: Created Products People Love

Design everything

Be intentional.

See:

Interfaces matter

Everything has an interface. A platform has an API. A computer has a keyboard, a mouse, and a GUI operating system.

Teams have interfaces too. How do you file a bug or make a request? Where and when does the team collaborate with any other team?

The two critical components of a good interface are that it be narrow and well-defined.

For example, the add-ons API is extremely narrow. Add-on providers only need implement two calls: one to provision a resource, and one to consume it.

The add-ons API is also well-defined, with an API spec and the kensa tool which runs a live test to verify the correctness of your implementation.

A poor interface is one that is wide and poorly-defined. For example, the way that apps interact with the operating system in traditional server-based hosting is poor. The number of ways the app can interact with the operating system -- system calls, libc, the entire filesystem, executing binaries in subshells -- is essentially infinite and impossible to specify.

See: Explicit Contracts

Names matter

Think careful about how something is named. Pick exactly one name for each concept the user needs to track, and use it consistently. For example, add-on providers are always called providers, never "vendor" or "partner" or anything else. Writing a glossary can be a good way to design the vocabulary around something.

Maniacal focus on simplicity

There is no step 1.

CLI 4 LIFE

Web UIs are great for many things, but command-line interfaces are the heart of developer workflows.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment