I'm falling back into a routine. The first few days were a fight to get the routine going. The few days afterwards have been empowering. I can't say they have been great. But it's been a lot easier keeping the routine.
I think that's with all new practices. The initial period is always horrendous. It's a few days or a few weeks of thinking about doing something, but never doing it. It makes me think of Confidence and Paranoia from an episode of Red Dwarf. Lister ended up getting sick, and his confidence and paranoia came to life as external beings. Your confidence, to paraphrase Lister, is the guy who tells you you're great, you're wonderful, you're sexy, and everyone loves. Your paranoia tells you you're stupid, you're ugly, and everyone hates you.
Both are just competing opinions in the brain. The answer is simple and obvious: trudge on regardless. Start regardless of what you think.
It gets easier to follow the routine through days 3 and 4. Though the first few days are pretty much like pulling teeth.
Is it automatic yet? No. No where near. But it is at least to the point where I can see a benefit in going through the motions and doing the exercise. I'd generally say give something at least two weeks, but I know I haven't done that before.
But then I'm also influenced by the thought that people overestimate what they can do in a day and underestimate what they can do in a year. Broken down, some goals aren't that hard when spaced out over a year. There just has to be definite progress throughout. And there almost never is definite progress.
Recent books I've read:
The Four Hour Chef by Tim Ferris
A blog about the things that interest me. Includes random thoughts, Cisco, programming, and business related stuff from convenience store world.
Wednesday, September 21, 2016
Sunday, September 18, 2016
The Boring Details
I've been spending a lot of time contemplating automation recently. Automating things is rather great. But I think there is an unwritten side part to automation. I'm going to write that down.
In order to automate anything, you must first document the entire process.
After reading that sentence, you are probably thinking a lot of sarcastic comments. I'd like to agree with you, but the stupid simple is what most people miss in the first place. How often has business classes shown case study after case study of ridiculous levels of bureaucracy that can be removed and processes that can be streamlined by knowing the process.
But then that involves a lot of boring drudgery. That's the part that no one does. It's a simple thing, but doing that simple thing is all that really needs to be done. By the end of the process of documentation, you've got an in depth understanding of the events that take place. Often in the process you start thinking about why certain things are done, and you realize just how much time you can solve by automating.
I looked at the same idea when I was fighting the Windows Automatic Installation Kit. Sounded like a great idea. I could never get the network drivers to work on my builds. So I basically burned through a lot of crap and none of it worked.
So after that, I went back to partial automation and partial manual. If part of the process is copying files and creating directories, why not automate that? A batch file is perfectly acceptable for that and it becomes automatic and the same everywhere.
I want to do the same thing with network discovery, but Python is giving me hell. Something I'm not certain of is causing me problems. I can't get the data file to create.
Anyways, I guess this is the call to do boring but important things. Documentation is boring. But it solves a world of problems. It also gives you the ability to solve all sorts of problems in the future. And it gives you the best ability: delegation. If you have something well documented, you can then delegate the task and give it to someone else.
In order to automate anything, you must first document the entire process.
After reading that sentence, you are probably thinking a lot of sarcastic comments. I'd like to agree with you, but the stupid simple is what most people miss in the first place. How often has business classes shown case study after case study of ridiculous levels of bureaucracy that can be removed and processes that can be streamlined by knowing the process.
But then that involves a lot of boring drudgery. That's the part that no one does. It's a simple thing, but doing that simple thing is all that really needs to be done. By the end of the process of documentation, you've got an in depth understanding of the events that take place. Often in the process you start thinking about why certain things are done, and you realize just how much time you can solve by automating.
I looked at the same idea when I was fighting the Windows Automatic Installation Kit. Sounded like a great idea. I could never get the network drivers to work on my builds. So I basically burned through a lot of crap and none of it worked.
So after that, I went back to partial automation and partial manual. If part of the process is copying files and creating directories, why not automate that? A batch file is perfectly acceptable for that and it becomes automatic and the same everywhere.
I want to do the same thing with network discovery, but Python is giving me hell. Something I'm not certain of is causing me problems. I can't get the data file to create.
Anyways, I guess this is the call to do boring but important things. Documentation is boring. But it solves a world of problems. It also gives you the ability to solve all sorts of problems in the future. And it gives you the best ability: delegation. If you have something well documented, you can then delegate the task and give it to someone else.
Subscribe to:
Posts (Atom)