That sounds more like a manager or architect than an engineer. Engineers should take a proactive role in discovery and talking with business to figure out the best place to create value (that's a once a month meeting for us), but at the end of the day it's up to the PO to translate business needs into product development. Either way, I doubt you need 4+ hours a day to flesh out the technical requirements. When I worked at bigger companies, I'd spend only roughly 4 hours coding a day too. It's not because the problems were harder, but because there were blockers at every corner due to siloing and overly complicated business processes. I'd spend days in meetings and escalation emails just to get a networking rule exception.

>As a senior engineer, if I told my manager in a performance review that I mostly worked alone on tickets with well defined requirements, I’d be on PIP immediately and probably fired a month later.

Then you're a sucker. Engineers are supposed to write code. Even at the bigger companies, all senior engineers (and I mean 15+ experience) wrote code most of the time and did everything in their power to avoid meetings and other disruptions. That's how I learned about the "Law of Two Feet". Business expects you to coordinate between stakeholders and the rest of the engineering team. What's next? Should you manage the team's budget as well? Make long-term product roadmaps? Get yourself a promotion!

What else are they supposed to be doing? If requirements are fleshed out then all you can do is get started. The bigger the change, the more you'll have to be concerned about architecture and implementation details. I think sitting down and thinking about the problem before you code is necessary for any dev, but I'm here to write the solution at the end of the day.

>If your tasks can all be done truly asynchronously without blocking someone else, they probably aren't very exciting or special.

My company right now is about 15 people, 5 of which are engineering (including myself). When your team is that small, you don't have room for too many specialists. We're all capable individuals that can do the work without waiting for anyone. I'll get a ticket asking for a new web page, a new backend endpoint, DB updates, Et Cetera and it's the expectation that I do this all by myself. If there's something out of my wheelhouse, I can lean on my team but this is the exception and not the rule (and can still be done async). I don't know what special looks like for you but I can list the contributions I've made and the impact it has for our bottom line. In two months I reduced AWS spend by $5k/month, added payment enforcement logic netting us tens of thousands within the first week of its release, and seamlessly added a Huggingface NLP model into our AWS infra (our DevOps guy doesn't even know ML, he just treats the Sagemaker instance like any other resource). That's pretty impressive to me.

What I've noticed is that I really do have more time to just do work. I end up releasing 3x a week instead of twice a month. I think it's still good to have refinement meetings and set time with the PO/Manager about vision and priority, but this idea that you need to spend even 10% of your time in synchronous discussions with your team is ridiculous.

That's because the value proposition with most games is in their art direction and gameplay - nobody cares how you get the polygon on the screen. I wrote my own game engine for a bit but then realized that all the work once the scaffolding was complete was in creating a fun game. Turns out that I don't really enjoy level editing and 3D modeling as much, so I stopped developing the project.

EDIT: To answer your question, I actually think that JSX is a downside to React. I get that it was needed to convince the web crowd to adopt the library, but we need to stop pretending like we're writing HTML. We're not. The framework will take our JSX and do whatever it wants to it. I wish we just treated the DOM like a compilation target. That's actually what I like about Flutter - it treats the view as a render target and not as a document that you write to. Flutter web actually uses the canvas API to draw actually. And because of this, you can define your View model in a much more sane way (while still being fast). E.g. Flutter's Layouts make much more sense than HTML and flexbox/grid. They managed to separate the layout from elements. https://docs.flutter.dev/development/ui/layout

Every template-based framework I've seen has involved a lot of magic, syntax and DSL. That's not to say that JSX isn't a DSL as well but you can return regular React.Elements just as easily. You shouldn't need to remember a unique expression system just to be able to conditionally render. The premise that you're just not doing much with the data except dumping it into HTML is less true the more complex your site becomes. Think of the loads of conditions and evaluations that happen when you go to your Facebook wall or friends list.