Santa role — how and why to introduce a bug-focused developer

Io 🌒

The year is 2399, and the human species has finished its colonization of Io, the 3rd largest of Jupiter’s 79 moons.

These colonizers’ teams combined humans, robots, and humanoid robots.

They handle scheduled and incoming tasks almost immediately, and due to enhanced brains, also simultaneously.

Today, as simplified as we’ve got in 2022, multi-tasking is a feature we’ve yet to develop completely.

Who is brave enough for this challenge?

Is your team working on high-priority features?

Are tasks piling up?

Is your backlog expanding and attention at its maximum?

If yes, keep reading this post and I’ll add some logic and balance to those important daily decisions.

Eventually bringing you closer to completing your tasks, while staying attentive to those other topics and channels.

Who’s in charge of being in charge?

Deciding which developer should be assigned to which incoming tasks is something we can’t assess the effect of on the Sprint.

Some questions take time to answer, meaning that some answers need research and former knowledge.

In the same way, some bugs take time to debug and fix.

A developer’s attention is distracted all of the time, juggling between reviewing code, answering questions, learning, and meetings.

The core reason we deliver or fail our schedules is derived from our time management and task assigning methods.

Without being overly dramatic, teams that keep the delivery keep delivering, and the roadmaps keep roadmapping. The method is fine, but can we try and change it a little bit?

I mean that most of us are kind of good, even without a plan to manage the unmanaged work.

So why have I asked you to consider changing the system?

Because our goal (as a human code machine), should always be to improve our delivery and raise questions about our working methods.

The Agile Sprint concept is okay, but it can be more than that.

Handling incoming and important work can still be relaxed and fun. Inspecting suspicious behavior, debugging failed CD tests, and helping another team’s developers / PMs / Support can, and should be, included in the Sprint’s workload. And we can do so without knowing when they’ll arrive or preparing extra time in advance.

Introducing the Santa role: who deserves a present and who deserves coal?

Say Hello’ ho’ ho’ to jolly Santa, he’s here to help us handle alerts and questions, making everyone else much more concentrated on their tasks.

Santa’s job is to:

• Provide peer support on questions from the Slack channels
• Ask questions and get answers in standard time, preventing time-consuming meetings
• Assist with incoming support questions and queries, which (when not answered) can sometimes be translated into unnecessary bugs
• Get a first look at incoming production bugs
• If possible, do the work, and not necessarily the one who it’s assigned to eventually
• Respond to CI/CD failed sanity tests
• Keep the team reachable and attentive

What’s the price?

Santa will take less work on the Sprint, many times he can work on less urgent developments, but all those features he’s providing make him very valuable — even when not assigned to the regular Sprint’s tasks.

What impact do we gain from this role?

Better handling of incoming calls from Slack channels, making our CS quieter, and not opening unnecessary bugs we’ll need to close (after investigating) later.

We all know each of our products, and how to raise their environment. Our CI/CD is much more stable — failed tests rerun and are checked almost immediately.

My team develops customer reviews widgets, injected into ~600k eCommerce shops, handling ~48,000,000 reviews daily. In a microservices world, we’re first in the chain.

I once heard from my uncle that with great traffic comes great responsibility…

He’s mistaken! He probably meant bugs, many questions on Slack channels, multiple dashboards, CD Monitoring, PM requests here, and designers’ requests there.

So we’ve been able to become an integral part of Yotpo’s R&D while being attentive and helpful to other factors. We’ve created new backend services and rewritten our widgets in new advanced frameworks.

Our development has made an impact, enhancing the user experience through performance improvements and new designs.

All that has been done with only 3 developers, with one of us on production support every Sprint.

Initiating the Santa role is a key milestone in every new developer’s learning process.

While a new employee is answering questions, overlooking the CD, and handling Santa issues hands-on, they’ll boost their learning process and gain confidence faster.

My personal impression

This role is not a completely new concept for me, as I’ve worked for companies with similar ideas.

But, IDK, maybe being raised on a kibbutz has made me a socialist. And now, when this responsibility passes between everyone in the team, it makes the working environment something I prefer even more.

As mentioned before, this was a key milestone in my professional advancement at Yotpo.

Conclusion

We didn’t come any closer to colonizing Io, but we did find a way of preparing for those alerts that we weren’t ready for.

The Santa role turns all those unplanned incoming issues into something we can adjust our time to (if needed) and develop. It enables the entire team’s better understanding of legacy code and how to debug it, as well as how to solve production issues in general.

There is no doubt that our industry will require us, developers, to handle immediate requests, and there is no way to plan 100% ahead.

But there are methods that can make developers work calmly, keep delivery at high volume and backlog stack small (as much as possible), and still leave us with enough time to grab drinks together and plan fun days.

Seems to be much better than moving to a forsaken moon 🌒

Let me know how your team handles these issues…