RE: Discussion: "The Server IS the Documentation" (OR Standa…

Top Page
Attachments:
Message as email
+ (text/plain)
+ (text/html)
+ (text/plain)
Delete this message
Reply to this message
Author: Paul Mooring
Date:  
To: Main PLUG discussion list
Subject: RE: Discussion: "The Server IS the Documentation" (OR Standard Process [Obnosis] verses Useless Arrogance [Experience/Training])
I'm curious what sort of background you have in doing IT work. My experience (however limited that may be) has been mostly the opposite. I've seen lots of smart people with backgrounds in anything but IT or fresh out of school that just can't hack it. They think if the code works and the servers running then they're doing a top notch job. Then someone else joins the team code/config isn't in version control, servers are special snowflakes that would take days if not weeks to re-build, no DR plan, they don't know how to watch/plan for growth, ect.

This isn't to say that I or anyone else who's been doing this for years is smarter or better, just that it's 90% experience in this field. Your code sucks until you write a lot of it (so did mine), your network is a fragile house of cards until you learn from mistakes (so was mine). Then you spend some time learning how to do things right, you get better and you help people new to the job learn just like you did before.

Also since I missed the beginning of the thread, as much as I'm an advocate of the code is the documentation (I hit our Chef repo before the docs) if you think a running server and it's raw config is all the documentation you need your infrastructure is either trivially simple or you're going to regret that viewpoint later.


Paul Mooring
Systems Engineer - Customer Advocate
www.opscode.com

________________________________
From: on behalf of Gilbert T. Gutierrez, Jr.
Sent: Friday, May 17, 2013 2:00 PM
To: Main PLUG discussion list
Subject: Re: Discussion: "The Server IS the Documentation" (OR Standard Process [Obnosis] verses Useless Arrogance [Experience/Training])

I will add my 2 cents ...

I read all the posts. Experience on a specific system will allow a person to respond quickly but will not allow them to specifically solve a problem, especially if they are not as educated on a system as they think they are. If the Server is the documentation, you are riding by the seat of your pants and it will catch upto you. In addition, a business is more nimble and can accomplish more if there is redundancy in the understanding of systems in place. You must have a well documented system/process that a competent person can follow and update.

I will now move my comments a little more off topic ...

Now answering this as an employer hiring staff, experience counts for me; but I put more weight in an employee's education, ability to be agile, solve problems, communicate clearly, and work with others. I expect to train new staff from the bottom up on a system/process.

Now we are off topic and maybe offending ...

Some may disagree with me or feel I maybe belittling their career, but most jobs in IT, in my opinion, can be done by almost anyone if they are in the right mindset and given proper training. IT is not magic.

Gilbert T. Gutierrez, Jr.
Phoenix Internet


On 5/16/2013 9:03 PM, Lisa Kachold wrote:
Across the board, the number 1 worst attribute that I see working with the PLUG, technology teams, and mentoring (at or around year 3 in academics, and year 3 - 10 in IT/linux professionalism) = arrogance.

What exactly is arrogance anyway. Where is this found? Why?

It's the place in the discussion where one person dominates assuming that their position or knowledge is greater (without investigation). This is also referred to as "OneUpManShip".
It's the place in the presentation where students and PLUG peers write off the person who has taken on the role to "present on the subject" based on their ability to verbally spiel acronyms. This is referred to "Minimizing".
It's the place in the team dissemination of project roles and tasks where a member's enthusiasm is downplayed based on experience. This is referred to "Dues Hierarchy".
This is the place in the interview where the employer fails to realize all they need to do is very the work history, since everything for a Linux professional is motivated by and driven from an ethical systems administrator viewpoint (not any communications with or responsibilities disseminated from the employer); just as we are woken from sleep to work on or check systems; and jazzed beyond belief by a well engineered hardware server like IBM Blade (can you say Fiber channel switched backplane?)...

There are a great many examples where an ego based emotional assumption of or judgement is placed on our peers, our work, and even ourselves at one point or another.

The ability to understand linux systems requires a certain type of systemic theory; which can be daunting for some people; such systems integration can be hard to troubleshoot [and successfully negotiate within] without inherent abilities but can be done with a great deal of complex experience, however this is NOT ROCKET SCIENCE. So the people who do well at what we do, are usually those that find that they inherently find this easy.

It is, however, far from easy, since most of us work long hours, without adequate physical exercise and balanced stress free environments. The sheer amount of responsibility and ultimate reliance in all shops on the unique abilities of the Unix/Linux systems administrator are daunting to most once they get a full view.

However, we each learn standard process applied across the OSI stack and/or fed through the kernel/memory/processor for systems or DevOps applications performance and integration, security or troubleshooting.

Standard process, which includes a few easy to learn rules, relies on logs and linux tools, completely supplants any experience, past systems history knowledge (available on/in the server), most visio documentation or RunBooks (which should not exist unless something cannot be known by server view alone).

Ironically, to people who are not linux-ish, the statement that "The Server IS the documentation" seems incredibly arrogant, when in fact, it simplifies all the arrogant posturing and 7 deadly sin based profit from the misunderstanding of unix/linux administration and engineering.

We all intimately understand the concept of "obnosis" or Knowledge by Observation - rather than what is imparted via formal rote learning and scholastic pursuit.

What do you think? Is the adage "There is NO substitute for experience" correct or can anyone using standard process (as opposed to documented process) and NIX command line skills (yet bringing no experience) get to the finish line at the same time?

http://wiki.obnosis.com <http://wiki.obnosis.com>
--

(503) 754-4452 Android
(623) 239-3392 Skype
(623) 688-3392 Google Voice
**
it-clowns.com<http://it-clowns.com/c/index.php>
Chief Clown


---------------------------------------------------
PLUG-discuss mailing list -
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss