Back to articles
How I went from .NET comfort to shipping AWS serverless code in 90 days
Before joining Runa, my development world revolved around .NET. Every company I’d worked for used a similar architecture, tools, and “ways of working”.
Over the years, I became very comfortable in that environment - I knew the frameworks, the patterns, and where the tricky bugs usually hid. But that familiarity also meant fewer surprises, and I was ready for something that would push me to learn again.
Then I joined Runa - a team made up of people from all kinds of technology backgrounds, bringing different perspectives and ways of thinking. In practice, our architecture is firmly rooted in AWS and serverless, but the diversity of experience on the team meant I’d be learning a lot of new approaches.
On my very first day, everything was new. And I decided to lean into that.
I was offered a choice between a Windows or MacOS machine. I could have stayed in my comfort zone since I had only used Windows professionally… but instead I went with MacOS. If I was going to shake things up, I might as well go all in.
That meant learning hotkeys, window management, and a whole new interface from scratch. Luckily, my colleagues jumped in with tips, shortcuts, and “must-know” tricks that made the transition a little less bumpy.
Little did I know, that same “lean into the new” mindset would define my first three months.
First impressions and feelings
In the first few days, I was hit with terms like serverless, lambdas, step functions, API Gateway 🤯 - all completely new to me.
It was exciting, but also a little overwhelming - a mix of new tools, rapid learning, and the occasional “Is this job for me? Am I a good developer?” moment.
What kept me moving forward was Runa’s well-structured onboarding plan. It gave me milestones to hit, resources to explore, and documentation that made the learning curve feel less like a cliff.
I still remember closing my first ticket after just one week.
It was a low-priority task - just a couple of lines of simple code for a bug fix - but it felt incredibly satisfying to contribute something tangible to the team so early on ✅.
After that first win, I knew I could keep making progress - but I also knew I’d get there much faster by learning directly from my teammates. That’s where pair programming came in.
Pair Programming
With many new domain specific acronyms, tools, and even a brand-new IDE to get used to, I quickly realised I could spend days just trying to figure things out on my own.
Instead of reinventing the wheel, I started pairing with different teammates.
Each session was like a guided tour of the codebase - seeing how others approached problems, exploring different areas of the project and architecture, and walking through diagrams of the system.
This wasn’t just about learning shortcuts; it gave me a deeper understanding of how things fit together and how I could start making meaningful contributions.
One pairing session in particular stands out. We have two repositories with almost identical names 🙈. I had been quietly wondering for some time which was used for what. My teammate walked me through the difference, what they are used for and when we should make changes to them. It was such a simple explanation, but it instantly cleared up a big source of confusion and made the codebase feel a lot less intimidating.
That kind of teamwork not only saved me time, but I could now see more clearly how everything fit together and how I could start contributing effectively.
As I got more familiar with the codebase, I also started noticing how we made technical decisions - and that’s when I was introduced to something completely new for me: technical decision documents.
Technical Decision Documents
In previous companies, technical decisions often happened in quick calls or came as top-down instructions from someone in a more senior position. We’d agree on a solution, implement it, and move on - but rarely did we document the why behind those choices.
At Runa, it works differently. Every significant technical decision is captured in a decision document. It’s a structured write-up where we outline the problem, propose different solutions, list the pros and cons of each, and record the reasoning behind the final choice.
At first, it felt like extra work - until I wrote a few of them.
I realised how valuable they are especially when you’re new and trying to understand why something was built a certain way. You can trace the thinking that led to a particular solution without having to dig through endless chats or schedule extra meetings.
My first decision doc was… rough 😅. The structure was sloppy, I missed some important details, and it took several rounds of feedback before it was finally accepted. But that back-and-forth forced me to fully understand the problem I was solving. By the time it was accepted, I knew exactly what to build - and I could jump straight into implementing my tickets without hesitation.
But even with all that documentation, there were moments when I needed answers right away - and that’s when AI became one of my onboarding accelerators.
And, of course, AI
Everyone’s talking about AI these days - how powerful it is, how risky it might be, whether it will replace developers.
For me, its biggest impact during onboarding was much simpler: it helped me understand the codebase faster.
When I was stuck trying to figure out how a feature worked, I could ask AI to walk me through it - from where it was built, to where it was used, to how it was tested.
Having that map in my head made it much easier to extend features or fix issues without feeling like I was poking around in the dark.
I also found AI surprisingly useful when working on automated tests 🤖✨. It could suggest a rough starting point, which I could then refine and adapt to fit the project.
All these tools and habits I’d picked up in my first weeks - from decision docs to pairing and even AI - were about to be tested when I joined my first large-scale initiative: a design sprint.
Design sprints and POCs
At Runa, when we face bigger, more open-ended challenges, we tackle them with design sprints. We split into smaller groups, spend a few days exploring possible solutions, and build quick POCs (proofs of concept) to see how those ideas would work in practice.
These sprints aren’t just about coding fast - they’re about experimenting, validating assumptions, and making sure we choose the right direction before committing to a full build. Decision documents play a big role here too, capturing our thinking so it’s clear why we moved forward with one idea over another.
Recently, we kicked off an initiative to solve a specific problem, and we gave ourselves the time and space to experiment. We came up with three very different solutions - not just in code, but also in the infrastructure they required. While building the POCs, we changed our minds multiple times, each time spotting where that solution might fail, become overly complex for our use case, or simply not deliver the value we expected.
It was a little exhausting to switch directions so often, but every change taught us something new. Instead of clinging to ideas, we treated each discarded POC as a step toward finding the right approach.
Working on these POCs turned out to be one of the most valuable learning experiences of my first three months. I could try out ideas in a low-risk environment, get quick feedback, and see firsthand how we make decisions that shape the future of the product.
Key Takeaways
Looking back, my first three months at Runa were a mix of steep learning curves, small wins, and a lot of “aha” moments.
I joined from a completely different tech background, learned an entirely new stack, and went from being overwhelmed by acronyms to shipping meaningful work.
Pair programming sessions, technical decision documents, AI assistance, and design sprints all played their part in helping me get there.
If I had to sum up my onboarding into a few lessons, they’d be:
- Lean into the unknown. From a completely new tech stack to tools I’d never touched, every unfamiliar step helped me grow.
- Ask, pair, and learn from others. Every teammate sees the system from a different angle, and that perspective is gold when you’re new.
- Don’t get attached to your first idea. The best solution often comes after you’ve explored (and thrown away) a few others.
- Write things down. Decision docs aren’t just for the team - they’re a gift to your future self.
- Use the tools that help you learn faster. Whether it’s AI or just good documentation, find your accelerators.
Three months ago, I was wondering if I could keep up - now I’m contributing, learning, and excited for what’s next.
