My new book – Advanced Hands-on Rust – is now in beta! Intermediate to advanced Rust, writing games in the Bevy engine. Generics, traits, macros, library creation and more. https://pragprog.com/titles/hwmrust/advanced-hands-on-rust/
#rust #rustgamedev #bevyengine

@pragprog beta books get you most of the e-book now (sadly, we can’t ship out a new print for every beta!), and each subsequent release as the book advances towards final release. You can also file bug reports and help make the book better.

The tendency for corps to automate away low-tier work has some unfortunate consequences when this tendency hits things like SOCs - at that point, removing e.g. tier-1 triage type work produces minimal cost savings (junior analysts aren't all that expensive) but also removes the work experience that is required to learn how to become a senior analyst.

When your educational pipeline is interrupted, this also interrupts knowledge transfer from seniors within the organization, resulting in increased institutional knowledgebase decay over time.

Many of the services currently in production are highly resilient to disruption - and well they should be; they've been built from the accumulated knowledge and expertise of many people over a period of years, with the explicit goal of creating resiliency, maintainability, and performance.

However, that resilience is a finite resource for these services, and is maintained over time by the application of institutional knowledge and expertise; even the best-documented and most-resilient systems will decay over time if the personnel who comprehend its structure and maintenance requirements depart the service-operations role without passing this distillation of knowledge down to their successors - successors who, in turn, need an onramp to obtain such roles in the first place, an onramp that was formerly expected to be the tier-1 roles that are being progressively automated away.

And that's not to say that all tier-1 roles will vanish, and certainly not immediately - but the progressive reduction in their availability will impact the pool of personnel available for these roles.

Like all complex systems, the ones I'm talking about aren't going to immediately fall over; instead, we see gradual losses in effectiveness over time - for "the system by which security analysts are trained from neophytes to senior level" this will look like a much-reduced qualified candidate pool over time, with fewer and less-qualified candidates for the jobs that are available.

This is likely to end up being compensated for in the short run by outsourcing and exploiting international workers from areas that are lagging behind in technological availability of these junior-removing automations - but these workers will necessarily not have the same context and institutional knowledge that in-house workers will have about the nature and purpose of the systems being used, which will cause impedance mismatches that we already see with, e.g., MSSPs and their clients.

I don't have a clear feasible solution for this. I'd like to see various outfits that are working to automate away junior positions engage with this directly, tho, and to have frank and open discussions about ways to teach people how to work with their systems to gain that expertise so that they can be effective seniors in the paradigm that those companies envision in the future - tech requires people to operate, and if your product is intended -for- the disruption of such a market, describing the new system that you envision resulting from the disruption is, I think, a requisite for ethical participation in such markets.

Ultimately, I think that considering the whole lifecycle of how -your- product interacts both with the system as it is -and- with the system that your product will define with its success is absolutely necessary for a product to remain successful over time.