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.
I think its actually that most people generally don’t really understand most things beyond the minimal level necessary to get by. Now that the tech industry isn’t just a bunch of nerds you’re increasingly more likely to encounter people who are temperamentally disinclined to seek understanding of those details.
That and also - humans not knowing something can man up and learn it. When they need, they’ll learn.
And OP’s question about European clouds - it depends really. A lot of what this endeavor needs is just advanced use of OpenStack. I’m confident there are plenty of people with such skills in the EU countries.
As for the post content - I dunno, my experience with Kubernetes consists of using it, but not trying to understand or touch it too closely, because it stinks. Maybe those engineers were like that too.
When they need, they’ll learn.
100% agree. But. If you are a principal engineer claiming to have experience hardening the thing, you would expect that learning to have already happened. Also, I would be absolutely fine with “I never had a chance to dig into this specifically, I just know it at a high level” answer. Why coming up with bs?
Maybe those engineers were like that too.
I mean, we are talking about people whose whole career was around Kubernetes, so I don’t think so?
Ah. OK. Yep, people lie in their CV’s.
That is technically correct in a way, but I’ll argue very wrong in a meaningful way.
Cloud services are meant to let you focus less on the plumbing, so naturally many skills in that will not be developed, and skills adjacent to it will be less developed.
Buttttt you must assume effort remains constant!
So you get to focus more on other things now. E.g. functional programming, product thinking, rapid prototyping, API stuff, breadth of languages, etc. I bet the seniors you are missing X and Y in have bigger Zs and also some Qs that you may not be used to consider, or have the experience to spot and evaluate.
Mind you that my take and experience is specifically in the context of security.
I struggle to make the parallel that you suggest (which might work for some areas) with a security engineer.
Say, a person learned to brainlessly parrot that pods need to have setting x or z. If they don’t understand them, they can’t offer meaningful insight in cases where that’s not possibile (which might be specific), they can’t provide a solid risk analysis etc.
What is the counterpart to this gap? Because I struggle to see it. Breadth of areas where this superficial knowledge is available is useless, IMHO.
Yeah I can see that.
However, you are now arguing a different point than I am getting from your original post. Maybe my fault in interpretation ofc, but the main difference (in my view) is:
You say “incompetent” and “less skilled” as general statements on senior engineers. Those statements are false.
You also say “missing the skills you are looking for” which is obviously true.
And the implication that before cloud, people developed the specific skills you need more naturally - because they had to. This makes sense and I believe it.
You say “incompetent” and “less skilled” as general statements on senior engineers. Those statements are false.
I am saying that the competencies of people who grew up (professionally) with outsourced services are more superficial and give them way less understanding (and agency) on the systems they oversee. I make the opinionated argument that knowing which service to use in a cloud provider is not just a different skill from implementing that functionality “manually”, but is hierarchical inferior, easier to acquire and less useful in general.
A weird parallel would be someone who hikes 100% of the time with a guide who takes care of orientation, camp setting etc., and someone who goes alone. If I am simply comparing the pictures they are showing me, I might not appreciate the difference, but if you asked me who I would trust to come hiking with me, I wouldn’t have doubt, because I consider the skill “finding, choosing and listening to the guide” to be hierarchial inferior to “orient, set camp etc. by yourself”.
So it’s not just a matter of matching the skills I need, is actually a much broader argument about deskilling engineers.
I understand.
Obviously, “knowing which cloud services to enable” is a lesser skill than knowing how those services work. That is not a parallel or equal skill in any way.
But do you assume people are just going drrrrr brain off when they don’t learn that one skillset you are accustomed to spotting?
Well, for the relatively small sample of Kubernetes experts I interviewed, basically any topic beyond “you use this tool” was a disaster, including Kubernetes knowledge. I am not selective, it’s not like I expect a specific skillset, but what would you think if someone with a decade of platform security doesn’t understand cryptography and supply chain, Linux permissions, Kubernetes foundational concepts, container isolation or networking? At some point the question is legitimate, what are you expert in? The answer I have been able to give myself so far is “stitching together services that do stuff” and “recommend what the documentation/standard recommends”. I consider myself satisfied to have somewhat decent knowledge in some of those areas, I am not expecting someone understanding all of that, but none of them? Maybe from someone who just joined the industry.
That being said, I am genuinely frustrated by how little people know or care about the plumbing these days. :D
I am so fucking tired of seeing someone spin up 3 cloud databases for what could be a 40k in-memory hashtable.
I disagree. On paper that sounds good, but I firmly believe good engineers are curious, so they’ll learn a lot more than necessary to do the job.
For example, when I worked at a company that designed antennas as a software engineer (built something tangentially related), I didn’t need to know anything about electrical engineering, but I was curious so I asked a ton of questions and now I know a fair amount about EE. These days I work in a very different domain and still ask a ton of questions to our domain experts. In my own field, I look into all kinds of random things tangentially related to the tools I use. In each case, that curiosity has come in handy at some point or another.
In each role, I can tell who’s there to clock in and clock out vs who is genuinely curious and looking to improve, and it’s the latter group who tend to produce the best work and go on to great roles after leaving our company, while the 9-5 warriors who just focus on the requirements tend to do pretty mediocre when it comes to advancement.
When I hire, I look for that curiosity because you never know what you’ll need to know to fix a prod issue quickly. My esoteric knowledge about SSH helped keep my team productive for a few days when IT was being slow revolving our issue, and likewise we’ve had quick resolution to prod bugs because someone on the team knew something random that ended up being relevant. That’s what I mean when I say I look for a diverse team, I want people with different strengths who all actively seek to improve so we’ll have a good shot at handling whatever comes down the pipe (and we get a lot of random stuff, from urgently needing to embed 3D modeling tools into our reporting app to needing to embed complex C++ simulation code or rewrite Fortran code into our largely CRUD Python app).
Most of these cases of “focus on one niche” are often symptoms of lacking curiosity and just wanting to tick boxes to quality for a role. I’d much rather someone miss a few important boxes but tick a lot of random ones because they’re curious; they’ll take longer to on-board, but they’ll likely be more useful long term.
I don’t work in the security space, but I think the same applies to most technical fields. Breadth of knowledge in an individual provides depth of knowledge in a team.
Yeah I don’t think we actually disagree much here. :)
I think my angle is just slightly different? I see that ease of access (eg cloud) make it possible for a lot more uncurious and clock-out people to enter the field and pass as competent. To be honest, even the modest introduction of auto-formatting editors are easy to see as good and useful, but I also feel that they allowed shoddy work to look passable at first glance. AI will make this a lot worse.
But as for the actual people who have it in them to be competent, people that were always there and still are, cloud is not going to make them worse.
I guess my point is that it’s harder to suss out the actually competent people if they’re able to build a good portfolio using tools. AI makes this harder, since they can sound more competent than they are, and them a few months down the line we need to discuss them leaving the org.
The main factor, IMO, is that everyone wants good engineers but good engineers don’t change jobs that often.
Meaning most of the candidates you interview will suck in one way or another.
And everyone calls themselves “senior” nowadays.
Everyone calls themselves senior because that’s the only type of position recruiters look for.
I’m a mid level dev, but I’m encouraged by recruiters to apply for senior positions because their clients are actually looking for a range of levels
Yeah, that’s true, everyone thinks they want a senior where usually someone who’s not a straight up junior is more than enough. And a fast learning and motivated junior is the best you can get, IMO, though those are pretty rare as well.
Exactly. We don’t hire “junior” positions, because all the midlevels are juniors, all seniors are mid-level, and seniors don’t apply. I’m a senior and a recruiter found me, I didn’t apply (at least not to this company).
That has been my experience with security people, too. They are button pushers and copy pasters. But I don’t think it’s cloud computing causing it. They were like that before clouds.
Yeah, they are frequently just parroting things like CVE notices as highlighted by a fairly stupid scanning tool.
The security ecosystem has been long diluted because no one wants to doubt a “security” person and be wrong, and over time that has made a pretty soft context for people to get credibility as a security person.
I’m a very good engineer, but so much of my time is consumed fighting with Tekton pipelines and migrating testing frameworks and versions I barely have time to write code. But that’s because I can figure that stuff out when I have to. All the code is written by the people who can’t figure that stuff out.
Why this isn’t two separate jobs I can’t understand. Let me do some stuff I’m good at rather than constantly fighting with things I’m not?
I somewhat disagree here, but also somewhat agree.
In my org, we get a lot of requirements that require very different skillsets. For the first 2-3 years, our task list was mostly CRUD stuff with some domain specific logic, but otherwise a boring web app. In the last 1-2 years, we have:
- ported a Fortran simulation to Python
- embedded a C++ simulation in Python
- created a 3D UX for our previously 2D only app (lots of 3D logic on both FE and BE)
- implemented a machine learning algorithm to train our simulations
If I hired only for the work I’d seen in the past, we’d be completely unfit to handle this workload since we’d mostly have people who are really good at building CRUD apps (so DB optimization and quick UX building).
On the flipside, we cut off huge swaths of work so people don’t need to wear too many hats. We have:
- dedicated devOPs - handles everything from trst pipelines to prod deployments
- dedicated QA - manual and automated app-level testing - devs still do unit testing
- dedicated product teams who handle feature requirements and documentation
- dedicated UX team to produce designs for FE engineers to implement
So our devs only need to worry about development, but they also need a broad skillset in that domain, from everything from local tooling to working in different domains. We hire a diverse set of candidates, some with a heavy math background, some with design experience, and some with low level programming experience, because we never know what projects we’ll get or who will suddenly leave the org.
If I understand the gist, I’ll just say I’d like my job to be some stuff I’m good and some stuff that challenges me. When I do nothing but challenge myself, imposter syndrome sets in. When I do nothing but the stuff that I’m good at, it gets really boring. I need to find a better mix than I have been.
nah, I was incompetent long before cloud services.
I’m not in any way, shape, or form an engineer so I don’t really understand the exact details of your post.
However, you post reminded me of a really good episode of a podcast called Hidden Brain. In it the host, discusses the topic of knowledge with a cognitive scientist.
At one point, they talk about how sophisticated technology has gotten that people don’t know how to solve problems if that technology brakes, especially since technology is getting so good that it makes fewer mistakes. They use an airplane as an example in which an experienced pilot forgot how to get out of a nosedive and crashed the plane. On a smaller scale, the host mentioned that he has a hard time navigating if his phone’s GPS doesn’t work.
Its a really interesting listen if you have the chance.
Thanks, indeed I think there are many parallels with other areas. I will check it out.
Or maybe it’s just a different skill set
Not when the skillset is essentially outsourced and you are left consuming the product of that skillset.
Understanding is nonnegotiable in security, IMHO.
You can’t fail to understand how signature attestation works, if you are implementing it, to make one example I made in the post. Otherwise you end up verifying the signature in the CI (like that person claimed it should be done) and waste the whole effort. You can definitely still outsource the whole infra and scripting to Github, but you still need to understand. The problem is that when you can outsource everything, at some point understanding becomes an extra step.
deleted by creator
