This is the story of how I got hired to learn Java, was asked to assess a C# project after joining, and ended up writing a JavaScript plugin running on the Internet Explorer engine. And I couldn’t have been happier!
I am currently heading towards being between jobs, and I find myself a bit lost. What am I looking for in my next role? Do I want to get back to coding and being a solo contributor, or should I stick to leadership? Exploring different paths, I realized I’m not even sure what I would like from each role. What does my dream engineering role and job look like?
Looking for answers, I found myself reflecting on my very first job interview as a developer - a time when I wasn’t even sure if I belonged in the world of programming. It was a leap into the unknown, and the experience taught me more than I ever expected. That memory brought me back to a dreamy period in my career. I remember finishing late and thinking about what I was going to do the next day on my way home. I was excited, I was engaged, and I deeply cared about my project - more than I feel I’ve cared about anything in the future.
How Did I Even Get There?
At the time, I was still studying computer science on weekends and working as an IT consultant during the week. My job back then was in an old government building with mismatched desks and flickering lights. So when I stepped into the shiny new office in the center of Warsaw for my first day, it felt like a reward in itself. A brand-new, high-spec MacBook Pro - the second one I’d ever used - was the cherry on top. I’d been a huge fan of Apple for years but couldn’t afford one. Sitting there, surrounded by all that newness, I felt special and professional.
The company was looking for Java developers, and although I had only tried Java a bit at my uni, majority of projects I did in C#. Recruiter said that's good enough as long as I am willing to learn. I got the job, and so began my journey as a Java developer - or so I thought.
The Sentence I Gave Myself
Shortly after joining, the company re-discovered my C# background and asked me to assess a legacy project to see if it was salvageable. Nervous but motivated, I got to work. After my research, the conclusion was clear: we needed to rewrite it. But not in Java. The best option was JavaScript.
I remember being nervous as I presented my findings. Here I was, tasked with evaluating a C# plugin, and I was suggesting we start fresh with a completely new technology. My heart raced as someone asked, “Wait, you’re not suggesting we write this in JS?” I had to reply, with a wry smile, “I’m afraid I am.” At first, my colleagues looked skeptical, but as I walked them through my research, those skeptical looks turned into less skeptical and more curious. It was settled: I'm going to be a JS Dev 😅
A Scrappy Start with JavaScript
At university, JavaScript was painted as a scrappy language - a tool no real developer would use, and certainly not for projects that needed to scale or respond to real user needs. I was both afraid and unsure about diving into it. I didn’t feel like it was a “proper” programming language, but I had no choice. I was worried this first programming language same as first impression, might stick with me forever.
It kind of did - but in a good way. JavaScript evolved. It’s almost an ugly duckling story at this point, and I’m all here for it.
A Dreamy Kind of Work
Fast forward a few months, and there I was, learning Redux in my spare time just to implement it in the project the following week. I’d think about unfinished issues on my way home and talk with teammates in the kitchen about new features we could implement. I even sought advice from other teams on how best to approach certain things.
We were a small team: me as a junior dev, my close friend as a mid-level dev, and one QA. We also had a part-time PM, a part-time designer, and a Scrum Master. We were truly a team. Ted Lasso-level of a team. We cared for each other, our skills, and our growth. We celebrated every sprint goal met and felt genuinely frustrated when we missed deadlines. But those frustrations fueled us during retrospectives, which were led by the best Scrum Master I’ve ever worked with. Our discussions turned into real solutions to real problems.
Nobody told us to write tests or learn how to write them. We didn’t need to be told. Even with our inexperience, it was obvious this was the way to go. We cared about our code and about improving ourselves.
Why Were We So Engaged?
How was all of this possible? How did the company create an environment where our team could bloom?
We were almost left unchecked - but we had clear objectives. We knew the problem we were solving, the constraints we faced, and the long-term goals. Despite being inexperienced, we were trusted to experiment, make mistakes, and learn from them. We were not burdened with scope creep on which I wrote more in this post.
We controlled our backlog, planned our sprints, and refined our work as a team. Our PM was there to help, not dictate. Together, we decided what stories to tackle next. We were a true Scrum team: self-governing, self-organizing, and highly engaged. That sense of ownership, combined with constant learning and the freedom to try new things, made all the difference.
Were We Cost-Effective?
I think so. Since then, I’ve worked on other projects with different teams, and I’ve seen how uninspired, unmotivated teams can drag progress down. Even though we probably weren’t 100% optimized, I’d argue we outperformed many others.
Sure, there was room for improvement, but we would have welcomed it - as long as it didn’t overshadow the purpose of the solution we were building. Over-optimizing a process, like prematurely optimizing code, often does more harm than good.
What Did I Learn from This Memory Lane Trip?
- I still believe in Scrum. For teams that trust each other, are engaged, and feel responsible for what they’re building, Scrum can unlock potential.
- As part of leadership, I’ve learned to trust engaged teams. Discussions around remote work miss the point - if the culture is built on respect and trust, remote work thrives. If not, maybe the issue lies elsewhere.
- Things end. That journey with that team ended, and I regret not appreciating it more at the time. But it was my first job. I thought it was always going to be like that. I had no idea what a unicorn we all were.
- Working with the right people hardly feels like work. Working on the right problem with the right process hardly feels like work.
- All of this was possible because someone in leadership trusted us. Our inexperience was covered by our excitement - and we paid that trust back tenfold.
Have you ever worked on something so exciting that it stopped feeling like work? Maybe it wasn’t the task, but the people around you who made all the difference—and the company that allowed it.