I’ve thought about that time more than I probably should, not in a regretful way, but in a “I really had no idea what I was doing” kind of way. Starting out in a data-related field felt overwhelming in a very specific sense. It wasn’t just that things were hard, it was that they were unclear. You’re handed tools, languages, datasets, and expectations, and it somehow feels like you’re supposed to already understand all of it. Like you should know how to code, how to think analytically, how to ask the “right” questions, and already have a direction.

I didn’t. And if I’m being honest, most other people didn’t either. They were just better at hiding it.

If I could say one thing to that version of myself, it would be this: not knowing what you’re doing at the beginning isn’t a weakness, it’s the entire point. Data as a field is built on uncertainty. You’re constantly working with incomplete information, messy datasets, and questions that aren’t fully formed yet. Feeling unsure doesn’t mean you’re behind. It means you’re actually engaging with the work the way you’re supposed to.

If anything, I wish I had leaned into that uncertainty more instead of trying to avoid it.

One of the biggest shifts for me came from something a professor once said: he assumed you weren’t really thinking until you asked a question, because asking a question proved that you were. That stuck with me. I had spent so much time trying to look like I understood everything that I avoided doing the one thing that would have actually helped me understand anything.

In a data-driven field, questions are everything. Before any code runs, before any dashboard gets built, before any “insight” exists, there’s a question. And if that question is vague, rushed, or unexamined, everything built on top of it will be too. Learning to ask better questions isn’t just a skill, it’s the foundation of doing meaningful work.

And those questions don’t need to be perfect, they just need to be honest. Why does this look different than I expected? What am I missing here? Does this actually mean what I think it means?

That kind of thinking is what actually moves you forward. Over time, you realize that the people who grow the most aren’t the ones who always have answers, they’re the ones willing to dig deeper.

I’d also tell myself to start asking those questions sooner and out loud. I used to hesitate because I thought asking for help would make me look unprepared. But in reality, it’s the opposite. The world isn’t sitting there waiting for you to fail. It actually wants to help you figure things out. Professors, classmates, coworkers, even people online are usually more than willing to give you a hand. But you have to meet them halfway. You have to be willing to say, “I don’t get this yet.”

That shift, from trying to prove yourself to trying to learn, changes everything. I’d also remind myself that I didn’t have to figure everything out alone. For a long time, I treated independence like it was the goal, like needing help meant I wasn’t capable. But this field is collaborative by nature. People share ideas, troubleshoot together, and build off each other’s thinking. Letting yourself be part of that process doesn’t make you weaker, it makes you better.

Another thing I wish I understood earlier is that you don’t have to be completely consumed by something to be good at it. There’s this idea that you need to “live and breathe” data to belong in the space, and I don’t think that’s true. I used to think I needed to find that one thing I was endlessly passionate about. When I didn’t feel that way, I questioned whether I was in the right place.

But being good at something doesn’t always start with passion. A lot of the time, it starts with consistency. With showing up, putting in the effort, getting a little better each time, and slowly building confidence through competence. You can grow into something. You can learn to enjoy it because you understand it, not just the other way around.

At the same time, striving to improve doesn’t mean becoming someone else in the process. You can push for better: better skills, better understanding, better work, while still staying grounded in who you are. That balance matters, especially in a field that can feel technical and rigid.

For me, staying grounded also means bringing my relationship with God into what I do. Not as something separate from school or work, but as something that actively shapes how I think and grow. When I trust that He can guide my mind, open my thoughts, and support me in what I’m working toward, I approach challenges differently. It doesn’t replace effort, but it gives that effort direction and purpose.

And through all of this, I think the simplest thing I’d say, the one that took the longest to fully understand, is to just be myself. Not a version of myself that fits what I think the field expects, not a version that blends in better, but the one that actually thinks the way I think.

Because in the end, data isn’t just about numbers, it’s about interpretation. It’s about perspective. The way you approach problems, the way you ask questions, the way you connect ideas. That’s where your value is.

Allowing yourself to be yourself doesn’t mean you settle where you are. It just means your growth is actually yours. It’s not forced, it’s not performative, and it’s not based on who you think you’re supposed to be.

Looking back, I wouldn’t hand my freshman self a perfect plan. I’d give a little more clarity instead: you’re allowed to not know, you’re expected to ask, you’re not doing this alone, and you’re capable of growing into this.

So keep asking, keep trying, and stay grounded in what matters to you. You don’t need to have everything figured out right now, you just need to keep moving forward and trust that clarity comes with time.

Ever since I was young, I’ve had this drive to track my own info, but in recent years, I’ve really taken to tracking my music. It actually started because I was suspicious of the shuffle button. I felt like every single time I shuffled my playlist, it would play the same twenty songs on loop while other songs just sat there, never getting played. So, I decided to test it. I would shuffle the playlist, record the first 20 songs, and then after a ton of iterations, I could see exactly how many songs had been played, how many times they popped up, and which ones were being totally ignored.

I’ll be real with you, I never actually “finished” that experiment in the sense that I didn’t wait until every single song was played at least once. New music was coming out, and my taste was changing way too fast to stay stuck in that one spreadsheet forever! But it taught me something important: data doesn’t have to be boring. It’s just a way to prove what you’re feeling.

Another thing I find particularly interesting about data is how it can be totally concrete while also being completely subjective to personal opinion. For my recent big project, I listed out a bunch of songs and then scored them in 12 different categories that actually mattered to me. I rated things like overall enjoyment, the “turn-it-up factor,” replay desire, live anticipation, and the sing-a-long urge. I even tracked nostalgia, my “gut like,” and even a “gut dislike” category (which acted as a negative scale).

I created both raw and weighted scores because, let’s be real, not every category holds the same importance in my listening experience. Sometimes a song has high nostalgia but low replay desire, and the weights help balance that out. I’m so happy I was able to do it because the results feel so right.

But here’s the thing: My music rankings are perfectly accurate for me. They tell a story about my taste, my preferences, and my biases. Someone else using my exact framework would generate completely different results. And that’s okay. Because data is always tied to context.

It took me about six months to finish this for around 300 songs because I insisted on listening to each song as I scored it. I wanted to make sure they were as accurate as they could possibly be. I consistently had fun with it, and I even made a little box plot with the high and low rankings per album, and genuinely, that really appealed to my nerdy heart.

To me, data isn’t actually messy in itself. When I look at a massive table, it makes perfect sense to me. I see the patterns and the logic immediately. But I also understand that it doesn’t look that way to others, and that’s why I love what I do. I am happy to take that information and make it understandable for everyone else. My job is to help that data “dress up” into something pretty that is actually meaningful to you.

But before data can “dress up,” it has to exist in the first place.

At its most basic level, data is just a recorded observation. A number. A timestamp. A yes or a no. A click. A stream. A purchase. A skipped song. What’s really changed in recent years isn’t necessarily what data is, it’s how much of it we generate and how effortlessly it’s collected. Every time we open Spotify, tap a credit card, or check our watch for our heart rate, something is recorded. We are constantly producing those rows and columns of information without even realizing it.

Not that long ago, collecting data was a huge, intentional chore. Someone had to design a survey and hand-enter numbers. Now, businesses no longer ask, “Should we collect data?” They ask, “How on earth do we manage the overwhelming amount of data we already have?”

That’s where data science becomes so powerful. Raw data on its own is like my giant spreadsheet of 300 songs before I started scoring them. It’s information, sure, but it isn’t insight. The magic happens when you start asking the questions: What patterns exist here? What is overrepresented? What actually matters? When you scale that up, that’s exactly what businesses are trying to do every day. Companies don’t just want dashboards; they want clarity. They want to know why customers behave the way they do. Data at its base level is neutral. It doesn’t argue, and it definitely doesn’t explain itself.

That’s our job.

I’ve always loved when something abstract becomes measurable. My music rankings are a perfect example. They aren’t “universal truths”. They are just my reality reflected in numbers. In today’s world, data is infrastructure. It’s embedded into healthcare, streaming platforms, sports, and everything in between. The organizations that succeed aren’t the ones with the most data; they’re the ones that understand it best.

At its core, data is just recorded reality. And I think that’s kind of beautiful. Because when you care enough to track something, whether it’s global sales metrics or just the first 20 songs from a shuffled playlist, you’re saying, “This matters.”

As a data scientist, my job isn’t just to look at numbers. It’s to respect where they came from, clean them carefully, and then translate them into something useful. I still get excited about tables and box plots. I still love rows and columns that mean something. But what I love most is taking a world full of ‘stuff’ and proving that none of it is actually random, and then making sure it finally makes sense to someone who doesn’t spend their life in a spreadsheet.

Working with data in a professional setting is very different. Real-world data work is far more ambiguous, open-ended, and unclear in both scope and delivery timelines. In my job, the data I work with comes from a live connection to the source. This means I constantly have to consider how often the data changes and how those changes affect how I clean, transform, and analyze it.

Some of the data I work with is mostly static. When it updates, it simply adds a new row of information, allowing me to look back at previous values and easily perform week-over-week comparisons. However, other datasets can be completely overwritten depending on the circumstances. This means the data I see on Monday may not be the same data I see on Friday, with no built-in way to view what the data looked like earlier in the week.

Despite this limitation, the management team I report to still expects week-over-week comparisons and, by the end of the year, a clear picture of how the data changed over time. This creates a challenge: if I waited until December 31 to generate a yearly report, I wouldn’t be able to show trends between busy and slow seasons because past versions of the data would no longer exist. Since this historical perspective is essential for decision-making, I had to think carefully about how to “freeze” or archive the data without compromising its integrity.

Another important consideration is ensuring that I am querying the live data source correctly. Because dashboards and visuals automatically update when the data refreshes, I need to verify that they are displaying the correct statistics and time periods. A small mistake in a query can lead to misleading visuals, which can quickly become a larger issue when shared with management.

The key takeaway is that working with static, never-changing datasets is very different from working with constantly changing data while still needing accurate time-based comparisons. To handle this, I’ve created weekly routines in both Power BI and Excel. In Excel, I use macros to ensure that the same steps are followed every time. One of these steps involves what I call “freezing” the data—copying the current values and pasting them into a new sheet, or saving end-of-week data in a designated comparison area. I save each weekly report with the current date, while maintaining a separate working file for daily updates and refreshes.

Power BI works a bit differently. I export specific tables into designated files, which are then consolidated to support week-over-week comparisons for live data. Each row of data is tagged with the date it first existed, ensuring that comparisons always reflect the most recent and accurate information.

Through this process, I can confidently answer questions about the current data landscape while also preserving historical data. This allows me to show management exactly what the data looked like at any given point in time—and know precisely where to find it.