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
One idea from my production engineering degree that 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’s developer experience in one sentence, and I didn’t know it till 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 didn’t 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 less focus break and more attention: the work gets the part of the brain the form used to take.
One observation I had about myself I try to deliver what is asked, on time most of the time and late with a reason the rest. Most of times the reason for the delay was excess DX implementations.
I don’t call a task done till I’m 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 and the learning.
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. This did grow up to be more than containerisation in the product, rather it spun off a completely different feature in the product.
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.
My mentor there is really well articulated, with deep understanding of Linux, Cloud and DevOps. He was also kind to point me time to time in right direction in technical decision making like distribution of private binary, using IPC rather than shell redirects and logs.
The rest was leading: a React frontend, a Node.js backend, and a move of the product itself to GKE that cut the cloud bill by a quarter.
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. I applied directly, no agency and no consultant, and what worked was going after the less obvious openings, in my case that was platform and CI work most people in my circles weren’t doing. The big names everyone knows have hundreds of applicants and you are competing on paper, while a smaller company hiring for something specific is where being unusual helps instead of hurts.
Small advice that I had by instinct: don’t pay anyone if they promise you a job, a visa or a way in outside of India. That industry exists because people are desperate, and the ones who are genuinely hiring don’t charge you.
The interview went well, with a lot of deep technical questions. It was mostly on AWS technology but not how you use it rather why and which situations will you use it. The exposure to majority of AWS concept was really helpful back then.
The behavioural round was the first I ever had as a separate interview. Most of the questions were about collaboration, tackling inter-personal difficulties within team. Importantly experiences that I had in my career that were not technical or their topic was technical but situations was something else, I did not had lot of those so for some of them I did said so for few from them I explained what I will do if I were in that situation. That went well and it showed me how things work elsewhere.
They offered €75k with 30% ruling for five years which I didn’t knew what it was. I had to buy my own tickets and arranged the stay for first couple of days. I did not knew how much I will get in hand monthly and if it was enough for my expectations. I had to reply with in 24hrs.
I started browsing sites like numbeo, blog posts about Amsterdam, Netherlands. Calculated based on what I had to pay monthly and what I would spend monthly and how much I would be left with. I had a 13 lakh loan in India running so that was one factor in calculation too. If I relocate I had to do it with a family of three, so the calculations were based on everyone’s needs and not wants. Cause the calculations were changing drastically based on living situations, lifestyle. But my wife and I came to conclusion we may not live in lavish life but it will be comfortable. So we accepted the offer.
Small general advice that I found on forums asked by Indians were generic and sometimes slightly different from ground reality, mainly because people project their expectations in advice and it always is based on their living conditions and comforts. Simply find Indians actually living in the country or better working in the hiring organisation and ask about day to day things and financial spendings bluntly, for example. How much do you pay in taxes and insurance? How much is rent, is the locality good? How much saving can I expect as I have this much offer?
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. Then shopping, planning first few days, weeks and the month. I was nervous mainly because this was my first travel outside of India.
I landed alone, went straight to the accommodation, dinner in same premise and straight to bed as next day I had to report the office. Next morning walked into the new employer’s building, for the first time I clearly understood what ASMR was. The first days were formalities, and the company provided a relocation agent to find an apartment. We got a 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 don’t always match, and I wasn’t 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 retail price the way there is in India. The weather I knew about, so it didn’t 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. You are meant to collect the original from the Indian embassy once the Dutch licence arrives, not when you hand the Dutch one back. 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. That team had all senior engineers, same or more experienced than me. Surprisingly I felt like I was back in college dorm rooms, luckily everyone was patient and understanding. For whatever time I was in that team it was good atmosphere and comradery.
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 helped update 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, my Go skills came handy and I learned additional skills in the trade.
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 and it needs something most places don’t have: engineers who keep architecture and code documented in Markdown next to the code. Without that it goes stale, and a CMDB already answers who owns what. It earns its keep past about five hundred engineers who move between teams often, and below that I have watched the maintenance cost outrun 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. I had one interview with principal engineer. The feedback was “you lack power of influence”, and I heard it as “you are not famous here” and dismissed it as a popularity contest. It took me years to understand what it meant, which is relationships built before you need them, articulating a point so it lands with the person in front of you, handling somebody who disagrees without it turning into a fight, and walking into a hard conversation with a strategy you are willing to change halfway through. None of that is dishonest. I just wasn’t doing any of 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. I had outbursts in team meetings, not pointed at any one person in particular. Work was one reason. The main one was personal: I was missing my family, and in India family means wife, kids, parents and siblings. Not having supporting people in my family, which included parents and brother, was causing toll on my emotional capacity. 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 before I might have not 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. GitLab had better security posture, more compliance support and data residency, which GitHub also supports now. The security posture was non issue as we didn’t needed single centralised security services in the git host provider. Compliance could be built and we did build it using Terraform later. But it went GitHub’s way on cost, community support and the ability to break scripts into steps that pass information forward, and to his credit he tested every single point himself before he agreed. That’s the version of the game worth playing, and you still have to argue, prepare, and stay in the room longer than is comfortable. 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 didn’t 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.
A Terraform provider for the identity management service came out of that period, so that a single pull request in the IaC pipeline could manage access to repositories. protoc-gen-gotf came out of it too, a Go plugin that generated about eighty percent of a Terraform provider from gRPC proto files. I still bring both up in interviews. It’s 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. We didn’t showed it to GitHub but they 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. I asked the reasons and process of candidate selection, 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. A manager who deflects instead of telling you why you didn’t get it is the part I still have no answer for. Mine was to get good enough that leaving was always an option, which is expensive, and I wouldn’t hand it to anyone as advice. It is what I did.
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 €125k, which at my level I am 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 wasn’t 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. For years I filed everything I didn’t like under politics. Some of it was. Most of it wasn’t. 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. CodeArtifact doesn’t support container images so you need ECR, which is fine, but it also doesn’t support Helm charts, Terraform modules or RPM packages.
I built CI/CD automations and helped put DORA metrics into Grafana and Prometheus, and that was the whole of it. By then I had been working with AI daily for about a year and it had changed how I work a lot. I write less code, not zero, some days 150 lines and most days far less, and I feel more useful than I did before it. None of that has shown up in my salary. My peak in the Netherlands was €126k and that is where it stopped.
The job lasted six months, and by then I had reached a conclusion. But it introduced me to lot of tools like mise and just, and I got to work with Junie AI.
The realisation Link to heading
I had left lot of personal experiences in and out of my professional life. They kept popping up same questions in periods, “Are we going to settle here?”. I cry most of times when I hear national anthem cause I’m ashamed of thinking I’m better or happy leaving India behind as if it could ever be behind me. It always was and will be in-front me. Some of people I talked to laugh at my thoughts, it’s fine by me after all not everyone values what you value or prioritise what you prioritise. I wrote a short LinkedIn post about the reasons. Maybe it needs its own separate post.
I can’t tell the moment last conversation triggered it. But after many paused and un-paused discussions my wife and I agreed that returning to India was what we both wanted. So why not now? And no answer stood up against that question. I wrote that post to let the emotions out and to capture some of the thinking at a turning point in my life.
I resigned, told my family back in India, they cried and got excited.
Back in India, 2026 Link to heading
The first thing I did after stepping off the jet bridge in India was साष्टांग दंडवत्. Then straight to home.
Within a month I started searching job, I had searched opportunities before coming but I needed time to settle first and one call I had in the Netherlands was so weird the recruiter asked in email why my timezone is showing wrong also LinkedIn do not give you good list of jobs in the country you are applying to. Two offers came after I got back.
First was very low-balled, I immediately rejected it. Second one I received an interview invite and I was hesitant to apply as travel time was my concern, so in the initial conversation I asked about remote work and got the reply, usually 3 days in week but we are flexible. However in actual offer it mentioned something else, and on asking, the recruiter said it’s company policy but it’s mostly up to the manager’s discretion. I was not in situation to spend 2.5hrs a day in travel that too with self travel as company did not had transportation facility, if you live in Pune you’ll know what this feels like and I had done this in 2015.
What I’m doing now Link to heading
I registered a private limited company this year instead, platform engineering and cloud consulting, services. Four months in it has no clients and no revenue. Registering it took a week.
The years of thinking about it were the expensive part.
I still sometimes miss the food, the quiet, the air, the people and most importantly my dog Zoro from the Netherlands. I left Zoro behind cause he wouldn’t have survived climate here, is genetically not build for this place.
But still I’m happy with my decision.
Things I left in the open Link to heading
Tools I built along the way that are public, each one 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.
A public repository that solves a real problem does more for a move than another certificate, of which I have none at the time of writing, not that certifications don’t help. Recruiters filter on the word “relevant”, engineers who read a repo do not.
What I was by 2025 Link to heading
At the end of the cloud startup I was an engineer who goes a layer down when the layer I’m on has no answer, strace and the proc filesystem and a compiler backport for a 2.6 kernel instead of reaching for another framework, and that is still the first thing I do.
By the time I left the streaming platform I was platform engineer and not fullstack, and the production engineering degree had finally become useful to me, cause taking the mechanism of a mistake out of somebody else’s day is the same job as poka-yoke on a shop floor, only the floor is a pipeline.
At the flight booking job I became someone who can move a thousand repositories with one other engineer, and most of that work wasn’t technical. It was going through commit history and Slack threads till somebody agreed to own a repository. And it gave me more experience in understanding ownership and the other DX aspects.
At the chemical distributor I was a specialist building for teams I never met: a GitLab component, a Terraform module, tokens that rotate on a schedule without failing a running pipeline, and documentation doing the work a conversation used to do.
By the banking platform I was six months of CI/CD automation and DORA dashboards, and I’d stopped learning. That is where I stopped asking what to build next and started asking where I wanted to live.
Typing the implementation was always the smaller half of this job. The rest was working out what problem we were solving, who owned the system, and what would break in production at three in the morning, and fourteen years in that is what I was paid for. Eight of those fourteen years were me noticing too late that I was growing sideways.
I can still take a process of any kind, explain it in simple terms, and name the step that eats somebody’s attention for nothing. That is the one thing I had in 2011 and have not lost.
What I would tell myself in 2017 Link to heading
- Power of influence is not fame. It is relationships, how you put a point, how you handle somebody who doesn’t share your view, and walking into a hard conversation with a strategy and changing tactics inside it. I heard it as “you are not famous in this company” and failed the principal round more than once on that reading. In your first years there is nobody to influence, so watch how the people who have it work and copy that.
- Build relationships with the people you don’t find likeable, they help you increase the influence in ways you don’t expect.
- In a flat and agile culture you have to put your hand up. Stay quiet and you get the short tasks, cause the long-running work goes to whoever positioned themselves for it. I understood that a couple of years too late.
- Don’t wait for your company to build a path for publishing code. The Jenkins plugin from chapter 1 is part of why the 2017 job came, and the kaniko scripts and the Snyk component are some of the best scripting I’ve done and nobody outside that company will ever see them.
- I push deadlines for better DX or product, which is sometimes a trade-off, and knowing why you take one over the other is the part worth understanding.
Why I wrote this and previous chapter Link to heading
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. I started looking back at it and realised the experiences I had so far are vague in my head. Importantly articulating it on paper had helped me in past but doing it in public helps more, as the feedback and questions you get help you express your own thoughts that never get articulated.
All of that is/was the biggest brake on my growth and writing is how I am taking it off.
The move out was easy and the move back is not. Seven years there, and I’m still digesting being back. Salary converts cleanly, the rest of it is work in progress. It is tougher here in some ways than it used to be, and tougher than when I left, but tougher is not always the same as worse.
The next post in this series waits on a milestone I have not reached yet. Ask me in a year.