I mean, at a conceptual level, knowing history is important in the "ignorance of history will lead to repeated history" line of thinking - and I don't disagree. ... and knowing why decisions were made can help determine which tools to use (IE: Why use static typing or duck typing and when to use the other... or when to use procedural programming, async, functional, etc...)
Maybe it's a combination of you "projecting" and me not being clear. And trying to discuss what could be deep conversations in a little more than a twitter tag of 140 chars.
I'm personally a .Net Developer and while I do stick with the latest versions (IE: .Net Core), I also have enough experience to know the past (IE: ADO vs Entity Frameworks). I was trained in school on a mainframe (IBM DB2 with RPG and SQL). I'm not trying to stick with the latest "hotness" as most of MY work is actually done via Windows Services, API interactions and moving files around - definitely not the latest fad. With that said, I am working on using good tools to get my job done faster/better - IE: CI/CD pipelines to automate builds, testing, deployment, etc. Tools that didn't exist 5 years ago could be the latest fad but I don't think that's what you are suggesting.
I'm more worried about learning different things (IE: Functional, procedural, async, parallel, etc) than I am worried about "history" of those. When I pick up a programming book, I'm less worried about the "Microsoft created version 1 in 2000 and version 2 in 2005 and..." and more concerned about do's, do not's, best practices, etc.
Maybe it's my personality and the way I "deemphasize" history... it's not that I think it's unimportant... I just think that it's more important to focus on other things. Learning some history along the way is good and fun but it's never been my focus and I've never used what I consider "history" in an interview or a job on a day to day. Maybe that's rubbing people the wrong way lol
Maybe it's a combination of you "projecting" and me not being clear. And trying to discuss what could be deep conversations in a little more than a twitter tag of 140 chars.
I'm personally a .Net Developer and while I do stick with the latest versions (IE: .Net Core), I also have enough experience to know the past (IE: ADO vs Entity Frameworks). I was trained in school on a mainframe (IBM DB2 with RPG and SQL). I'm not trying to stick with the latest "hotness" as most of MY work is actually done via Windows Services, API interactions and moving files around - definitely not the latest fad. With that said, I am working on using good tools to get my job done faster/better - IE: CI/CD pipelines to automate builds, testing, deployment, etc. Tools that didn't exist 5 years ago could be the latest fad but I don't think that's what you are suggesting.
I'm more worried about learning different things (IE: Functional, procedural, async, parallel, etc) than I am worried about "history" of those. When I pick up a programming book, I'm less worried about the "Microsoft created version 1 in 2000 and version 2 in 2005 and..." and more concerned about do's, do not's, best practices, etc.
Maybe it's my personality and the way I "deemphasize" history... it's not that I think it's unimportant... I just think that it's more important to focus on other things. Learning some history along the way is good and fun but it's never been my focus and I've never used what I consider "history" in an interview or a job on a day to day. Maybe that's rubbing people the wrong way lol