Data analyst or programmer? Try the work before choosing the title

When someone asks me whether to become a data analyst or a programmer, I first want to understand what sits behind that choice. Sometimes it is an interest in technology. Sometimes it is a career change, a preference for remote work or frustration with current responsibilities. Each reason leads to a slightly different set of questions.

I would not choose a profession simply because its list of tools looks shorter. A spreadsheet may feel familiar while a code editor feels strange, but the difficulty of either job quickly extends beyond operating software. Both involve understanding a problem, checking a result and working with the person who will use it.

My perspective comes from data analysis. Even so, I want to describe both directions fairly, without promising an easy entrance into technology work. Concrete tasks make the comparison more useful. Alongside the differences, I will suggest two small experiments you can try before making a larger commitment.

Treat the original comparison in its historical context

The original article appeared in January 2025. In this October 2026 revision, I qualify its earlier claims about entry difficulty and the effect of AI. I do not assume that analytical work is automatically easier to enter, that programming starts from nothing or that one profession is protected from automation.

Those claims would require evidence about a defined population, market and period. Here I focus on tasks and a practical way to explore your preferences. The companion video remains in the Polish version as historical material referring to 2025. This article is not a current labour-market forecast.

Start with the result each role delivers

Imagine a company struggling with late deliveries. An analyst might be asked where delays occur, how often they happen and what deserves further investigation. The result could include an agreed definition of delay, checked calculations and a recommendation with clearly stated limits.

A programmer might be asked to build a tool that identifies late shipments and displays them to customer support. The result would include working behaviour, tests, handling of invalid inputs and a way to maintain the solution. Both people are improving the same process, but they are delivering different kinds of output.

This is deliberately simplified. Analysts can write programs, and programmers can analyse data. In a small team, one person may do both. I find it more useful to ask what I am responsible for than whether I open Python or a spreadsheet during the day.

For an external reference, I use O*NET’s descriptions of Business Intelligence Analysts and Software Developers. These are US occupational descriptions, rather than a description of every vacancy or a prediction of an individual’s employment prospects. They do, however, show collaboration, documentation and checking work in both roles.

What analytical work involves before the chart

In the delivery example, I first ask what counts as late. Are we comparing the date promised to the customer with the delivery date? Do weekends count? What happens to an order that has not yet arrived? Without those answers, several technically correct reports could produce different numbers.

Next I inspect the sources, missing values and level of detail. One record might represent an order, a parcel or a status change. Confusing those levels could make me count one order several times. Only after understanding that structure do I choose a tool, write a query and prepare a presentation of the result.

Some of the most important work happens after the first chart. Someone asks why the number differs from another report. I need patience, a way to reproduce the calculation and a willingness to revise an assumption. If investigating that disagreement sounds interesting, it is a good problem to include in your own analytical experiment.

It also helps to separate an observation from an explanation. A table can show that a group has more delays without explaining why. I want to recognise that boundary and identify what additional information would support a better decision. A polished visual does not remove uncertainty from its source.

What programmers do beyond writing new code

For a shipment-status tool, someone must define the expected behaviour. What should appear when a date is missing? When should the status refresh? What happens if the source is temporarily unavailable? The answers affect both implementation and whether a user can rely on the result.

Programming also includes reading an existing solution, diagnosing faults, reviewing changes and checking how a new feature interacts with the rest of the system. A small function may be easy to write from scratch but harder to integrate into an established application. That is why I would not judge the profession from the first successful tutorial alone.

Someone who enjoys building a predictable mechanism and refining its behaviour may find this direction appealing. That does not imply fewer conversations. Clarifying requirements or explaining a technical trade-off can require more attention than changing a few lines. It is worth testing whether you like that part of the work too.

Maintenance matters as well. A useful program must remain understandable when its author returns weeks later or another person changes it. Naming, small tests and a clear explanation of the expected inputs are part of the result. They are not merely decoration added after the interesting work is finished.

Previous experience can transfer to both careers

I disagree with the idea that a career changer always starts programming from zero while automatically having an advantage in analysis. Experience needs to be unpacked. Knowing logistics will not replace learning a programming language, but it may help you notice that a delivery can contain several parcels with different deadlines.

That knowledge can help an analyst define a measure and a programmer design a data model. Someone from customer support may recognise confusing error messages. An operations specialist may understand dependencies between process stages. A teacher may be skilled at explaining difficult ideas and preparing instructions that another person can follow.

I therefore write down something specific: which problem do I understand better because of my previous work, and how will a project demonstrate that? Saying “I have soft skills” provides little evidence. An example of clarifying requirements, finding an error source or explaining a decision gives another person something concrete to assess.

Transferable experience also has limits. Familiarity with a business process does not prove that I can build reliable software or calculate a measure correctly. I want to combine domain knowledge with new technical practice. I explore that connection further in my article about moving from the humanities into data analysis.

Begin learning with a small scope

For a first analytical project, I would choose a spreadsheet or SQL, a few basic data operations and a simple way to communicate the result. I do not need every tool mentioned in every vacancy. I need to explain a filter, a grouping, a missing value and the limits of my conclusion. The next task can reveal which additional skill is useful.

For a first program, I would choose one language, basic data structures, conditions, functions and a few behavioural checks. If that language is Python, my article on variables, types and operators provides a starting point. A local program is enough for this experiment. User accounts, payments and a production deployment would add unrelated work.

In both cases, I care about the learning loop: attempt something, observe the result, check it and make a correction. Watching lessons can make terminology familiar without showing how I respond when there is no prepared solution. I want to finish one modest task before designing a learning plan that extends several months into the future.

Experiment one: analyse six deliveries

Here is a synthetic dataset you can enter in a spreadsheet. Promised and actual durations are whole numbers of days measured in the same way. Every delivery in the initial table is complete. For this exercise, a delivery is late when actual duration is greater than promised duration.

Set aside roughly ninety minutes for an initial attempt. That is a suggested limit on scope, rather than a promise that every beginner will finish within that time. Count late deliveries overall and within each channel. Write three sentences for the person responsible for the process: the result, its limitation and the next question.

The expected result is three late deliveries out of six, or 50%. Store has two out of three, while Partner has one out of three. I would not conclude that the sales channel causes delays. This is a tiny invented dataset, and other factors are absent. A useful next step would be to examine comparable periods, products and delivery methods.

Finally, add a row without an actual duration. Pause to describe whether that means missing information or an unfinished delivery. Do not automatically insert zero. Discussing what the record means is part of analysis. Notice whether this ambiguity makes you curious or whether you mainly want to bypass it and move on.

Experiment two: build a small classifier

Using the same rules, create a function that accepts promised and actual delivery durations. It should return one of three messages: “on time”, “late” or “missing data”. Define a missing actual duration as the third outcome, and reject a negative duration as invalid input.

Use the language you are currently learning. You do not need a login screen or a production database. A function and several calls are sufficient. For promised 2 and actual 3, expect “late”. For 2 and 2, expect “on time”; the same applies to promised 3 and actual 2. A missing actual value should produce the missing-data message, while a negative value should produce a clear error.

Then ask someone to run the program using your instructions, or try reproducing the process yourself the next day without relying on remembered shortcuts. Check whether the input description is clear, the outcomes repeatable and the error understandable. This introduces a small part of the responsibility involved in building something for another person.

You can also give this experiment an initial ninety-minute limit and record unfinished work. Do not compare the professions solely by speed. If you already know spreadsheets but are installing a programming environment for the first time, the difference mostly reflects your starting point. Repeat the task after becoming familiar with the tool before treating the first attempt as a career verdict.

Compare the experience of doing the work

After each experiment, I record which moment held my attention. Did I want to split the result into further groups and investigate what was still unknown? Or did I prefer refining the function, organising the code and adding another test case? Either response is useful. Enjoying one task does not close the other path.

I also describe the difficulty. Unfamiliar syntax is different from disliking the underlying problem. Frustration during installation does not establish that programming is unsuitable for you. Similarly, excitement about a first chart does not prove that you will enjoy regularly resolving conflicting definitions and reports.

I do not attach a score that supposedly selects a lifelong profession. These exercises gather information about your preferences. The next attempt should move slightly closer to real work: someone else’s dataset with documented gaps, or a small correction in an existing program. That adds reading, questions and the need to understand decisions made by another person.

Communication belongs to both directions

An analyst explains what a result means, while a programmer explains how a solution behaves. Both need to communicate what they have not yet checked. That can happen in a meeting, an issue comment or a short document. I do not equate good communication with being the loudest person in the room.

For the delivery analysis, a useful statement would be: “Half of these six records are late; the dataset does not establish the cause.” For the program: “The function distinguishes missing duration from zero; calendar dates are outside its current scope.” Both statements help the reader understand the boundary of the work and decide what should happen next.

If quiet work matters to you, investigate how the team operates. Meeting frequency, documentation quality, preparation time and customer contact can vary considerably between employers. A job title alone cannot tell you what Tuesday will look like or how much uninterrupted time you will have.

AI changes tasks without guaranteeing employment

I do not treat analysis as immune to AI or programming as destined to disappear. A tool’s ability to generate code or a chart is insufficient to predict the number of jobs. Work organisation, data quality, accountability, costs and decisions made by individual companies all matter.

In these experiments, AI can help explain an error, suggest a query or propose tests. I still check whether it used the correct definition of delay and preserved the distinction between missing data and zero. GitHub’s Copilot documentation also calls for reviewing and testing suggestions. That is guidance about a tool’s limitations, rather than a study predicting the future of either profession.

When learning, I record the assistance I used and what I can explain independently. If I cannot predict the output for a simple input, I return to the basics. Generated work may save time, but a portfolio should also show checks, decisions and corrections. Those details make it possible to discuss my understanding of the problem.

Read vacancies through responsibilities and conditions

Instead of repeating broad claims about demand, I collect a small sample of current vacancies from a market where I can actually work. I record location, experience level, responsibilities, required tools, language and working arrangements. I distinguish essential requirements from desirable skills, check dates and avoid counting duplicate advertisements.

Titles can be misleading. An analytical role may focus on reporting, product experiments or maintaining data models. A developer may build interfaces, integrations or internal tools. I want to compare specific kinds of work rather than put every variation into two enormous categories.

I am not providing a salary ranking or a percentage chance of employment here. Without a country, seniority level, contract type and period, that comparison would imply precision it does not have. Your decision can instead draw on available roles, your time constraints and the evidence of skill you can produce. I discuss the search process in my article on a strategy for changing careers.

Choose the next stage, rather than a permanent label

After the experiments, I choose one direction for the next project. I define the output, a manageable scope and a way to check it. For analysis, that might be a short report with an agreed measure and data-quality checks. For programming, it might be a small tool with setup instructions, error handling and tests of its main behaviours.

I also decide when to revisit the choice. After completing the project, I assess what I learned, what still interests me and how the result relates to the vacancies I inspected. That gives me a basis for decisions beyond the latest headline about technology careers. I have observations from my own work to return to.

If both areas interest you, the shared foundations will remain useful. Working with data, reading code, checking outcomes and explaining a problem clearly all matter where these roles meet. Start with one task you can finish, though. A completed small project will reveal more about your preferences than another list of technologies you might learn someday.