Internal API Documentation

About the project

During my internship at Neural Technology Solutions, one of the things I worked on was internal API documentation. It was not a public product, but it was useful work: helping other developers understand what was available and how to use it without having to rediscover everything from the code.

My part

I contributed documentation while also working with Angular 2, Redux, Flux architecture, Git, and the team’s APIs. This was my first exposure to modern web development. Redux and Flux were completely new ways of thinking about how state and information moved through an application, and a lot of the value came from seeing those ideas inside a real professional project.

Good internal documentation is easy to ignore because users never see it. Developers do. It can make onboarding less confusing and reduce the number of questions that have to be answered again and again.

Fun fact: the NDA

I had to sign an NDA that required me to not talk about my work there for five years or I could be sued for an exorbitant amount of money. In retrospective, there was not much about my job that was especially unique, but I was scared enough by the NDA that I never shared this experience in the interviews I had while looking for my first official job.

It is funny now, but at the time I treated almost every detail as if it was a dangerous secret. That also makes this page feel a little overdue.

What is public

The documentation and product details are internal, so there are no screenshots or source links to share. The artwork on this page is an original placeholder made for the portfolio, not an image from the project.