Ask an engineer what they did this week and very little of the answer will be typing new logic into an empty file.
Where the time actually goes
The public image of the job is composition. The reality is closer to archaeology, negotiation and repair.
Reading existing code to understand what it does. Reproducing a reported fault. Reviewing someone else's change. Integrating with a system whose documentation is out of date. Waiting on a build. Discussing an approach. Deploying. Investigating why the deployment behaved differently from the test environment. Fixing something that has worked for two years and stopped.
Actually writing new code is a genuine part of the work and it is not the largest part, and it is rarely the part that determines whether the project succeeds.
The constraint on most software teams is comprehension and coordination, not typing speed.
This has a direct training implication. A development programme that focuses entirely on languages and frameworks is training for the smaller half of the job. The skills that decide outcomes, reading unfamiliar systems, reviewing well, designing for change, communicating a technical decision, are teachable and are usually left to absorption.
What the direction covers
The scope: architecture, code, testing, application programming interfaces, version control, deployment and working as a team.
Four areas.
Construction. Languages, design, interfaces and the craft of writing code others can change.
Verification. Testing at every level, review, and the discipline of knowing what has actually been checked.
Delivery. Version control, continuous integration, deployment and release practice.
Collaboration. Working in a team on a shared system, which is where most of the difficulty in commercial software actually lives.
The largest job increase in the whole table
Worth stating precisely, because the public conversation about this occupation has become confused.
The US Bureau of Labor Statistics projects employment of software developers to grow 15.8 percent between 2024 and 2034, an increase of 267,700 jobs. In the same set of projections, that is the largest absolute increase among the technology occupations tracked, larger in raw numbers than data scientists and information security analysts combined, even though both grow at higher percentage rates. Total employment across all occupations is projected to grow 3.1 percent over the same period.
Two qualifications belong immediately alongside that figure, and leaving them out would be dishonest.
It is a projection. Projections are models built on assumptions about technology adoption and industry growth, and they are revised. This one incorporates an assumption about artificial intelligence raising productivity, which is why the same table shows several administrative occupations declining.
Entry-level hiring has been difficult. Graduates and career changers have faced a tighter market than the headline growth figure implies, and aggregate decade-long growth says nothing about how easy it is to get a first job in a given year.
The reconciliation is that a large share of projected openings comes from replacement rather than expansion, and that the demand skews towards people who can work with existing systems. That is a statement about which training pays, not an argument that the growth is fictional.
Review is the skill that scales a team
The highest-leverage teachable skill in software engineering, and one that almost no organisation teaches deliberately.
Code review is where defects are caught before they cost anything, where knowledge spreads across a team, where standards become real rather than documented, and where junior engineers learn fastest. It is also where a great deal of time is wasted and where a surprising amount of workplace conflict originates.
Four things that separate useful review from ritual.
Knowing what to look for. Correctness, error handling, security, scale behaviour, and whether this will be comprehensible in a year. Formatting is what a tool should handle, and it is what inexperienced reviewers spend their attention on.
Reviewing the design, not the diff. The most valuable comment is frequently that the change should not exist in this form, and that comment is much cheaper before the work is done.
Separating what must change from what you would have done differently. Conflating preference with requirement is the single largest source of friction in review, and it teaches people to stop asking.
Making it safe. A review culture where people fear being criticised produces smaller, later, less honest changes and hides problems until they are expensive.
None of this is difficult to teach. It is simply assumed to be learned by exposure, and people learn whatever their first team happened to do.
Where this sits in the domain
Software engineering is the second of eight directions in Astra Trainer's AI, data and computing domain, and it is the largest by headcount across almost every partner organisation. It rests on computer science for the underlying model and connects forward to cloud computing and DevOps, where the delivery half of the job now lives.
It also connects to cybersecurity, since a large share of vulnerabilities are ordinary software defects, and to artificial intelligence and machine learning, where the systems around a model are conventional software engineering. You can see the eight directions here.
Maintenance is the job, not the aftermath
Software is not finished when it ships. Most of the money spent on a system over its life is spent after the first release, and most engineers spend most of their careers working on code that already exists.
Yet almost all technical education uses greenfield exercises. People are taught to build something new, in isolation, with clean requirements and no history, and then hired into a system with fifteen years of accumulated decisions, partial migrations and comments describing behaviour that changed long ago.
The skills that gap requires are specific and teachable.
Reading unfamiliar code. Finding the entry point, tracing a path, building a working mental model without reading everything.
Changing code safely. Adding tests to untested code before modifying it, making small reversible changes, and using types and contracts to constrain the effect of an edit.
Understanding why something is the way it is. Much of what looks irrational in legacy code was a correct response to a constraint that no longer exists or a bug that is no longer remembered. Deleting it without knowing which is how outages happen.
Managing technical debt honestly. Distinguishing decisions that were reasonable trade-offs from accumulated neglect, and making the cost of each visible to people who decide priorities.
Migrating incrementally. Almost every large rewrite that was attempted as a single replacement is a cautionary story. Incremental migration is a skill with known patterns and it is rarely taught.
The roles, named
Software engineers, across front end, back end and full stack.
Platform engineers, building the internal tooling other teams depend on.
Mobile engineers.
Quality and test engineers, including automation.
Site reliability engineers, where software engineering meets operations.
Technical architects.
Engineering managers and technical leads, where the constraint is usually judgement rather than coding ability.
Developer experience engineers, a growing specialism aimed at the comprehension and coordination bottleneck.
Integration engineers, connecting systems that were not designed to meet.
Who can be trained into it
Quality assurance and test engineers. The strongest internal conversion. They already know the product, know how it fails and know the codebase from the outside.
Support and operations engineers. Into development, holding production knowledge that development teams lack and frequently need.
Data analysts. Already writing code, needing engineering practice: version control, testing, review and design for change.
Business analysts and product staff with technical inclination, into engineering-adjacent roles where domain understanding is the scarce half.
Engineers from other disciplines. Mechanical, electrical and civil engineers convert well, bringing systematic method.
Scientists and researchers who already write code for their own work, needing collaborative practice rather than programming.
Experienced developers in ageing technologies. Frequently overlooked, holding deep systems knowledge and needing a current toolchain rather than a career change.
On generated code and accountability. Code produced by generation tools is the responsibility of the organisation that ships it, and may carry defects, security vulnerabilities, licensing implications or behaviour that nobody on the team can explain. Review, testing and provenance obligations do not transfer to the tool. Sectors with regulated software, including medical, automotive, aviation and financial systems, have specific requirements for development process and traceability that apply regardless of how the code was produced.
What to take from this
Producing new code is the minority of the job, and training that covers only languages and frameworks addresses the smaller half.
Software developers are projected to add 267,700 jobs by 2034, the largest absolute increase in the technology occupations BLS tracks, and that is a projection sitting alongside a genuinely difficult entry-level market.
Code review is the highest-leverage teachable skill in a team and is almost universally left to absorption.
Maintenance and legacy work is where careers are actually spent, and education overwhelmingly trains for greenfield.
And the best internal candidates are usually in test, support and operations, already holding the knowledge that new hires take a year to acquire.
What do software engineers actually spend time on?
Reading existing code, reproducing faults, reviewing changes, integrating with systems whose documentation is stale, deploying and investigating differences between environments. Writing new code is real but is not the largest share.
Is software development still growing as an occupation?
BLS projects 15.8 percent growth from 2024 to 2034, an increase of 267,700 jobs, the largest absolute increase among the technology occupations it tracks. That is a projection rather than an observation, and it coexists with a difficult entry-level hiring market.
Why does code review matter so much?
Because it catches defects before they cost anything, spreads knowledge across a team, makes standards real and teaches junior engineers faster than anything else. It is also where most technical friction originates when done badly.
Why is legacy code work undertrained?
Because technical education uses greenfield exercises with clean requirements, while most engineers spend most of their careers changing systems with years of accumulated history, partial migrations and undocumented reasons.
Who converts well into software engineering?
Test and quality engineers first, then support and operations staff, data analysts who already write code, engineers from other disciplines, and experienced developers in ageing technologies who need a current toolchain rather than a career change.