My Journey into Data Science: Physics, Economics, and Turkish Sentiment Analysis

I studied physics and economics before moving into computer science. They are different fields, but each offers a way to question data before accepting an answer. In physics, a measurement needs units, conditions, and a model that makes sense of it. In economics, a recorded choice can also reflect the rules and incentives around the person making it. A number does not arrive with an explanation attached. That is the connection I see between those subjects and my later work with data: first ask what produced an observation, then ask what it can support.

During my master’s in computer science, that path took a more specific form: I researched sentiment analysis in Turkish. Here the material is not a neat table of physical measurements or prices. It is language: text whose meaning has to be represented before a method can analyze it. Sentiment analysis asks what attitude a piece of text expresses, but an answer depends on the examples collected, the labels used, and how the method is checked. These are questions about data as much as algorithms. Today, that research is the concrete example I can point to when I describe where language, data, and software met in my work.

I completed the master’s and started a PhD. My professional work also moved into building software and products for organizations. That change of setting matters to how I tell this story. In research, a question and a set of data can be defined for study. In a product, data passes through software that people use, and the output needs a meaning beyond the method that produced it. Thinking about a research dataset and thinking about a tool are different tasks, but both require asking what the input represents and what the result can support.

Later startups pulled me toward entrepreneurship, and I founded Indisera. My work there has involved AI, text analytics, and language technology. The questions raised by the research return in another form: what is the text actually evidence of, what can a method infer from it, and how should the result be presented? A paper can discuss a method directly; someone using a product sees what the tool says and must decide what to do next. In that setting, the limits of an output are part of what the software needs to communicate. The difference is practical, not simply academic.

That is the route I can describe: physics and economics, computer science and Turkish sentiment research, a master’s completed and a PhD begun, then software products and entrepreneurship. From today’s perspective, I can see a line connecting those stages: know where data comes from, state what a method can infer, and be clear about how its output will be used. The route is winding, but those are the actual parts of my work and education behind this account of my journey into data science.