Comment on Using Clouds for too long might have made you incompetent

• IsoKiero@sopuli.xyz ⁨5⁩ ⁨days⁩ ago

  Does a senior mechanic need to understand the physics of piston design to be a great mechanic

  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.

  source

  • sugar_in_your_tea@sh.itjust.works ⁨4⁩ ⁨days⁩ ago

    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.

    source

    • IsoKiero@sopuli.xyz ⁨4⁩ ⁨days⁩ ago

      The best mechanics can track down an issue by reasoning about what could be causing it

      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.

      source

      • sugar_in_your_tea@sh.itjust.works ⁨4⁩ ⁨days⁩ ago

        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.

        source
• loudwhisper@infosec.pub ⁨5⁩ ⁨days⁩ ago

  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.

  source