What can I do with a computer science degree besides coding?

Knowing how software works does not oblige you to spend every week building product features. The degree is useful anywhere someone needs to investigate systems, keep them running, explain them clearly or connect technical limits with human decisions. Here are six directions worth testing.

Which computing careers involve less coding?

What does each direction involve?

Digital forensics

Investigate what happened on a device or system after a breach, fraud or dispute. The work combines technical examination, careful records and reports that a non-technical reader, sometimes a court, can follow. Patience and precision matter more than speed.

Infrastructure and reliability

Keep services available, diagnose failures and improve how systems recover. Some roles involve regular coding; others lean more on configuration, monitoring and incident work. On-call rotas are common, so ask about them early.

Technical writing and developer relations

Explain tools and systems to the people who need to use them. Depending on the role, the output may be documentation, examples, workshops, feedback to product teams or support for developer communities. Clear writing and patience with confused readers are the core skills.

Data engineering

Build and maintain the systems that collect, transform and deliver data. This is still engineering and often includes code, but the central questions are reliability, structure and data quality rather than product features.

Technical product and solutions work

Translate between a problem, a customer and what a system can realistically do. The balance of analysis, conversation, documentation and technical work differs sharply between employers. You spend much of the day in meetings and writing.

Research and formal methods

Explore theoretical or experimental computing questions in universities, research institutes and some companies. Look closely at postgraduate requirements and the day-to-day work before treating this as a route.

How do you choose between them?

1. 01Pick the two directions from the table that sound most interesting.
2. 02Do the one-hour test for each, ideally in the same week.
3. 03Note which hour went faster and which output you wanted to show someone.
4. 04Read five current job adverts for the winner and list the skills that repeat.
5. 05Message one person in that role and ask what a normal week contains.

How do you show these skills to employers?

Build one small public piece of work for the direction you choose. A rewritten documentation page, an incident write-up, a cleaned dataset with a short pipeline, or a product brief all work. Employers in these roles want to see how you think and explain, so include your reasoning, not just the result.

On your CV, name the direction in your summary and put the project near the top. Your degree modules matter less than evidence that you can do the specific work.

What are the common mistakes?

• Assuming every computing job is a software engineering job with a different title.
• Judging a role by its title instead of reading what the job description asks you to do.
• Avoiding all code completely, when a little scripting makes most of these roles easier.
• Waiting for a perfect project idea instead of doing one small test this week.

How is AI changing these roles?

AI tools now write more routine code, which makes the judgement around code more important: deciding what to build, checking whether output is correct, securing systems and explaining trade-offs. Several directions in this guide are built on exactly that judgement. Security, reliability and product roles all need people who understand how systems fail.

Do not treat that as a forecast that these jobs are safe. Treat it as a reason to test the parts of each role that rely on understanding, explaining and checking, because those are the parts least likely to be handed to a tool.

How do you get your first role in one of these areas?

• Support or junior operations roles are a common way into infrastructure and security.
• Contributing documentation to open-source projects is a direct route into technical writing.
• Graduate analyst or associate product manager schemes exist at some larger employers.
• Internal moves work well: start as an engineer and shift towards product, writing or reliability.
• Small companies often let one person cover several of these jobs at once, which is a fast way to learn which you prefer.

What are the signs a direction is worth pursuing?

You finished the one-hour test and kept going. You started reading about the field without being asked. The boring parts, such as writing up an incident or tidying documentation, felt worthwhile because you could see who they helped. Those are better signals than whether the job title sounds impressive.

Which modules matter most for each direction?

Operating systems and networking help most in infrastructure, reliability and forensics. Databases and distributed systems matter for data engineering. Human-computer interaction and software engineering practice are useful for product and technical writing. Theory and algorithms matter most for research. If you still have optional modules to choose, use them to test a direction cheaply.

Illustrative example: from coursework to documentation

A graduate who found her coding modules tiring but enjoyed helping classmates understand them rewrites the setup guide for an open-source tool she used. Two maintainers comment on it, one change is merged, and she has a real piece of technical writing to show. Her next test is a short tutorial, to see whether longer writing holds her attention too.

She has not ruled out engineering for good. She has found a direction that uses her degree and that she wants to test further, which is a better position than applying for every developer role and hoping one feels right.