If I may derail the conversation a little bit, may I ask if/how you use the things you've learned today?
I mean, is it things like paradigms that have stuck with you like OOP/functional/w\e, or do you always structure your exception handling in a certain way, no matter the language? Are there skills/technologies you've been using since you've started? For example little scripts of basic that you've never let go off that automate things like setting up build servers and the like?
For me it's always been about problem solving rather than simple fascination with some particular technology. If I can solve a problem with a keyboard macro in Emacs, great. If it requires Perl or Java or javascript, so be it.
I try to use the tool that's appropriate. If I can solve a problem quickly and move onto something more interesting, one-and-done.
If I have to stop and learn something new (e.g., WKWebView in iOS ObjC) to get my task done, so be it, and I'll put in some late nights to get there because at my age, I'm a bit paranoid about looking bad so I try to give the good folks at HQ no reason to doubt me. I spend a lot of time on Stack Overflow and Youtube doing concentrated learning.
But the real thing is what others have also mentioned: properly defining a problem that needs to be solved, proper communication, keep good records, and try to maintain transparency, honesty, and pleasant comportment at all times.
Honestly the older I get, the less I notice people's age. If someone half my age knows something I don't, then the way I see it, they have something to teach me. I've been to many conferences and watched many youtube tutorials where the teacher was very young (from my wizened perspective) but the information is why I'm there and that's all I care about.
What do I think about young people? (you didn't ask but I'm saying it anyway)
I love young people. They have so much spirit, so much energy and creativity. I keep hearing critical (snarky) things about millennials this, X-gen that. But I don't see it. The young people I've been around (for a while I was back in school full time, surrounded by 20-somethings and a few 30-somethings) were a joy. Fun, humorous, inquisitive.
Everyone has his faults, not least myself, and I believe as we get older we become more tolerant of others' faults and shortcomings. In fact that may be the single hallmark of growing older (apart from physical issues).
Once you grok Lisp, everything else is easy. You come to realize that the vast majority of what passes for "new technologies" is really just a re-discovery of something that exists (or is easily implemented) in CL. That makes it a lot easier (if a tad frustrating at times) to keep up.
EDIT: CLOS, and generic functions in particular, are a HUGE lever that no other language has co-opted yet.
So much this. (From a soon-to-be geezer who's staring down 40 soon.)
Check out Dylan, Julia, and my old hobby language Magpie[1].
I highly recommend guile to anyone who wants the battery included nature of common lisp. I know that racket is also a great choice here, I just have little experience with it.
The tech changes - I don't use BASIC or Z80 machine code day to day. The skills that I can speak to, and the skills I see from others with this level of experience, are problem solving and communication, and secondarily the confidence that comes from having made mistakes. Few projects fail miserably solely due to technical issues and skill; in my experience failures come about because of poor communication (including documentation, but also speaking, reading body language, office politics, etc).
Not sure I have any specific sources to share (others might) but after working with all types of hardware, languages, business realms and what not... you start to see patterns. Human behavior patterns, mostly; the same sorts of needs were there 30 years ago as are here today. People need stuff done yesterday, don't know how to describe what they want, oversold a client on something, etc. The numbers may be bigger, the gigahertz faster, and the memory far greater than people could have imagined, but the problems of translating what people say in to what they want via code is ... fundamentally still the same.
A 16k RAM module was ... $200 in my early days. Then a few years later I got 512k for only $150. Today I can get a 16 gig USB stick for $10, at at a local grocery store checkout aisle no less.
No doubt technology has changed and become more ubiquitous. Peoples' expectations of what's possible and what's normal are somewhat different today than 10-20-30 years ago, but the communication problems are still largely the same. Who's in charge of a project? What are the parameters? What defines "success"?
I'm not sure there's any real silver bullet here - most of the "mythical man month" stuff (from even before my time!) is still largely true (speaking in generalities because I can't think of every single line right now).
Learn to figure out how to communicate better - emails, phone, IM, paper, phone, f2f, etc - they all require different skills, and have different impacts on different teams.
Happy to answer more specific questions here or via email - mgkimsal@gmail.com - not sure if I'm just rambling now or not.
The main thing I learned was to be able to look at code and determine if it was going to actually do what I wanted it to do without having to run it through the debugger a couple times.
It's important to spend time thinking about and reviewing code when edit, compile, and test cycles start to get long. There are a lot of instances where that still applies, such as with multi-threaded programming, integration testing or long running jobs.
I also learned the value of having muscle memory for APIs. Sure you can look things up in a jiffy, but actually rote memorizing stuff that is used often can speed development up.
There's plenty of languages I've used over the years that I have no use for today, or hardly even remember: Basic, FORTRAN, assembler, Pascal. None of those languages even had exception handling, so it's hard to say that it influenced my thinking on the subject, except by forcing me to be familiar with the alternatives.
Today it's C++ and C# that pay the bills, with as much Python as I can sneak in. Next up in the queue is Javascript, for which I'm admittedly overdue, but that one's entirely on my own time.
Python is the interesting one of the bunch. I was exposed to it about 1995, when a coworker selected it as an embedded scripting language for our product. I didn't pay much attention to it at the time, as it was outside of my immediate responsibilities. It was selected again as an embedded scripting language at my next employer around 2003. This time I paid attention, and came to love it. It's the language that lets me turn my thoughts into results the fastest.
Thanks for asking the question, I've never stopped to think about my programming history in this much detail.
1 8 + A 5 + 0 0 + 6 5 + 0 1 + 8 5 + F A + A 9 + 0 0 + 8 5 + F B + 4 C + 4 F + 1 C
I remember how much like some kind of incantation it was. I still get that feeling. And I've had the good fortune to work some fun, powerful, and interesting magic with those incantations.
I suspect that most younger people haven't yet seen their tech choices slip into decay and disuse. And they hang on tightly, hoping to expend less effort in learning as time goes by and they master that tech. It's a vain hope. The essential part of the experience is the underlying creativity, the joy of getting to the next ledge, and really understanding what a marvelous thing a computer is.
