Freedom to choose your (engineering) hammer

In medieval times in order for a carpenter's apprentice to achieve the rank of master craftsman they needed to make their own set of tools. They needed to show their skill and understanding of the craft by making hammers, axes, saws, chisels etc. This was both a way to showcase what they'd learned and a way to prepare themselves for future work. Thus, a set of hand-made tools was a point of pride for a master carpenter. We as software developers can share in this sense of pride.

Picking the right tool for any particular problem can mean a lot of things. Starting from a choice of OS, a code editor and AI coding agent you want to run, on to programming language or a set of libraries to work with, all the way to picking between Kafka and RabbitMQ for your particular message streaming use-case.

At Infobip, we believe in empowering developers to make these choices.

We are product oriented, which is another way of saying that our teams are owners of applications that they build. A team is continually presented with new technical problems that they need to solve. It's up to them to pick the solution, implement it, support it in production and expand upon it with future features. You build it, you own it.

Whether your customer is an enterprise client using our platform or an internal team or employee relying on the tools and infrastructure you build, ownership and accountability work the same way.

Picking the right tool usually starts with research; looking into existing solutions, prototyping and validating them, accelerated by use of AI tooling. During this you can lean on a large engineering community inside Infobip for guidance and experiences. But it's up to the team that's working on a given service to agree on the best solution, as you are the ones that are the domain experts. Ultimately it's delivering the solution to our clients that matter, but in the end, you and your team are the ones who will have to live with the consequences of this choice.

On the software platform level we try to support varied choices of technology and tools in a generic way. For example, if the app is packaged in Docker image you can use standard deployment pipeline to manage it. And we have pre-made images for popular tools like Redis, RabbitMQ or Postgres that help them fit into our service discovery, health monitoring, metrics collection etc. Most of our existing backend services are written in either Java/Kotlin or C#, but we are increasingly turning to Go and Python for specific use-cases that they excel in. Even picking the language is up to you, and you'll likely find other proponents of your favorite tech stack within the company.

If no existing solution meets the specific use-case we aren't strangers to rolling out our own. There can be benefits to crafting a custom tool to solve a particular problem. This is where the experimentation comes in: you can put together a prototype, compare it to existing options and pick the best performing one. We don't put barriers between research and development. They are both parts of our standard development cycle, all carried out by our dev teams. In addition to offering cool learning opportunities for knowledge eager engineers, this also helps the company keep innovating and adapting faster.

Our micro-service architecture helps with this pick-your-own tech stack approach. Services communicate with JSON over HTTP, so it doesn't matter which language any particular app is coded in. It also means that you can keep up to date with the latest versions of your preferred language and runtime. Would you like to utilize the latest Java version to benefit from new features and performance improvements? Sure, feel free to do so. Looking to experiment with a new distributed database that appears to match your needs perfectly? No worries - feel free to explore and choose the best tool for the job. This is how we are keeping up to date with the latest technology trends. Not every service is running on the latest language versions, but we do have access to all the latest options and the freedom to use them where they matter.

In the end there's a special kind of satisfaction that we as software engineers get from choosing and implementing a solution on our own. It's a mixture of mastery over the technology and pride in a job well done. You'll never get to know limits of a tool without stress testing it and comparing it to other solutions on the market. And you won't get the same sense of achievement from rolling out one cookie-cutter solution after another. Being handed a challenging problem and open hands to find the best solution is where it's at.