Refactoring: Focus on Culture, Not Code

Be the change you want to see and create a domino effect.

This text started with my journal, where I wrote about a day I worked in person with a colleague. The names are fictional.

In one of my conversations with Laura, we discussed a lot about the refactoring culture in the company, especially in our team. A team member, Clara, often complains that we don't have a refactoring culture. Laura and I both disagree. So, why does Clara see it this way? What aspects make her think the culture isn’t in place? The irony is that she is the one who opens fewer refactoring PRs, doesn't take the initiative to break things down and improve the code with smaller steps, and doesn't advocate for technical improvement prioritization. I understand where it comes from: she has been here for a long time. She is tired. In her opinion, we must prioritize a project to redo the entire architecture. Otherwise, we can't get rid of technical debt. She is disappointed and believes small changes won't change anything.

You probably worked with someone who complains about the lack of refactoring culture. Or, unlike in my short story above, you are on a team where this culture doesn't exist. No matter which is the case, complaining won't help. Instead, it is a smell that you need to work on the team culture and not too much on what is happening in the code (not yet). Putting all the energy into the code’s problems and prioritizing big projects to deal with technical debt will create temporary relief. If a culture of improvements and refactoring isn’t in place, it is only a matter of time until the next huge refactoring project comes to life.

In this text, I will bring light to the topic and share some practical things that help to reinforce a refactoring culture.

• 🫂 Technical Debt is Part of the Nature of Software Development

• ⌛ Culture Is a Long-Term Investment

• 📣 Advocate For The Culture You Want

  • Cultivate Self-Awareness

  • Split Refactoring from Business Logic PRs

  • Show the Value of the Changes You Introduce

  • Don’t Let Your Motivation Drop

  • Grow and Empower Others

  • Make Onboarding a Priority

  • Don’t Ignore Lack of Ownership

  • Don’t Wait for Your Manager, Be a Leader

🫂 Technical Debt is Part of the Nature of Software Development

A refactoring culture is about routine and consistency, not perfection. Engineers are aligned with the same mindset and naturally make things happen. They don't need to decide; they do. Sometimes, you'll refactor more, sometimes less. It depends on your constraints. But you never stop doing it.

Technical debt will always exist, no matter how strong your refactoring culture is. You need to normalize it. It is something to manage, not something to get rid of. As business requirements, they must have a reason to happen besides the sake of having a perfect code. Your focus must be keeping it under control.

⌛Culture Is a Long-Term Investment

It takes time for culture to change the status quo. Be prepared to put in much effort and not see significant changes for a while. Technical debts require more time to fix than to create. They are usually the easy path in the short term. 

Don't expect a substantial refactoring project to be prioritized against all the other company's priorities to say the culture exists. Instead, you are responsible for explicitly communicating the risks whenever you acknowledge that a project can increase the technical debt. By communicating, you should understand the business language. What are the consequences? Which initiatives can be blocked? How big is the complexity you're introducing? How complex would it be if you decided to postpone it?

Maybe your current status needs a refactoring project because the technical debts are so huge that handling them in smaller pieces is impossible. However, focusing first on the project and later on the culture is a mistake because people tend to relax when the pain decreases.

📣 Advocate For The Culture You Want

You shouldn't wait for someone to advocate for the things you value. When you only complain, you are actually reinforcing a culture where it becomes normal, and no one takes the initiative to solve the problem.

If you truly appreciate a culture of refactoring, make it visible. Bring up conversations and be the role model you want to see. Be aware that the time for significant benefits to appear is proportional to the size of the mess you have on the code.

Cultivate Self-Awareness

Where are you in the culture challenges? Are you complaining, making a difference, or just being neutral and avoiding fatigue? Self-awareness is a powerful tool. If you lack it, you might create harm without realizing it. 

Build your own "chain of whys." Reflect on the reasons behind your decisions. Journaling and working logs are great tools for doing it. The idea is to split what you do consciously and what are automatic choices. The second one is often the source of a weak culture. 

Split Refactoring from Business Logic PRs

When working on introducing business logic, split your PRs into at least two parts — the first with the refactoring and the second with the business logic. Remember, the refactoring doesn't need to be something huge. For example, you can just rename a variable to something easier to understand. If you always start by refactoring, it moves from "if I have time, I’ll do it" to being a regular part of your development flow. Also, isolating the implementation from the refactoring makes PR reviews easier and brings awareness about refactoring efforts. If others see value in it, they will replicate the practice. It creates a domino effect.

Show the Value of the Changes You Introduce

Showcase your refactoring based on impact. Nothing is obvious. Everyone expects that all you do will add value. But how it happens is unclear for many people. And if they don't see it, it won't get that important. Assumptions don't create culture or help maintain it. Here is a trivial example to make the idea more concrete.

I found a variable called a. I had no idea about its purpose. I needed to read three files, more than 200 lines, to understand how it affected the five lines of code I needed to change. It took me more than 40 minutes to get there. Besides introducing the new logic, I also renamed this variable to somethingThatIsEasierToUnderstand. This small change will reduce the cognitive load of the next person that will touch it. In practice, if I had found it this way, it would take me (at least) 40 minutes less to do the same work.

Don’t Let Your Motivation Drop

Keeping culture alive isn’t easy at the beginning when it is still weak. Engagement usually drops over time. Blaming the culture or finger-pointing will not make it better. Take ownership, teach others, and act as a role model. Don’t forget to find a way to keep you motivated. With time, it will be natural, like breathing.

Grow and Empower Others

Many engineers don't know how to refactor code properly. Techniques like shortening the scope and not being lost in a rabbit hole, splitting PRs, starting by adding tests, etc., can be learned. Don't think you can change the world alone. Team culture can't be built by a single person. It is something that everyone must own.

Make Onboarding a Priority

Guiding new team members to the cultural aspects you want to keep in your team is crucial. It is one big reason I don't like to onboard many people on the same team simultaneously. The culture can quickly shift to something unexpected because you don’t have a balance. If you need to do it, make sure people have all they need to learn your team culture.

Don’t Ignore Lack of Ownership

If someone says the refactoring culture doesn't exist, challenge them to start doing it. Don't ignore excuses like "others don't do it, so I won’t." You must work as a team and grow as individuals.

Don’t Wait for Your Manager, Be a Leader

You don't need to be a manager to start a change. You need to be a leader. Leaders are everywhere in many different roles. It isn't about holding a position but being an example and actively engaging others.

🔖 Related Content You Might Like

• How we deleted 4195 code files in 9 hours by

  Anton Zaides
  . Anton shared an interesting initiative to remove old code. It could inspire you to promote something similar and create visibility about the issue.

• Lead Your Culture by

  James Young
  . A good source for managers. Culture is a huge topic, and in this text, many aspects of it are considered.

---

That's all for today! 🎉

I like getting feedback and connecting with people. Feel free to reach out—I'd love to hear from you! You are also welcome to suggest topics for future posts.

See you next time 👋