• 0 Posts
  • 31 Comments
Joined 2 years ago
cake
Cake day: June 12th, 2023

help-circle


  • I’ve said it before, but this is a 20-year-old problem.

    After Y2K, all those shops that over-porked on devs began shedding the most pricey ones; worse in ‘at will’ states.

    Who were those devs? Mentors. They shipped less code, closed fewer tickets, cost more, but their value wasn’t in tickets and code: it was investing in the next generation. And they had to go because #numbersGoUp

    And they left. And the first gen of devs with no mentorship joined and started their careers. No idea about edge cases, missing middles or memory management. No lint, no warnings, build and ship and fix the bugs as they come.

    And then another generation. And these were the true ‘lost boys’ of dev. C is dumb, C++ is dumb, perl is dumb, it’s all old, supply chain exploits don’t exist, I made it go so I’m done, fuck support, look at my numbers. It’s all low-attention span, baling wire and trophies because #numbersGoUp.

    And let’s be fair: they’re good at this game, the new way of working where it’s a fast finish, a head-pat, and someone else’s problem. That’s what the companies want, and that’s what they built.

    They say now that relying on Ai makes one never really exercise critical thought and problem-solving, and I see it when I’m forced to write fucking YAML for fucking Ansible. I let the GPTs do that for me, without worrying that I won’t learn to code YAML for Ansible. Coding YAML for Ansible is NEVER going to be on my list of things I want to remember. But we’re seeing people do that with actual work; with go and rust code, and yeah, no concept of why we want to check for completeness let alone a concept of how.

    What do we do, though?

    If we’re in a position to do so, FAIL some code reviews on corner cases. Fail some reviews on ISO27002 and supply chain and role sep. Fail some deployments when they’re using dev tools in prod. And use them all as teachable moments. Honestly, some of them got no mentorship in college if they went, and no mentorship in their first ten years as a pro. It’s going to be hard getting over themselves, but the sooner they realise they still have a bunch to learn, the better we can rebuild coders. The hardest part will be weaning them off GPT for the cheats. I don’t have a solution for this.

    One day these new devs will proudly install a patch in the RTOS flashed into your heart monitor and that annoying beep will go away. Sleep tight.







  • I’ve had my enterprise-distro linux machines updating by cron for 22 years. I had two glitches in those 20 years, too, just like you. But in addition to my two glitches - I had to bring in one unlisted dep for cobbler and also correct the smb.conf’s old format on another box - in 20 years, I also got

    • out-of-the-box
    • do-nothing patch runs
    • trivial back-out if I needed it

    And while I know your numbers are excellent, I simply haven’t had to DO ANYTHING since deploying some boxes. They patch, they bounce later on a weekend if they need it (‘needs-rebooting’ is centralized because ALL software installs are) and I can patch while under load because linux write-locks instead of read-locking. My effort is to check ‘some time later’ and ensure things are working in ways nagios doesn’t catch.

    Printer issues? Nah. Supply thing. App not working because java/perl/python/DLLs rug-pulled a dependency? Proper packages list hard dependencies, so that cobbler thing is a bug not an expectation. Network offline? nah. Reboots? timed at 3 minute downtime (1 min before systemd), or 7 minutes if I just updated 1gb of gitlab install because it starts like a manatee.

    It’s really a different world; and while I’ve teased the heck out of my windows peers, it’s a true statement.