Showing posts with label documentation. Show all posts
Showing posts with label documentation. Show all posts

Thursday, January 27, 2022

That's not how you get there

 I've been reading through Bold by Peter Diamandis.  It's an interesting book, with a lot of interesting ideas.  In the same period, I was listening to the audio book of The Traveler's Gift by Andy Andrews.  Despite both books being really good, I find them interesting in different ways.

There's only one big problem: both hit periods where you just need to power through to make it to what you really want to hear.  In the Traveler's Gift, it's the beginning.  If you can power through the first two to three chapters and get beyond how bad life sucks, then you are in for a treat.  The rest of the book is really interesting and well worth the time spent. 

Bold doesn't work that way.  Bold has a tendency to go from very good to slog in numerous places.  Some parts are brilliant, and leave me thinking about places I could go and ways to apply the things listed.  And then you have to slog through a good chunk of stuff to make it back into more interesting stuff.  That's just the way the book is written.  

The big problem I have with Bold is me.  I know I dislike working in large groups, forming companies, and solving the day to day people problems.  I'd rather spend my time working on my things and hope it all goes and works out well.  Or if it doesn't, I sit back at the drawing board and try to rewrite and revise.  Those rewrites and revisions solve lots of problems.  

But it's hard to make it work that way for complex processes and procedures.  It's not the complexity that's the problem.  It's the scope.  Some of the things I envision doing are the work of entire teams, done by one person.  And the pace I have to create these complex machinations just doesn't fit on scale.  Maybe if I had two to three hours a day just to work on my own ideas it might.  But I don't have those.  I have too many other problems to solve, and often it's other people's problems that need resolved.  Or a way to monitor something so a person who's not me can get the information necessary to make the right choice.

If they actually follow the flow chart I created, which is unlikely.

There's always resistance.  No matter how good the idea, there is always resistance.  And trying to get the most resistant person to follow the procedure is the hardest.  Because they don't know what the data means, and won't follow the procedure.  Even if it will lead them directly to what they need to act on. Because they don't understand it, and they won't focus on the material you have told them to focus on.

Simple questions become complex.  Go to this website.  Look at this specific thing.  What does it say?  Does it say X?  Then there is a problem.  If it doesn't say X, then there is no problem.

"What about this thing four lines down the page?"

"Ignore it." 

"But I can't.  It says alsdfhasdlfkhjalgedfj and I need to know what that means."

"It is not relevant to the problem at hand." 

"But I need this information."

And this is how the conversation goes.  From people who won't take the effort to learn LAN switching, router behavior, or any other complex technology.  

I know I need to learn more about cell signal strength and signal to noise ratio, but I don't have time to do that right now.  So I have to accept that when I look at that piece of data, it doesn't mean anything to me.  But the square box that tells me the router is on cell backup?  Yes, that is the important bit.


Monday, October 17, 2016

Color redesign

I decided to change the colors around this morning.  The old background was my dinner table from a few years ago, and is now sitting out on the back porch.  Not terribly impressive, but hey.  It's out there. 

The new one fits more with the manilla folder idea I've been obsessively using in the past few decades.  I remember a website I created back following the days of GeoCities where I had a manilla folder background.  Nothing terribly impressive, but it takes me back to those days.

This one was a little more professionally designed and actually tiles like it is supposed to. 

At work, I've recently been using TWiki a lot.  Seems like a good platform.   After my vacation a couple of weeks ago, I realized the catalyst for much change is documentation.  If you don't document, then you are going to keep repeating the same tasks over and over again, and wondering why no one ever gets around to changing. 

You can't shove a part of the job you don't want to do on someone if you do not document.  It's that simple. 

If you will not document, then you will do the same thing over and over again.

Once the documentation is complete, you must then hand the documentation off to someone else in order to test your documentation.  If your documentation is never examined or tested, it's not really documentation.  

You must also revise and expand on your documentation to the point where it is excessively long.  You have to realize the person you are handing your documentation off to has no clue what a native VLAN is or why it could affect communication between a router and a switch.  And why have a native VLAN in the first place.  I've probably heard that question before, but I don't remember the answer.   I know the difference between a native VLAN and a non-native VLAN.  Hell, I brought up ISL in the conversation in order to back up enough to provide a starting point.  

But in the end you must document to the point of excessive.  All you are going to do is take up disk space, and disk space is relatively free. 

Anyways.... 

Upgrades Tuesday, Wednesday, and Thursday this week.  At least the prep work is mostly done on them.  So they should go relatively quickly.