this post was submitted on 12 Jul 2025
115 points (89.7% liked)
Technology
72764 readers
1745 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Or maybe senior security engineers from 10 years ago were somewhat different from (wannabee senior) security engineers today?
Did you ask them to write 0xD6 in decimal? ๐
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.
Same principle works with IT. I do and have done sysadmin stuff for quite a while and there's always some random software or whatever I've never heard of and someone comes and asks me to fix it. Then you start to ask questions, "what exactly doesn't work", "can you show me what you're doing", "what should happen when you press that button", "can you show settings on that thing" and so on. Then you can start to dig down, does the server they're using respond to ping, does DNS resolve (it's always DNS after all), does that thing work on the next workstation, when did the problem appear and was there some other maintenance or changes going on at that time and so on.
Same principle, just start to reason the whole thing from bottom up, check everything you come across untill you find something which doesn't work and then do what's needed to fix that, rinse and repeat until the problem goes away and make sure that what you're doing won't cause new problems. Just the tools are different, the mindset is more or less the same.
Exactly! If you know enough foundational principles, you can quickly rule things out and develop ways to narrow down what remains. If you rely too much on diagnostic tools, you'll miss out when the tools fail to catch something odd.
I'm a software engineer and we had a problem where our corporate laptop wouldn't allow us to install our dev tools (needed to debug a windows specific integration and we dev on macos). Instead of waiting a week for IT to come fix it, I realized we just needed it to look like a service was running locally, and we had ssh through the git bash shell, so I set up an SSH tunnel between the windows system and the dev machine and they were able to keep working while waiting for IT to get time to help us. We rarely use SSH at work, but I understand enough about how networks and sockets work so I was able to quickly help them solve the problem.
You don't get that type of intuition if you don't understand how the underlying tech works, and that's true regardless of your field.
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.