Cultural Pillars at Esfera: Technical Excellence

When we started asking around at Esfera about how we perceived our own culture, many people noted that as an organization, we strived to be a benchmark for technical practices in this software and agile methodology space. We asked how we self-perceived our culture, and people mentioned product quality, flexibility in choosing the best technology for the problem at hand, continuous improvement, and agility, among other things.

The truth is, being at Esfera conveys just that. Beyond being part of a team that safeguards its product quality, you see it when we interact across teams. It’s very common to run into people in Esfera’s hallways (now mostly virtual) asking about a technology or practice, challenging the way we do things, or asking about past experiences or book recommendations from the community. If you visit the office, the first thing you see when opening the door is a library with several books available to browse. We also share a lot of virtual reading material, but physical books have that certain je ne sais quoi that’s hard to replicate with a PDF.

Once we start learning something, we love to share it. We host internal talks and training sessions to share our experiences using different practices and technologies. We don’t need to be experts to drive a space at Esfera where we learn collectively; sometimes it’s as simple as, "Hey, I want to learn Angular, who wants to get together and mess around with a small side project?"

At some point, what we were sharing internally, we wanted to bring to others. That’s how Esfera Conf was born, which recently had its second edition—this time open to the public. The conference featured several talks (mostly given by Esféricos/as) and was packed with everything we naturally want to share about technical excellence.

We also make heavy use of practices like pair or mob programming to learn and teach regardless of seniority. We’ve noticed that a good portion of the software community remains skeptical of these methods—people who believe the co-pilot in pair programming would be more "productive" working on their own task (though what defines "productive" is up for debate over a cup of coffee). Perhaps many people at Esfera felt the same way at first, but if one thing defines us, it’s testing and experimenting. Experiencing these practices firsthand helps us form a well-founded opinion on whether something truly works for a specific use case.

What Pair Programming Might Sound Like

Experimenting with technical practices also forces us to constantly question when they don't work. For example, pair programming is a great tool that we use often, but overusing it can be counterproductive or ill-suited for certain personality profiles. The key is always balance, and if there's one thing I’ve heard a thousand times at Esfera, it’s that there is no silver bullet. Understanding the problem in front of us will always be more important than implementing innovative techniques. If all you have is a hammer, everything looks like a nail.