Ask HN: How much of your time at work as a software engineer is spent coding?

very curious how different types of software engineers spend their time.

i'm working at my first big company. even within the company it seems that our engineers have vastly different types of jobs. some spend a lot of time writing application code. many others doing devops and configuration/deployment (and just justifying the work they're doing or waiting for answers).

I spend a long time getting requirements for a job. Then a couple of days reading documentation and slowly coding my way into a bunch of corners resulting in code that doesn't work. So after 3-4 days of "working" on a project, I'll actually get into a groove where I can knock out a decent app or tool in about two days. Then add another day for testing and documentation. With fixes needing to be made here and there, that means two good days of coding (and a couple days of bad coding that might be thrown away) for two weeks.

If I start spending a lot of my time coding, that means I'm running off without getting requirements, or I'm stuck with a problem I don't know how to make progress on. So for me this is a good cadence.

As a junior developer, I spend around 4-5 hours coding and the rest of my time is taken by meetings and code reviewing

Funnily, I spend my daytime researching, reading code, meetings about meetings, gathering requirements.. doing the human interaction aspect. I'll spend a lot of time assembling modules in my mind, while doing the dishes or house chores. By experience, I prefer spending days of hard thinking and hit the keyboard once I know where I'm heading. Coding is easy, programming an efficient system is hard.

My answer is: as much as possible! I willingly took a 50% paycut this year and left my $big_company job to invert the 80% meeting / 20% tech ratio, and it was the best decision professional decision I've ever made.

On a day-to-day basis, there's always going to be a cyclical element -- I just spent two weeks writing code nine hours a day to push through a big feature, and now I expect to spend a week or two on less focused work, catching up on all the things I ignored while I was heads down.

I also try to turn non-code work into coding work. In lieu of doing a BUFD, I'll try to throw together a proof-of-concept or do a spike. Whenever there's a production issue, I try to turn that into a project to eliminate that class of issue. If there's some repetitive administration to do, I try to automate it.