It was the day my desktop at work had blown up. I was running a persistent virtual desktop and somehow I borked Windows; the OS was dead. I had all my vSphere and Windows administration tools installed on it and like a well worn tool I knew the strong and soft spots.
That was the day I realized I had no equivalent to a carpenter's toolbox. Although my tools are strikingly different from the carpenter's toolbox the same care and feeding needs to be performed to keep my tools sharp and available for use.
My first tool was a vSphere management station. Loaded up with the most awesome management tools and only used for vSphere management with no corporate crapware (Outlook) to slow it down. I documented the build process and keep it up to date.
Like a good carpenter you should keep track of your tools, hone them, and retool them. I've started to blog about each tool I use, starting with "vmtools", a vSphere management tool. Using IFTTT, each blog post tagged with "ITtoolbox" is saved to a spreadsheet. The spreadsheet is now my virtual toolbox.
From my virtual toolbox I can see when I added a tool. I can then review the blog post, see if it needs retooling or if I need to remove it all together. I did some Googling on caring for hand tools and found this toolbox idea translates into a commonsense rule: "a place for everything and everything in its place". From there, I've compiled a short list of rules for IT tools:
- If you can't find what you're looking for or can't get to it quickly then you'll probably reinvent it. Save yourself the trouble and keep a list of tools in a spreadsheet. Event better if you can automate the process using IFTTT.
- Keep a few frequently used tools on portable media. Internet access isn't always guaranteed and you never know when you'll need your tools.
- Choose quality over quantity. You don't need five different IDEs, just one good one. Find what works best for you. Beta products are great to try but if they don't work well or not at all then they don't belong in the toolbox.
- Watch out for "flings" or "beta" products in production environments. Try before you add it to your toolbox. Before you add a tool to your toolbox give it a provisional time period. Kick the tires on it and if it lives up to its name it can stick around.
- Don’t use tools of unknown origin. Seems like a no brainer but do a quick Google for a solution to a problem and you'll see plenty of scripts and exe's claiming to solve the problem. Only run these tools if you trust the authors and examine source code when you can.
- Right tool for the right job. Holy wars aside, some tools are better than others at certain things. Usually it comes down to Windows Vs Linux for myself. Your milage may vary depending on your skill set. Some other examples are: Don't run a 32-bit operating system if your tools need more than 4GB of RAM. Don't use a VM if a physical device would be better suited.
- Last, but not least, keep your tools in working order. If a piece of software is no longer supported then you may want to reconsider keeping it for security reasons. Operating systems go out of support and need to change. Vendors supporting software packages change with each release. Know what's current and keep your toolbox up to date.