I'm primary a system and database administrator paired with a developer. There are a couple of tasks which are worth to be automated. I love automating the major parts of my technical tasks with powershell, except one timers. Automation reduces the time in my environment from hours to minutes. When I know I need to do things multiple times in future, I create powershell functions and scripts to automate these steps. Also I don't like to create classic or vintage documentation because they commonly require a lot of time and often has its focus on the wrong audience. The documentation is for my team and myself, not for non technical users who love to receive dozens of pages with long descriptions, screenshots and tables. This is waste of time which is required for other important tasks, so documentation is postponed, forgotten or skipped.

When I need to create a documentation for an installed system, I prefer to do it in three layers: - Vendor defaults are documented by the vendor for the specific version. Nothing to do for me. - Company defaults are documented in the company documentation and shows only the difference between the vendor defaults and the company settings. This had been created once, changes are noted with date and a change history. - Project or system individual settings are the only thing which need to be documented. The defaults referrer the company documentation. If there are changes after the initial documentation, changes are documented with a change history.

The clue is, the vendor documentation is for free and means no work, just a link to the sources. The company documentation is done once and only the project or system documentation is created with every installation. And this is the smallest part and takes only some minutes.

An example: I regularly need to install sql servers and other services. The installation is automated by powershell and installs the desired version and applies the latest cumulative update available and applies the company settings and is done within a couple of minutes. Then the individual settings are configured, which also would not take so long. Commonly I do this with powershell, so I can reuse these steps in other steps. A jupiter notebook is a great and helpful combination of documentation and script blocks, so you can follow step by step without switching between console and documentation. Finally I run pester to check the settings which should match the company defaults. Every difference in the result will result in a inconclusive result and give me the information for the indivial documentation. These and only these differences are documented, so it is quite normal, the documentation does not fill more than some single lines.

Another example: I prefer the usage of common default paths. If needed to store data on a different location, this is no problem. At the default location I create a symbolic link. This allows me to reach the files without checking the individual settings in the service, or even if the service is not available due to an error or other circumstances. No need to search for a documentation in this case. Even if, the required info will be found within seconds on the first page. A symbolic link for a specific reason: I can work with the files at the given location without the need to adjust something like paths etc. The system behaves like it's the original location.

What is the benefit in this case: I don't need a document with dozens of pages of text where the individual setting I need to know is hard to find. Why search in the pages, when every important info can been found on one page? This is my form of efficient work.

And this is one example. One of many possibilities where automation and planning ahead takes action and helps dramatically to reduce the time different tasks would require if they are done manually. I try to follow some basic principles: - DRY (Don't repeat yourself) This is so commonly known and stands for itself. - Work smart, not hard Also well known and for me it's spend 1 hour for a task to automate which can be done manually in 30 minutes. The next time automated it just takes some minutes. - Look ahead and be prepared While creating a function, make it versatile and flexible, so you can reuse it in multiple scenarios. - Be patient and stay focused Don't rush yourself because quick and dirty is not the way you want. - Create common standards and follow them While establishing standards, you should follow them. While making everything manually you loose time and you can create issues. Automation will bring consistence and reliability to your work. Regardless if you perform the task once a year or multiple times each month.

Regarding the automation: - think in small steps, do one after another and build robust functions for single tasks - store and maintain them in a central repository to make the reuseable. This will become your toolbox with tools for your tasks. It will grow with the time and contain a tool for countless needs. - use proper verbs and speaking names for the functions for an easy identification of its purpose. - Don't forget the synopsis block, which are easy to add within seconds by using tools like copilot, codeium or whatever else your favorite is. - Probably some additional comments in the function code itself, which can be helpful for further maintenance tasks or hints for specific documentation. - Create scripts is like a puzzle. The better your tool box is grown and maintained, the easier will your scripts come alive.

This way of working gives me a lot of time to do research, training and testing, which is also a part of my job and is important. Without developing and educating yourself, you won't be prepared for upcoming tasks and your personal skills will not improve. Else what will change with the time? Almost nothing else than the version number of your software and operating systems you use as the rest remains with the same limited and outdated type of work. So there is no need to look busy, when you can afford some time for other things. Read, learn, maintain and improve, evaluate and get in dialog with others.