Pathway · Sample Problems
Practical Computing & Digital Applications
What real problems look like — and what separates a serious one from the easy way out
You have already read what practical computing is and whether it might be for you. This page goes one level deeper. It shows what actual problems in this pathway look like, in enough detail that you can picture the real work involved — and see the difference between engaging with a problem seriously and doing the least you can get away with.
These are examples, not a menu
Every problem below is an illustration of the kind of work this pathway contains — not a list to choose from. You do not have to pick one of these. In fact, the strongest projects usually begin with a real annoyance in a student's own life — a task they are tired of doing by hand. You are welcome to build on one of these examples or design something entirely your own. Either way, the standard is exactly the same.
What makes a problem serious
Across every pathway in this course, the difference between a strong project and a weak one is almost never the topic. It is whether the work shows these six things:
- A real question. You are answering something, not just making something.
- A genuine computational core. A real algorithm, model, or analysis does the work — not a few lines that print a result.
- A design decision you can justify. You considered more than one approach and can say why you chose yours.
- Evidence that you tested it. You checked your result against something you can trust, not just "it ran."
- The ability to explain it live. You can walk through your own code and answer questions about how and why it works.
- Honesty about its limits. You can say what your work does not do, and why that matters.
The easy way out is to take any problem — including the ones below — and build only the shallow version: the part that runs quickly and looks finished. That shortcut is visible almost immediately, and it is unmistakable in the oral defense, where you have to explain and modify your own code on the spot. A problem is only as serious as what you do with it.
The thing to understand before you start
You are not assessed on how difficult your topic sounds. You are assessed on the depth of your engagement with it. A simple question taken seriously beats an ambitious one done shallowly, every time.
One test this pathway keeps coming back to
Would you actually use it? A tool built only to be handed in is easy to spot — it forgets your data the moment it closes, it breaks on anything unexpected, and no one, including you, would ever reach for it again. A tool built to be used is different: it keeps your data, it survives real use, and it genuinely saves someone effort. Build the second kind.
Sample problem 1 · Automate a task you would otherwise do by hand
This is the heart of the pathway. Somewhere there is a task that is repetitive and tedious — generating the same report every month, renaming a pile of files, reformatting data the same way every week. A strong problem finds one and builds something that does it automatically, reliably, every time, saving real effort.
The computational core is that the automation has to be genuine. It has to handle every case the task throws at it, run without you standing over it, and produce output you can trust — not a script you nurse through by hand each time you use it.
The easy way out
- A script that does one step, once, when you run it manually on perfect input
- "Automation" that still needs you to do most of the work
- Breaks the moment the task varies even slightly
What a serious version demands
- A tool that genuinely takes the task off your hands
- Handling of the variations and messy cases the task actually contains
- Reliable output every time, without babysitting
- An honest account of what it still cannot handle
Sample problem 2 · Turn messy real data into something usable
Real data arrives messy: missing values, duplicates, inconsistent formats. A strong problem takes genuinely messy data and turns it into something a person can actually use — a clean dataset, a clear set of charts, a small dashboard someone can explore to answer their own questions.
The core work is in the cleaning and the usefulness. Cleaning data so it can be trusted is the unglamorous part that everything else depends on; making the result genuinely explorable is what turns numbers into a tool.
The easy way out
- Use a small, clean, tidy dataset that avoids every real difficulty
- Print one static chart and call it analysis
- Never test it on data it has not already seen
What a serious version demands
- Genuinely messy data that you actually clean and validate
- A tool or view that lets a person explore and answer their own questions
- A result that still holds up when given new data
- Clarity about what the data can and cannot tell you
Sample problem 3 · Build a tool you would actually use every day
The most satisfying practical projects are the ones you keep using after the grade is in: a task manager, a homework tracker, a small system for organising something in your life. The real test is simple — is it good enough that you would reach for it tomorrow?
This is where persistence and real-world messiness bite. A tool that forgets everything the moment it closes is not a tool, it is a demo. A useful one saves its data, lets you search and prioritise, and does not fall over when you actually use it.
The easy way out
- A task list that lives only in memory and vanishes when the program stops
- No search, no priorities, no way to find anything again
- Breaks on anything you did not personally anticipate
What a serious version demands
- Data that persists to a file between runs
- Search, filtering, and prioritisation that actually work
- Sensible handling of odd or incomplete input
- Enough polish that you would genuinely use it yourself
Sample problem 4 · Make a program act on time, or connect the tools you already use
A passive list waits for you to check it. A useful tool acts: it tells you what is due before it is too late, or reaches out to another service and pulls in something you need. This is where working with dates and time — and connecting to the tools and data you already use — turns a static program into something that genuinely helps.
The core is correct time logic: what counts as "due soon," what is overdue, the edge cases around today and deadlines. Push further and it becomes pulling live data from an outside source — a weather service, a public dataset — reliably, and handling the moments when that source is unavailable.
The easy way out
- A "reminder" that only appears if you happen to run the program and read the output
- Date logic that quietly gets "today" or "overdue" wrong
- An outside data source that is assumed to always work perfectly
What a serious version demands
- Reminders or actions that surface the right thing at the right time
- Correct handling of dates, deadlines, and their edge cases
- Reliable use of any outside data source, with sensible behaviour when it fails
- A tool that does something for you, rather than waiting to be asked
Choosing your own problem
These four problems span a lot of the pathway: automating repetitive work, turning messy data into something usable, building a tool you would actually keep, and making a program act on time or reach out to other services. They are meant to show you the shape of the space, not to fence you into it. The best starting point is usually a real annoyance in your own life — something you are tired of doing by hand.
One honest warning specific to this pathway: these are exactly the kinds of tools an AI will write for you in seconds. That makes the easy way out especially tempting — and especially easy to catch. Code you pasted and cannot explain will not survive the oral defense, and a tool you do not understand is one you cannot fix when it breaks. Bring your idea to your teacher, hold it to the same six standards above, and build something you genuinely use, understand every line of, and could hand to someone else.