I'm thinking I'll code till the day I die. So much cool tech is always coming out - so much to play with and invent! I also have very time consuming hobbies - reading, playing video games, pen and paper role playing games, board games.
If and when I "retire" I would not see myself not working, but I do think I might do somthing completely different and new.
I could see walking away from computer tech entirely. In fact that idea is pretty attractive, honestly. I'm old enough to clearly remember the days before the internet, before mobile phones, before being constantly connected to everything 24x7. When you would leave the house or office, nobody would be able to get in touch with you and you could do what you wanted to do without interruption or distraction. It was nice.
It was nice? You can still leave your phone at home.
Most things are not time critical, and a sizable portion of the things that are, are not mission critical.
I think that poster's point about the same ideas coming round again and again was that in some areas of technology "keeping up with the state of the art" is just a case of re-learning how to do something that you already understand and know how to do, but in a way that is now structured differently. Broadening your horizons can (in some cases) end up in you seeing the underlying same-ness in a lot of things.
I understand the point; you've restated it exactly as I understand it. That's why I brought up unsolved problems. The state of the art here is very often new and novel approaches that have not been explored in enough depth.
Take color theory, for example. I want a function that maps points outside visible Lab to the nearest visible point in Lab. Sure, that's a solved problem, but if you don't already know how to solve it, you've got something to learn. More importantly, can it be done quickly? Can it be generalized to other color spaces? What is the best data structure for encoding only visible points in Lab? Then there's a problem of generating maximally orthogonal gradient curves covering an image.
There are purely technical problems. Can you solve them analytically? Will it help you to learn Topology or Tensor calculus? You won't know until you try. And there are new results in any of these fields coming out every day. Pick up a textbook and think about how to write software that will be capable of solving all the problems in that book. Does it already exist? Is it optimal? Easy to use?
Everything looks the same when you're saying "I'm just applying some abstraction to a problem and encoding it into a machine using several layers of translation." But that shouldn't make you cynical, as that leaves plenty of room for innovation and learning. But if you're thinking "this new framework/language is just doing more of the same," then maybe stop focussing on frameworks and languages and instead focus on the problems they should be solving rather than the ones they actually do. And even there, you should have no problem seeing syntactic and efficiency hiccups that might be ameliorated through an intense exploratory creative design session.
I was top of class in college, then advanced in huge strides in the first years of my career; now I just want to go home and read a non-technical book.
I might be burnt out.
I was able to pick up my career afterwards easily enough. I actually wound up working on education related software so my little teaching experience may have even helped.
The only lasting (sort of) negative was that I met so many people in Thailand who were living dramatically different lives that the idea of living out the rest of my days in a cubicle become less palatable.
If you've never worked outside the tech industry, you would be amazed at how good we get it.
The rate of change in some areas of technology can make you think that you're missing out on some kind of important development, however if things are changing that fast then perhaps nothing is really changing at all.
Mostly it's important that in whatever you're working on you're applying technology to a problem or area that you find interest in, otherwise the only "fun" can be found in the tech stack, which is not (in my not-too-humble opinion) a good place to find enjoyment. You can enjoy your tools, sure, but it shouldn't be the case that "We're using X, Y and Z" is more important than "to make Foo".