Data analyst or programmer? Choose through practical work

When I was 27 and working in customer service, I considered becoming a programmer. I could see the IT world from the outside: interesting problems, more independence and opportunities to develop. It was easy to like the idea of the job. It was harder to explain what I would actually do for most of the day, or where I would learn to do it well enough to be useful.

I eventually moved into data analysis. Excel and problems I understood from my existing work gave me a place to begin. That matters to my story, but it would be a poor universal instruction for everyone reading this. Having a spreadsheet on your computer does not determine your profession. Being interested in Python does not commit you to a software development career either.

If I were helping you make this decision, I would start by comparing work you can try now. Then I would examine the conditions for further practice and the expectations of specific jobs. Only then would I choose a first direction. Spending six months looking for the perfect professional label is an activity for which, unfortunately, nobody issues a useful certificate.

Compare the tasks you would repeat

An analyst receives a question about some part of an organisation: why support requests are increasing, which products have more returns, or whether a report represents sales correctly. The work involves establishing what the data means, preparing a calculation and explaining what the result supports. Sometimes the person expecting a single number first needs to answer several additional questions.

A programmer might be asked to build a feature that accepts support requests, validates their contents and saves them. The work includes defining behaviour, writing code, checking invalid cases and making later changes possible. The resulting software will run repeatedly, often under conditions that were absent from the first demonstration. Being able to maintain and explain it matters alongside getting the initial version to work.

This distinction is a useful starting point. The US O*NET profile for Business Intelligence Analysts includes querying data repositories and producing reports. Its Software Developers profile emphasises user needs, software design and development. I use these profiles to illustrate responsibilities, without applying American labour market statistics to Polish vacancies or to your individual prospects.

In practice, the boundary is flexible. An analyst building a data pipeline needs to think about maintainable code. A developer investigating a fault analyses evidence and tests hypotheses. Asking which profession types code therefore tells you relatively little. I would pay more attention to the outcome you want to own and the kinds of difficulty you are willing to encounter regularly.

Look at the less glamorous parts too

It is easy to enjoy a finished dashboard. Before producing one, somebody needs to understand what a row represents, why a date is missing and whether two departments use the same customer definition. If you like tracing discrepancies and explaining them, that is a good reason to explore analysis. Enjoying attractive charts alone gives you a much smaller sample of the job.

In programming, the appealing demonstration is an application that works. Less appealing activities can include reproducing a fault, reading unfamiliar code and revising a feature after requirements change. Notice whether you want to understand the system when the demonstration stops working. The first success feels good in either direction. A second session spent improving the result may reveal more about your preferences.

You do not have to love every inconvenience. The useful question is which problems you want to become capable of solving. You can dislike messy data while enjoying the process of making sense of it. You can find a software failure frustrating while still wanting to investigate its cause. That is different from being interested only in the polished result shown by an instructor.

Use what you know from your current work

My customer service experience mattered because I knew processes and problems that data could help describe. Excel gave me access to practical work. Your starting point might be logistics, sales, order handling or scheduling. Familiarity with a domain helps you ask worthwhile questions. Knowing an application function does not automatically tell you which business question deserves attention.

I would begin with a small problem whose result someone can assess. One example is a list of open support requests grouped by waiting time. You need a reference date, a definition of an open request and a rule for missing timestamps. Those decisions come before choosing a formula or a chart. The exercise gives you a taste of the analytical part of the work.

For software development, the starting point could be a repetitive file operation that you are allowed to automate. Before writing a script, define the expected input, output and response to an error. Some employers do not permit additional tools or personal scripts. In that case, create a similar exercise outside the company environment, using synthetic data and your own equipment.

Using professional experience does not require publishing company records in a portfolio. Separate your understanding of a problem from access to particular data. You can describe a fictional process and construct a small dataset yourself. This lets you demonstrate reasoning without suggesting that a practice exercise was a real client engagement or sharing information that belongs to somebody else.

Try two small projects on the same problem

Here is an experiment I would use to choose a next learning step. It is my practical suggestion, not a validated aptitude test. Give both tasks similar time limits and begin with simple tools. If one requires a weekend of installation while the other uses a familiar spreadsheet, record that difference. Do not immediately interpret unfamiliar setup work as evidence of a lack of ability.

Use a fictional equipment rental business. Prepare a dozen or so records containing a rental identifier, equipment category, collection date, planned return date and actual return date. Include deliberate exceptions, such as a missing return date and a repeated identifier. All the data is synthetic. A small dataset is sufficient to expose assumptions that a large clean example could hide.

For the analysis, identify which rentals are overdue on a specified reference day and compare equipment categories. Explain the classification rules. Distinguish items still on loan from those already returned late. Produce a short summary, manually check a few records and describe a decision someone could consider based on the result. Include a limitation if the data cannot support a stronger conclusion.

For the programming task, build a simple function or script that accepts the file and returns records needing attention. Decide what happens when a required column is absent, a date is invalid or the file is empty. Local execution is enough. You do not need accounts, cloud hosting or an administration panel that resembles a space mission control room.

After the first version, change one requirement. For example, the return deadline now includes a specific time rather than an entire day. Examine what needs to change in the analysis and in the program. This is particularly useful because it reveals whether you understand your earlier assumptions and can locate the places where they affect the result.

Assess independence, interest and the quality of your revision

I would avoid awarding points for first-attempt speed. Someone already comfortable with spreadsheets will naturally achieve more there than in their first script. Record separately where you needed help with syntax, interpretation and checking the answer. Specific gaps provide something to work on. A general feeling of being bad at everything does not produce a useful practice plan.

Be precise about interest as well. Did you want to find the reason for an unusual total? After discovering a program error, were you curious about preventing the same failure? Could you explain the result to another person? These observations do not deliver a career verdict, but they provide better material for a decision than another ranking of popular technologies.

Ask one person to perform a small check. For the analysis, they could ask why a particular record belongs in a category. For the program, they could change an input in an agreed way. Record their feedback and revise your work. If nobody is available, return the next day and follow the instructions as a user who does not already know your intention.

Do not assess only whether the revision was enjoyable. Check whether you understand its purpose, can explain it and know how to spot a similar issue next time. Professional work includes discussing the quality of an outcome. Both directions benefit from accepting a specific correction without turning it into a judgement about your entire personal worth.

Give a course a defined role in your plan

I do not dismiss courses. A well-designed resource can organise the basics and reduce aimless searching. The difficulty appears when completed lessons become the only evidence of progress. During a course, the instructor often chooses the tools, data and sequence of operations. In practical work, some of those decisions become your responsibility. That independence needs deliberate practice.

After a lesson, return to your own task. If you learned grouping, create a different summary and predict its output. If you learned functions, extract a repeated part of your script and check several inputs. The variation does not need to be dramatic. It should require a small decision that cannot be made by copying the final line of the demonstration.

A certificate can document course completion, but it cannot replace a conversation about your work. In a portfolio, describe the question, assumptions, checks and limitations. Call an exercise an exercise. A credible small result is more useful than a description suggesting a company deployment when the project was actually a reconstruction of a tutorial.

You can also keep a short explanation of what you changed after feedback. This makes the learning process visible without presenting a diary of every typo. A reviewer can see that you recognised a problem, understood its consequence and improved the solution. That story works for an analytical report as well as for a small program, because both involve judgement about the finished result.

Check the conditions for your next step

After the trial, examine current vacancies for specific roles and locations you would genuinely consider. Write down recurring tasks and requirements in your chosen sample. A handful of advertisements does not establish the state of the whole market. The purpose is narrower: to check whether your learning plan points towards work you actually want to apply for.

Separate immediate requirements from things you could develop later. Job advertisements can be broad, and titles are not always consistent. If you can speak with someone in a similar role, ask about an ordinary week, common revisions and how the team checks quality. Favourite technologies make pleasant conversation, but they tell you less about everyday responsibilities.

Include your calendar in the decision. A direction that requires substantial study may suit you, but it still needs to coexist with work and rest. Do not assume that every evening for several months will find you alert and available. Choose a scope you can test with the resources you have, and set a date to reassess the plan.

The practice conditions also affect how you interpret results. If a promising task keeps stalling because your environment is difficult to use, solve that practical obstacle before deciding the profession is wrong for you. Conversely, a convenient tool does not oblige you to enjoy its usual work. Access and preference are separate pieces of evidence, and I would keep both in the decision.

Take pay seriously without inventing probabilities

An earlier version of the Polish article compared illustrative salary amounts and chances of success. That calculation can appear rigorous even when the result depends entirely on invented inputs. I do not know your probability of getting a particular job. Multiplying an unsupported percentage by a salary gives a guess a tidy mathematical appearance; it does not make the estimate reliable.

Account for money through concrete conditions: the income you need, the time you can spend studying and the practical consequences of moving into a new role. When comparing vacancies, check contract type, hours and responsibilities. One unusually high advertised amount is not a typical outcome for a person starting from scratch, and it cannot establish the return on your own learning plan.

Likewise, I would avoid treating either profession as a guarantee of stability. Plan another assessment of your skills and the opportunities available to you. This article offers a way to gather information about tasks and your response to them. It does not forecast your earnings or promise a date by which you will receive your first job offer.

Separate a career choice from leaving your current situation

You may want both a different employer and a different profession. I would gather evidence for those questions separately. If your main difficulties concern management, working hours or a lack of influence over your tasks, a new job title cannot guarantee improvement. You also need to examine how the next workplace operates and how responsibilities are agreed.

Make a short note about what you want to do more often, what you want to do less often and the conditions you need. The first group might include investigating causes, building solutions or speaking with users. The second could include constant task switching or unclear expectations. The third might involve uninterrupted time and access to useful feedback. This separates the work itself from its organisation.

Check whether your current role offers a small opportunity to try the new direction. Producing a report or improving a repetitive task may provide practice before a formal role change. Agree the scope and responsibility so that initiative does not become an unofficial second job. An independent evening project needs boundaries too, otherwise its real cost becomes difficult to assess.

If both directions remain interesting after the trial, there is no need to force a winner. Choose a task that develops shared skills: describing a problem, checking inputs, recording assumptions and explaining an outcome. Then add a small element specific to one direction. The next attempt will give you new information instead of recreating the same dilemma in front of an empty editor.

When speaking with someone in the profession, show the task you completed. Ask them to identify one important gap and describe comparable work in their role. A general question about whether you belong in IT invites fortune-telling. A concrete sample makes a more useful conversation possible. You can receive a practical next step even while the final career choice remains open.

Choose a first stage and a review date

After the two trials, choose a direction for the next month. Define one result you want to produce independently and how you will assess it. For analysis, this might be a report with explicit definitions and data checks. For programming, it could be a small application with running instructions and invalid-input checks. Keep either scope small enough to finish and review properly.

Also write down what would justify reconsidering the choice. You may find analysis interesting while struggling with the basics of a tool. That calls for practice, rather than an immediate change of profession. You may instead discover that building the mechanism interests you more than interpreting its output. That is a reasonable reason to attempt another programming task.

If you choose analysis, your next question may be whether to learn SQL or Python first. If getting started has become the main obstacle, read about returning to learning after losing motivation. You do not need to settle your entire career before completing a first task. A sensible trial, an honest assessment and a next step based on what you observed are enough to move the decision forward.