Skip to content Skip to a section

💻Craft & Know-How

Software Engineer · Writes, tests and maintains the code that runs modern life — and is one of the first professions watching AI automate its own daily work.

At a glance
Score intensity

Darker cells mean a higher score for this topic on that metric.

Last reviewed Sources & creditsMedia creditsMethodology

Quick answers

What does a software engineer actually do all day?

Most days split between writing new code, reading other people's code during review, fixing bugs, and talking to teammates about what to build next. Meetings, planning and mentoring take up more time than newcomers expect. A senior engineer often writes less code personally than a junior one, spending more time on design decisions, reviews and unblocking others.

Do I need a computer science degree to become a software engineer?

No, but it remains the most common and lowest-friction route. A four-year degree teaches algorithms, data structures and systems concepts that are expensive to learn on the job. Bootcamp graduates and self-taught engineers do get hired, especially by smaller companies, but usually need a strong portfolio or open-source work to substitute for the credential.

Is software engineering at risk from AI?

Parts of it already are. Tools built into modern code editors now write a large share of routine code — boilerplate, first-draft tests, translations between languages — for engineers who use them regularly. What is much harder to automate is deciding what to build, why, and how a system should be shaped so it survives contact with real users and failure.

How much do software engineers earn?

It varies enormously by country and company. In the United States the median is around $133,000 a year; in Germany roughly €69,000; in India, where the industry employs the most people, a national average is closer to ₹900,000. Senior and staff engineers at large technology companies can earn several times the national median once stock compensation is included.

What's the difference between a software engineer, a programmer and a developer?

In practice, little — the titles overlap and companies use them inconsistently. 'Programmer' is the oldest term and emphasises writing code; 'developer' is common in web and product companies; 'software engineer' leans on the idea of applying disciplined process, testing and design, borrowed from older engineering fields, to building software. Job descriptions rarely distinguish them consistently.

Is a coding interview really necessary to get hired?

At most established technology companies, yes: a live or take-home technical interview, often involving algorithm problems on a shared document or whiteboard, remains the standard filter, alongside a system-design round for more senior roles. Smaller companies and startups are more likely to substitute a paid trial project, a portfolio review, or a conversation about past work.

Open compare lab

Share this page

The image of an engineer typing continuously for eight hours is mostly wrong. Reading other people's code, reasoning about a failure with no obvious cause, and explaining a technical trade-off to people who are not engineers take up as much of the job as writing new code — often more, for anyone past their first couple of years.

The craft passed down inside the profession is less about which language to learn and more about habits of mind: how to search for a bug systematically instead of guessing, when to leave working code alone, and when deleting code is the most valuable thing you did all week.

What the work demands

889074807083
Problem decomposition
88
Debugging
90
System design
74
Communication and collaboration
80
Testing and code quality
70
Continuous learning
83

Problem decomposition

Breaking a vague, large request into small, independently buildable and testable pieces — the skill that most separates productive engineers from ones who stall on big tasks.

Debugging

Systematically narrowing down where and why a system misbehaves, rather than guessing and changing things until it happens to work.

System design

Choosing how services, data and teams should be divided so the whole thing can keep changing safely for years, not just work on day one.

Communication and collaboration

Explaining a technical trade-off to a non-engineer, writing a change up clearly for reviewers, and negotiating scope — most professional code is read and argued about far more than it is written.

Testing and code quality

Writing checks that catch a broken change before a user does, and keeping a codebase legible enough that the next person — often the same engineer, months later — can safely modify it.

Continuous learning

Languages, frameworks and now AI tools turn over every few years; engineers who stop deliberately learning after their first job plateau quickly.

A day in the life

Inbox, standup and triageDeep work: writing codeLunchReviews, pairing and meetingsDebugging, deploys and wrap-upOff the clock (mostly) 036912151821 24h
  1. 7–9 Inbox, standup and triage

    Catching up on overnight alerts and messages, then a short stand-up meeting where the team says what it is working on and what is blocking it.

  2. 9–12 Deep work: writing code

    The best-protected block of the day, ideally with notifications off, spent implementing a feature or fix that needs sustained concentration.

  3. 12–13 Lunch

    A genuine break; many engineers report this is the first thing that disappears in a crunch, and the first thing they regret losing.

  4. 13–16 Reviews, pairing and meetings

    Reading colleagues' pull requests, pairing on a hard problem, and the design or planning meetings that tend to cluster in the afternoon.

  5. 16–19 Debugging, deploys and wrap-up

    Finishing and shipping the day's change, watching it roll out safely, and leaving notes for tomorrow or for whoever is on call overnight.

  6. 19–7 Off the clock (mostly)

    Personal time and sleep — unless it is an on-call week, when a phone alert can turn 3 a.m. into an unplanned production incident.

The know-how

Craft knowledge practitioners actually pass on — not motivation.

01

Bisect, don't guess

When a bug appeared somewhere between a working version and a broken one, binary-search the history instead of eyeballing the diff — check the midpoint, then repeat until one change is left standing.

Standard binary-search debugging, automated by Git's bisect command
02

Read the failure before you read the code

The full error message, stack trace and surrounding log lines usually contain the answer already; jumping straight to the source and guessing wastes the one piece of evidence the computer freely gave you.

Echoed in Brian Kernighan and Rob Pike, The Practice of Programming (1999)
03

Make the change easy, then make the easy change

When a feature is hard to add, that is usually a sign the code is shaped wrong for it. Refactor first, with no behavior change, until the feature becomes a small, obvious diff — then make that diff.

Kent Beck
04

Chesterton's fence

Before deleting or simplifying code, a config value, or a check you don't understand, find out why it was put there. It may be quietly protecting against a failure that hasn't happened in years for exactly that reason.

G.K. Chesterton, The Thing (1929), adopted as engineering folklore
05

Deleting code is progress

Code that no longer exists cannot have a bug, cannot confuse the next reader, and cannot need updating. Removing dead paths and unused features should be celebrated the same way shipping a feature is.

Echoed by Jeff Atwood, Coding Horror, 2007 ("the best code is no code at all")
06

Rubber duck debugging

Explain the problem out loud, line by line, to a colleague or even an inanimate object before asking for help. The act of articulating it precisely often surfaces the bug before anyone answers.

The Pragmatic Programmer, Andrew Hunt and David Thomas (1999)

Tools of the trade

Code editor / IDE

Visual Studio Code and JetBrains' IDEs dominate; both now build AI-assisted autocomplete and chat directly into the editor.

Git

The version-control system nearly the whole industry standardised on after Torvalds wrote it in 2005; almost nothing ships without it.

Issue tracker

Jira, Linear or GitHub Issues turn a backlog of bugs and features into something a team can plan a week or a quarter around.

CI/CD pipeline

Automated systems that build, test and deploy code on every change, turning a release from a nervous manual event into a routine one.

AI coding assistant

Tools like GitHub Copilot now write a large share of the lines an engineer accepts, shifting the daily job toward reviewing and directing rather than typing.

How people fail at it

Resume-driven development

Choosing a trendy language, framework or architecture because it looks good on a resume rather than because it fits the problem, leaving behind complexity the next team has to maintain.

Not reading the error message

Pattern-matching to a remembered fix instead of reading what the program is actually reporting, which can burn hours chasing the wrong cause.

The big-bang rewrite

Scrapping a working system to rebuild it 'properly' from scratch is a famously risky move — Netscape's late-1990s full rewrite of its browser is a widely cited case where it cost the company its market lead.

Similar professions

Closest neighbours on the six-score profile — not the same field only.

Continue exploring

Keep exploring

More in Engineering & Technology