And you are here why?

There are  so  many factors that go into success — market, product, requirements, customers, oh, the list goes on. That said, there are a couple of things that you  must  do to make sure that  failure  isn’t guaranteed. The following list isn’t exhaustive, but it is, most definitely, table-stakes these days for how you should structure your APIs. 1. Respect Every API : You don’t really know which API is going to be used, and which one isn’t. Murphy’s law pretty much guarantees that the throwaway buggy one that you put out there is going to be  the  one that causes you the most trouble. And  Hyrum’s law  will ensure that that shitty implementation will be made concrete, and you’ll never get rid of it. 2. Be Obvious : Make sure that there are no surprises. No unexpected side-effects, no behavior that isn’t documented. Seems like such a small thing, but, in the end, it’s the side-effects and/or hidden features that will get you. 3. ...

“ Great documentation builds trust, differentiates you from your competition, and provides marketing value . ” Here, Diana is talking about the good stuff, the stuff that you actually enjoy reading, that you can rely on, and that you might actually extol. (Yes, it exists!  Stripe’s docs  are a great example). /via http://geek-and-poke.com/ Unfortunately, in most of our world, documentation is one of those things that is frequently an afterthought. Or worse, left to the  #TechBros . “The code is the documentation”  — #CowboyDeveloper Documenting  what  the code does can be remarkably useful for somebody modifying the code, but  is close to useless for somebody that wants to use the system, and doesn’t give a s**t about the underlying code . The Components Product documentation should have three clear components • Concepts : An introduction to the system, that provides an understanding of its overall purpose , the ideas and concepts emb...