ReadMe

San Francisco, CA

  • Coding principles
    Ship first, refactor later, Everybody can push to prod, Bleeding-edge stack
  • Work/Life Rhythm
    Remote as needed, Massive impact == fulfillment, Do Not Disturb weekends
  • Modern Tech Stack
    AngularJS, ExpressJS, CSS 3, HTML5, JavaScript, Node.js, React

Our Mission

We're making documentation & APIs better for everybody. ReadMe gives teams the tools they need to create and manage beautiful documentation with ease, monitor their APIs, and connect with their users in more personal ways. We're a small team of humans (and one owl) working together to do big things. We believe in three principles for great documentation: 1. Show don't tell. I don't know about you guys, but when I go to a new page to use a new API I scroll down to find the code snippets, copy and paste it, if it doesn't work I tweak it a little bit and try it again. Then eventually if I still can't get it to work then maybe I'll read the documentation itself. And that's not a bad thing. That's actually great. They want to build something and they want to get past your API as quickly as possible. When you say you like Stripe or Twilio is another big one that people talk about. When you say that you really like one of these APIs you don't care about the API itself, what you really care about is building something cool. Rather than making people construct code samples in their own language and leave a lot to chance, because English is very ambiguous. If someone is reading a bunch of paragraphs of text and they try to translate that into code, they're going to miss something. Whether it's because the documentation was unclear or because maybe they misinterpreted something, or maybe when you wrote the documentation there is something that seemed really obvious to you but wouldn't be obvious to someone using your API. There's five, or maybe 10 popular languages out there that will cover most use cases. You should be writing code snippets for your users. Not only does it save thousands of hours of time, because you write it once and thousands of people can use it or hundreds or dozens, but it also makes it so that you know it's right. When you write paragraphs of text, there's a lot of ambiguity. You think you're doing a good job but someone has to still translate that into code. You can skip any sort of ambiguity and it just either runs or it doesn't run, if you write code samples. 2.  Personalization. We traditionally have all grown up, anyone who programs, learning from a book or from a very static thing. This book's huge because it has to go through every edge case, it has to talk about every skill level, different languages, different weird oddities. We don't have to do that. Because with an API we're incredibly lucky. We know exactly what's going on with your API. We know exactly how many times you've used it or if you've never used it at all. We can start showing content that's directly relevant to the person who is consuming the documentation, as opposed to just having to do the same thing that we did with books where it had to be good for everyone. We can specifically narrow in on the person who's using the documentation at the time and show them only what they need to see. And third is making it really easy to edit. This is something that traditionally API documentation is built by a developer. It's generated statically, it's deployed, and that's great at first. It's not a bad thing at all. As time goes on a marketer will come over and be like, "Can you mention this?" Or a customer will e-mail and have some confusion and you want to change it. If it's not really easy to edit it's really easy for your documentation to fall out of sync with the API, or to just not have all the most relevant information. Some of the best companies take a step further and they open it up so anyone can suggest edits to their API. 3. Easy to edit. This is something that traditionally API documentation is built by a developer. It's generated statically, it's deployed, and that's great at first. It's not a bad thing at all. As time goes on a marketer will come over and be like, "Can you mention this?" Or a customer will e-mail and have some confusion and you want to change it. If it's not really easy to edit it's really easy for your documentation to fall out of sync with the API, or to just not have all the most relevant information. Some of the best companies take a step further and they open it up so anyone can suggest edits to their API. Whether they provide the documentation on GitHub or at ReadMe, we have suggested edits feature. The really nice thing about that is that if it's easy to edit for your community, let's say someone spends eight hours trying to track down this bug that's driving the crazy and they finally figure it out. You don't want that knowledge to die with them. You want them to be able to contribute back so the next person doesn't have to spend another eight hours figuring it out or 3 hours or and have that repeat ad nauseum. If it's really easy to edit that means that anyone from the CEO, marketers, and obviously you want some sort of review process. You don't want people just to put anything out there. But if you allow anyone to make really easy edits it decreases the chance that your API documentation is completely out of date.

Tech Stack

ReadMe replaces paragraphs of text with custom-tailored developer experiences. Our tech stack includes frontend (Angular/React) and backend (Express) programming. We care about design-first thinking, and we're building a developer-focused company culture from the ground up.

Team Q&A

  • APIs in the real world

    ReadMe

  • How does ReadMe Build work?

    ReadMe


Core Values

We value autonomy, flexibility, and solving big problems. What We Do: Most documentation is hideous, chronically outdated, and hard to manage. Most companies have no clue how their APIs are used. We're fixing that by making documentation and API logging simple, beautiful, and easy for everyone. So companies can build stronger developer communities and make better connections with their customers. Why We Care: Because better documentation means better relationships, better products, and better companies too. When documentation is easy to create and maintain, developers can develop. Writers can write. Sales can sell more effectively. And customers can find what they need without having to call up support. We're saving the world from bad documentation and clunky APIs. And that feels good.

Vacation & Benefits

Competitive Pay: We offer competitive salary and significant equity. We offer a relocation package if you're outside of the SF Bay Area. Quarterly Retreats: Every few months, we spend a few days roadmapping in places like Santa Cruz or Tahoe. Come along! Paid Gym Membership: …and time to actually use it. Because your job should never take priority over your health. Unlimited Days Off: You've got a life outside of work. We want to grow as much as every startup, but we don't work through weekends to do it. Full Healthcare: Including medical, dental and vision coverage as well as paid maternity/paternity leave. We also give each employee a OneMedical subscription. Work-From-Home Wednesday: Every week, we all work from home to get caught up on work… and laundry! Our work week is flexible, so you can work in a way that's best for you

Culture

  • Design-first thinking
  • Freedom & autonomy

Cool Tech

  • Vim
  • Full-featured IDE editor

Day in the Life

  • Dog friendly
  • Daily lunch together
  • Continous feedback
  • Weekly executive Q&A

Team members

  • 22 employees

Greg K.

Founder

  • Macbook Pro
  • Spacemacs
  • Macbook
  • React, Express, Node, Javascript
  • Ticket to Ride
  • Age of Empires

React/Node Developer

San Francisco, CA・New Grad・Full Time

Apply

Support Engineer

San Francisco, CA・New Grad・Full Time

More Companies You May Like

2 jobs

LG Electronics

We create consumer electronics, appliances and mobile devices that are designed to help you connect with those who matter most. Whether that means cooking a nutritious, delicious meal for your fami...

Globally distributed

Aluna

We believe that better data means a better world. Aluna aims to combine the very best of medical science with technological breakthroughs so that parents and kids can breathe a little easier - anyt...

San Francisco, CA
3 jobs

LiveAction

Our mission is to help both our large enterprise and service provider customers simplify their network management experience by using our intuitive and ever-evolving software platforms. Our vision ...

Palo Alto, CA & globally distributed team