Beyond the obvious -- keep your tech skills up to date -- what advice would you give someone to future-proof their developer career?

Soft skills. Not only critical at all points, but you'll find as you grow in seniority that you spend more and more time in google docs, slack, and jira than an IDE or text editor. It's just the name of the game.

Developing is, in the end, something that somewhat nebulous to measure. I have heard that in quantitative finance, for instance, it's more cut and dry, and assholes that make a lot of money for the company are much more tolerated. On the other hand, your performance is really going to be determined by what your manager thinks and what your peers think. I've found that the stereotype of the crass but excellent technically programmer does not persist much in actual companies - they tend to do poorly in perf and get PIP'd in short order.

Really common things like argue (never argue with anyone that you actually want to convince, arguments only lead to the other side being more convinced of their own beliefs), or to be blunt in criticism (no matter what anyone says, yes it'd be great if we could all be upfront, but the reality is that people can very easily be deeply hurt and hold grudges regardless of how illogical it is). Don't do that. Always be cordial. Never be defensive, even if you think something is unwarranted.

Other than that, just have an open mind for tech, and honestly anything. But I think there's some old man yells at cloud style attitudes when new things pop up. If it's catching on, maybe it's a fad, but you can always learn something from playing around with it, even if it disappears. And if it doesn't, then all the better.

As with most jobs, one of the most important parts is interpersonal communication. Work on improving it for professional development; it's one of the most important aspects of the job at any level.

As as junior developer, it's important to be able to explain what your code is doing, to be able to advocate for your ideas, and to make connections, which is important for advancement. As an intermediate, knowledge translation is a key aspect of any project. As a senior developer, effectively communicating about pull requests, and helping to build up junior and intermediate developers is a core skill. Beyond that, you may need to speak with clients, negotiate things, sell yourself, and more.

I feel like... the more senior I get in my software career, the more I think that software development is in effect extremely short-term sci-fi writing. While you've got to "earn your chops" in getting a computer to understand your intent, the bulk of effort in a new coding project is to look into the future and be able to articulate that vision with a concise and easy-to-understand "story." At the lowest levels, that story turns into easy-to-reason-about code. At higher levels, it's about being able to convey that story to the developers on your team, in your org, and in your company as a whole.

One result of this is that I find it difficult to truly separate management from coding; it's harder than you think to split a project into "someone tells us what to do" and "we figure out the best way to do that thing." In many cases the real effort of the project is turning some vague high-level goal that, in reality, is deeply confused and self contradicting, into simple analogies and stories that clarify the myriad ways the top-level goal could be interpreted. This process essentially defines what the business is and how it functions, and so as a developer you're taking on "business" responsibilities whether you want to or not. As an aside, I suspect this is behind much of the failure of the "offshoring" trend of the 90s and 00s--if you're unable to push-back or work to change the business that you work for, you have little hope of a successful software implementation.

As this translates to keeping up with a development career, I see several places to grow. Developing writing skills and clarity of thought pays dividends in being able to do "inception" and instill your vision for the future in those around you. The better your ability to communicate, the more you signal to everyone around you that you're the keeper of the vision. On the other hand, you need the ability to generate that vision in the first place. To that end, I think it's beneficial to keep an open mind and explore many areas of interest. You never know where the next brilliant metaphor or analogy for a system will come from. I've pulled from mathematics, engineering control theory, history, sociology, economics... the bigger and broader the toolkit you develop as a person the more likely you are to have some interesting overlap and connection to pull from.

Say yes. If you're asked to take on new and different responsibilities, to try new things, say yes. Try things. Gain varied experience. Saying yes to things is also important for being able to manage workload and expectations and to be able to communicate what you can and can't take on to peers and supervisors. Saying yes generally means you cycle away from tasks others can do and get tasks prioritized to you because you're good at them.

The longer I've been in the field, the less actual coding I do because more and more time is spent in project management, people management, presenting stuff internally or to clients or so on. Those things are what develop and future-proof a development career.

Because I code less and less, I always try to have at least one coding project going. It's pretty important to me that those projects are complicated and demanding enough that I actually have to keep up to date with at least some basic but common trends in the field, to learn new languages and stay abreast of things that aren't in an increasingly specialized day-to-day environment where one isn't exposed to what's happening in the field elsewhere.

Others have already said some good things about interpersonal skills, and ongoing education. I'll add:

It's good to be good, but it's better to be a "multiplier". That's someone who is not only good themselves, but also makes their teammates better, too. That happens by influencing, teaching, and mentoring. It can happen in a short amount of time, and it can take effect over a longer period. Good management will recognize good multipliers among their human resources, and leverage them to improve teams that need the improvements that the multiplier can bring. Being a recognized multiplier means you're an even more valuable asset to a company. Needless to say, you can't influence others if you don't have a minimum level of soft skills, or if you don't treat colleagues nicely.

Becoming a multiplier may require an active change of mindset. Instead of picking up whatever next Kanban card you like, you might stop to ask yourself "would this be a good card for Jeff to take, so he can learn more about $technical_domain_X?" Or, when someone comes to you with a technical problem, even if the solution is obvious to you, instead of just outright dropping the solution in their lap, perhaps you coax them down a learning path with some Socratic method. Or you give them half the solution, and let them try to figure out the other half.