My take on how a decade (or more) of using cloud services for everything has seemingly deskilled the workforce.
Just recently I found myself interviewing senior security engineers just to realize that in many cases they had absolutely no idea about how the stuff they supposedly worked with, actually worked.
This all made me wonder, is it possible that over-reliance on cloud services for everything has massively deskilled the engineering workforce? And if it is so, who is going to be the European clouds, so necessary for EU’s digital sovereignty?
I did not copy-paste the post in here because of the different writing style, but I get no benefit whatsoever from website visits.
That’s the thing! I think it wouldn’t be conceivable that your “principal engineer” (real position for one of the people) doesn’t understand the basic theory of the stuff they are implementing. Now it feels you can instead work years and years just shuffling configuration and pressing buttons, leading to “senior” people who didn’t gather actual years of experience.
I don’t want to pretend I am outside this logic. I am very much part of this problem myself, having started my career 10 years ago. I do despise cloud services though (if anything, they are super boring), so I tend to work with other stuff. But I could 100% just click buttons and parrot standard and keep accruing empty years of experience…
You want to hire the “guru”, not the “principal”. You want to actually ask him to write 0xD6 in decimal, and if he dares to answer “Seriously? Come on now, that’s boring”, then you hire him on the spot.
But you can’t hire only gurus. You need normal seniors, too. Build a normal team around one guru. Maybe build one ultra advanced team around 2-3 gurus, if you really need to invent new and hardcore difficult stuff.
Instead of hiring gurus, I think you want a diverse set of curious “regular” people. Maybe one person is really good with working in different number bases (and 0xD6 in decimal is something they know off the top of their head), another is really good w/ databases, etc. None of those would know everything, but they’re all curious and picked up random stuff from their career because they asked a lot of questions.
Hiring the right guru is hard, having the equivalent of a guru across a diverse time is a lot more tractible, and maybe one will become that guru you need after cross pollinating with the team.
I agree with your lack of affection for cloud services, but I think your view might be a little skewed here. Does a senior mechanic need to understand the physics of piston design to be a great mechanic, or just gather years of experience fixing problems with the whole system that makes up the car?
I’m a Senior Systems engineer. I know very little about kernel programming or OS design, but i know how the packages and applications work together and where problems might arise in how they interact. Software Engineers might not know how or don’t want to spend time to set up the infrastructure to host their applications, so they rely on me to do it for them, or outsource my job to someone else’s computer.
I would argue that if senior mechanic doesn’t understand the physics of piston design at least on some degree he’s not a great mechanic. Obviously mechanic doesn’t need understanding on metallurgy, CAD models and a ton of other deeper level stuff just like an IT engineer doesn’t need to know on a deep level how circuit boards are designed or how CPU die manufacturing process works. But both benefit greatly when they understand why something is built the way it is.
I’m also an systems engineer of sorts and have worked with software engineers. And I’ve had requests like “Can’t you just set 'bind-address = 0.0.0.0 on mysql-server and disable firewall” on a directly internet-facing machine and then received complaints when I’m “making things more difficult” from “senior software” -titles. Sure, I can’t write the code they’re doing, or at least it would take me a crapload of more time to do that but on the other hand there’s guys who have so very narrow understanding on anything they work with that it makes me wonder how they can do their work at all in the first place.
Of course no one can master everything in any field but I find it concerning that a lot of guys just press the buttons more or less randomly until their thing works without any clue on what they actually did and how it might affect on different parts of the house of cards they’re building.
I 100% agree.
The best mechanics can track down an issue by reasoning about what could be causing it, and understanding how pistons work can help deduce whether that knocking is actually the engine or something else entirely. They probably didn’t learn that from their official training, but instead worked with some guy who used to work at a car manufacturer or something and picked their brain.
The best engineers are curious and jump on opportunities to learn more.
But you know what the kernel is. You know that syscalls are a thing, you know what role the kernel performs, you know that different filesystems have different properties (and pros and cons), etc…
You don’t need to know the details, perhaps, but you can’t ignore the fundamental theoretical concepts of kernel and OS. You might not know the whole detail of the boot procedure, but if your machines are stuck on boot, you know at least what to look for.
Here I was talking about equally foundational topics. There is nothing “above” - say - producing attestations and then verifying them. That’s literally all there is to it, but if you don’t understand the theory behind it, what exactly are you doing? As as I said, I don’t care about the details, I didn’t expect someone mentioning ciphers or timestamp authorities, transparency logs etc. All I would expect is “we produce a signature with a bunch of metadata and we verify it where we consume the artifact, so that we are sure that the artifact has the properties attested by the signature”.
Not knowing this is like someone claiming that they administer Linux machines but can’t explain what network interfaces are or how routing is determined. This is not a question of being expert on different layers, this is just being oblivious to those other layers completely.