Commit to change: From analyst to developer

A colleague of mine, who transitioned from analyst to data engineer, once shared a perspective that stuck with me:

As an analyst, you’re running from tree to tree, putting out fires as you go. As a developer, you pull up a chair in front of a sprout and watch the tree grow.

I’d take that a step further. As an analyst, you move fast and stay at the center of the action. As a developer, you don’t just watch the tree grow; you ensure that every element, the soil, the water, the sunlight, is perfectly balanced to build a sustainable future. It requires patience, but the satisfaction comes from building a system that flourishes.

Two years ago, I made this switch from analyst to Java developer myself.

Analyst at Picnic

My career at Picnic started as a Data Science Working Student, a perfect match for my Master’s in AI. After graduating, I still wasn’t sure if I wanted to be a developer or shift my focus toward business. I chose the latter, wanting to gain a broader perspective before specializing, and joined the Transport team as an analyst.

Within months, I was the go-to expert on transport. I was given a lot of responsibility and loved the pace at which we worked. As an analyst, you have to get used to continuous context switching. Think of it like the 80/20 principle: in 20% of the time, you gain 80% of the results. Analysts thrive in that first 20%. Think fast, build quickly, and if it works, it works. It keeps the work varied and exciting, but there is rarely enough time to deep-dive into the remaining 80% of the work. If you love this and get bored by hyper-specialization, the analyst role is exactly for you. You can contribute to big projects, connect with many people, and advance at a high pace without details slowing you down. But while some people are deterred by too much detail, I found myself wanting to deep-dive into the final 20% of outcomes.

Automation

The deep-dive I missed was especially in coding. As an analyst, the role was quite technical with focus on automation. We built our own tools in Google Sheets. The sheet served as the UI, and Google Apps Script was the production code behind it. I could move as fast as I wanted. Concepts like branches, pull requests, or deploy cycles simply didn’t exist. To make a change in the production code, I would make a copy of the entire sheet, test a thing or two, and paste the script back. Ctrl + S and there it was: committed, merged, and released in one go.

When Picnic introduced a coding platform for analysts, EDGE, automation was taken to another level. Python and Git were introduced, and PR reviews became required. Software developers maintained the infrastructure and provided a standardized framework with EDGE, allowing people without a computer science background to write code without a heavy technical burden. However, it also provided room for LGTM! reviews on 1,000+ line PRs, both concepts being highly questionable.

I used the platform to build a new system from scratch, to support direct data communication with an external supplier. It was more complex than anticipated, but incredibly rewarding that I could do everything by myself. This exact taste of a more structured environment only triggered my curiosity further.

Making the right decision

Once I realized that I didn’t thrive in this dynamic environment anymore, and I became more interested in engineering, I had to make a decision whether a career change to tech was the right choice. I knew I would be in doubt forever if I didn’t force myself to make a decision. Therefore, I asked myself three dedicated questions to turn curiosity into a concrete decision:

1. What is it like to learn from senior engineers?

2. Would I still love coding if it became my primary responsibility?

3. Would I also enjoy infrastructure and architecture, or just the code itself?

Being the expert on a topic was rewarding, but it meant I was usually teaching myself. I missed the growth that comes from learning from others, especially in coding. To answer the first question, I found a mentor in the tech lead of my former team. For the second question, I started to dedicate at least one day a week to programming. Finally, I talked to other engineers to better understand their day-to-day jobs.

The outcomes were clear: I learned a lot from my mentor and I loved it; my coding day became my favorite day of the week and I only wanted to do more; and while the technical overhead still felt intimidating, conversations with engineers gave me a realistic look at what to expect, which encouraged me to give it a try.

I felt my questions were answered: it was time to commit.

From Python to Java: just. learn. syntax.

How hard could it be? I was already familiar with Python and had spent plenty of time in Google Apps Script, so I figured Java would simply be a mix of the two. I couldn’t have been more wrong. The path to becoming a Java developer was anything but a straight line. In total, it took me months to make the actual switch. Learning Java was not just the syntax, but a completely different way of thinking. Concepts like interfaces and repositories were completely unknown to me. But it was rewarding to learn a new language, and printing “Hello World” in Java felt like my first victory.

When I finally felt ready, I still had to apply to Picnic again. My technical knowledge was put to the test through a series of interviews. Succeeding after that long journey of decision-making, learning, and putting myself out there was a huge relief. I was now a Java Developer, and the real coding was about to begin.

Being a Java Developer

Starting as a developer is like getting your driver’s license: the real learning only begins once you’re out on the road. I joined the Transport Systems team, working on the very truck-planning algorithms I had used daily as an analyst. This gave me a unique advantage: I understood the consumer side, which is vital when bridging the gap between business needs and technical constraints.

Advantage of business knowledge

I quickly realized that what seemed simple to a business user could be a technical nightmare for a developer, and vice versa. For example, a perfect data model in Java could force an analyst to unwrap layers of deeply nested JSON in a spreadsheet just to get a simple answer. I also discovered how much common knowledge differs between tech and business. I could often identify when a logical technical solution wouldn’t actually support operations in the real world. I remember frequently talking about shifts (part of our delivery windows), only to find out that this was strictly a business concept. Some developers had never heard the term because it wasn’t explicitly defined in our code. Creating that awareness was essential; we even ended up adjusting one of our heuristics based on this understanding.

This bridge goes both ways. As an analyst, I barely knew what a “build” was. Now, when I talk to business teams, I’m careful not to get lost in jargon like “artifacts” or “pods” that might isolate them. Being able to switch between these two languages is crucial for effective communication.

I love being the bridge between these two worlds. Translating complex business problems into functional code is what excites me most. Especially within the field of logistics, where we build algorithms and optimizations, we require creativity, prototyping, and high-level problem solving.

The daily job

In tech, the stakes are high. A truck schedule that is slightly off can trigger a domino effect across the entire supply chain, so every piece of code is heavily reviewed. A part of my job is performing code reviews. While it can be dry at times, it’s also an opportunity to learn from others and have a sneak peek into their way of thinking.

In the end, my job isn’t just about implementing or reviewing code. I also write technical specifications to translate functional requirements into a technical plan. Business often wants features yesterday, necessitating quick, pragmatic thinking without missing important edge cases. Together with coding, this is exactly the kind of deep-diving I was looking for.

I also discovered that coding isn’t solitary; I love brainstorming and pair-programming with other developers and learning a lot from them. And even though I no longer work directly in operations, I collaborate closely with business analysts. We rely on their expertise to translate real-world chaos into functional requirements. Without this collaboration, tech risks becoming an isolated island while the actual business takes place elsewhere.

The main difference now? The 80/20 rule has flipped. In tech, the final 20% of the outcome that takes 80% of the time is exactly what matters. You have to spend the time to make it right. You aren’t just writing code for a task, you’re building a system with a team.

Challenges: identify what you don’t (need to) know

Change doesn’t come without discomfort. It’s difficult when a career move you’ve been so enthusiastic about doesn’t provide instant satisfaction. I often wondered if I had made the right decision. But I had to learn that growth doesn’t happen the moment you change your title; it happens in the months of persistence that follow.

The hardest part actually surprised me: a lack of intuition. Without a formal CS background, it was difficult to filter what I needed to master versus what I could take for granted. This made it harder to identify if I truly wasn’t interested in a topic, or if it was just a temporary lack of knowledge holding me back. I also struggled with the technical overhead. The PR reviews, infrastructure, and technical maintenance didn’t immediately catch my interest. This was exactly what I had been afraid of. But as my confidence grew, so did my interest. I enjoy PR reviews much more now because I can truly contribute.

Some of my initial doubts remain. I am more interested in translating business problems than thinking about infrastructure. This confirms that my passion lies in building products for business teams and collaborating with people. But here too, only time will tell how that evolves.

The path forward

Beyond the code, I like to bring people together. My goal is to bridge the gap not only between business and tech, but also between different technical domains. As I continue my path, I will definitely bring the learnings from my career switch to the future:

• Dare to change: career paths aren’t always linear, but that doesn’t mean it’s impossible. Be realistic, but don’t let the fact that it might not follow the book stand in your way.
• Make a decision: just do it. Or don’t. But it’s in the power of making a decision. Identify the questions holding you back, find the answers, and then commit to the outcome.
• Give it time: navigating change is hard. Learning new things takes time, and it might take time to enjoy it. Therefore, don’t give up too soon, and make sure to give it a real shot.

Looking back at the crossroads I faced two years ago, I can say with certainty that it was worth the change, and I would do it all again. I am very happy in my current role as a developer, and curious about what the future will bring.

Thanks for reading!

Commit to change: From analyst to developer was originally published in Picnic Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.