# Long Term Refactors - Max Chernyak Synced: [[2024_01_29]] 5:29 PM Last Highlighted: [[2024_01_28]] Tags: [[career growth]] [[software]] [[teams]]  ## Highlights [[2024_01_28]] [View Highlight](https://read.readwise.io/read/01hn7rjdkcebm7paj7xzbdbwtv) > Big (or “Long Term”) refactors are hard to pull off in a busy company. To succeed, we must: > • Convince business that it’s worth the delay. > • Decide what features will have to wait. > • Produce regular status updates and ETAs. > • Justify the refactor as we go. Is it the right approach? > • Keep ourselves from burning out. > • Allow time for the team to digest and review the huge diff. > • Fix a bombardment of QA issues. [[2024_01_28]] [View Highlight](https://read.readwise.io/read/01hn7rqepy83swwnf6w3b52yjz) > **Write up refactoring instructions.** > Create a document in your internal knowledge base and title it with the name from step 5. Some tips: > • State exactly what to do, and how to do it. Be brief and specific. > • *Do NOT tell stories*: “Over the years we’ve realized that the method we’ve been using …” > • *Do list specific steps*: “Find a class that has function X. Create new class named Y. Move function X into class Y.” The steps can’t all be plain of course, but challenge yourself to see how brief and specific you can make them. > • Link your example merge request from step 3. People should see the code before and after. > • Finally, feel free to add some context at the end. Here, you’re welcome to provide the background, tell stories, link to relevant resources and discussions. That said, do hide this part under an expandable element, like [<details>](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details). We want the doc focused on the pattern itself, with an option to expand the context as needed. This is probably the biggest step to getting other people to buy-in to a refactor, even knowing how to do the refactor in the first place