Translating your computer science degree for family: 4 strategies that bridge the gap

Your relatives ask what you study and you say "computer science" or "electronics engineering", and the next question is whether you fix laptops. You describe algorithms and the eyes glaze over. The disconnect is real, and it doesn't mean your work is too complex to explain — it means the words you've learned at university aren't the words most people use to think about technology. IJCSEE breaks down how to frame your degree in terms that land without dumbing down what you actually do.

Starting with what they already use

Most people interact with the results of your field every day without thinking about the systems underneath. Their phone unlocks when they look at it, their car warns them before they drift out of a lane, their thermostat learns when they're home. Each of those behaviours required someone to write instructions, design circuits and test what happens when things go wrong.

Anchor your explanation in something they've experienced. If they've ever wondered why their phone battery drains faster in cold weather, you can talk about how circuits behave under different conditions. If they've cursed at a website that wouldn't load, you can describe the layers between clicking a button and seeing a result. The technology is invisible until it breaks, and that's where your explanation starts — with the moment they noticed it at all.

Picking one device they rely on

Choose something they use daily: a car, a heating system, a contactless card reader. Walk them through one decision that device makes on its own. A modern car doesn't just warn you about low tyre pressure — it compares readings from sensors, decides whether the difference matters and chooses the right warning for the dashboard. Someone programmed each of those steps, and someone else designed the circuit that reads the sensors in the first place.

You're not claiming you built their car. You're showing them that what you study is the hidden layer that makes it work without them thinking about it.

Handling the "so you fix computers" assumption

This one comes up at every family gathering. The short answer: you study how computers think and how circuits carry information, which is different from diagnosing why a printer won't connect to Wi-Fi. Fixing a specific machine is troubleshooting; your degree is about understanding the principles that make all machines possible.

A useful analogy: a civil engineer knows why a bridge stands up, but you wouldn't ask them to repaint your fence. Both involve structures, but the work is different. You're learning the theory and practice that lets someone build a new kind of device, not the support skills that keep an old one running.

If they're still confused, try this: you learn to write the instructions that make a computer do something useful, or to design the circuits that turn electricity into signals a computer can read. That's not the same as installing an update or swapping out a hard drive, even though both involve computers.

When they ask if you'll work at a big tech company

Some graduates do. Others design medical devices, write software for manufacturing robots, develop control systems for renewable energy or build embedded systems for cars. The degree opens more doors than the five companies everyone's heard of, and explaining that breadth helps people see past the stereotype.

Turning abstract concepts into everyday comparisons

Words like algorithm, compiler and microcontroller mean something precise to you and nothing concrete to someone outside the field. You don't need to avoid technical terms — you need a translation that shows what the term does in the real world.

An algorithm is a set of instructions for solving a problem, the same way a recipe is a set of instructions for making a meal. Both need to be clear enough that someone else can follow them and get the same result. If you're studying what an algorithm is, you're learning how to write instructions that a computer can execute without guessing.

A compiler takes code written in a language humans can read and turns it into instructions a processor can carry out. Think of it as a translator that works in one direction, turning English into machine commands. A microcontroller is a tiny computer on a single chip, the kind that lives inside a washing machine or a car key fob. It reads sensors, makes decisions and controls outputs, all without a screen or a keyboard.

Building a comparison table that fits your modules

When someone asks what you're studying this term, match each module to something they recognise. The table below shows how that might look in practice.

Describing what you actually do in a lab or a project

Theory makes sense once they see the hands-on part. Explain a recent piece of coursework in terms of the problem you solved, the tools you used and the result you tested. You built a circuit that turned a temperature reading into a signal a computer could log. You wrote a program that sorted a list faster than the obvious method. You debugged code that crashed under one specific condition and traced the error to a single line.

The structure of "problem, method, outcome" is one most people follow in their own work, even if the tools are different. Your uncle might not know what a breadboard is, but he understands the idea of assembling something, testing it and fixing what doesn't work.

Making the debugging process tangible

If you've spent hours tracking down a bug, that's a story they'll recognise. Describe it as detective work: you had a symptom, you formed a hypothesis, you tested it and you narrowed down where the fault was hiding. The satisfaction of finding a misplaced bracket or a wiring error is something anyone who's ever fixed a broken appliance can grasp, and it shows that your work isn't abstract — it has a definite right answer and a moment when you know you've found it. For more on that process, read how to debug code when you're stuck.

Addressing the "isn't that all done by AI now" question

This one has come up more in the past year. The short version: tools that generate code or suggest solutions are useful, but they don't replace understanding how a system works or knowing whether a solution is correct. Someone still needs to define the problem, evaluate the output and fix what the tool gets wrong.

An analogy: a spellchecker catches obvious mistakes, but it won't tell you whether your essay makes sense or whether you've answered the question. You still need to understand grammar, structure and argument. The same applies to code. A tool might write a function for you, but you need to know whether that function does what you need, whether it handles edge cases and whether it fits with the rest of the system.

Automation changes what you spend time on, but it doesn't remove the need to think. If anything, it raises the bar — you're expected to work at a higher level, solving problems the tools can't.

Framing the degree as learning to build, not just to use

Most people use technology; you're learning to create it. That's the distinction worth making. Your cousin might be good with spreadsheets, but you're studying how the spreadsheet software decides which cells to recalculate when one value changes. Your aunt might video-call relatives abroad, but you're learning how data gets compressed, transmitted and decoded at the other end without either person noticing the work.

The difference between a user and a builder is the difference between driving a car and designing the engine. Both are valid, but they require different knowledge. Your degree is about understanding the principles deeply enough that you can make something new, not just operate something someone else made.

Preparing answers to the questions that always come up

Some questions arrive at every gathering. Prepare a short, honest answer to each one so you're not caught off guard or tempted to oversimplify in a way that makes your work sound trivial.

1. Write down one sentence that captures what your degree trains you to do. Keep it general enough to cover the range of modules but specific enough that it doesn't sound like "I work with computers". Try "I learn to design systems that process information and control devices" or "I study how to turn problems into instructions a computer can carry out".
2. Pick one project you've finished and rehearse how you'd describe it in under a minute. Name the problem, the approach and the result. Leave out jargon unless you've just explained it.
3. Find a comparison for the most common term you use. If you talk about algorithms often, have the recipe analogy ready. If you mention circuits, have the plumbing comparison in your back pocket — both move something from one place to another, and both fail in predictable ways when a connection breaks.
4. Identify one way your field has changed something they care about. If they worry about data privacy, mention encryption. If they drive, talk about the sensors and control systems in modern cars. Make it relevant to their life, not just to your coursework.

Recognising when detail isn't helping

Sometimes the most honest answer is a short one. If your grandmother asks what you're studying and you say "computer science and electronics engineering", and she says "that sounds complicated", you don't owe her a lecture. A warm "It is, but I enjoy it" is often the right note. Not every conversation needs to be a teaching opportunity.

Gauge interest before you go deep. If someone asks a follow-up question, they want to know more. If they nod and change the subject, they were being polite. That's fine. Save your energy for the people who are genuinely curious, and give everyone else the version that satisfies without overwhelming.

#Algorithms #Circuits

Download PDF: Explaining your degree: a one-page guide for family conversations PDF, 28 KB