I’m not the slightest worried about my own job, but it is currently a shitty market for fresh grads. Probably due to all the post-covid layoffs saturating the talent pool with more experienced people, and the aforementioned AI fad.
Its a bit more than that I think. IT is killing its entry level job pipeline which grew people into seniors. In the infra space, we don’t really troubleshoot systems anymore in a “pets” method, we just redeploy new “cattle” meaning all the troubleshooting skills and underlying understanding of our systems you would have had doesn’t get learned anymore. For those of us that had to go through that, we’re fine because we developed the skills, but the new folks we bring in we just tell them to re-deploy to get it working.
I’m seeing this too in the software dev space. Small modules worth a few story points would have been given to junior developers to learn on and knock out getting some work done, but more importantly getting those juniors trained up with trial and error. Now an LLM can crank out mostly working code for that small module in a seconds and after a few minutes of human review that module is done. So the work is being done faster now, but the critical educational experience the juniors had before is missing.
In both infra and software dev spaces we’re cutting off our ankles, then legs, because when we retire very very few will have our skills that we had to learn, but didn’t give them the chance to learn.
You still have to debug things in a cattle approach, though. If anything there’s even more and more complex things to debug. Training will just have to shift from throwing the new hire into the deep end of the kiddie pool to something else. Granted, “something else” is probably going to be offloading it on educational institutions, which sucks for recent grads, so they’ll have to work it out somehow. Probably by creating a market for post-grad practical skills classes, is my guess.
You still have to debug things in a cattle approach, though. If anything there’s even more and more complex things to debug.
I would disagree on your complexity metric (for the purposes of learning troubleshooting) for cattle. What can be more complex than a completely unique system that only exist because of 10+ years of running on that same hardware with multiple in-place OS upgrade occurring along with sporadic (but not complete) patches to both the OS and the application? Throw in the extra complexity of 9 other unrelated applications running on that same server (or possibly bare metal) because the org was too cheap to spring for separate servers or OS licenses for a whole hypervisor.
If you have a memory leak in your application in a container running on k8s that will kill the pod after running for 72 consecutive hours, would you even notice it if you have multiple pods running it on a whole cluster as long as the namespace is still available?
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.
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.
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.
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.
Its a bit more than that I think. IT is killing its entry level job pipeline which grew people into seniors. In the infra space, we don’t really troubleshoot systems anymore in a “pets” method, we just redeploy new “cattle” meaning all the troubleshooting skills and underlying understanding of our systems you would have had doesn’t get learned anymore. For those of us that had to go through that, we’re fine because we developed the skills, but the new folks we bring in we just tell them to re-deploy to get it working.
I’m seeing this too in the software dev space. Small modules worth a few story points would have been given to junior developers to learn on and knock out getting some work done, but more importantly getting those juniors trained up with trial and error. Now an LLM can crank out mostly working code for that small module in a seconds and after a few minutes of human review that module is done. So the work is being done faster now, but the critical educational experience the juniors had before is missing.
In both infra and software dev spaces we’re cutting off our ankles, then legs, because when we retire very very few will have our skills that we had to learn, but didn’t give them the chance to learn.
You still have to debug things in a cattle approach, though. If anything there’s even more and more complex things to debug. Training will just have to shift from throwing the new hire into the deep end of the kiddie pool to something else. Granted, “something else” is probably going to be offloading it on educational institutions, which sucks for recent grads, so they’ll have to work it out somehow. Probably by creating a market for post-grad practical skills classes, is my guess.
There’s still coworkers who can’t debug worth a shit. I don’t understand. Like that was CS101
Just because they passed the class doesn’t mean they retained any of the knowledge.
I would disagree on your complexity metric (for the purposes of learning troubleshooting) for cattle. What can be more complex than a completely unique system that only exist because of 10+ years of running on that same hardware with multiple in-place OS upgrade occurring along with sporadic (but not complete) patches to both the OS and the application? Throw in the extra complexity of 9 other unrelated applications running on that same server (or possibly bare metal) because the org was too cheap to spring for separate servers or OS licenses for a whole hypervisor.
If you have a memory leak in your application in a container running on k8s that will kill the pod after running for 72 consecutive hours, would you even notice it if you have multiple pods running it on a whole cluster as long as the namespace is still available?
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:
The list goes on and on. With increased complexity you don’t get less problems, just different ones.
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.
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.
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.