Chapter 1 ended in 2017 with a Jenkins plugin and a wish to grow upward instead of sideways. This chapter covers the years since.

Production engineer Link to heading

My degree is in production engineering, not computer science. Production engineering is the study of processes: mass, batch, manual, tiered, any way of turning inputs into outputs with people and machines in between. Understanding a process and explaining it to the people inside it is the one skill from that degree I use every day.

One idea from it stuck: poka-yoke, mistake-proofing. In college I read it as “prevent errors”. It took years of platform work to see the real point. You remove the mechanism of mistake so the person can spend their attention on the part of the job that needs it. That is developer experience in one sentence, and I did not know it until I was doing the job.

A small example. One Jenkins pipeline deployed Kubernetes clusters on GKE. Its inputs were free text boxes: fill in the values, hit run. A typo failed the pipeline, and if you did not know the valid options for a field you went off to the Google Cloud documentation to find them. I fixed both with awesome-jenkins-utils: the text boxes became choice lists with sensible defaults. Fewer failed runs, and nobody had to leave the page to find an option.

Time saved is the side effect of good developer experience. The gain is attention: the work gets the part of the brain the form used to take. I deliver what is asked, on time most of the time and late with a reason the rest. I do not call a task done until I am satisfied with it. That habit has cost me deadlines. It has also produced the work I am proudest of, and it is what pushes me toward better and more personal developer experience, so I keep it.

The cloud startup, 2017 Link to heading

The startup did DevOps consulting and built a SaaS product around DevOps automation. I joined as a team lead on the cloud management product. The part I built with my own hands was the automated containerisation of legacy Linux applications: a Go tool that watched a running process through strace and the proc filesystem, worked out what it touched, and produced a container from it. The strace fork we needed for that is public.

With my mentor’s help I backported Go 1.10 and its compiler to CentOS 5, a 2.6 kernel with glibc 2.5. It was my first time working at the compiler level, and it is what made automated containerisation possible on that generation of Unix and Linux systems.

The rest was leading: a React frontend, a Node.js backend with a role-based API, moving the product itself to GKE, which cut the cloud bill by a quarter, a Terraform module we sold as a feature, and a scheduler that paused idle EC2 instances to save customers money.

Leading a product and a team, on the technical side or the people side, is more than one person’s job. I never had to lead the product much, and the company was lean enough that the people side was light. The technical side was the challenge, and I loved it.

My seniors and colleagues there were a joy: daily exchanges, random discussions, and work that kept me engaged. The exposure to DevOps and cloud engineering there is what got me the next job, in the Netherlands.

The sports streaming platform, 2019 Link to heading

The interview came through Stack Overflow Jobs, since closed. It went well, with a lot of deep technical questions. The behavioural round was the first I had ever had. It went well too, and it showed me how things work elsewhere.

The offer came with visa support. Apostille birth certificates, the embassy appointment, the document submission, all smooth. The photos, which had to be the right size and angle, were a last-minute scramble. I bought my own tickets and arranged my own stay for the first couple of days.

I landed alone. Walking into the new employer’s building for the first time was ASMR, a tingle down the back of the neck. The first days were formalities, and the company provided a relocation agent to find an apartment. We got a three-bedroom penthouse with a view and a good neighbourhood. My family joined me after a month, and a new life started.

A few things surprised me in the first month. Portion size and price do not always match, and I was not eating at fancy places. Public toilets are rare: malls, multi-storey shops, even restaurants with more than ten tables often have none. Grocery prices for the same brand and the same product vary a lot from store to store; there is no printed maximum price the way there is in India. The weather I knew about, so it did not surprise me. It felt gloomy at first, and the warm light everyone uses indoors helps more than I expected. You stop missing white light at home and in restaurants.

One thing I learned only when leaving the Netherlands, because nobody told me and I never read up on it, concerns the driving licence. I had handed in my Indian licence to get a Dutch one without a test. What you are meant to do is collect the original from the Indian embassy once the Dutch licence arrives, or when you hand the Dutch one back; I still do not know which. After seven years my licence was lost somewhere between the RDW and the embassy, and nobody knows where.

I joined the payments team as a backend engineer, building 3D Secure integrations with Klarna and Paynow on Node.js and AWS Lambda. Then I moved to the developer experience team in platform engineering, which is the corner of engineering I have stayed in, in one company or another, ever since.

There I rewrote the frontend deployment tool so that multi-region, edge and versioned deployments stopped being a ritual, and release cycles got about a fifth shorter. I maintained the internal Go CLI engineers used for AWS account access, encryption, tunnels and changelogs.

The company decided to move from Drone CI to GitHub Actions. A principal engineer and the cloud engineering team led it; my team’s job was to migrate our own pipelines and help where our tooling was involved. I wrote a CLI that translated Drone CI YAML into GitHub Actions workflow YAML. It saw little use. Most teams translated their pipelines by hand, and with many senior engineers who already knew GitHub Actions, that was the faster path. The tool still taught me how GitHub Actions works and, more useful later, how a migration to it goes.

One thing I learned there and used later was inner-source. A colleague led it and translated the CNCF process into an internal one for building an inner-source community and projects. He left before it was finished. It was developer experience work in the full sense, and the best example of it I have seen.

Later another principal engineer led the Backstage rollout and I contributed: code for a custom plugin, and small help with an internal tool, PRR, the pull request review board, which later became a Backstage plugin. Backstage is well built. I doubt it fits most large organisations. Most large organisations run on Confluence, SharePoint and the like. Few have people who keep architecture and code documented in Markdown next to the code, and Backstage needs that to stay useful. Its promise is easy visibility of services and their owners, and most large firms already have a CMDB that answers that well enough. Backstage earns its keep in organisations of more than five hundred engineers who move between teams and start on unfamiliar systems often. For most large firms the cost of implementing and maintaining it outweighs what it gives back.

I tried for principal engineer there more than once and did not pass. At the time I believed I had everything the role needed. One piece of feedback, “you lack power of influence”, I heard as “you are not famous in the company”. Back then the two meant the same thing to me. Power of influence comes from relationships, from how you articulate a point, from how you handle someone who does not share your view, and from going into a hard conversation with a strategy and changing tactics inside it.

My manager in the DX team carried me through a lot of stress in those days, and I thank him for it. Once or twice my behaviour was unprofessional. No insults, no anger, but not professional. Work was one reason. The main one was personal: I was missing my family, and in India family means wife, kids, parents and siblings. How that shaped those years is something I am still unpacking.

I stayed longer than I should have, unhappy with the work. In a culture that open and that agile, you have to put yourself forward to get the interesting projects. Stay quiet and you get the simple tasks, nothing long-running, because the long-running work goes to whoever positioned themselves for it. I understood that a couple of years too late. Had I known, I would not have left.

The Dutch flight booking platform, 2022 Link to heading

Another product company. They sold flight tickets and were big in the Netherlands, the EU and the Americas. The interview was a coding task, a review and a technical discussion, followed by a good offer and an office in the centre of Amsterdam.

I joined the system tooling team. Again: CI/CD, CLIs, the monitoring stack.

The company ran an in-house CI, Estafette, built by one person. It was good, and it was ageing: new features had stopped and the author had left. It had become a burden and had to be replaced. My team lead and I set out to find the replacement and landed on two candidates, GitHub Actions and GitLab. We both did the analysis, the documentation, the comparison and the recommendation. The recommendation was the contested part: he wanted GitLab, I wanted GitHub. After more than a week of back and forth we settled on GitHub Actions. I was glad the facts carried it, and to his credit he tested every single point before he agreed. Three facts carried it: cost, community support, and the ability to break scripts into steps that pass information forward. The company approved it and planning started.

One problem: the source was Bitbucket Cloud, and with a custom CI in the mix GitHub offered no automated migration, only a paid service the budget did not cover. That may have changed since. So the plan was to move more than a thousand repositories and the CI with two engineers, my team lead and me. My Drone-to-Actions CLI from the previous job turned out to be useful after all.

We built the migration tool in-house. It cloned each repository from Bitbucket to GitHub, applied the new default settings, and set team and individual permissions. Permissions were the hard part: onboarding engineers, placing them in the right teams, and giving each team its repositories, which raised the question nobody had written down, who owns what. We went repository by repository through commit history and Slack threads to find an owner, or someone willing to own it, or to conclude it could be archived and skipped.

Two things from that period I still bring up in interviews. The first is a Terraform provider for the identity management service, so that a single pull request in the IaC pipeline could manage access to repositories. The second is protoc-gen-gotf, a Go plugin that generated about eighty percent of a Terraform provider from gRPC proto files. It is useful if you already have gRPC services and want the provider skeleton to follow the proto. It never handled reconciliation, a gap I knew about and never fixed because it never bit.

I built more than a dozen GitHub Actions there, in a TypeScript monorepo, and shared workflows with a workaround for the reusable workflow naming problem that GitHub has still not fixed. wait-for-jobs came out of that period too; there is still no native alternative.

The tool had migrated about thirty percent of the repositories when I left. My team lead told me later it took the rest to a hundred with a few changes. GitHub would have found it worth a look.

The company was unstable then. A merger with the buyer was on hold because of COVID, and I watched a lot of people leave, and started looking myself, with regret. There was a second reason. I expected a promotion and a colleague from another, larger team got it, with different expectations on their side. My manager did not handle it well. He deflected instead of stating the reasons, and that opened a rift between us that took a year or two to close.

The chemical distributor, 2023 Link to heading

2023 started in our own house in the Netherlands. It was a period of not knowing whether to stay or return to India. The atmosphere, the work, the living, the people were all good, and the heart was restless. After years of talking about it, we bought the house to commit to something instead of living in limbo.

The interview was demanding: no coding, several technical interviews online, behavioural rounds. The last round went so well that they offered forty percent over my previous salary, which at my level in the EU is something to be proud of. Two days before I started they sent a bouquet.

I joined the DX and CI/CD team. Everyone on it was strong. They had already built a lot: the CI/CD itself, and an AWS Service Catalog product for runners that engineering teams could deploy and manage themselves.

My first job was onboarding Artifactory for the engineering teams: an AWS Service Catalog product for using Artifactory from AWS resources, and a CI/CD component for using it from pipelines. I built both. The design had a fatal flaw. The Service Catalog product was bound to one account and one region, and it was the core of the runner integration, so every region needed its own copy, we had to ship to every region, and every engineering team had to maintain accounts times regions of products. This is where Terraform and Terragrunt earned their keep. I designed an internal repository where one pull request gives a repository or project its Artifactory API tokens through GitLab variables. GitLab variables lacked two features for that, which I contributed to the GitLab Terraform provider. Tokens rotated on a schedule without failing running pipelines, by overlapping the old and new secret for a fixed window. The terraform-repeating-sequence module came out of that: blue-green on a Terraform resource by repeating steps between applies.

Then a GitLab component for Snyk, so any project could run scans with sensible defaults, and a container power tool: shell scripts around kaniko that build, scan, push and tag images inside GitLab CI/CD. Scripting is my favourite thing after writing programs, and it keeps giving. Neither is public. Both were built around company specifics, and the company had no path for publishing code. I thought about building one. It was not worth it then: the first public codebase would have needed documenting, planning, explaining and approval before a line went out.

A colleague led managed GitLab runners on Kubernetes, which made the Service Catalog runner product obsolete. That was the right moment to deprecate it.

Then came SDLC and ServiceNow. As the DX team we had to own the SDLC process so it was consistent and efficient for every kind of team. Many sessions, many heated arguments, and unprofessional behaviour from me and from colleagues. I clashed with one colleague more than once, and the last time crossed a line on their side. My manager gave me support and clarity about what I could expect, and I decided to move on. A couple of months of searching, and I had a new role.

The banking platform, 2025 Link to heading

This was the last stop in the Netherlands. I was promised a platform engineering team to start and found myself on a migration from Nexus to AWS CodeArtifact, which after Artifactory feels wrong on many levels.

I built CI/CD automations and helped put DORA metrics into Grafana and Prometheus. That was it. The job lasted six months, and by then I had reached a conclusion.

After many conversations, my wife and I agreed that returning to India was what we both wanted. So why not now? Nothing stood up against that question. I wrote a short LinkedIn post about the reasons. I wrote that post to let the emotions out and to capture some of the thinking at a turning point in my life. It may become a post here, if I keep up the writing.

I resigned, told my family, they cried, and we came back to India in January 2026.

Things I left in the open Link to heading

Tools I built along the way that are public. Each one exists because a real pipeline needed it.

  • protoc-gen-gotf: a protoc plugin that generates a Terraform provider from Protobuf messages and services, plus skeleton code that only needs the gRPC calls filled in. Started at the flight booking job as sole contributor. It keeps the provider schema in step with the Protobuf fields, so the provider does not rot.
  • go-grpc-hmac: an HMAC interceptor for gRPC clients and servers that needs only a secret provider function.
  • go-shutdown-graceful: watches for signals and shuts an application down without dropping work in flight.
  • trivy-cache-action: caches the Trivy vulnerability database in the GitHub Actions cache, which matters on self-hosted runners.
  • wait-for-jobs: a GitHub Action that holds a job until named jobs in the same run succeed, so a job can start early and wait at the right point.
  • pod-dependency-init-container: an init container that waits for the pods it depends on.
  • k8s-update-ecr-creds: a CronJob with RBAC that refreshes the ECR login token, for clusters outside AWS pulling images from ECR.
  • awesome-jenkins-utils: scripted pipeline helpers from the Jenkins years.
  • job-fan-in-plugin: the Jenkins 1.x plugin from chapter 1, outdated now, that triggered a downstream job on the stability of several upstream ones.
  • lua-import: relative imports for Lua modules.
  • strace fork: the probe behind the containerisation tool at the cloud startup.
  • Contributions elsewhere: Estafette, the open source CI from the flight booking job, where I added pipeline archiving, build control for GitHub repositories and log cleanup; the GitLab Terraform provider, where I moved the group variable resource and data sources from the SDK to the new provider framework and added masked and hidden variable types, with the matching go-gitlab change underneath; and a fix to a Terraform module for AWS CodeArtifact during the artifact storage migration at the banking platform.

Why I write this Link to heading

I started these posts to condense thoughts that had run loose for years, to let out pressure that had built up, and to re-learn things I once learned in a hurry. A side effect: the people I work with next can read this and decide for themselves whether they want to.

For most of my career I used a language or a tool for a few months and moved on without understanding the mindset its author had. That is the biggest brake on my growth now, and writing is how I am taking it off.

This year has brought new engineering adventures. The next post in this series waits on a milestone I have not reached yet.