Discussion on:
View:
Show:
I would promote documentation to item #1. documentation is something that is always behind
In this age we are in due to economic woes, documenting everything might not be too good of an idea . Yeah ! Be careful !
Economic woes may mean the now over-paid guru gets the axe, leaving the dime-a-dozen noobs left to figure things out. To the bean-counters, two 40K new-hirers is better than one 80K Zen Master.To them, IT workers are replaceable minions, while managers and execs get to count on such subjective concepts as intrinsic value of knowledge and experience.
Case in point, my company found it cheaper to migrate a system to a brand-new platform, rather than to keep maintaining the old one and the only guy left who knew how to fix it. Being a very, very expensive core business system kept him employeed for over 30 years, then all of a sudden, that couldn't save him anymore. (He was 58.)
Case in point, my company found it cheaper to migrate a system to a brand-new platform, rather than to keep maintaining the old one and the only guy left who knew how to fix it. Being a very, very expensive core business system kept him employeed for over 30 years, then all of a sudden, that couldn't save him anymore. (He was 58.)
I try to document as I go. It sometimes takes twice the effort to do it later. Things like: what IP did I give that database server? Add it to a wiki or something while you configure it rather than wait till later and have to run a nslookup or whatever to find it again so you can add it. Once it is documented it is a lot easier to configure clients properly because again you don't have to look up the ip from a console every time your setting up the connection.
Next up why this is good: hardware/software installed on clients leaving the lab. Heck half the time you'll forget what you called that system. You end up having to go to the persons office to get the computer name then fiddle around with it to see what all you installed on it and document it etc. Much easier to add the computer name/location and stuff on it when you actually have it in the lab to play with. Most times the user won't know you spent an extra 10 min with their new machine before giving it to them anyways.
Next up why this is good: hardware/software installed on clients leaving the lab. Heck half the time you'll forget what you called that system. You end up having to go to the persons office to get the computer name then fiddle around with it to see what all you installed on it and document it etc. Much easier to add the computer name/location and stuff on it when you actually have it in the lab to play with. Most times the user won't know you spent an extra 10 min with their new machine before giving it to them anyways.
No, you chouldn't, but if you already have fallen behind, quite time is the time to get caught up. I think that was the point of the article.
11) Clean yer drives. Bloated network drives full of junk are fun rummage through and delete. You can make a game of it, play dress up or maybe have a yard sale with those 10GB crash dumps you've been "meaning to look at" since 2007. The kids love being handed a bunch of directories labeled "Backup" no one remembers. You may even find some cash!
12) I agree, documentation is not a rainy day past time. It is an essential element of fault tolerance.
12) I agree, documentation is not a rainy day past time. It is an essential element of fault tolerance.
so you're a neat shop, have recovery plan, regular, tested backups for the really important.
but even in a neat shop there are other things to backup. you can do some "irregular" backups for the not so importants, plus review and clean up outdated, details-forgotten temporary copies created in emergency situations
if only the first part of the first sentence is true, than just simply do irregular backups, test them, and so on.
but even in a neat shop there are other things to backup. you can do some "irregular" backups for the not so importants, plus review and clean up outdated, details-forgotten temporary copies created in emergency situations
if only the first part of the first sentence is true, than just simply do irregular backups, test them, and so on.
Don't forget the need for training techs in new software, hardware, and other technologies that have recently been adopted by your organization. It also helps to cross-train techs in the basics of every technology used by the corporation to incluide telephony, wireless, ITV, and video conferencing.
After you have tested, documented and made some audits i would recomend you Automate what ever you can! its time for taking these manual, daily repetitive tasks and automate them so when your business get out from the slow down, you will be ready to make it happened very fast and efficient - see what you can automate quickly and you and your company can benefit from it 5 IT process Automation Challenges and how to overcome them http://runbook-automation.com/5-it-process-automation-itpa-challenges-and-how-to-overcome-them/
When you have "cleaned up" your code, don't forget to begin the testing cycle from the beginning. Only God knows what new undocumented features your cleanup introduced.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle

































