IMO doing both code and art at the same time is the best place to be, and it has served my career well, in both CG films and in games. The point of learning art isn’t necessarily to get a job making assets, it’s to be a better developer, and learning art seriously will make you a better developer. (Also artists who learn to code seriously are better artists, this goes both ways.)

It’s a mistake to think that software engineers making assets is a waste of time. Engineering and games in general would be better if every dev took a rotation in the art department. The reason companies silo and specialize their teams isn’t for your benefit, it’s for the short-term efficiency of a specific production.

It’s a bonus that you could make assets if you want, as opposed to the vast majority of programmers who can’t. Being able to code+art will also give someone a major leg up in small shops and/or for solo devleopment.

I would argue sadly in this economy it is not. I don't think you should be learning how to model and texture, but you absolutely should be learning how 3d data, textures, materials, metadata and so on are structured. Specifically you should understand matrix multiplication, traversing rigs and scene hierarchies, float array and integer array buffers for face index and vertex data, and so on. The list is very very long, and unless you are purely like, an online account web dev or cross platform bit twiddler which I feel is greatly decreasing in value (and is very competitive because of 40 years of bit twiddlers before you), then you absolutely need to be doing this stuff. Once you've done all that, you'll find the modeling part isn't even so far away from you for hard surfaces at least, but organic is truly its own life quest. You're right on that part.

Yes and sorry for the delay. A common issue/complaint I see with fellow programmers is they feel like they haven't actually made something on their own. Perhaps they've only followed tutorials, implemented random features in their day job, or perhaps they actually have written something kind of cool but it is sitting unused by anyone in a github or hard drive somewhere.

This often translates to anxiety once you get into an interview, because you are trying to answer behavioral/design/career questions based on some heuristic, some proxy, some guess at "what the interviewer wants to hear".

While some interviewers are indeed assholes who play weird games and don't operate anywhere near reality, the truth is, if you've written literally anything that people actually use even weekly to do something (e.g a blender add on that simplifies texture baking, a toy online chat room as a discord alternative, a wrapper for ffmpeg or etc to convert files to different formats, a simple time wasting game in threejs, etc), you will be astonishingly more confident in your answers, even if they don't work every time.

Why is that? Because, by actually writing software without a tutorial that is still good enough for someone to use, it guarantees you have solved some problem, without any help besides reference documentation, and have therefore wrestled with crucial design questions like "should i make this a vector or a scalar? do i need a map here? should i do this by naming convention? should this be done in a loop or should i make it a task for multiple threads?"

It doesn't mean you should like, focus on marketing or chasing hot problems, but definitely do this if you are feeling like you are faking some parts of your interview questions, which are so abstract, they can benefit from delivering a real world answer naturally and confidently.