31 ms·

I'm a CS undergrad, do you have any recommendations for effectively combating this?

wrigby 4y ago
No approach is a silver bullet here, but what I've found effective is to seek out friendships with / mentorship from senior and staff-level engineers. They'll have tons of war stories from 10-20 years ago, and may even have some snarky opinions on what "new technologies" are just re-inventions of something that the industry had already solved decades ago. As a current undergrad, you can also look to your professors for this (especially those with industry experience before they went into teaching). After graduation, this may mean working at a company _with_ those older engineers, as opposed to a 5-20 person startup with a homogeneous group of 20-somethings.
- jameshart 4y ago
  It’s gotta be tough though for young devs to tell the difference between old fogeys just dismissing new tech because it’s new, vs because it’s a recapitulation of an old mistake. And the thing is that what was a bad idea in 2000 might now be an idea whose time has come, because the surrounding context has changed - be it browser technology or the size of machine memory or the capabilities of programming languages. So, like, when I point out that kubernetes is just DCOM all over again I’m not actually dismissing kubernetes (just because we don’t use DCOM any more doesn’t mean it wasn’t a good choice then); less still suggesting that we should go back to using DCOM; I’m just saying ‘maybe there are some lessons we can learn from how people used DCOM back in the day about what cases kubernetes is suited for and what the pitfalls might be’. And, also, maybe raising the possibility that in a few years time we will look back at kubernetes as a bloated outdated approach and be glad to see the back of it - even though right now it might be a great technology to use. But I’m not sure how a new junior dev can possibly pick up all that nuance from just listening to old farts like me talking about how this reminds us of how we used to do things back in the old days.
  - switchbak 4y ago
    Wouldn't DCOM be more akin to Corba or RMI? I'm failing to see the analogy to Kubernetes.
    - jameshart 4y ago
      Independently deployed components, connected up to discoverable queues and data providers, relying on a registry for discovery and load balancing… there’s a lot more in common than you’d think.
switchbak 4y ago
Not the OP but the courses I took on operating systems (writing a simple one, in C) have yielded lessons that I've used throughout my career. If you can find a course too challenge you, and it's taught well, that should provide a ton of the learning that us old neckbeards couldn't avoid back in the day. Forcing yourself to use barebones languages and environments is good too. Hacking on ancient machines or targeting embedded hardware is another good way to get a better intuition on the order of magnitude performance differences of various approaches. Reading about promising tech of the past is also useful: prolog, Smalltalk, etc. Lots of inspiring and fruitful lessons to mine there.

No approach is a silver bullet here, but what I've found effective is to seek out friendships with / mentorship from senior and staff-level engineers. They'll have tons of war stories from 10-20 years ago, and may even have some snarky opinions on what "new technologies" are just re-inventions of something that the industry had already solved decades ago. As a current undergrad, you can also look to your professors for this (especially those with industry experience before they went into teaching). After graduation, this may mean working at a company _with_ those older engineers, as opposed to a 5-20 person startup with a homogeneous group of 20-somethings.

jameshart 4y ago
It’s gotta be tough though for young devs to tell the difference between old fogeys just dismissing new tech because it’s new, vs because it’s a recapitulation of an old mistake. And the thing is that what was a bad idea in 2000 might now be an idea whose time has come, because the surrounding context has changed - be it browser technology or the size of machine memory or the capabilities of programming languages. So, like, when I point out that kubernetes is just DCOM all over again I’m not actually dismissing kubernetes (just because we don’t use DCOM any more doesn’t mean it wasn’t a good choice then); less still suggesting that we should go back to using DCOM; I’m just saying ‘maybe there are some lessons we can learn from how people used DCOM back in the day about what cases kubernetes is suited for and what the pitfalls might be’. And, also, maybe raising the possibility that in a few years time we will look back at kubernetes as a bloated outdated approach and be glad to see the back of it - even though right now it might be a great technology to use. But I’m not sure how a new junior dev can possibly pick up all that nuance from just listening to old farts like me talking about how this reminds us of how we used to do things back in the old days.
- switchbak 4y ago
  Wouldn't DCOM be more akin to Corba or RMI? I'm failing to see the analogy to Kubernetes.
  - jameshart 4y ago
    Independently deployed components, connected up to discoverable queues and data providers, relying on a registry for discovery and load balancing… there’s a lot more in common than you’d think.

switchbak 4y ago

Not the OP but the courses I took on operating systems (writing a simple one, in C) have yielded lessons that I've used throughout my career. If you can find a course too challenge you, and it's taught well, that should provide a ton of the learning that us old neckbeards couldn't avoid back in the day. Forcing yourself to use barebones languages and environments is good too. Hacking on ancient machines or targeting embedded hardware is another good way to get a better intuition on the order of magnitude performance differences of various approaches. Reading about promising tech of the past is also useful: prolog, Smalltalk, etc. Lots of inspiring and fruitful lessons to mine there.