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.
Comment on Using Clouds for too long might have made you incompetent
Deestan@lemmy.world 1 month ago
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.
Deestan@lemmy.world 1 month ago
sugar_in_your_tea@sh.itjust.works 1 month ago
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.
MangoCats@feddit.it 1 month ago
now I know a fair amount about EE
But, did you ever use a Smith’s chart to assist in antenna design / analysis?
sugar_in_your_tea@sh.itjust.works 1 month ago
I know what a Smith’s chart is, but I never needed to actually use one. I’m a software guy who knows some random details about RF, and that sometimes helps with random things like identifying issues with WiFi or whatever.
MangoCats@feddit.it 5 weeks ago
Yeah, I was an EE in college so I took the Smith’s chart class, did the exercises, then promptly started using newer tools when such things were called for… mostly I worked in software after school so all those exercises were… academic.
Deestan@lemmy.world 1 month ago
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.
sugar_in_your_tea@sh.itjust.works 1 month ago
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.
loudwhisper@infosec.pub 1 month ago
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.
Scipitie@lemmy.dbzer0.com 1 month ago
Because a security engineer focused on cloud would rightfully say “pod security is not my issue, I’m focused on protecting the rest of our world from each pod itself.”. With AWS as example: If they then analyze the IAM role structures and to deep into where the pod runs (e.g. shared ec2 vs eks) etc. then it would just be a matter of different focus.
Cloud security is focused on the infrastructure - looks like you’re looking for a security engineer focused on the dev side.
If they bring neither to the table then I’m with you - but I don’t see how “the cloud” is at fault here… especially for security the world as full of “following the script” people long before cloud was a thing.
loudwhisper@infosec.pub 1 month ago
I mean, the person in question had “hardening EKS” on their CV. EKS still means that the whole data plane is your responsibility. How can you harden a cluster without understanding the foundation of container security (isolation primitives, capabilities, etc.)? Workload security is very much part of the job.
I mean the moment some pod will need to run with some privilege (say, a log forwarder which gets host logs), and you need to “harden” the cluster, what do you do if you don’t understand the concept of capabilities? I will tell you what, because I asked this very question, and the answer was “copy the logs elsewhere”, which is the “make it work with the hammer solution” that again shows the damage of not understanding.
I am with you about different scopes, skillsets etc. But here we were interviewing people with a completely matching skillset on paper.
Scipitie@lemmy.dbzer0.com 1 month ago
Oh yeah I see…
As some old philosopher once said: “shit’s fucked, yo”.
Seems to be appropriate here.
Deestan@lemmy.world 1 month ago
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 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 these skills more naturally - because they had to. This makes sense and I believe it.
loudwhisper@infosec.pub 1 month ago
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.
Deestan@lemmy.world 1 month ago
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?