 |
www.conserver.com |
|
|
www.conserver.com |
Basically, because I can. And because I have learned many of the things that I have learned, because others have taken the time to share their knowledge with me. In a way, I view making these pages as a way to pay them back (or "pay it forward") for the time and knowledge that others have given to me. But, I can list a few other reasons that have motivated me to post this information for everyone to see.
Because I've done this for a while. I began to dabble in serial communications before I bought my first HAYES 300 SmartModem (then new). I've had roles involving R&D with serial ports (UARTs and etc.), and because of that background, I always seemed to inherit the serial/modem-related problems where I worked. "Give it to Zonker, he's the [serial|modem] guy in the group." Since I did most of the problem solving, I gained more experience, and others did not...so the problems kept coming to me.
Because I don't want to be the only one who knows. I was once told by a mentor "If you are the only one who knows how to do a job, you probably won't get promoted, since your boss will still need you to do the old job...and if you DO get promoted, you'll still have to do the old job as well.". This was the first push I received about documenting what I did at work. If I don't want to be the only Serial Guy in my shop, I better have documentation to share with my peers.
I learned that documenting something was more than just taking notes on a topic. These notes needed to be informative, and instructional enough that someone else could use them to do the job without me. Documentation must be able to stand alone, without relying on information in my head. Sharing these documents with others, answering their questions, and using those answers to improve the documentation helps me learn as well.
Because I'm "professionally lazy". By my estimate (based on experience), the time it takes to make documents and share them will be almost equal to the time used to copy and share your notes with that same information with more than two people (including the time to explain and clarify the notes). That is, the time you will spend answering questions and clarifying details to 3 people will be more than the time it would take to make a piece of documentation and give it to them each for peer review. My feeling is, if I'm likely to have to share information with more than a few poeple, over the lifetime of the information/document (which may be years...), then it's worth my time to create a document. And, if I create a good document (and use questions and feedback to improve the document), I reduce the amount of extra time needed to make others more productive.
Once you've shared a document with more than 3 folks, any other time you can just pass that document to someone who can benefit from the information, that is just "time saved", in my humble opinion. (There is also the goodwill to be gained by sharing knowledge with others...bosses also notice, and often appreciate this as well, so there can be secondary future benefits, too.)
Because I'm interested in NEW puzzles and problems. Once I've solved one problem enough times, and I see there is a simple answer for most of the cases, it's time to document the process or the solution(s). This way, I reduce the number of times that this problem comes to me in the future, (since folks can find my pages with a web search), and if/when that problem does come to me, I can minimize the time needed to educate the person with the problem by pointing them to a URL, versus typing up a complicated answer. This ties back to the Professionally Lazy item above...
I understand that Cisco TAC refers customers, and some employees, to my Cisco pages for information. (I'm glad I can help.) I normally receive at least 1 request/question from outside the US every 1-2 weeks, plus 2-5 questions from US folks each week. I've even had a friend wind up working in Taiwan, who had trouble with the serial console on an IBM computer, and in his web searching for answers, he found my name and web pages. If he hadn't found the pages, he wouldn't have thought to call me, due to the timezone difference. (Since he found the pages, he also didn't have to wait for me to check email, if he had thought to write to me instead.)
Because problems still come to me. Due to these pages, and my willingness to give answers, I've become well-known in the Sysadmin and Netadmin communities, and so people with unusual questions come to me (usually via email) to see if I can shed some light. As a result, I offer what I know, adding what I can from experience. In return, I usually hear back with the resolution was, and I learn from the exchange as well. I enjoy this!
I've also been a consultant, and an employee, with large corporate networks, and I've been involved in design and architecture roles. To this end, I've needed to research various hardware (terminal and console servers, serial multi-port adapters, etc.) as well as exploring software limitations. My employers, and people who were paying for my time and opinions, deserve to get good information, so I do my homework, in an effort to ensure that my opinion is worth what they are paying for it.
I also receive questions from console server equipment makers, because I'm also reviewing Console Server hardware, usually under NDAs, and providing feedback to these manufacturers. At least a few of these companies have found that this reveiw process has yeilded useful information, and this has affected new product development in a couple of cases.
Being part of the Conserver community involves helping other folks get their installations running. Sometimes it's a bug in the code. But more often it's a configuration option on a console server, and sometimes it's a bug in a console server firmware. When folks post their questions to the Conserver Users mailing list, I'll offer what I think might be the cause, or at least offer something the user can check. Again, in the sharing of information, the resolution is often posted as well, and we all learn from each other.
I've also have the good fortune to work with some very large Conserver deployments (some sites with more than 2300 serial consoles online, and more than 90 console servers in multi-site, distributed mode deployments). The demands of large, international enterprise networks, "production" for-pay networks, and BioTechs have helped me understand some of the special needs of those customers.
As a member of many professional organizations (USENIX, SAGE, SCTE and others), I've been motivated to develop some console/conserver tutorials for those technical communities, such as the tutorials that I've presented at the USENIX LISA technical conferences in 2000 and 2002. Because async serial ports are likely to be used for administrative control for many years to come, I'll probably put together more presentations in the coming years.
|
NOTICE: Most of the pages, articles, and tutorials on this website are copyrighted works. You may make 'deep links' to various pages. (If you let me know which page(s) you are linking to, I'll let you know if I move the page(s) during updates.) Please send me email if you wish to republish any material, or use it on your own website. |
