In this video, I break down the question I get all the time: “Do you really code 8 hours a day as a software engineer?” The honest answer is no—and it depends. How much I code changes based on the project I’m on, the team dynamic, whether I’m between projects, and even whether I’m pushing for a promotion. For example, at the beginning of the year I spent a huge chunk of time in roadmap planning: meetings, brainstorming, writing design docs, and aligning on priorities with PM and UX. During phases like that, I might only code 10–20% of the time, and a lot of the “work” is improving existing systems and figuring out direction. I also explain how this shifts as you grow from entry-level into more junior/senior roles. The company expects you to drive direction, define scope, and propose high-impact work—not just execute tasks quickly. These days, I average around 50% coding (about four hours of focused time), and the rest goes to code reviews, documentation, and on-call work. Code review is a real skill: it can take as long as writing your own code because you’re digging into context, researching, and catching design risks. And when you’re on call, even “30 minutes of coding” can cost way more energy because of debugging, verifying, and the pressure of P0 issues.