I've been in the industry for 47 years - first 5 in hardware followed by 42 in software/firmware. Most of my past 32 years have been spent doing system level code in C which I still enjoy. I've had a few short stints as an acting manager and have managed to reject management's attempts to make those permanent each time because I enjoy spending my days solving problems.

It has gotten harder to remember what I've worked on lately. For the past 15 years, I've been keeping notes in text files to remind me of what I work on each day. It's far easier to do a recursive grep on my top level notes directory than it is to find something in Outlook. I also make heavy use of Confluence to document everything I work on. I think I've created more Confluence pages than the rest of my group combined.

I've kept in touch with a number of people I've enjoyed working over the years with which has made it much easier to find jobs when I need to make a change. For the past 20 years, I've maintained a mailing list to organize weekly happy hours with some of them. I got hit by a RIF 5 years ago (first time in 47 years, believe it or not) and managed to line up a new job in 2 months thanks to a hardware engineer I had enjoyed working with 32 years ago. I also had a few whiteboard interviews during that time which helped remind me why I hate the traditional way of finding jobs.

I've come across 20+ year old kernel code I need to understand/debug/optimize.

I certainly didn't write it 20 years ago, but I was there and around and can understand the motivations which is helpful.

Right around then, most open source kernels started doing a lot of performance work on sockets. Some of which has stood up until recently, but some things look silly with today's eyes. You could set the port number hash length to more than 16-bits, which doesn't make sense... But they added it to get 2 or 4 bits of hashing in 2000, and it worked enough that nobody changed it. Things like that.

Its not so much that I remember what I did. Its that I remember the discussion around why the project did what it did, the alternatives, and the false starts down the wrong path. Eg, I tend to remember why things are the way they are in the areas of the kernels that I care about. So that prevents me repeating somebody else's mistake (oh, yeah, somebody tried to so something like this in 2013, and it didn't work because of x, y and z)...