I have worked in data science for almost a decade now. During that time, I have seen many tools become popular. There were Hadoop and Spark, followed by easier machine learning libraries, cloud platforms, and now generative AI tools that can help us write code.
I learned many of these tools along the way. Some are still part of my work, while others do not appear much in my daily projects anymore. However, when I think about the skills I still use regularly, many of them are not new at all.
The World Economic Forum’s 2025 report expects 39% of workers’ core skills to change by 2030. This prediction is for jobs in general, not only data science. At the same time, analytical thinking remains the core skill most commonly identified by employers. For me, that describes data science quite well: we need to keep learning new tools, but we also need to improve how we think about the work.
So, which skills have aged well in my experience? I also looked at what other data professionals have learned to see where our experiences are similar or different.
Let’s get into it.
SQL Is Still Everywhere
SQL was already an important skill when I started working with data, and it is still important today. According to O*NET’s analysis of U.S. data scientist job postings in 2025, SQL appeared in 51% of postings. For comparison, TensorFlow appeared in 11%, PyTorch in 10%, and Spark in 7%.
Of course, job postings do not tell us everything about what data scientists do. Still, they show that SQL remains useful even as the tools around it change.
What changed for me is how I use SQL. Earlier in my career, I focused on remembering the syntax: joins, subqueries, window functions, and so on. I still need to know them, but writing a valid query is not the difficult part of many analyses.
Take an example of joining a customer table with a transaction table. The query might run without any errors, but one customer could have many transactions. If I count the rows after the join without checking the data, I could report the number of transactions as the number of customers.
That is why understanding the data grain, table relationships, and metric definition matters more to me than memorizing every SQL command. AI can help generate the query, but I still need to check what the result represents.
Avery Smith, who has worked in analyst, data scientist, and data engineer roles, also wrote that he learned many tools on the job. In his experience, domain knowledge helped him understand the problem and interpret the data. I agree with that point. Knowing SQL gives us access to the data, but understanding the context helps us get the correct answer.
Statistics Helps Me Question the Result
Statistics is another skill I appreciate more now than when I started. At first, I mostly associated it with formulas, distributions, hypothesis tests, and model assumptions. Those topics are still important, but statistical thinking has become useful to me in a more practical way.
For example, imagine that an experiment shows a new feature performs better than the old version. Before accepting the result, I would want to know whether the groups were comparable, whether the sample was large enough, and whether the difference is meaningful for the business. I would also ask if we selected the metric before seeing the result.
We can run a statistical test in a few lines of Python. The function can give us a number, but it cannot decide whether we asked a good question or collected suitable data. The U.S. Bureau of Labor Statistics still includes mathematics, statistics, analytical skills, and logical thinking among the important parts of a data scientist’s work.
For me, the skill that aged well is knowing what we can conclude from an analysis, and when the evidence is not enough.
Understanding the Problem Comes Before the Model
Earlier in my career, I was often excited about choosing a machine learning model. Should I use Random Forest? Would Gradient Boosting perform better? Could I improve the score by tuning more parameters?
Now I am more interested in the question before modeling: what decision are we trying to support?
Take a churn prediction project as an example. A model could identify customers who are likely to leave. However, we still need to know what the team can do with that information. Can they contact these customers? How early do they need the prediction? What kind of action could actually help? Without answers to these questions, even an accurate model might not be useful.
A 2025 study in Harvard Data Science Review compared data science with decision science skills. The researchers found that data science tends to emphasize coding, machine learning, and data management, while decision science gives more attention to problem framing and business knowledge. The study argues that we need both to turn analysis into useful decisions.
This also matches Yu Dong’s reflection on six years in data science. She explains how understanding the product and talking with other teams helped her find work that people could act on. One point from her experience adds to mine: we should not underestimate dashboards and reporting. A reliable dashboard can establish the baseline and shared metric definitions we need before attempting a more advanced model.
Sometimes the best solution is a model. At other times, it could be an experiment, a dashboard, a simple rule, or better data collection. I have become more comfortable choosing among these options only after I understand the problem.
Messy Data Still Needs Context
Data tools have improved a lot. We have cloud warehouses, better pipelines, automated checks, and AI tools that help write data preparation code. Yet messy data has not disappeared.
In dbt Labs’ 2025 survey of analytics professionals, 57% of respondents said they spent most of their workday maintaining or organizing datasets. The survey covers several analytics roles, not only data scientists, but the result feels familiar to me.
We can remove duplicate rows or fill missing values with code. The harder question is why those values are there. A duplicate might be a data error, or it might represent a real second transaction. A missing value might mean “unknown,” “not applicable,” or a problem in the data pipeline. Each situation requires a different response.
The same problem appears in machine learning features. A variable might have a strong relationship with the target because it was created after the outcome happened. Using it would make our model look good during testing, but the information would not be available when we actually need to make a prediction.
For me, understanding how the data was created has aged better than any particular cleaning library.
Evaluation Shows Whether the Work Is Useful
Building a model has become easier. We can train several models quickly, use AutoML, or ask AI tools to help create the code. However, we still need to decide whether the result is better than what people already do.
This is where evaluation becomes important. We need to choose a relevant metric, keep the test data separate, and compare our solution with a realistic baseline. A recommendation model might perform better than a random suggestion, but can it outperform simply showing the most popular items?
A data scientist reflecting on ten years of experience described a three-month A/B test comparing personalized recommendations with a popular-items fallback. He also looked at operating costs and found that not every project produced enough value to continue. I find this comparison useful because it evaluates the model against a real alternative rather than a score in isolation.
The same idea applies to generative AI. A demo can look impressive, but we need representative examples, clear evaluation criteria, and a baseline before saying the new system is better.
Communication Is Part of the Analysis
Communication was a skill I underestimated when I started. I thought the technical work came first and presenting the result happened afterward. My view has changed.
For example, a model might achieve an ROC-AUC of 0.87. That number could be useful to another data scientist, but a business team may ask different questions. How many customers can we reach? What happens when the model is wrong? What should we do next?
Explaining the result in those terms also helps me check my own work. If I cannot explain why I chose a metric or what the result means, I probably need to look at the analysis again.
The Airbnb data science team described a similar lesson. They found that analysis had less impact when data scientists were too far from the people making decisions. Closer collaboration helped them understand the problem and make their findings more useful. Avery Smith makes a related point in his career reflection: communication at the beginning helps avoid the wrong analysis, while communication at the end helps people use the result.
For me, communication is no longer something that comes after data science. It helps define the work and determine whether the work has value.
Conclusion
I still think learning new tools is important. Python appeared in 66% of the same 2025 U.S. data scientist job postings, and AI tools are already changing how we work. We cannot ignore these changes.
However, after almost a decade, I worry less about knowing every new tool as soon as it appears. I would rather keep improving the skills that have helped me through several changes: understanding the data, questioning the result, framing the right problem, evaluating against a useful baseline, and explaining what the analysis means.
The tools will continue to change. These are the skills I expect to keep using.
If you want to learn further about SQL in the AI era, don’t miss my latest written SQL Course.