> But you can only add so much value to an organization typing on a keyboard.
In my understanding, non-junior software development jobs never were about typing on the keyboard. Senior software engineer is a fancy name for a problem solver, and code is just a specialized tool they can build to possibly achieve the goal. It always was about talking to stakeholders, figuring out what the heck they actually want today, how it fits with what they think they want tomorrow, learning more about those stakeholders so you can guess what they will think they want next week. Only then it's thinking about it all it for a while, and only after that it's getting to press the actual buttons.
But I'm not sure those things require "soft skills" aka - in my understanding - being a people person. For me, it was a very simple learning process - I (as a junior) coded something, a manager came next month and said I have to rewrite everything again because things have changed. I hated it, so I started to think how to possibly avoid or minimize it and optimize my own processes.
And in my mental model, it's not about people (save for tiny companies where a whole department/role is a single person, so I have to account for their mental chaos monkeys), it's all about business. That's why I wrote "stakeholders", intentionally dehumanizing (with no negative connotations) the model.