Tooting your own horn: Why developers should celebrate small wins
Our development team kicked off the day with a call where we discussed communication. Lately, I’ve noticed that our #development Slack channel occasionally gets bogged down by minutiae. I asked the team to hop on a call to unpack why this friction occurs and...

Our development team kicked off the day with a call where we discussed communication. Lately, I’ve noticed that our #development Slack channel occasionally gets bogged down by minutiae.
I asked the team to hop on a call to unpack why this friction occurs and what we can do to avoid it in the future.
During the call, we discussed a range of topics: our different communication methods, expectations for receiving feedback on code, processes we could implement to help our work progress. But one of my favorite topics that came up was how to celebrate wins.
Writing code involves a lot of little victories
When Casey, our marketing coordinator, writes a blog post or newsletter, his work is out there for everyone to see. When Mwale, our QA Analyst, finds a bug, he reports it to the team. And when Ehlers or Bennemann, our technical support team, assist customers and receive glowing feedback, their efforts are celebrated in Slack. But what happens when a developer writes a really good line of code?
Up to this point, we’ve mostly only celebrated product updates and new releases, but these are the culmination of hundreds of “commits” (bundles of code changes). And many changes to code don’t add functionality that would ever be noticed by customers…or even by other developers on our team!
When changes are made to our code, we do internal code review before they get merged with the product. This involves another developer reading the code and making note of any issues they find. They’re looking for problems. During this process, it’s far too easy to look past all the good code that’s been written. And yet, so often in the world of development, the true victories are hidden within a single, overlooked line of code.
Sometimes a problem gets solved elegantly and thoroughly and it’s virtually invisible. How can the code reviewer and the team know about these hidden wins?
🎺 We’re going to try tooting our own horn… and you should, too!
During the call, I proposed an idea we’re excited to try: sharing and celebrating these small wins. We’re going to take some time to explain how we’ve kicked so much butt. This may involve, for example, making a video about our win and sharing it with the team on Slack so we can—at the very least!—get some emoji responses to our post.
We should take time to celebrate our wins, even though it’s often challenging when working remotely on a constantly evolving codebase.
The GravityKit team is a humble crew. We often keep focused. But we’re going to try sharing more about what we do well, because the alternative is that our work may go unnoticed. And going unnoticed often leaves one feeling undervalued.
Don’t forget to toot your own horn to let people know about the amazing work you’re doing (and especially if you’re a woman)!
More articles
Launch Log: Magic Links enhancements and DataTables sorting fixes
I tried to organize a party in space once, but there was no atmosphere… Okay, okay let’s get into this week’s product updates! This week, we released several focused fixes across GravityEdit and GravityView, along with new capabilities for Magic Links and small but…
The why and how of using WordPress to build an MVP
Noah Kagan, the founder of AppSumo, says that the secret to marketing is to build a great product. But here’s the catch: in order to build a great product, you need to know what users actually want. Enter the MVP, or “Minimum Viable Product”….
Launch Log: Clearer admin errors, custom code placeholders, and key fixes
Ever wondered why aliens don’t visit our solar system? It turns out they read the reviews, and it only has one star! Welcome to our first Launch Log of 2026. We’re kicking things off with a raft of exciting updates, including clearer error notices…
