<story><title>Always Be Quitting</title><url>https://jmmv.dev/2021/04/always-be-quitting.html</url></story><parent_chain><item><author>b0afc375b5</author><text>I&amp;#x27;m that guy in my current company. When I get brought in to an existing project, the first thing I look for is the README. To my disappointment, it either doesn&amp;#x27;t exist at all, it&amp;#x27;s the default generated, or it&amp;#x27;s 1 or 2 years outdated. So during project on-boarding, I document everything I can, create or update the README, then commit and push to the repo.&lt;p&gt;In all of my coworkers across all projects, I&amp;#x27;m the only one who does this. I&amp;#x27;m pretty sure nobody reads them either. I don&amp;#x27;t mind though, it has paid for itself countless of times already, since I always reference it.</text></item><item><author>Brajeshwar</author><text>A few years back, I had the opportunity to lead the Product Team of a 200+ people company. It took me over a month to understood who does what, and I tend to try to know things around me and at least have the idea of “what to do in an emergency.”&lt;p&gt;I stumble on one DevOps guy who wrote every bloody thing happening in the system. He likes doing it, but from the way people were asking questions in the common chatrooms, group emails, I knew nobody read them. He loves plain text, nicely formatted with the old-school Unix-styles et al. I had talks with him outside of work and found him fascinating; I asked him help with my hobby, home-lab tinkerings, etc.&lt;p&gt;By that time, I had already started internal blog groups and was encouraging people to write. And indeed, a lot of people came out to write about engineering, marketing, product, and it became a routine for people to show off what they can do, what they love, and what they are good at.&lt;p&gt;In one of my regular company-wide emailers, I dedicated a big piece to the DevOps guy, pointing to his work and the beauty of his documentations. People loved it, and they began reading it. He remained a friend. That mailer was the only way I could highlight people I encounter doing good work, to the whole team up to the CxOs.&lt;p&gt;By the time I left the company, I was responsible for many vital things in the company, but I could transition everything smoothly with the documents and credential details (thanks to 1Password).&lt;p&gt;In the last year or so, I have been thinking more about -- always be dying. I think the similar vein of Always be Quitting; I try to document, write out details, just in case I die and my family has to figure out the intricacies.</text></item></parent_chain><comment><author>nickfromseattle</author><text>Building a culture of documentation starts from the top.&lt;p&gt;Today our 40 person org has 1,337 knowledge base articles (as of yesterday, a coincidence, and we probably have a different number today).&lt;p&gt;It started with myself (CEO) creating all of the initial documentation.&lt;p&gt;3 months after my first employee joined, I started holding her accountable to creating and updating documentation.&lt;p&gt;It&amp;#x27;s not a one time thing.&lt;p&gt;You can&amp;#x27;t say, &amp;quot;your job is to do documentation&amp;quot; once.&lt;p&gt;It&amp;#x27;s consistently talking about it.&lt;p&gt;It&amp;#x27;s scoping in documentation updates and refreshes into bi-weekly sprints and quarterly goals.&lt;p&gt;Once she was onboard, we began to hold everyone else in our organization accountable too.&lt;p&gt;Again, it&amp;#x27;s never a one time thing to get anyone bought it.&lt;p&gt;It needs to be constantly discussed and scoped.&lt;p&gt;Today, all of the managers are bought in.&lt;p&gt;Instead of me explaining the importance of documentation, it&amp;#x27;s our org&amp;#x27;s managers embodying and instilling the culture of documentation into everyone new.&lt;p&gt;They understand the value of having their reports check the KB first.&lt;p&gt;They understand the value of being able to link someone to a KB instead of repeating themselves.&lt;p&gt;They understand the value of being able to work more async.&lt;p&gt;They understand the value of not being a bottleneck for someone else.&lt;p&gt;I stopped spending much time creating documentation about 6 months ago - and the number of documents just keeps increasing.&lt;p&gt;Today, I&amp;#x27;ll push documentation forward for new position &amp;#x2F; roles.&lt;p&gt;I&amp;#x27;m working on delegating finance - and spent a bunch of time putting together documentation on how to handle the company&amp;#x27;s money.&lt;p&gt;- Expense policies&lt;p&gt;- Org software purchases&lt;p&gt;- Invoicing and payroll&lt;p&gt;- Phishing and security&lt;p&gt;- etc</text></comment>
<story><title>Always Be Quitting</title><url>https://jmmv.dev/2021/04/always-be-quitting.html</url></story><parent_chain><item><author>b0afc375b5</author><text>I&amp;#x27;m that guy in my current company. When I get brought in to an existing project, the first thing I look for is the README. To my disappointment, it either doesn&amp;#x27;t exist at all, it&amp;#x27;s the default generated, or it&amp;#x27;s 1 or 2 years outdated. So during project on-boarding, I document everything I can, create or update the README, then commit and push to the repo.&lt;p&gt;In all of my coworkers across all projects, I&amp;#x27;m the only one who does this. I&amp;#x27;m pretty sure nobody reads them either. I don&amp;#x27;t mind though, it has paid for itself countless of times already, since I always reference it.</text></item><item><author>Brajeshwar</author><text>A few years back, I had the opportunity to lead the Product Team of a 200+ people company. It took me over a month to understood who does what, and I tend to try to know things around me and at least have the idea of “what to do in an emergency.”&lt;p&gt;I stumble on one DevOps guy who wrote every bloody thing happening in the system. He likes doing it, but from the way people were asking questions in the common chatrooms, group emails, I knew nobody read them. He loves plain text, nicely formatted with the old-school Unix-styles et al. I had talks with him outside of work and found him fascinating; I asked him help with my hobby, home-lab tinkerings, etc.&lt;p&gt;By that time, I had already started internal blog groups and was encouraging people to write. And indeed, a lot of people came out to write about engineering, marketing, product, and it became a routine for people to show off what they can do, what they love, and what they are good at.&lt;p&gt;In one of my regular company-wide emailers, I dedicated a big piece to the DevOps guy, pointing to his work and the beauty of his documentations. People loved it, and they began reading it. He remained a friend. That mailer was the only way I could highlight people I encounter doing good work, to the whole team up to the CxOs.&lt;p&gt;By the time I left the company, I was responsible for many vital things in the company, but I could transition everything smoothly with the documents and credential details (thanks to 1Password).&lt;p&gt;In the last year or so, I have been thinking more about -- always be dying. I think the similar vein of Always be Quitting; I try to document, write out details, just in case I die and my family has to figure out the intricacies.</text></item></parent_chain><comment><author>pwdisswordfish8</author><text>&amp;gt; first thing I look for is the README. To my disappointment, it either doesn&amp;#x27;t exist at all, it&amp;#x27;s the default generated&lt;p&gt;Auto generated READMEs (and their handcrafted equivalents) are worse than useless.  Not only are you wasting your time creating one (and giving yourself the sense of having accomplished something when you haven&amp;#x27;t) but the effect of a README creation is one-to-many, so consider that wasted time and then throw a multiplier on it.  That&amp;#x27;s the cost of a dummy README.  Don&amp;#x27;t create them, people.</text></comment>