The latest articles on DEV Community by Tiago de Noronha (@tiagodenoronha). https://dev.to/tiagodenoronha https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F95201%2F2171a388-9d5c-4aa0-ad17-b6f92b1267fa.jpg https://dev.to/tiagodenoronha en Tiago de Noronha Sat, 04 May 2019 17:37:57 +0000 https://dev.to/tiagodenoronha/not-documented-not-done-1kkn https://dev.to/tiagodenoronha/not-documented-not-done-1kkn <p>This is my first post anywhere, so be gentle! :)<br> Also, this is my opinion based on my work experience and in the type of projects I have encountered. I would love to hear your opinions on the article in the comments!</p> <p>I know what you're thinking. <strong>Everyone hates documenting stuff.</strong></p> <p>Take for example doing your taxes. I hated doing the taxes until they implemented a mechanism for me to click "Yes, I confirm" and be done with it. But we do taxes because <strong>we have to</strong>. Documenting is based on the same principle.</p> <p>Nowadays I've turned a new leaf and I'm actually really fond of documenting. I try to document everything I can, with as much detail as necessary. I believe in teaching my junior team members the same thing. As soon as they enter my team they quickly realize if it's <strong>Not Documented, It's Not Done.</strong></p> <blockquote> <p>Note: Documenting and Commenting are two separate things. Think of code like a problem: while commenting mitigates, documenting fixes.</p> </blockquote> <p>When I started my first job, the moment we got an email saying that we won a new contract, was also the moment we started writing the code. <strong>There is no worse practice than this in software development!</strong></p> <blockquote> <p>Software development is like building a house. First you study the best approach, you review it, then you get your hands dirty.</p> </blockquote> <p>This has happened to me more times than I can remember. (Un)Fortunately I'm usually the firefighter who needs to put out some major fires in different types of projects. Maybe that's one of the reasons why I now like to document a lot.</p> <p>Imagine you are put on a project already on course and you have 3 days to implement a feature without absolutely no context at all. What would you give to see a really good written manual about what the project does, and how does it do it.</p> <blockquote> <p>Everyone likes starting a project from scratch and just going heads on to the code. Nobody likes entering a mid-finishing project without knowing properly what happened.</p> </blockquote> <p>Help your local firefighter colleagues and document people! Be it in .md, a word file, or even a Visio that explains the flow of the application you're developing!</p> <p>I hoped you enjoyed the article!</p> <ul> <li>What are your feelings on documenting? Do you like it or do you hate it?</li> <li>How do you usually document?</li> <li>Are you normally the firefighter in you team? :)</li> </ul> documentation