Book a demo
Is your documentation AI-agent ready? - Get your free Agent Score in 30 seconds!
Thirty-Three Rules of API Documentation with Robert Delwood, the Lead API Documentation Writer at iManage
Podcast

Thirty-Three Rules of API Documentation with Robert Delwood, the Lead API Documentation Writer at iManage

• Published: •

Updated on Jul 17, 2026

✨ Try Document360
View all

AI Summary

  • Robert Delwood, lead API Documentation Writer at iManage, discusses the thirty-three rules of API documentation, producing API documents, and challenges in creating high-quality technical documents.
  • He has an MA in CIS/MIS, a BA in Journalism and Business Administration, and over five years in technical writing. He began programming in 6th grade and believes programming exposure helps create better technical content.
  • Robert advises programmer writers to meet user expectations, define call names and parameters, and evolve a documentation style using code snippets, starting guides, and how-tos. He describes API documentation as more art than science.
  • One rule is “document it for yourself”: understand a new concept before teaching it. Coding is not mandatory, but technical soundness helps writers explain API examples.
  • Robert values developer feedback, recommends learning technical skills, and identifies Open-API and YAML as favorite resources. He believes technical documentation tools need improvement and encourages careers in API documentation.

AI-generated content. It may contain errors.

See Document360 in action

Robert Delwood, the lead API Documentation Writer at iManage, joins the Knowledgebase Ninja Podcast to share the thirty-three rules of API documentation, the fundamentals of producing API documents, and the challenges of creating high-quality technical documents. 

Key facts

  • Robert’s LinkedIn
  • iManage’s website
  • Robert has a MA in CIS/MIS and a BA in Journalism and Business Administration 
  • Robert is currently working as the lead API Documentation Writer at iManage
  • Robert has been serving the technical writing niche for over 5 years 

Kay takeaways

  • Robert began programming in 6th grade and later pursued journalism and business administration in high school
  • Robert believes that his exposure and self-practice in programming provide him with an edge in creating high-quality technical documentation. “Understanding of backend and programing helps you deliver better technical content and help in explaining the concepts to the targeted audiences”
  • Robert advises programmer writers to focus on meeting user expectations rather than only fulfilling the requirements 
  • Robert believes that API documentation is more of an art than science. There are pre-defined API documentation reference guides, but it’s advisable to choose a style that works best for you when communicating new ideas and concepts to consumers. The bottom line of a technical document is to help users digest technical information in the most simple manner
  • The most important factors for quality documentation are meeting audience expectations, the call name, and having defined parameters. You can start out in a conventional manner; your personal style of technical documentation should evolve through the course of a document. Examples include code snippets, starting guides, and how-tos, to name a few. Some programmer writers produce entire applications in order to showcase the calls and the interaction of the calls. A “call site of a function or subroutine” is the location (line of code), where the function is or is not called, through dynamic dispatch. A call site is where zero or more arguments are passed to the function, and zero or more return values are received
  • Robert follows a strict regimen constituting thirty-three rules for documentation. One of them is that you document it for yourself. Explain a new concept to yourself first, then teach the company product to develop it. If you don’t understand something – stop and repeat
  • Robert shares that learning to code isn’t mandatory to enter into the technical writing industry. However, a technical writer can deliver better documents when they can feel the code or technical concept in action. API documentation is all about quoting technical examples, and writers should have technical soundness to explain concepts in examples  
  • Robert shares his knowledge bank on Medium and Reddit regularly. He believes that putting up an article online enables him to access it conveniently 
  • Robert believes that technical documentation tools need improvements. Before Open-API, there were no standards, both code and documentation were rarely synchronized. The YAML tool is a great addition to the community
  • Robert believes that the world needs API documentation writers, and encourages people to establish a career in  API documentation 
  • Robert’s biggest influence

Robert considers formal and informal conversations with developers as the best form of learning. He says that feedback from developers enabled him to understand concepts better. 

What documentation related advice would Robert give to his 20-year-old self?

Robert’s advice to his 20-year-old self would be to “learn any sort of technical skills, be it programming language, Windows OS or Linux OS. This will help you flourish in a technical writing career.”

Robert’s favourite documentation related resources 

Subscribe to the Knowledgebase Ninjas

Quote:

Centralize all your documentation and make it easily searchable for everyone.

cta

Gowri Ramkumar

Gowri Ramkumar is VP of Sales and Customer Success at Kovai.co, leading global sales, customer engagement, and partnerships across a team of more than 80. She spent her first decade in IT in software testing, as a test analyst, technical test lead, and project test manager, including testing projects for Lloyds Banking Group in London. She hosts Knowledge Base Ninjas, Document360's podcast on technical writing and knowledge management, and has been a guest on The Customer Experience Podcast. She writes on knowledge base strategy, customer onboarding, and retention.

Read more
Request Documentation Preview