If you’re a developer, you likely spot (and ignore) irksome bits in your code or product regularly. Perhaps it’s an excessively long if-block or a border offset by 1 pixel too many. Maybe you manually run through 5 steps every week to get your test database just right. 

‍

We let these annoyances slide because we might not have time to fix them. We also understand that what seems small isn’t always a quick nip-tuck fix. 

‍

Last year, the Dropbox Sign engineering team started holding a quarterly "Bug Squash" to clean up these exact types of issues. Like the name implies, it’s a two-day event to fix small bugs but we also use the time to make workflow enhancements, perform housekeeping, create developer tooling, fix broken windows, and tinker with small projects. 

‍

It’s had a positive effect on team morale and satisfaction, and resulted in improved product quality and provided useful improvements to the team and our users. 

‍

Some examples of what we’ve squashed:

‍

• Added a Google Inbox Action to our signature request emails.
• Fixed the display of apostrophes in team names.
• Quieted noisy logging and tests.
• Replaced the JavaScript alert() calls in our internal support tool to use Sweet Alert (because our Support Team is equally sweet!).

‍

Bugs and product improvements aside, the eight days a year we use to re-channel our energy has been time well spent from an emotional and psychological health perspective. We’re a small team and spend the remaining 97% of the year driving product initiatives to our users. A two-day breather mixes the schedule up, allowing us to focus on something new and flex our engineering muscles in a way that feels more like play than work. 

‍

This may not be the first time you’ve heard of a Bug Squash. Some companies even regard them as an anti-pattern that should be avoided because they communicate that quality can be added later. 

‍

At Dropbox Sign, the quality improvements that result from the Bug Squash are expressly secondary. We dedicate a percentage of every release cycle to fixing bugs that are prioritized by our QA, Product, and Customer Care teams and the Bug Squash is just another tool in our belt that gives our engineers freedom to practice their craft and take pride in their product, team, and dev environment. 

‍

If we’ve convinced you to try your own Bug Squash, consider these tips that have worked well for us:

‍

Get Buy-In

‍

The support of your department and company can go a long way towards positioning the Bug Squash for success by eliminating fears of distraction or time wasted. Impress upon stakeholders the importance of pride and high morale that can motivate engineers to take deeper ownership in their work and product the rest of the year.

‍

Create a Wish List

‍

Encourage your teammates to create Bug Squash tickets year-round. We use JIRA and ticketing these items is helpful when prioritizing, coming up with a theme, and ultimately pulling changes into your SDLC and QA process.

‍

Pick a Theme 

‍

Choose a broadly applicable theme like “UI Polish,” “The API,” or “Integrations” to provide direction for new team members or those that have long lists and require a bit of focus.

‍

Celebrate and Share

‍

Schedule a team review at the end of the Bug Squash to talk about accomplishments, challenges, and v2’s or next steps. Snacks and libations highly recommended! Don’t forget to share what you accomplished with the rest of the company and celebrate!

‍

Time to Get Squashing!

‍

Do you conduct events that are great for team morale? Have ideas or suggestions for improving this format? We’d love to hear your thoughts in the comments! 

‍

If you're interested in reading more about how we foster a positive developer environment here at Dropbox Sign, you might enjoy these posts: "5 Tips For Cultivating Psychological Safety" and "APIs for Humans: The Rise of Developer Experience."