Comment

I’ve maintained both and still do. While you may not be debugging memory leaks on k8s (although you should), you get all sorts of other fun things to debug. Things like:

Why did our AWS bills suddenly triple?
Why is that node accepting jobs but just hanging when they start?
Why is that statefulset not coming back up? Is the storage still attached somewhere else perhaps?
Why did all the data in our Kafka suddenly disappear?
Why is everything still down after that outage? Maybe a circular dependency, thundering herd problem, or both?
What’s wrong with my Helm chart this time?

The list goes on and on. With increased complexity you don’t get less problems, just different ones.

source

Sort:hotnew top

partial_accumen@lemmy.world ⁨1⁩ ⁨day⁩ ago
And nearly all of those problems are ones that other people have run into or at least have guidance on how to go about addressing. Old organically grown systems are many times unique one-offs which have little to no established path except to start diving into the fundamentals about the hardware and software.

I’m not here to get into a pissing match about who’s job is/was harder. If you think juniors have a better chance at learning on today’s systems than they did in the past, I still disagree with you. Problems exist on modern system, except juniors will rarely if ever get a chance to try to solve them and thereby learn from them.

source
- bus_factor@lemmy.world ⁨1⁩ ⁨day⁩ ago
  I’m starting to think we’re talking past each other. Your last paragraph seems to imply that legacy systems were more approachable for a newbie to debug. If that’s your point I wholeheartedly agree. It’s not that hard as long as you get over the fear of fucking something up.
  
  I do agree that juniors had an easier time learning on legacy systems, and that’s been true since the dawn of technology. Things get more complicated, and thus harder to get a deep understanding of, the more time passes. It’s a lot easier to understand older and simpler technology.
  
  I’m a little confused why you seem to be arguing both that the issues I mentioned are easy to google, while at the same time saying newbies never get a chance to debug them. Surely, if it’s so easy, the newbie can take a stab at it?
  
  Personally, I like to let the newbies have a stab at non-urgent issues first, and nudging them if they get stuck. They may not be able to solve the problem solo, but they know a lot more about how the system works afterwards anyway.
  
  source
  - partial_accumen@lemmy.world ⁨22⁩ ⁨hours⁩ ago
    I think we have slightly different approaches but ultimate want the same thing: opportunities for juniors to get exposure.
    
    However, employers these days are reluctant to hire them, and the barrier to entry is higher now so they can’t necessarily get in the door on their own merits without that experience they don’t have access to learn.
    
    source