>for how long ? I dont blame him for reading about C++ in 1989 and saying "hrmmmf! hogwash!". But in 1995 ? in 2000 ? It sounds like he got set in his ways, and how is that NOT an "age problem" ? I'm also 32, and I'm getting slightly more set in my ways as I get older.

Christmas of 2002.

>well, had he had an open mind and not shunned new things, he might be a Herb Sutter today. Or even in IBM, had he bet on a different "horse", and moved into As/400 or whatever other IBM technologies there are, he could be earning more than a C++ programmer, knowing some obscure proprietary IBM language and having 20+ years experience backing it up. I've heard of guys like that making $100+/hr because only a few people in the world can do it.

That's actually the big trap. He WAS making good money because of legacy systems and because not many people were familiar with the technology... right up until there were no jobs left. It makes changing fields earlier difficult even though it would have probably been the best long term strategy.

>I think his story is one of mismanagement of intellectual capital. Maybe it's naive of me, but I dont see how you could be in software engineering for 30 years and not be worth at least a million, especially from his era. Did he invest in IBM or any tech companies at all ? How could you not see everyone making money in the dot-com era and not be a part of it ?

I assume he's worth well over a million. It isn't enough to be worth a million when you are 50. When you and your wife will be living for (hopefully) another 30-40 years and social security doesn't kick in until 62-65, you gotta keep working unless you explicitly planned for an early retirement.

As for how to avoid the .com era - well, you miss it by seeing it as a bubble (and feel vindicated when it "pops" in 2001). You also miss it because you are committed to living in a certain geographic area without a significant presence of e-commerce companies.

I've got a year on you and I think I'd agree that OO is snake oil. The worst code bases I've ever seen (and I've seen some horrors) have been from over used inheritance and mixing logic and data. Provided you avoid global state (also a problem with OO) I think a c program would be more understandable than a lot of java/c# ones.

Not to say there aren't useful features, that would go well with a language like c, like interfaces, but I'd love to get rid of inheritance, encapsulation and mixing data and code.

it could very well be snake oil, but I make a living doing it (or at least knowing how to answer C++ questions during interviews. many of my jobs were advertised as SE but really dont require much actual coding (to my frustration)) and I actually enjoy C++.

Personally, I think both java and javascript (yes I know they are entirely separate languages ) are snake oil. But you know, I learned to program in them anyway.

I tried to find a happy medium where I learn about a new technology and see if it sticks. If after 3-5 years its still around, I give it a try. This worked for me for javascript and python. When python first came out (or when I first heard of it ) I said "no way, not learning a new language right now. perl works fine as a scripting language". Then year after year I kept hearing about it, and heard about perl less and less. Then I finally tried it.

But a couple years ago, I kept hearing about "coffee script" and "clojure". I said the same thing, "not touching it". And now, I hardly ever hear about them, and I barely even know what they are.

From what you are saying I guess you have never been in an OO project but you just worked in the "cold hell" of procedOOral code, the worst mix of copy and paste, overblown inheritance and singletons. I experienced a lot of it in my career, nowadays I am more oriented towards the functional world, but saying that OO is completely useless and even dangerous is an outright lie. The most awful codebases on which I worked on would have been quite nice applying the OO best practices. Sadly they where far too big to be changed by the concerted effort of a couple of people. And they were full of anti-patterns. Even loving the type safety of F# and Haskell I can't honestly say that OO is an anti-pattern per se. What it matters is not the size of the hammer but how you use it. But I can rightfully proclaim that the wrong tools used for something that they were never meant for are the worst possible solution. EVER.

I've spent 10+ years of my career working in OO languages, I'm no stranger to it and I've seen it used well. But we'll tends to be a subset of OO, with minimal inheritance and encapsulation with data and logic in seperate places.

You would probably enjoy Go, for the most part.

I've been thinking that. Rust is probably next on my list though.