{"id":508,"date":"2026-01-30T09:55:33","date_gmt":"2026-01-30T09:55:33","guid":{"rendered":"https:\/\/productive.io\/engineering\/?p=508"},"modified":"2026-01-30T09:55:33","modified_gmt":"2026-01-30T09:55:33","slug":"are-you-documenting-your-project-enough","status":"publish","type":"post","link":"https:\/\/productive.io\/engineering\/are-you-documenting-your-project-enough\/","title":{"rendered":"Are You Documenting Your Project Enough?"},"content":{"rendered":"

Workflow<\/a><\/p> –

{{minutes}} min read<\/p>

Are You Documenting Your Project Enough?<\/h1> \"\" <\/a>

Davor Tvori\u0107<\/p><\/a> Frontend Engineer at Productive. Excited about anything related to computer science. I spend most of my personal time reading and playing video games.

January 30, 2026<\/p> <\/a> <\/a> <\/a> \"\"

Writing documentation is important but tedious. We\u2019re all probably aware that we have to write documentation for the products we develop. I don\u2019t know how you feel about it, but when I do it, it hurts my brain.<\/strong><\/p>

It\u2019s not even that difficult (most of the time), but the whole process around it is what makes it so dull. Personally, I enjoy writing, but even I have to force myself to write a couple of sentences about what I\u2019ve done. But you gotta do it, baby.<\/strong>

I\u2019ll be explaining the techniques we incorporated in our workflow to improve the whole documentation situation. If you\u2019re struggling with this, I\u2019m sure you\u2019ll be able to take away some ideas from this post.<\/p>

The Problem With Documentation<\/strong><\/h2>

I won\u2019t spend too much time explaining why documentation is important and who benefits from it because I\u2019m sure you already know that. I\u2019ll mention some problems that I\u2019ve run into when dealing with documentation.

When I first started working at Productive, there was already a fair share of documentation. A lot of things were documented, from setting up your workstation to details about using a specific component. I was excited about being brought up to speed with everything, but I started running into cases and features that were either not detailed enough or not documented at all. Even though I was optimistic at first, this didn\u2019t really surprise me since it\u2019s a huge codebase with a lot in it. This just meant that I\u2019d have to ping other colleagues and figure some stuff out on my own.

Fast forward a couple of months, it was my time to write documentation. Up until this point, I was very excited about documenting everything I\u2019ve done. But when it was time to write something, I had this nagging feeling in my head. I knew that it had to be done, but now I had to think about how and why something was done in a particular way, how detailed the explanations should be, where to actually write the documentation, and a whole lot more. It\u2019s even worse when it\u2019s a system that you don\u2019t completely understand and you start asking yourself if you\u2019re the best choice for writing this piece of documentation.

So many problems\u2014and I haven\u2019t even started writing any documentation yet.<\/p>

A Helping Hand<\/strong><\/h2>

Now, this sounds a bit more dramatic, but all of these thoughts passed through my mind at some point. We quickly brainstormed a couple of ideas to tackle the problems mentioned above. If we had some sort of a process and a frictionless way of writing documentation, everyone would have a lot more brain power to actually write documentation as opposed to worrying about issues related to writing documentation.<\/p>

Here are the things we agreed upon:<\/p>