Technology
Software Engineer
Writes code and keeps digital systems running
What does a software engineer do?
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 interact with, back-end engineers on services behind it, while mobile, infrastructure, security and games roles bring different constraints.
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, but graduates also enter from maths, engineering, sciences and non-technical 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.
- Starting pay£31,000
- Ten years in£80,000
- IntensitySteady, with spikes
- CompetitionFierce
- Postgraduate trainingNone needed
Software engineer salary in the UK
- A typical earner
- Bottom 10% up to top 10%
| 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 |
The good and the bad of being a software engineer
The good
Your output keeps working after you stop
Software is an unusual kind of output: once built, it 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, guide somebody home or let friends on opposite sides of the world share an experience. Seeing something that existed only in your head become a machine that keeps doing useful work is one of the profession’s distinctive satisfactions.
Your ability compounds
Programming rewards accumulated understanding. Patterns that once took days to recognise become familiar, you learn which shortcuts create trouble later and you get better at turning a vague request into a clean design. Tools powered by artificial intelligence can now produce code quickly, but that makes judgement more valuable rather than optional: someone still has to decide what to build, spot plausible-looking mistakes and understand how the pieces fit together.
You can automate the parts of your own job that annoy you
Software engineers are among the few workers who can build their own tools. If you keep typing the same command, you can write a script; if tests take too long, you can improve the system that runs them; if a recurring mistake wastes the team’s time, you can create a check that catches it automatically. Not every irritation deserves a technical solution, and a “quick tool” can become another thing to maintain, but there is something deeply satisfying about removing a tedious task from existence.
The bad
Much of the job is archaeology rather than invention
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.
Tiny mistakes can have very public consequences
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 they do not remove it. In teams that run important systems, you may take turns being on call and have to think clearly while an incident is affecting real people.
A small request can contain a system’s worth of consequences
“Just let friends edit a playlist together” raises questions about conflicting changes, permissions, offline devices and notifications. Each dependency is real even when the interface looks simple, so a careful explanation can sound like obstruction and a realistic estimate can sound slow. Engineers are expected to move quickly without ignoring failure modes that have not happened yet, a tension that can make responsible work difficult to defend.
Software engineer career path
Graduate / Junior Software Engineer
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.
Software Engineer
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 be able to understand it and customers must be able to rely on it. Alongside making design choices and reviewing code, you help operate what the team has built.
Senior Software Engineer
Usually 5–7 years’ experience
The briefs become larger and less clearly defined. Before anyone starts coding, you shape designs, expose risky assumptions and decide which complexity the team can avoid altogether. Mentoring and careful technical review begin to matter as much as your own output because a senior engineer improves the decisions made around the code.
Staff / Lead Software Engineer
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.
Principal Engineer / Engineering Manager / Director
Usually 10+ years’ experience
At this point, the career usually divides. Principal engineers remain technical and shape some of the organisation’s hardest systems; engineering managers and directors focus more on hiring, coaching, priorities and how teams work together. Both routes require credibility with engineers and an understanding of the business. The choice is between building through technical influence and building through people.
What degree do you need to be a software engineer?
Gives you the most direct foundation in programming, algorithms, databases and how computers work. The degree opens doors, but employers will still want evidence that you can build, debug and explain something outside a carefully specified university assignment.
Teaches you to break complicated systems into parts, work within constraints and care about failure. Electronic and computer engineering are especially close, but mechanical, civil and other engineers also move across after developing their programming skills.
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. Scientific programming or data work can provide a bridge, particularly into employers that value knowledge of the underlying field.
Economics builds quantitative reasoning, while business and social-science degrees help you understand organisations, incentives and how people behave. These graduates normally need to develop their programming foundations separately, but their subject knowledge can be valuable when building software for a familiar industry.
These graduates usually enter by adding technical evidence through a conversion course or substantial self-directed projects. Clear writing, careful interpretation and an ability to understand context become genuine advantages once the basic engineering bar has been met.
Hover a subject to see why it helpsTap a subject to see why it helps
A day in the life of a software engineer
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.
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.
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.
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.
Meal deal.
A product manager and designer show you an idea for letting friends listen to the same song in perfect sync. The interface is little more than a play button and an invitation link, but the software has to cope when somebody’s connection slows down, the host skips a track or one listener cannot play that song in their country. You map the difficult cases together and agree on a smaller first version. Some of the most valuable engineering happens before any code is written.
You build the part of the service that creates a shared listening session, connect it to the new interface and write automated tests around 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 that will go into the system.
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.
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 at once. The team redistributes traffic and removes the emergency limit in stages as playback times recover. One region slows again, revealing an uneven queue that the average had hidden. You rebalance that load and keep watching until real listeners - not merely the test requests - are playing music normally.
What skills does a software engineer need?
How many hours does a software engineer work?
+3 hours compared with the average graduate profession