What software engineers actually do all day

In one sentence

The job is deciding what to build and keeping it working — writing the code is the part that takes the least time and causes the fewest problems.

Why it matters

Most people arrive at this job having practised one skill: given a clearly stated problem, produce a correct program. That skill is necessary and it is maybe a quarter of the work. The other three quarters are the parts nobody sets exercises for, and they are the parts that determine whether you are trusted with anything significant.

Knowing this early changes what you practise. It is the difference between three years of experience and the same year three times.

Where the time actually goes

Roughly, for a working engineer on a team:

• Reading code and systems. Understanding what exists before changing it. This is the single largest slice, and it never shrinks — new codebase, new team, new area of the same codebase.
• Deciding what to build. Turning "users are complaining about search" into a scoped change with a defined boundary.
• Writing and revising code. Including the second and third attempt after the first one turned out to be wrong.
• Reviewing, discussing, and writing things down. Pull requests, design docs, the message that stops someone building the wrong thing.
• Operating. Debugging production, responding to alerts, fixing what broke.

The proportions shift with seniority, but they shift away from writing code, not towards it.

What good looks like in each

Reading. Start from an entry point and follow one real request all the way through. Do not read the codebase; read one path through it. Use the tests as documentation — they encode intent that comments do not. Run it locally and put a breakpoint somewhere confusing.

Scoping. The most valuable question is "what is the smallest version of this that is worth shipping?" Almost every project has a 20% that delivers most of the value, and finding it is a technical skill, not a product one. The second most valuable question is "what happens if we do nothing?"

Writing code. Optimise for the person who changes it next, which is usually you in six months with no memory of today. That means clear names, obvious control flow, and no cleverness that saves three lines and costs ten minutes of reading.

Reviewing. Look for correctness and design, not style — a formatter should have settled style before a human sees it. Ask questions rather than issuing instructions when you are unsure. Approve changes that are good enough; a review is not a search for the ideal implementation.

Operating. Assume the bug is in your code, form a hypothesis before changing anything, and never ship a fix you cannot explain. "It works now" after a speculative change means you have two bugs.

What to learn first

If you are early, the order that compounds fastest:

1. Your editor, your debugger, and Git. These are the tools you use every hour of every day. An afternoon on each pays back for years, and most people never spend it.
2. SQL and the database you use. Almost every performance problem in an ordinary application is a database problem, and almost nobody looks there first.
3. How HTTP actually works. Methods, status codes, caching, and cookies. Enormous amounts of confusion dissolve at once.
4. Testing. Not the frameworks — the judgement of what is worth testing and at which level.
5. Writing. The engineer who can explain a trade-off in three paragraphs has more influence than the one who cannot, at every level.

What you can safely defer

• Memorising design patterns. You will recognise them when you have written enough code to need them. Learning them first mostly produces AbstractFactory in places that wanted a function.
• Framework churn. The specific frontend framework matters far less than understanding the browser underneath it.
• Distributed systems theory. Genuinely important, genuinely not urgent until you have more than one service. Learn caching and idempotency first; those bite everyone.
• Kubernetes. Unless you are on the team that runs it.
• Competitive programming. Useful for interviews, weakly correlated with the work.

The uncomfortable part

The skills that get you promoted are not the ones that got you hired. Interview processes select for solving well-specified problems alone, under time pressure. The job rewards choosing which problem to solve, doing it with other people, over months, with incomplete information.

Nobody tells you when the switch happens. It is worth noticing on your own, usually somewhere around the point where you stop being the person receiving tickets and start being the person who could have written a better one.

Further reading

• Google's engineering practices — what a code review standard looks like when it is written down.
• The Pragmatic Programmer — still the best single book on the parts of the job that are not language syntax.