6 ms·
This is where the use of "Older" IT people would help. Take all the new ideas and innervation and filter it through the 60 year old IT guy (Knowledge experts).
by mgrennan 10y ago
This is where the use of "Older" IT people would help. Take all the new ideas and innervation and filter it through the 60 year old IT guy (Knowledge experts).
Explain your ideas well with examples. Lesson how that problem has been solved before. Don't build new ideas on old code. Find shortcuts to the results.
Don't be naive. Ignorant is better.
Naive is not knowing your don't know.
Ignorant is knowing your don't know.
- mgrennan 10y agoYes I'm 60 with deep knowledge. Electronics, assembler, system / language / application development, data structures and flow design, protocol design, UI design and now working on AI.
- mlvljr 10y ago..to replace thyself when retired? sorry :)
- BatFastard 10y agoDang it, he has a year on me! I will never get hired ;-)
- acupofnope 10y agoPlease excuse my curiosity: would you consider your work to be more hands on or managerial or both? Have you ever felt overwhelmed with the sheer amount of 'topics' out there?
- rimantas 10y agoHow many years would it take to master one topic? Say to the top X percent. How many of these intervals fit in 40 years career? Worth keeping in mind, that if we are talking technology there usually overlap between fields so you are unlikely to start at 0 every time.
- mgrennan 10y ago10,000 hour rule seems to be true. But I believe you can work on more then one skill at a time. So in a 40 year career you can master about eight to ten skills. I didn't say I'm also an artist.
- mgrennan 10y agoTotally hands on. I mentor not manage. Overwhelmed, no. More excited by advancement in knowledge. I'm more frustrated by the number of subjects that could be investigated that go un-explored.
- makmanalp 10y agoI've worked with some older folks with a ton of experience (think: programmed in the 80s or earlier) before, and I have huge respect for those folks who can see a disaster coming miles away, or have been around the block enough times to have formed solid opinions on many subjects. --- Although, while more often than not true (perhaps partly due to survivor bias), I do think that it's not a given that old programmers are wonderful. Some older folks do seem very set in their ways and unwilling to experiment in a way newer programmers aren't. The natural example is that you hear a lot of "ah it's like <blah> all over again" where blah is something like winforms or activeX or CORBA or lisp or OSGI or what have you, but it's frustrating to come into everything with that baggage. Yes it might be the same idea, but it might be executed quite a bit better! Perhaps much wider platform support, perhaps lower total cost of ownership, perhaps increased viability under current conditions, perhaps much larger community of people and tools! The cycle turns much quicker than it used to, and using older, more mature but inferior technology sometimes does have a big effect on the bottom line or provides a disadvantage over competitors in a way that I don't think it did as much earlier on. Granted, this isn't always the case and knowing when it is also matters. I think "strong opinions loosely held" is a great motto, and a lot of these folks follow that motto to wonderful effect. --- It is also entirely possible do essentially the same project over and over in a multi-decade long career, and learn nothing material from it all, and I've seen that happen too. --- In conclusion, I think older programmers can be a great asset to your team, and are often overlooked for no good reason. But they're also people like everyone else.
- gwbas1c 10y ago"It is also entirely possible do essentially the same project over and over in a multi-decade long career, and learn nothing material from it all, and I've seen that happen too." I remember interviewing someone like that. He came to the interview with 11 years exclusive experience in a language that's 11 years old; yet he struggled with the basic patterns and terminology that should be wrote memorization for anyone who's worked in it since the beginning. As I struggled through the interview, I wondered if the guy just outright lied on his resume, and if I should end the interview early. Then, at the end, I got to my question that's basically writing boilerplate data access code, and he zoomed through it. I realized that this guy spent 11 years writing mindless data access code and never really learned how to program!