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 and a code editor that you want to run, on to programing 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.

Picking the right tool usually starts with research; looking into existing solutions, prototyping and validating them. 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. By working on the service you become a domain expert and, in the end, you and your team are the ones who will have to live with the consequences of this choice.

There are no external approval processes, lengthy validations or oversight. Ultimately it's delivering the solution to our clients that matters.

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 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. You'd like to use newly introduced sealed classes to retain tighter control over your Java APIs? Sure, feel free to build your app on Java 17. You are tired of waiting for Java to introduce these features? No problem, use Kotlin. 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 it matters.

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.