Garbage In, Garbage Out

     When I was in school. I took a class in applied sciences about thinking. I know it sounds like a total bird course right? The course left me with some considerations in how I come and go between complicated tasks.

• What makes it more difficult for us think?
• How come others don’t think like us?
• How much extra time do we all spend accessing something previously encoded in ourselves but find it very time consuming to access?
• What is the biological science?
• What are some examples about how self documenting applies to everyone.

Or.. Encoding and Decoding

Neuroscience is captivating, yet the specific biological details are fascinatingly boring to anyone who isn’t a specialist. We are seeing modern brain mechanics finally prove what academic research suggested years ago. However, it’s far too easy to drift into “woo” territory here; connecting biological “code” to human outcomes is a complex task. To make a real impact, we have to be ruthless: keep the mechanisms that work and throw out the rest.

Noise Noise Noise!

It’s Christmas, let’s talk about noise.

The Impact of Noise

Noise and distraction are two obvious drivers that harm your ability to think, work through a complex problem, or concentrate. Something everyone can understand. There is also cognitive noise to consider. Things like, too many tasks in your head, self confidence, and time stress toward proper implementation.

The Problem with Scientific Silos

Now, looking to science with noise and how we think is difficult because each silo of science only wants to look at their own dominating factors. Except people don’t fit into little silos just perfectly so through these studies we find that there is always a little bit of deviation. Some people struggle with auditory noise. Some people struggle with visual noise. Some people struggle with competing thoughts.

Why Frameworks Fall Short

So if you have been trying to apply frameworks to improving your efficiency and they all just seem to fall a little short? Consider that frameworks tend to target the struggles of a group of people or workflow. Things that the creators of the framework struggled with themselves.

Worse, some of the more popular frameworks will point to how they were implemented in an organization and use KPI metrics returned that seemed positive but we have to think further. There are so few scientific controls in those business situations, blindly accepting that they are working or repeatable may be byproduct of the framework itself. Perhaps a deeper struggle the organization was dealing with was rallying staff around a particular way forward at all in which case any framework would show a marginal improvement. This is not scientific. For example, maybe an the agitation was just moved to another department and nobody recognized the catalyst for change at the time.

Case Study #1: The 85dBA Threshold

A paper on the affect of noise exposure on cognitive performance found that the testing was fairly inconclusive. Some people really struggled, some didn’t. It was only after they turned it up past 85dBA that suddenly the scientists began to see some strong comparison in cognitive decline.

https://pmc.ncbi.nlm.nih.gov/articles/PMC6901841/ 🔗

That’s fairly loud. Like listening to the spice girls when no one is around loud. Like I can tell you what I want what I really really want loud.

Good Baseline Controls

This study below used additional technologies to measure brain waves while conducting their testing. They isolated for people that don’t drink coffee, or have sleep issues etc. Human beings that are a step above the rest of us mere mortals which is a good baseline for control.

The Solve

Simple, we control environment. Reduce noise, and see a positive boost on that section of the population that struggles with auditory sensitivity.

Study #2: Decision Fatigue and Ego Depletion

You’ve likely heard of this and there are all kinds of takes on how to handle decision fatigue. From the most extreme just say “YES” style cultish self help for joining new experiences to picking the right fruit in the grocery isle.

The paper referenced below focuses on decision fatigue as it relates to nursing and states that the average person makes 3500 decisions per day! The research also suggests that decision fatigue is very susceptible to glucose levels. As fatigue sets in, confidence wanes and people become more passive or fearful to make strong decisions to move forward.

The correlation to support self documenting systems in this case is that we want scenarios where we are making quick determinate decisions on our tasks without having to think through or research harder.

The evidence suggested by the paper suggests detriment to executive function which is your mission control for solving problems. Planning also suffers.

https://pmc.ncbi.nlm.nih.gov/articles/PMC6119549/ 🔗

The Solve

It’s unfortunate that this is such a widespread phenomenon. There are many indicators related to decision fatigue in cognition and it increases negative attributes such as bias the more fatigued a person is.

The best advice right now? Reduce cognitive load, manage our fuel levels and plan our deep research or use our planning energies earlier in the day. Reduce cognitive load for benign small tasks that could use less executive function. Regardless, decision fatigue is real and has impact. In a more practical sense it’s also a great agument against end of the day meetings.

Reference #3 Chunking Patterns

Chunking is compressing smaller ideas into lists or patterns that are easier to process.

Just like certain workloads on computers may benefit from how large a block of data stored is due access times regarding retrieval. Humans do better at juggling just a few small variables at once. Smaller chunks and less of them mean faster workloads. If we can also apply patterns to that idea then we get an even smoother efficiency toward transitioning between internal considerations.

https://www.ebsco.com/research-starters/psychology/chunking-psychology#full-article 🔗

What Does This Have to do with Self Documenting

Your prefrontal cortex makes better decisions when systems are clear, packed neatly and displaying recognizable patterns.

Nothing, and everything. So imagine you are looking to change a GPO in your domain and there are 100’s of GPO’s or maybe there’s just one big GPO with 100’s of settings (god speed). Now, you know the behaviour that you wish to change but the list is overwhelming and that’s even before you add in the complexity of applying user or group individual rules or find OU hierarchies and overrides, you get the point.

Changing the rule can have adverse consequences if you don’t test it thoroughly and that drives a new trigger (fear) which then dumps a chemical called cortisol into your brain. You were tasked with changing a simple behavior on Windows clients but suddenly you are paralyzed and stuck looking for a needle in a haystack and begin to expect poor outcomes.

Maybe you have to setup a whole test situation and sync that client to the domain adding onto the time the task will take. This is an extremely common situation for IT people. Something that sounded like a two second change, is now a 2 hour endeavour.

Solving the Wrong Problem

Just look at the tools we have available for this task, to deconstruct environments and try and find common threads in group policy objects. Whole command line utilities have been written in an attempt to make this process clear. A self documented system could get you there with a high amount of confidence and even allow you to circumvent the testing period.

Solving the Right Problem by Self Documenting Design

Alternatively, let’s assume you had a really good sysadmin that cared about self documenting the domain, clients, and networking because they had the foresight to know ahead what this situation progressed would look like. Well a number of things could be done.

• Client names could all follow a pattern. Like: SITE-LT-CS-01
  • Site acronym
  • machine type or department
  • unique number

Now at a glance. With this short hand, you can tell a lot about that client. Where it physically should be, if it’s a laptop or desktop, which department (customer service) and when it was assigned based on a deployment number. We can also structure our GPO’s in the domain in a similar way using names and folders to split them individually by action. That’s If we had the foresight to start this pattern and trend ahead of the issue all together. We are architects toward a future that we don’t always know will bear fruit without past experiences in this way.

That’s Just Called “Being Organized”

While it looks like simple organization, there is a fundamental difference in intent. Traditional organization is often a personal ritual of beautifully penned notes, complex grids, and proprietary shorthand that work perfectly for the creator but remain a mystery to everyone else. These systems are fragile because they are built around the person, not the task. Self documentation, however, is about universal accessibility. It is a system designed to be decoded by a total stranger on their first day. Its power doesn’t come from a manual; it comes from an inherent clarity that supersedes the need for explanation.

However bitter sweet, the highest praise a sysadmin can receive is to automate themselves out of a job.

Organizational Incentives and Leadership

This is also something that can be socially difficult. In an organization where maybe you need other departments to adopt a certain way of naming things or those work flows. If one department is tasked with troubleshooting GPO’s but the other isn’t. Well now you have mismatch in incentives.

This is where leadership matters and great forms. Good leadership will recognize and sweat the small things, make good arguments and deal with other silos to care about the cross contamination of self documenting workflow. They’ll recognize the projects that further benefit these systems and rally.

The Challenge in the Homelab

For ourselves and in our home labs. There really isn’t as much excuse but perhaps what’s more difficult personally is the creativity to design the self documenting aspects while solving a problem, and then sticking to it in an environment where there is nobody but yourself to answer to.

Design vs. Agreement

Regardless the self documenting system is almost always superior against time lost in implementation. This is exactly why we don’t see this enough in the real world. Agreement, is more difficult than design in this case up front and performance outcomes span in a more subtle way over time. This requires a clear leader with the ability to turn down a group and avoid implementation by committee. Where vision and intention may be misunderstandingly removed. Ideally people come with us, and joyfully so but that just isn’t always the case.

Foundations and Child Objects

If you have a foundational workflow such as naming. Then that advises all other workflows where those child objects reference. Imagine, a few months later, you begin implementing some sort of asset management system to track those clients.

Except now, along with all the other wonderful information that can be gathered such as last time a machine was seen or individual specs. You already have host names and data that can then interpolate between these two systems to draw a much stronger picture.

Prioritizing Reads Over Writes

Data entry is still a barrier and congruence between departments is once again the weak point. From there you can implement tighter controls on how data is inputted and make the formal process more clear. The input can still follow a bit of a guide or better, use built in constraints that notify the user immediately providing us clean sanitized data via forms.

Remember the intention is to retrieve faster, not necessary encode and store faster because just like computers, we are more likely to do more frequent reads rather than writes.

classDiagram
    class Animal {
        <<Parent Class>>
        +String species
        +int age
        +Eat()
        +Sleep()
    }
    class Dog {
        <<Child Class>>
        +String breed
        +String ownerName
        +Bark()
        +Fetch()
    }
    class Cat {
        <<Child Class>>
        +bool isIndoor
        +Meow()
        +ClawScratch()
    }

    Animal <|-- Dog : Inherits
    Animal <|-- Cat : Inherits