Ask the user, ship the fix

Staff at the Immigration Office's register residents, plan their stay, track their documents, file their inventories and more. Almost all of it runs through one platform. We build that platform.

It replaced its predecessor after two and a half years of work, which already tells you something about the size of its scope. It is now being extended: more functionality, more users, more data. So it is a good moment to say what this work actually looks like for the backend engineers building it.

The stack

C# on Azure. SQL Server. A handful of microservices behind one global API, with API Management in front of it. Angular on the front end. Files in blob storage. Authentication straight through Microsoft, because every user already has a government account, so there is no identity layer of our own to build or babysit. Application Insights for monitoring. Four environments. Infrastructure as code in Terraform, shipped as Docker images through Azure DevOps pipelines.

We work inside the client's setup

This is data about people living in the centres. Names, documents, medical records. There is no version of this system where casual access is acceptable, so there is a serious setup around it.

The client's cloud team owns the infrastructure. We work with their Terraform templates, and Azure pipelines to deploy. We go through a managed environment to reach anything sensitive. Access to a new environment starts with a formal request that has to be specified up front. It takes time.

"Better slightly too much security than slightly too little. Certainly in government." — Julien Cambier, Back-end engineer @ In The Pocket

That is the deal, but that governance is there for a reason. Adapting to how a client like this works is part of the job. There is still a lot of freedom. The code is ours. Package choices are ours. Architecture decisions are ours, made in conversation with the client rather than handed down. 

"We're in charge of the code itself. On packages we have a pretty free hand." — Tobie Devries, Back-end engineer @ In The Pocket

Closer to users than backend engineers usually get

Backend engineers normally sit a long way down the feedback pipeline. Someone talks to the client, someone writes it up, someone prioritises it, and a ticket eventually arrives.

We have a different look on how great products and platforms are made.

"As a backender you sit deep down the feedback pipeline. You'd expect to never hear from the client. Here you do, and in a good way." — Julien

Sometimes that means getting out of the building. The team visited one of the centres and watched badges come out of the machine, on a dedicated plastic badge printer. Some of them were not readable enough. The team was triggered. They made the tickets themselves when they got back, and got to work.

As Tobie put it: normally a feature like this stops at a PDF written to disk. What happens to that PDF on paper is somebody else's problem.

Here, the team cares. Julien sends a PDF over Teams to someone working in a centre and asks them to print it. A photo comes back. There is no faster loop available than that, and the people on the other end can tell they are being taken seriously.

The same speed shows up across the collaboration. A ticket lands in the morning saying something is broken, and it is fixed before the end of the day. Praise from users lands in the team channel too, which backend engineers do not get nearly enough of.

"I come from clients where a user could never contact me directly. Here they can.” — Tobie

Some of it never leaves the team. Our team speaks to the client often enough that most open questions are answered in a five minute conversation internally. It is what it looks like when the roles on a team actually work together on one mission..

Technical improvements become product improvements

When a team sees how their product is used, they become more proactive. Proposing changes, instead of waiting for instructions.

Data that users filled in by hand is now being calculated and shown automatically instead. It saves someone time, every day.

A bigger one: pulling together information scattered across documents, inventories and other records, and turning it into a single list users can export. That was a nice engineering problem. The volumes are large enough that a naive implementation crawls, and it had to stay fast as the platform grows. It was built to be extended.

That’s a conversation we have often: “We probably do not need this yet, but we will, so let us not make it hard later.”

The trade

You give up some of the immediacy engineers take for granted, and you learn to work with a bit more process than you are used to.

In return you know exactly who uses what you build, you can ask them directly, and you can see what a clearer badge or a shorter queue does to someone's day. In a job that already carries plenty of frustration for the people doing it, software that simply works counts a lot.

We gladly make that trade. If you do too: we are hiring backend engineers.