DEVELOPER DIARIES · TEAM
My Search History Is My Resume
Eight months, one browser, and too many tabs. A junior software engineer's first year told entirely through the things she had to look up.
Mabuhay! My name is Juliana, and the team calls me "Yana," because my name is pronounced julyana. I created that nickname myself, mostly because I got tired of the alternatives my relatives kept trying, and because some people had started calling me "Juls," which does not suit my personality at all (don't ask me why).
I am a Computer Science graduate and a Junior Software Engineer at Future Analytics. I am a curious person who likes to learn new things. My motivation every morning is "another day, another learning." And I am lucky enough to live in an era where the internet is a thing, so when I am curious about something, I can just go to Google and ask. Literally anything.
"Barbie movies." "Why is the moon following me?" "Why does Sleeping Beauty need a prince to kiss her just to break the curse?" "How to become a doctor." That is roughly what little Juliana's search history would have looked like, if she'd had the internet back then.
The truth is that as long as we live, learning never really stops. And in my eight months at Future Analytics, my search history has been an honest record of trying to keep up with a very fast industry.
Eight months in, one browser, too many tabs.
So let me actually show you. These are the real things I typed into Google, and no, I did not clean them up to sound smarter (very tempting, though).
"what is medallion architecture"
I was the first software engineer to join Future Analytics. Before me, the team was a data team — data engineers and analysts, all fluent in a language I did not speak.
So my first week involved a lot of nodding. People said "bronze layer" and "gold layer" like these were ordinary words. There was Microsoft Fabric, ingestion pipelines, dlt, data models in dbt, and Power BI reports sitting on top of all of it. I understood the shape of it and almost none of the detail.
I was not hired to be a data engineer, and I still am not one. But I could not build anything sensible on top of a platform I did not understand. So the first thing I learned at this job was not a framework or a language. It was my teammates' vocabulary.
I still think that was the right first thing to learn.
"power apps documentation"
My first real task: build a web application where our client could view their embedded Power BI reports, then keep adding the features they asked for on top of it.
Which meant living inside the documentation. Documentation is a developer's textbook, and I read a lot of it that month — figuring out which service solved which problem, and what the platform would and would not let me do.
That project turned into a much longer story, and I wrote about it separately in When Low-Code Hit the Ceiling, We Built Our Own Ladder. The short version is that it worked, and then we outgrew it.
"everything i need to know about ai agents"
In college, my thesis project used a CNN and YOLOv8, so I arrived at this job thinking I had a reasonable idea of what "AI" meant. It meant training a model to recognise and classify things.
Then I started working with AI agents and discovered the word had a completely different meaning here. I learned what subagents are, and skills, and hooks, and why the difference between them actually matters. I learned to optimise token usage instead of throwing whole codebases at a model. I learned how to spot a confident hallucination, and how to stop an agent from making the same mistake in five separate sessions.
JP and I went further down that path and built a vendor-agnostic AI framework, which is genuinely its own blog post, so I will stop here before I write it by accident.
The realisation I keep coming back to: AI is not going to replace the people who know how to take advantage of it. Every good result I have gotten out of an AI tool had a human in the loop — usually me, reading carefully and telling it that it was wrong.
"kubernetes in a nutshell"
I had been seeing this word on my Instagram reels for months and understood exactly none of it.
It turns out the fastest way to learn Kubernetes is to find out it is already in your production stack. My job here is flexible enough that I did not just get a glimpse of deployment — I ended up doing it. Clusters, overlays, environments, the lot. I learned the basic concepts the way I learn most things, which is to say urgently and in public.
It was also my first time deploying a whole stack to cloud hosting, which is a sentence I could not have said a year ago.
And if my Instagram reels ever accidentally serve me Kubernetes explained by cats, maybe I'll finally understand it.
"do's and don'ts when talking to a client"
As if being a software engineer across frontend, backend, and infrastructure was not enough — it turns out I needed to be client-facing too.
The strange part is that I was not nervous. I had expected to be. But I had spent so long talking to other developers that being on a call felt normal to me.
The actual challenge was different: explaining technical things to people who do not work in tech. That is a genuine skill and I did not have it. Alex and Sam would debrief me after meetings and walk me through the terminology I should not use, and even what tone to take when writing the client an email. It was humbling in a useful way.
But I like it now. Understanding what a client actually needs, rather than what they first asked for, is what makes it possible to build the right thing. I did not sign up for this part of the job, and it has done more for my communication skills than anything else this year.
"what's next"
I do not have a good answer to that one yet, which is sort of the point.
Little Juliana wanted to know why the moon was following her. This Juliana asks Google to explain Kubernetes in simple terms. The questions got significantly harder. The habit did not change at all.
That is the thing I would want anyone reading this to take away. I did not arrive at Future Analytics knowing what a medallion architecture was, or how to deploy a stack, or which words not to say on a client call. I arrived knowing how to look things up, and being completely unembarrassed about needing to.
So my search history is not a record of what I did not know. It is a record of what I decided to find out.
Another day, another learning.

