Since starting my career in software engineering, every senior developer I have spoken to recommends refactoring as a technique for improving and growing as a developer. Its importance and benefits are widely acknowledged: it improves code quality, reduces technical debt, increases maintainability, and results in better overall software design. It can also help to reduce the likelihood of bugs and errors, as well as make it easier to add new features and functionality to the software.
But despite these benefits, how many developers actually take the time to do it regularly? As the great Martin Fowler said, “refactoring is like doing the laundry. It’s not fun, but if you don’t do it, your code will start to stink.”
For some time, I considered how to incorporate this good practice into my daily routine, but I knew that I needed to give it a spin and make it fun to turn it into a habit. That’s when it hit me: I reached out to my colleague Victoria Kovaleva, and together we created our 30-day refactoring challenge.
We wanted the challenge to be realistic, which is why we agreed to do a daily refactor for no more than an hour and we also made sure it would not disrupt our personal or team goals. To make it impactful, we checked the different types of refactors we could tackle and reviewed the ones that were new or not so familiar to us. Last but not least, we wanted the challenge to be empowering for both of us. That’s why we made sure to meet every week to check on our progress and support each other.
To make the challenge official, we announced our commitment to our respective teams. This helped keep us accountable and raised awareness about the importance of refactoring. Victoria suggested we keep a log of our daily commits and register our thoughts, frustrations, and learnings in a document, which allowed us to reflect on our progress and share our experiences with each other.
To kick off the challenge, we reached out to our colleagues for suggestions on refactors to create a backlog of tasks that required attention. One of our colleagues suggested spending some time creating or improving our documentation. Initially, it felt like a chore, but how helpful is it when you find updated documentation when you need it the most? Another colleague reminded us to ensure that the refactors were safe by writing tests and double-checking the relevance and validity of suggestions from our respective IDEs. These suggestions helped us hit the ground running and stay motivated throughout the challenge. We were all set and ready to succeed.
So after spending an average of 11.5 hours refactoring and having worked on 7 different projects, what have we learned during the past month? Let me share with you our five biggest takeaways:
- The timing of the refactor matters. Doing it at the beginning of the day made all the difference. It set the tone for the rest of the day and warmed us up. Plus, how great does it feel knowing that you have started your day by giving value to your team?
- Keep it short and sweet. Set a time limit and break big refactors into smaller pieces. It is so easy to get lost in them.
- Make the most of it. The time that you are dedicating to refactoring can also be used to practice other complementary skills. For Victoria, it was typing skills, and for me, it was learning new IDE shortcuts.
- Involve your team. Challenge your teammates to practice refactoring regularly and suggest creating a team backlog. This will provide guidance on what to tackle next and help you stay relevant in your work. Additionally, it can spark interesting conversations about different approaches and techniques within the team.
- There is no failure in refactoring! It doesn’t matter if the refactor is small or if it is ultimately undone. The goal of refactoring is threefold: to improve the code, learn how it works, and understand the business model. If you end up accomplishing even one of these goals, it was time well spent. You were successful.
Shortly after starting the challenge, we began to notice the rewards of adding refactoring to our daily routine. It was very exciting to see that we were able to identify potential refactors in our code more quickly, the overall quality of our code improved, and we felt more connected to our work. Refactoring also helped us build confidence in ourselves and our abilities, reducing our feelings of impostor syndrome.
To sum up, completing this challenge and incorporating refactoring as a habit has brought benefits that extend beyond just improving our code. It has boosted our confidence, improved our code quality, and fostered collaboration within our team. We highly recommend this challenge to anyone looking to improve their coding skills and make a positive impact on their team.
Moving forward, now we wonder: what other challenges can we tackle to improve our coding skills, boost our confidence, and support our team? Share your ideas in the comments below.
Victoria Kovaleva – Linkedin Twitter
Marta Vila- LinkedIn
