This kind of depends on the engineer, the company, what phase of life the company is in, etc. I spend a large majority of my time working with code. This is reading, debugging, testing, and writing. Personally, I bundle those up into 'writing code' because I can't successfully add new code without reading and understanding what exists. I shouldn't be shipping production code without writing tests, and doing at least some minimal testing of real use cases. As we all know, there will be bugs. And debugging takes time to read and understand what the intention is, and figuring out with testing in which cases it breaks.
All of that said, it still depends on how your team and projects are structured. Undocumented code isn't very useful. As a backend engineer, writing an API without documenting it doesn't help other teams understand what you're doing. As a new engineer though, no matter where you are, you're likely to spend a lot of time reading code, updating documentation, working on small bug fixes, and other tasks that are hard to justify putting engineering time on. It's not just because it's a bit of grunt work, it's a great way to understand the stack and tools that you're going to be working with. There's a lot to learn!
If you're in an early stage startup, you'll write a lot of code because you're creating things that don't exist yet while trying to get to a big, robust product. If you're in a large long-standing company, you're more likely to be in a maintenance role - adding to existing functionality and patching bugs. Ultimately, no matter what, you're going to spend a lot of time working with and communicating with coworkers. Someone (almost definitely not you) is going to decide what needs to be built, when it needs to be built by, and what the parameters are. You'll be in conversation with them throughout the project to ensure it meets the needs of the problem you're trying to solve. You'll spend a lot of time reviewing code. Deciding with coworkers which third party dependencies should be used. How to transition to new technologies when things start to get out of date.
Depending on how you frame it, this is all writing code. It's the underbelly of what it is to write and build something new. It's not always as fun as making something new, but it helps build something stable and maintainable that you and others can continue to add to without needing to rewrite something each time a new problem is faced. And in the end, it makes the time when you're working on a project much easier to reason with and solve in a reasonable way.