In September 2024 I started an MSc in Data Analytics at National College of Ireland. I’d already spent nine years working with data in India, most of them building SQL Server and Azure platforms at S&P Global. People asked why I’d go back to university.

A year later, here’s my honest answer.

Industry teaches depth, university teaches breadth

Nine years of work had made me very good at a narrow set of things: SQL, ETL, data modelling, dashboards. The MSc forced me into modules I’d never have picked on my own: optimisation, deep learning, generative AI, data mining. Some I loved, some I struggled with, and all of them widened what I could imagine building.

The field had moved faster than I realised

When I started my career, “machine learning” meant regression models in a notebook. By 2024, students were fine-tuning language models and building retrieval systems for coursework. Being in a room with people who’d grown up with these tools was the fastest way to catch up.

Experience is an unfair advantage in group work

Where I did have an edge was knowing how real projects fail: unclear requirements, messy data, stakeholders who change their minds. In group projects I often ended up translating between the technical plan and what the “client” actually needed. That’s a skill no module teaches.

The dissertation was the best part

My dissertation, Enhanced Personalized Learning Experiences by Leveraging Knowledge Graphs and Prompt Engineering, is published in the NCI research repository. Owning a research question for months, with nobody telling me the answer, was very different from delivering tickets at work. It taught me to frame problems, not just solve them.

What I’d tell anyone considering it

• Pick a dissertation you’d want to talk about in interviews. It becomes your portfolio.
• Build in public while you study. Coursework disappears; blog posts and repos stay.
• Use the city. Dublin has meetups for Python, data, AI and cloud almost every week. Go to them.
• Don’t treat it as a reset. Your industry experience is the thing that makes your degree valuable. Lead with both.

Was it worth it? Yes. Not because of the certificate, but because it changed what I believe I can build.

Every system that decides “is this content harmful?” makes two kinds of mistakes. It removes things that were fine, and it misses things that weren’t. You can’t drive both to zero. Choosing which mistake you’d rather make is one of the most important decisions an integrity team takes.

The two numbers

• Precision: of everything the system flagged, how much was actually violating? Low precision means innocent users get actioned.
• Recall: of everything that was actually violating, how much did the system catch? Low recall means harm stays up.

Raise the threshold for flagging and precision goes up while recall goes down. Lower it and the reverse happens.

Why the “right” threshold depends on the harm

There is no universal setting. It depends on the cost of each error:

The human review layer changes the maths

Most teams don’t rely on a single automated decision. A common pattern:

1. High-confidence violations: action automatically.
2. Uncertain middle: send to human reviewers.
3. High-confidence benign: leave alone.

Now the question becomes how wide to make the middle band. Wider means better decisions but more review cost and slower action. This is where the work becomes an operations problem as much as a modelling one.

Measure on the right sample

Precision is easy to measure: sample what you flagged and check it. Recall is hard, because you need to find what you didn’t flag. That requires sampling the unflagged population, which is usually huge and mostly benign. Teams that only measure precision tend to drift towards under-enforcement without noticing.

Practical advice

• Report precision and recall per harm category, never as one blended number.
• Track appeal overturn rates as a real-world check on precision.
• Revisit thresholds when content patterns change. A threshold tuned last year may be wrong today.

In the next trust and safety post I’ll look at prevalence: the metric that tries to answer “how much harm do users actually see?”

Views are my own and use public, general examples only.

At S&P Global Market Intelligence I helped migrate on-premise SQL Server databases to Azure SQL PaaS. Our team moved between 10 and 50 databases to Azure SQL Managed Instance. The headline result was a reduction in infrastructure costs of about 25%. The more important result was that the people using those databases barely noticed it happened.

Here’s what I learned about doing a migration like that well.

1. Inventory before you plan

Before choosing a target, list everything that touches the database: ETL jobs, reports, linked servers, SQL Agent jobs, cross-database queries, CLR assemblies. PaaS options don’t support every on-prem feature in the same way, and you want to find the gaps on a spreadsheet, not in production.

Microsoft’s Data Migration Assistant and Azure Migrate help here, but they don’t know about the Excel workbook someone in finance refreshes every Monday. Talk to users.

2. Pick the right PaaS flavour

Azure SQL Database and Azure SQL Managed Instance trade compatibility against simplicity. Managed Instance keeps more instance-level features (Agent jobs, cross-database queries), so it suits lift-and-shift. Single databases are simpler and can be cheaper, but may need refactoring. Decide per workload, not per estate. We went with Managed Instance, which kept most instance-level features in place and meant fewer changes to existing code.

3. Right-size, don’t copy

Most of the savings came from not paying for capacity we didn’t use. On-prem servers are sized for peak load plus growth plus fear. In the cloud you can measure actual usage and scale. Look at real CPU, memory and IO over several weeks before choosing service tiers.

4. Migrate in waves

Start with low-risk databases: development, reporting copies, internal tools. Each wave teaches you something about networking, permissions or performance that makes the next wave smoother.

5. Test the boring things

Performance gets attention. In our migration, the real problems came from elsewhere:

• Connection strings hard-coded in old applications and reports
• SSIS packages and SQL Agent jobs that needed reworking to run against Azure
• Jobs that relied on local file paths on the old servers

Also worth checking: time zone and collation differences, firewall rules and private endpoints.

6. Define “done” with the users

A migration isn’t finished when the data moves. It’s finished when every report, job and application works as before and the old servers are switched off. Agree that checklist with stakeholders up front.

The takeaway

Cloud migration savings come mostly from right-sizing and retiring infrastructure. Keeping users happy comes from inventory, testing and communication. Neither is glamorous, and both matter more than the migration tooling.

In 2015 I finished a Bachelor of Computer Applications in Gujarat and took my first job doing SEO keyword research. Ten years later I hold an MSc in Data Analytics from National College of Ireland, I’ve built data platforms for a global financial information company, and I work on platform integrity operations in Dublin.

This is the first post in a series where I’ll write about what I’ve learned along the way: data engineering, generative AI, and the less glamorous work of keeping online platforms safe.

The early years: cleaning data by hand

My first data role was at Bright Info Solutions in Ahmedabad. Most of the work was unglamorous: pulling data with SQL, cleaning it in Excel and Python, building weekly reports. It taught me the lesson every analyst learns early. Most of the job is making data trustworthy before anyone looks at a chart.

Building platforms at scale

From 2019 to 2024 I worked at S&P Global Market Intelligence as a data analyst and ETL developer. I built SSIS pipelines over multi-million-record financial datasets, designed data models for analytics, and helped migrate on-premise SQL Server databases to Azure SQL PaaS. That migration cut infrastructure costs by about 25%.

What I took from those years: good data engineering is invisible. When it works, nobody notices. When it breaks, everyone does.

Starting again in Ireland

In 2024 I moved to Dublin for a master’s. Going back to study after nine years of industry work was humbling. Modules in machine learning, deep learning and generative AI showed me how fast the field had moved. My dissertation combined knowledge graphs and prompt engineering, and my main project, SkillBot, paired a fine-tuned GPT-3.5 model with a 2.3-million-triple knowledge graph using retrieval-augmented generation.

Where I am now

Today I work in platform integrity, analysing complex escalations with AI-assisted tools. It sits where my two interests meet: data and AI used to make platforms safer.

Why write in public?

Three reasons:

1. Writing forces clarity. If I can’t explain something simply, I don’t understand it yet.
2. Dublin is one of the world’s great tech hubs. I want to contribute to its data and AI community, not just work in it.
3. Accountability. Publishing every week keeps me learning.

Over the coming months I’ll post about Azure migrations, RAG evaluation, knowledge graphs, content moderation metrics, and the career lessons in between. If any of that interests you, follow along. I’d love to hear what you’re working on too.