What programmers actually do all day

How much time goes on code

Less than people assume. For an ordinary developer, writing new code takes roughly a quarter of the working day, often less.

The rest is reading other people's code, working out why something doesn't work, discussions, clarifying requirements, reviewing changes, meetings.

That doesn't make the work dull. It means the picture of "a programmer sits and types" is wrong, and anyone entering with that expectation is disappointed.

An ordinary day

• A morning check-in. Fifteen minutes: what people did, where they're stuck.
• Working a task. It usually looks like this: work out where to change things, read the surrounding code, understand why it was done that way, and only then write.
• Reviewing others' changes. Reading colleagues' code and leaving comments.
• Answering questions. Yours and other people's.
• Investigating a breakage. A regular part of the job: something doesn't work and you have to find out why.

What surprises people

More reading than writing. You join a project with a hundred thousand lines written before you. Getting your bearings in unfamiliar code matters more than typing speed.

A lot of talking. Clarifying requirements, explaining decisions, negotiating with a neighbouring team. Entirely silent work is rare.

Requirements change. What was needed yesterday is cancelled today. That's the normal course of things, not somebody's failure.

Little beautiful code. Real projects always contain places written in a hurry. Much of the job is carefully improving what already exists.

What you genuinely need to be able to do

• Figure out the unfamiliar. The main skill. Knowledge dates; the ability to get up to speed doesn't.
• Ask questions. In time and to the point.
• Explain your decisions. If you can't say why you did it that way, the decision is treated as accidental.
• Finish things. Closing tasks is valued above starting them elegantly.

Who it suits

People who enjoy working out how something is put together and aren't maddened by long spells of poking at the incomprehensible. People who can calmly spend three hours finding out why one number doesn't add up.

It suits poorly those who need fast results and can't bear uncertainty: a large part of the job is the state of "not clear yet".

How to check whether it's for you

The only reliable way is to build something yourself, end to end. Not complete a course — build: with baffling errors, dead ends, and the need to decide for yourself what's right.

And to find out whether the collaborative side suits you as well, work with people: divide the tasks, discuss each other's code, agree deadlines. That's closest to the real job — and it becomes clear far faster than a year of studying alone.