For a long time, software was just my job. It was not my passion, and I was fine with that.

What changed that was not a new language or a faster framework. It was learning how to work: with people, with process, with care. And it took a few specific people to show me the door.

When it was just a job

I studied Telecommunications engineering, and somewhere along the way I ended up writing software. Mostly C, whatever the job needed. This was before coding got its glamour. Nobody said “best practices” out loud. Testing was barely a habit. “Agile” was a word you might have skimmed once in the business pages of a magazine. Scrum, Kanban, linters: none of it existed in my world. Life happened in Bash, in scattered text notes, and in the Eclipse editor.

I wrote code that worked, and I went home. If it ran, it was done. I was not unhappy. I just did not feel much of anything.

Agile, and a different universe

The first crack of light came in Germany, where I joined a research company affiliated with a university. The team took Agile seriously, back when it was a trend there and had barely reached Spain. I turned up expecting to write code. Instead, I found people who wanted to talk about how we wrote it.

At first it felt like a detour. Long conversations about process. My first real sprints. People asking not just “does it work?” but “will this be easy to change in six months?” and “how do we estimate this properly?” The question was always how, before the doing.

Most of that I learnt from Imanol, the tech lead on my team. We would run a planning session, but first we would talk about how to run a planning session. We took estimation seriously, and moved to story points; it changed how we planned around the team’s real capacity. “Forget time relation, give me your points,” Imanol used to say. “Eventually you will start thinking in points when estimating.” It sounded slow at first. Then, little by little, it stopped feeling slow and started feeling like a different universe.

We started thinking about sustainability too. How do we keep this alive and working over the long term? Coding was not about stringing instructions together to get a behaviour. It was about writing something another human could read, months later, without cursing my name. Thinking about the future, and about other people, quietly changes what you do today. I stopped building things to work for now. I started building them to survive change.

Step by step, I moved into Scrum. I brought quality into the conversation. I slowed the rhythm down on purpose, which felt wrong and turned out to be right. We even helped the company make the full move to Scrum. It was not easy, and it is still one of the things I am most proud of. That work carried me back to Spain with a job in hand, in the middle of the crisis, when everyone else was heading for the door.

Without noticing, I had stopped learning what to build and started learning how.

The review that changed my mind

Back home, I was still learning to code in Ruby properly. Junior in the code itself, but carrying everything I had learnt about Agile into the project.

I was working on a feature with one of the main developers on the team. The code review was brutal: ten or fifteen comments on a pull request of barely fifty lines. Abstractions, dependencies, refactors. Comment after comment, and each one landed. I took it a little personally, the way you do when you are tired and a little proud. Then, instead of stewing, I asked him to jump into a pair session together.

We opened the code and refactored together. He walked me through it one change at a time, thinking out loud, and something shifted. For the first time, I saw code as something close to living art. Not a wall of instructions, but a thing you shape. We were focused on the code, on how to make it better, finding beauty in the process.

At one point I asked a question, half expecting to look stupid. He stopped and said: “Right. That is what makes you grow fast. You are asking good questions.”

He did not just fix my code. He showed me how to think about it, and how to sit with a hard review instead of hiding from it. Another person, opening the same door.

I had walked in with the sting of a nasty review. I walked out wanting to be better at this. Same afternoon, same code, a completely different feeling.

What the how gave me

That was when it happened. The work I had not cared about started to feel good. Not because the tasks changed, but because I did. It was no longer just writing code. It was making something properly. Something I was a little proud of. Something, honestly, beautiful.

The how had opened a whole dimension I did not know was there. And most of all, it came from people: how we talked, how we disagreed, how we carried each other along. It was about process, how the work flowed and how a team held together. And it was about quality, how you build something today so it survives tomorrow.

None of that came from a book. Every piece of it came from a person. Imanol and the team in Germany, who cared about the way we worked. The developer who turned a harsh review into an afternoon I still remember. Take those people away, and I am still writing code that runs, going home, feeling nothing.

That is the part I most want you to hear. You do not always have to start with passion. Sometimes you back into it, through the how, guided by the right people. Passion can be built.

You do not get to choose every teammate or every process. But when you can, choose them on purpose. They are what decide whether the work is a grind or a craft.

I started out as a developer with no real love for the job. The how, and the people who taught it to me, are the whole reason that changed.