Technology
Writes code and keeps digital systems running
Almost every modern organisation depends on software, from navigation apps to clinical systems and multiplayer games. A software engineer designs, builds and maintains that software. Front-end engineers focus on what users see and touch. Back-end engineers work on the services behind it. Mobile, infrastructure, security and games roles each bring different problems.
Code is exact about what you told it to do and indifferent to what you meant. Engineers therefore work with assumptions about users, data, other systems and possible failures. Turning an ambiguous request into reliable behaviour takes logic, curiosity and willingness to stay with a problem after the obvious fix fails. The work mixes precision with prolonged uncertainty.
Computer science and software-engineering degrees are direct routes. Graduates also enter from maths, engineering, sciences and other subjects after a conversion course or sustained self-study. Employers care about sound technical foundations, but evidence matters. A small working project you genuinely understand is more useful than a long list of languages you have briefly tried.
| When | Lowest 10% earn under | A typical earner | Top 10% earn over |
|---|---|---|---|
| On graduating | £24,000 | £31,000 | £48,000 |
| 1 year in | £27,000 | £36,000 | £56,000 |
| 2 years in | £31,000 | £42,000 | £65,000 |
| 3 years in | £34,000 | £48,000 | £74,000 |
| 4 years in | £37,000 | £54,000 | £82,000 |
| 5 years in | £40,000 | £60,000 | £90,000 |
| 6 years in | £43,000 | £65,000 | £98,000 |
| 7 years in | £45,000 | £70,000 | £105,000 |
| 8 years in | £47,000 | £74,000 | £112,000 |
| 9 years in | £49,000 | £77,000 | £118,000 |
| 10 years in | £50,000 | £80,000 | £125,000 |
Once built, software can repeat the same useful action thousands or millions of times without asking you to repeat the work. A small piece of code might translate a conversation or guide somebody home. It could let friends on opposite sides of the world share an experience. There is real satisfaction in seeing an idea become a machine that keeps doing useful work.
Programming rewards accumulated understanding. Patterns that once took days to recognise become familiar. You learn which shortcuts create trouble later and get better at turning a vague request into a clean design. Artificial intelligence can produce code quickly, but that makes judgement more valuable rather than optional. Somebody still has to decide what to build, spot convincing mistakes and understand how the pieces fit together.
Software engineers are among the few workers who can build their own tools. If you keep typing the same command, you can automate it. If tests take too long, you can improve the system that runs them. A repeated mistake can trigger an automatic check. Not every irritation deserves a technical solution, and a “quick tool” can become another thing to maintain. Even so, removing a tedious task from existence is deeply satisfying.
You will not always be designing an elegant new system from scratch. More often, you will be changing code written years ago by somebody who has left, with incomplete documentation and customers depending on it. A one-line request can take a day because the obvious fix breaks three less obvious things. Patience with existing systems is at least as important as excitement about new technology.
A misplaced character can send thousands of notifications to the wrong people, expose private information or take an app offline. Reviews, automated tests and gradual releases reduce the risk, but do not remove it. In teams running important systems, you may take turns being on call. You must think clearly while a failure is affecting real people.
“Just let friends edit a playlist together” raises questions about conflicting changes, permissions, offline devices and notifications. Each hidden link is real even when the screen looks simple. A careful explanation can sound obstructive, and a realistic estimate can sound slow. Engineers are expected to move quickly without ignoring failures that have not happened yet. Responsible work can therefore be difficult to defend.
Usually 3–4 years
Computer science and software engineering teach the most direct foundations; a four-year version may add a valuable year in industry. Graduates from mathematics, physics and unrelated subjects also enter after a conversion master’s or sustained self-teaching. In either case, build and maintain something outside a marked exercise. A modest program that another person can run, break and ask you about reveals more than a list of languages, especially if you can explain how you tested and repaired it.
Usually 0–2 years’ experience
You’ll work on contained tasks with support from more experienced engineers. Much of the job is learning the codebase, the team’s tools and how to make a safe change without accidentally disturbing something else. You’re judged less on speed than on whether you ask sensible questions, learn from feedback and gradually need less help.
Usually 2–5 years’ experience
A feature or technical problem can now be yours from rough description to working release. Success is no longer code that works once. Other engineers must understand it and customers must rely on it. Alongside making design choices and reviewing code, you help keep the team’s software running.
Usually 5–7 years’ experience
The briefs become larger and less clear. Before coding starts, you shape designs, expose risky assumptions and decide which complexity the team can avoid. Mentoring and careful review matter as much as your own output. A senior engineer improves the decisions made around the code.
Usually 7–10 years’ experience
This is often the start of the senior individual-contributor path. A staff engineer usually influences through technical judgement rather than formal authority, guiding work across several teams and solving problems between systems. A lead engineer is more likely to coordinate a particular team while remaining technically involved.
Usually 10+ years’ experience
At this point, the career usually divides. Principal engineers stay technical and shape some of the organisation’s hardest systems. Engineering managers and directors focus more on hiring, coaching, priorities and teamwork. Both routes require credibility with engineers and understanding of the business. The choice is between building through technical influence and building through people.
This majority group studies programming, algorithms, databases and how computers work as connected ideas. Carefully specified assignments make the principles visible. Larger codebases introduce a different discipline: building, debugging and explaining a change when the boundaries are not supplied, and when other people must maintain it afterwards.
Teaches you to break complicated systems into parts, work within constraints and care about failure. Electronic and computer engineering usually include substantial computing already. Mechanical, civil and other branches contribute strong systems judgement but leave a larger gap in programming, data structures and the conventions of collaborative software.
Builds the abstract reasoning needed to follow a problem through several layers and test whether an answer is actually correct. Graduates often pick up programming quickly, then need experience writing maintainable software with other people rather than solving a problem alone.
Chemistry, biology and related subjects teach structured problem solving, evidence and persistence when an experiment fails. Their knowledge is especially useful in scientific, health and environmental software, where a technically valid result may still misrepresent the underlying phenomenon. The gap is usually software design beyond scripts written for one analysis.
Economics builds reasoning with numbers. Business and social-science degrees help you understand organisations, incentives and how people behave. Graduates normally need to learn programming separately. Their subject knowledge can be valuable when building software for a familiar industry.
Arts, humanities, design and other less common subjects contribute clear writing, careful interpretation and an ability to understand context when requirements conflict or a technical choice must be explained. They usually provide little systematic computing, leaving substantial gaps in programming, algorithmic reasoning and understanding how software fails under real use.
Hover a subject to see why it helpsTap a subject to see why it helps
08:45 – 09:30Check the world is still turning
You look at messages from the team and the dashboard showing whether the music platform behaved overnight. Error rates are normal, but several listeners say that tracks sometimes disappear from a shared playlist when two people edit it at once. You reproduce the problem using two phones and add what you’ve learned to the team’s list for the day.
09:30 – 10:00Engineering stand-up
Everyone briefly explains what they are doing and where they are stuck. You thought your current feature would be finished today, but another engineer asks what happens when someone changes a playlist while their phone is offline.
10:00 – 11:45Follow the bug
You trace the disappearing track through the app, the service behind it and the database. Nothing is randomly deleting music. Two edits are arriving almost simultaneously, and whichever one finishes last quietly overwrites the other. You change how playlist versions are recorded, add a test that recreates the clash and check that older apps still behave correctly. Debugging is often the art of discovering which reasonable assumption was wrong.
11:45 – 12:30Review someone else’s code
A teammate has opened a proposed change. You read it for correctness, clarity and possible effects elsewhere in the system. You suggest simplifying one section and ask why an unusual case is not tested. A good review is not a hunt for mistakes; it is a second engineer helping the first make the change safer.
12:30 – 13:15Lunch
Meal deal.
13:15 – 14:00Work out what to build
A product manager and designer show you an idea for letting friends hear the same song in perfect time. The screen is little more than a play button and invitation link. Behind it, the software must cope when somebody’s connection slows or the host skips a track. One listener may not have permission to play the song in their country. You map these difficult cases together and agree on a smaller first version. Some of the most valuable engineering happens before any code is written.
14:00 – 16:15Build the first piece
You build the service that creates a shared listening session and connect it to the new screen. Automatic tests cover the important paths. An AI coding tool produces a useful first draft of a repetitive section, then invents a function that does not exist. You keep the useful part, correct the rest and make sure you can explain every line entering the system.
16:15 – 16:45Release carefully
Your shared-playlist fix has been approved. An automated process runs the tests and releases it to a small group of listeners before increasing traffic. You watch for conflicting edits and check with customer support that the original case now works. A change is not complete just because it ran on your laptop.
16:45 – 18:00Absorb a live surprise
An alert shows that playback is slowing down. A major artist has released an album without warning and millions of people are trying to hear it. The team spreads the demand more evenly and removes an emergency limit in stages. One region slows again, revealing a local queue that the overall average had hidden. You rebalance it and watch until real listeners are playing music normally.
+5 hours compared with the average UK job