LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Blogs > binary_pearl
User Name
Password

Notices


Rate this Entry

The art of training a new employee

Posted 07-21-2015 at 12:46 AM by binary_pearl

This blog is a rough draft of an idea that I just came up with, to explain how I go about training new Linux admins/engineers. My goal here is to help people who need to train new employees bring people up to speed as quickly as possible, without burning them out in the process. Think of the 'Price is Right' 'spinwheel' where the goal is to get as close to $1.00 without going over.

Over the last 5 years, I have now trained 6 Linux engineers / admins, whatever you want to call them. I was once told it was the best on-boarding training they ever had. That makes me feel good inside! But what is it about a 33 year old that can train older seasoned admins?

It's an understanding of the 'environment'. The 'environment' is a generic term, but it refers to things like:
"How many servers do you support?"
"What are the names of the servers you support?"
"What level of support do you provide for said servers?" (aka some servers will have full support, partial support...etc)
"Who uses which servers?" (aka Do these servers belong to DBA's, applications owners, both..etc).
"How does Application A interact with application B?"
"Who do you ask when you have a question about a particular issue?"

...the list goes on, but the overall point is something like this: "What questions will the trainee be asking when they are troubleshooting as issue?". Let's try to give them the answer before they are exposed to it.

But life gets more complicated, because people are complicated. And people learn things differently, at different paces. Some people will tune out of frustration. Sometimes it's language barrier. Sometimes it's because don't want to learn because the environment is too messed up in their views. Some people just can't handle it. Some people can take everything in and make suggestions on how to improve things on the fly.

So we are all over the place here, aren't we?

The trick is to figure out what makes sense to the person you are training. For me personally, it's colors and regular expressions, and this is my default method. I always have the the colors set in `vim`. And If someone else is driving at the console, I always ask them to ":syntax enable" and "set bg=dark or set bg=light" if color syntax highlighting is off. Why? Because I think in colors. It allows me to separate the different concepts. Ultimately we are breaking a larger problem into smaller problems, and using colors helps me visualize that.

OK, great, that helps me, but does it help you? Maybe, maybe not. Some people don't like colors, because they can't see that well. In this case then, what does the person need to understand the problem?

So let's get into documentation now. Clear documentation is key...for some people. I once worked with a person, and this person was frustrated that they couldn't understand what was going on. So I wrote a procedure, which was about 30+ steps. I decided to sit down with said person and go over the procedure. I don't think we got pass 5 steps before said person got frustrated and walked away. hmmm, that didn't work. Even though the procedure gave direct commands/steps, it was still too much to take in / understand.

In this case unfortunately, the person was not really qualified for the role. But the person was already hired, so it's not like they were going away anytime soon. So in this case I wrote scripts to automate some of these tasks. It wasn't perfect, but I reduced the process to about 5 steps, using menu options. That was much easier for said person to understand, and it made sure that the steps were being completed exactly as they needed to be done.

Now to do this automation, it required a lot of off-hour coding. Many times I ended up passed out drunk on the floor, drinking one more beer just to have a little more energy to get in one more line of code. Would I do this today? For the most part, no. It tore up a lot of my life. In this situation though, this person was the only help I had, and that wasn't going to change anytime soon (until I left the company and they ended up hiring 4 people to replace me).

So Lesson 1: Automation will help make complicated procedures easier to do, for yourself or others. But there is a price. Are you willing to pay that price? That's a question for you to ponder.
Posted in Uncategorized
Views 991 Comments 0
« Prev     Main     Next »
Total Comments 0

Comments

 

  



All times are GMT -5. The time now is 06:30 AM.

Main Menu
Advertisement
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration