4 ms·

I'm approaching 40 soon, I've also noticed that it takes longer to learn new things. I can't just load up a new set of libraries/syntax into my head every few d

I'm approaching 40 soon, I've also noticed that it takes longer to learn new things. I can't just load up a new set of libraries/syntax into my head every few days like I used to. Overall, I have much less time to devote to mayfly technologies. in preparation I've started to vet the skills I pick up more carefully. Nowadays, I look at the longevity of the tech. javascript frameworks come and go. those few weeks you invested in learning backbone/jquery are now obsolete. time to learn how to build the wheel again. Beam is a 30 year old tech and elixir looks solid so I'm happy to invest time in it. Flutter is still new and mobile landscape changes constantly so while I think its cool, I leave it to the newer engineers. Nowadays I'm investing more of my programming related time to systems build on stable platforms. cloud is more or less linux and that doesn't change too much. SQL written today is not going to change much in the next 20 years. Everything added in the last few years seem more or less opt in. Good architecture for backend doesn't change much either. IF you're in your mid 30's and you wanna stay in the game, I'd recommend doubling down on systems programming (start learning rust NOW if you haven't already) or machine learning with emphasis on theory. The fundamentals and apis don't change radically like frontend does. IOS and Android seems dangerous to me. if I was in my 20's I'd be happy to but I dont' have brainpower to completely relearn from scratch every few years anymore. getting older means using what you have more efficiently.

ElViajero 5y ago
> I dont' have brainpower to completely relearn from scratch every few years anymore. I understand what you mean when it comes to new frameworks. I learned to code in the 80s, and nothing has really change since then. There is this misunderstanding that things change fast, they do not change at all. Only the level of abstraction changes. When I was a kid I was capturing interruptions to implement mouse movement, it requires fast code that runs for a moment to react to the event and returns to not block the system. Same that with AWS Lambadas. I personally do not see any difference. Immutable messages passed between actors to implement concurrent behavior of enemies was common when multi-thread PCs first appeared. The theory is form 1973. Now I use that same knowledge to build micro-services. The big challenge is that what I did at CPU level in the 80s now I do at the service level in clusters of machines in the cloud. From CPUs, to virtualization, to cloud, all the same thing: input in, output out. But, I am also tired of learning new syntax for the same things. The most difficult part of learning AWS is to remember the specifications of the product, if they offer this type of connection in S3 but not in EC2. The difficulty is to remember arbitrary decisions based on temporal situations. > machine learning with emphasis on theory That is the only innovation (applied, the theory existed by very long) that I have no real equivalent from the 80s. And, I am following your same advise and going for it.
- throwawayoldman 5y ago
  > "The difficulty is to remember arbitrary decisions based on temporal situations." That is the difference today. As you said lot of things you learned decades ago is still applicable knowledge. The AWS ad-hoc stuff we learn today will be outdated and mostly useless information very soon. The undelying principles (even distributed computing) we already learned years ago.
Wagthesam 5y ago
That's exactly what I've done. I'm 32 and have years of exp in data engineering and data analysis. I wanted to pivot more to more eng. I did a lot of interviews with a lot of product eng offers, but ultimately went for infra, now working on a cpp and java stack. Feels like there's more staying power here. On the product side I would have been sprinting to director level people management as fast as I can. On infra I feel like I can stay an IC indefinately Even though I have an ML background, I don't feel like competing with every young hotshot out of MIT and stanford for ml eng roles, so going to opt out for now and focus on systems
- throwawayoldman 5y ago
  You will still need to re-learn infra frameworks in every 3-5 yrs. Also, after 10-15 years, you will be increasingly frustrated to be managed by 32 yr olds.
selimnairb 5y ago
Forty-three here. It takes longer to learn things mainly because I have a young child and my time is chopped up and my sleep is less/worse than it would otherwise be. One thing that has improved with age is intuition, which helps immensely with debugging. I can debug most problems much more rapidly than I could as a younger developer.
forinti 5y ago
I don't know if you lose much learning power or if you just lose interest. I've been through so many Java frameworks that I just can't see the value in learning another one. I also cannot muster the patience to wade through Oracle documentation anymore. But I've taken a liking to Rust, I've learnt a lot of maths and I've also read up on networking.
- throwawayoldman 5y ago
  > "I don't know if you lose much learning power or if you just lose interest." Both. - As we accumulate knowledge while aging it becomes more and more difficult to learn new things. We are smarter and smarter though. (Most of us :) - Losing interest sooner is natural. For example by the time I read through the documentation of one service that deploys containers on AWS the information is already outdated and two other, newer AWS services released doing almost the same. When someone says: "we need to investigate this new AWS ..." I am already shutting my ears.

ElViajero 5y ago

> I dont' have brainpower to completely relearn from scratch every few years anymore. I understand what you mean when it comes to new frameworks. I learned to code in the 80s, and nothing has really change since then. There is this misunderstanding that things change fast, they do not change at all. Only the level of abstraction changes. When I was a kid I was capturing interruptions to implement mouse movement, it requires fast code that runs for a moment to react to the event and returns to not block the system. Same that with AWS Lambadas. I personally do not see any difference. Immutable messages passed between actors to implement concurrent behavior of enemies was common when multi-thread PCs first appeared. The theory is form 1973. Now I use that same knowledge to build micro-services. The big challenge is that what I did at CPU level in the 80s now I do at the service level in clusters of machines in the cloud. From CPUs, to virtualization, to cloud, all the same thing: input in, output out. But, I am also tired of learning new syntax for the same things. The most difficult part of learning AWS is to remember the specifications of the product, if they offer this type of connection in S3 but not in EC2. The difficulty is to remember arbitrary decisions based on temporal situations. > machine learning with emphasis on theory That is the only innovation (applied, the theory existed by very long) that I have no real equivalent from the 80s. And, I am following your same advise and going for it.

throwawayoldman 5y ago
> "The difficulty is to remember arbitrary decisions based on temporal situations." That is the difference today. As you said lot of things you learned decades ago is still applicable knowledge. The AWS ad-hoc stuff we learn today will be outdated and mostly useless information very soon. The undelying principles (even distributed computing) we already learned years ago.

Wagthesam 5y ago

That's exactly what I've done. I'm 32 and have years of exp in data engineering and data analysis. I wanted to pivot more to more eng. I did a lot of interviews with a lot of product eng offers, but ultimately went for infra, now working on a cpp and java stack. Feels like there's more staying power here. On the product side I would have been sprinting to director level people management as fast as I can. On infra I feel like I can stay an IC indefinately Even though I have an ML background, I don't feel like competing with every young hotshot out of MIT and stanford for ml eng roles, so going to opt out for now and focus on systems

throwawayoldman 5y ago
You will still need to re-learn infra frameworks in every 3-5 yrs. Also, after 10-15 years, you will be increasingly frustrated to be managed by 32 yr olds.

selimnairb 5y ago

Forty-three here. It takes longer to learn things mainly because I have a young child and my time is chopped up and my sleep is less/worse than it would otherwise be. One thing that has improved with age is intuition, which helps immensely with debugging. I can debug most problems much more rapidly than I could as a younger developer.

forinti 5y ago

I don't know if you lose much learning power or if you just lose interest. I've been through so many Java frameworks that I just can't see the value in learning another one. I also cannot muster the patience to wade through Oracle documentation anymore. But I've taken a liking to Rust, I've learnt a lot of maths and I've also read up on networking.

throwawayoldman 5y ago
> "I don't know if you lose much learning power or if you just lose interest." Both. - As we accumulate knowledge while aging it becomes more and more difficult to learn new things. We are smarter and smarter though. (Most of us :) - Losing interest sooner is natural. For example by the time I read through the documentation of one service that deploys containers on AWS the information is already outdated and two other, newer AWS services released doing almost the same. When someone says: "we need to investigate this new AWS ..." I am already shutting my ears.