Working with Kids
June 12, 2009 3:12 PM Subscribe
I've been asked to look after two work experience kids (young teens) for the coming two weeks to experience and learn what I.T. is all about. What tasks can I give them that will educate and enlighten them while not killing my productivity?
I get one per week, so I can repeat tasks for the second one if need be, the important thing for me is they get something out of the experience.
I can't really let them play in the sandpit that is my usual day to day work, as it's mostly dealing with custom systems and touches a lot of confidential information.
Rock meet hard place.
I want to make that time spent as useful for them as possible, and would ideally focus on tasks that are fairly easy to set in motion, then backing off while they explore/complete that task. Then getting involved again at the end to review/problem solve.
So what tasks can you suggest I could give a total newcomer to I.T that helps demonstrate the work of a techy?
I've thought of:
- Reformatting/installing machines. (easy and time-consuming)
- Getting them to install a backup solution on the above, then ripping out the hard drive (as a hardware failure example) and asking them to recover the computer/certain files.
- Software support for the main office workers (word, excel etc) if they're savvy, but I think they're just in the 'hmm.. I.T. might be interesting' stage and we don't generally run into problems with Office.
- Teach them how to make a network cable.
- If I can find a few machines to format, get them to create a little test network, with file-sharing, cross backups etc.
- Create some posters/adverts for the stores (not really I.T...)
- Create a webpage (in Dreamweaver or something WYSIWYG) for some part of our company site, even if it's never published.
Let those ideas flow!
I get one per week, so I can repeat tasks for the second one if need be, the important thing for me is they get something out of the experience.
I can't really let them play in the sandpit that is my usual day to day work, as it's mostly dealing with custom systems and touches a lot of confidential information.
Rock meet hard place.
I want to make that time spent as useful for them as possible, and would ideally focus on tasks that are fairly easy to set in motion, then backing off while they explore/complete that task. Then getting involved again at the end to review/problem solve.
So what tasks can you suggest I could give a total newcomer to I.T that helps demonstrate the work of a techy?
I've thought of:
- Reformatting/installing machines. (easy and time-consuming)
- Getting them to install a backup solution on the above, then ripping out the hard drive (as a hardware failure example) and asking them to recover the computer/certain files.
- Software support for the main office workers (word, excel etc) if they're savvy, but I think they're just in the 'hmm.. I.T. might be interesting' stage and we don't generally run into problems with Office.
- Teach them how to make a network cable.
- If I can find a few machines to format, get them to create a little test network, with file-sharing, cross backups etc.
- Create some posters/adverts for the stores (not really I.T...)
- Create a webpage (in Dreamweaver or something WYSIWYG) for some part of our company site, even if it's never published.
Let those ideas flow!
What about giving them a defunct machine to rip apart and identify its components? Have them research and give a short presentation.
posted by mrmojoflying at 3:39 PM on June 12, 2009
posted by mrmojoflying at 3:39 PM on June 12, 2009
Making network cables was the first thing I thought, before reading your "more inside": it's something they're going to have to do until the ethernet standards get changed, so it'll be far more useful after they graduate than knowing the ins and outs of the current operating system. Have them make crossover cables, too, show them the difference so they have some understanding of why. The reformatting/installing and backup projects might be a bit much: if things go wrong, you'll be spending a lot of time figuring out where they messed up and how to fix it. Kids who say "I like computers" cover a very wide range, from ones who can already tear PCs apart and code in C, to kids who have a cool MySpace page and know little else.
I think the test network is a great idea, they'll like having the opportunity to mess with computers on their own, and it won't be a huge mess if they paint themselves into a corner; a kid who's interested in tinkering will enjoy being able to do (if windows) NET SEND, apply security to restrict logins, copy files back and forth, etc, and it is unlikely they've had two or more PCs to mess with at once without somebody getting mad ("Mom can't get her email now - what did you do?!?") -- depending on the operating system, there are simple webservers that they could set up and get an idea of how the web works, too. If you've got a bonepile of usable parts, make them assemble something from scratch, install an OS, and make it work - then go the next step, build two computers and make them talk to each other. If you have a closed-end result that you need them to accomplish, keep it very simple, like making network cables or organizing CDs, but expecting results of a backup, wipe, and restore may be a bit much. If it's more complex, make it more open-ended, so there's not an "I'm done, now what" moment, and if the results aren't reached at least the kid did something along the way to build on - if the kid spends all day just to get Windows installed, he's at least gotten past the assembling hardware step.
posted by AzraelBrown at 3:58 PM on June 12, 2009
I think the test network is a great idea, they'll like having the opportunity to mess with computers on their own, and it won't be a huge mess if they paint themselves into a corner; a kid who's interested in tinkering will enjoy being able to do (if windows) NET SEND, apply security to restrict logins, copy files back and forth, etc, and it is unlikely they've had two or more PCs to mess with at once without somebody getting mad ("Mom can't get her email now - what did you do?!?") -- depending on the operating system, there are simple webservers that they could set up and get an idea of how the web works, too. If you've got a bonepile of usable parts, make them assemble something from scratch, install an OS, and make it work - then go the next step, build two computers and make them talk to each other. If you have a closed-end result that you need them to accomplish, keep it very simple, like making network cables or organizing CDs, but expecting results of a backup, wipe, and restore may be a bit much. If it's more complex, make it more open-ended, so there's not an "I'm done, now what" moment, and if the results aren't reached at least the kid did something along the way to build on - if the kid spends all day just to get Windows installed, he's at least gotten past the assembling hardware step.
posted by AzraelBrown at 3:58 PM on June 12, 2009
Best answer: In schools IT essentially means 'anything to do with computers' it would really depend what they are interested in.
As an example I took IT in school because I was really interested in Web Design and scripting in general, while some other people took for the networking and engineering route.
As already mentioned the tasks you are able to give them really depend on the quality of the students.
Here are some of my ideas
- Basic Audit (would be a good introduction to the hardware / software)
- Some basic IP based exercises (ping, tracert, etc)
- Maybe updating an existing company webpage using basic HTML (basic HTML is really easy!)
- Perhaps lhandling non vital calls and logging accordingly
- Towards the end of the assignment it might be worth getting a friendly co-worker to place some fake support calls and getting the students to resolve them based on what they have learnt.
- Setting up email accounts
- Image manipulation for the webpage / print
- Set up some virtual machines with non windows operating systems
- Perhaps ask them to review windows 7 in comparison and get them to create mini report detailing the benefits and possible risks of upgrading
I think the most important thing is making sure you have enough deskspace for them (keep them together) and that the you notify rest of your team that they will be joining you.
posted by errspy at 4:10 PM on June 12, 2009
As an example I took IT in school because I was really interested in Web Design and scripting in general, while some other people took for the networking and engineering route.
As already mentioned the tasks you are able to give them really depend on the quality of the students.
Here are some of my ideas
- Basic Audit (would be a good introduction to the hardware / software)
- Some basic IP based exercises (ping, tracert, etc)
- Maybe updating an existing company webpage using basic HTML (basic HTML is really easy!)
- Perhaps lhandling non vital calls and logging accordingly
- Towards the end of the assignment it might be worth getting a friendly co-worker to place some fake support calls and getting the students to resolve them based on what they have learnt.
- Setting up email accounts
- Image manipulation for the webpage / print
- Set up some virtual machines with non windows operating systems
- Perhaps ask them to review windows 7 in comparison and get them to create mini report detailing the benefits and possible risks of upgrading
I think the most important thing is making sure you have enough deskspace for them (keep them together) and that the you notify rest of your team that they will be joining you.
posted by errspy at 4:10 PM on June 12, 2009
I teach this stuff to teens in HS. Most of them enjoy the hardware part. If you have any old machines for them to tear apart and troubleshoot, that would be fine for just a week. If these are absolute beginners it will be the quickest for them to understand without learning a bunch of new vocabulary and system info. So, your ideas about HD swaps, RAM upgrades, cables, etc are at the right level. If they are comfortable with the OS you could then have them take the computers they resurrected, the cables they made, and build a small workgroup LAN. Give them some experience that will give them a sense of mastery & control with basic home equipment & a consumer LAN.
posted by TDIpod at 4:15 PM on June 12, 2009
posted by TDIpod at 4:15 PM on June 12, 2009
First thing to do is figure out what they know and what they like. Some 14-year-olds think "computers" is Facebook and YouTube and that's about all they know. While others could get industry certifications without much work at all. On the other hand "IT" can be just about anything too.
I think one of the strong points of a good IT person is not knowing how to do something, but being able to find solutions. Give them a problem and see if they can find the solution. Give them some resources and pointers in the right direction and help them troubleshoot, but don't handhold. Ask them questions and let them find the answers.
If you don't have two old, nearly dead computers lying around, find 'em. Freecycle, whatever. Shouldn't be hard. Do a drive wipe on one and take the other apart. Their project for the week is to get an operating system going on the first one, assemble the second one, build and connect them with a crossover cable and send messages between them.
But they may not be into hardware at all. In that case try stuff like having them try to recover deleted files, disable a USB port and have them troubleshoot why the mouse isn't working. Mess with the network settings and have them troubleshoot. System images, software upgrades. If you're daring, pull the network card out of the old crappy computer, inflict some malware on it, and have them diagnose and clean it.
And they can get you coffee, doughnuts, and clean keyboards and mice, and do inventory.
posted by Ookseer at 4:40 PM on June 12, 2009
I think one of the strong points of a good IT person is not knowing how to do something, but being able to find solutions. Give them a problem and see if they can find the solution. Give them some resources and pointers in the right direction and help them troubleshoot, but don't handhold. Ask them questions and let them find the answers.
If you don't have two old, nearly dead computers lying around, find 'em. Freecycle, whatever. Shouldn't be hard. Do a drive wipe on one and take the other apart. Their project for the week is to get an operating system going on the first one, assemble the second one, build and connect them with a crossover cable and send messages between them.
But they may not be into hardware at all. In that case try stuff like having them try to recover deleted files, disable a USB port and have them troubleshoot why the mouse isn't working. Mess with the network settings and have them troubleshoot. System images, software upgrades. If you're daring, pull the network card out of the old crappy computer, inflict some malware on it, and have them diagnose and clean it.
And they can get you coffee, doughnuts, and clean keyboards and mice, and do inventory.
posted by Ookseer at 4:40 PM on June 12, 2009
Last summer we had two of our interns (one high school, one starting college) do a "Green Study." We had them install and create a wiki dedicated to documenting our current processes and to propose ways of making them more environmentally friendly. They also setup pages that grabbed rss feeds from other green-themed sites, and a couple of other functions using Google Maps, etc. Lessons they learned:
- Setting up and configuring a Wiki
- Integrating other tech (RSS, other APIs, etc.)
- Introduction to business process and workflow analysis, while using IT to address the situation.
In return, we have a site that people here actually use (Google map showing recycling locations and hours) and we have a place where our green initiatives are documented. Not bad for 3 weeks of cheap labor. Of course, it really depends on the initiative these kids have. We routinely throw our interns and new hires into the fire, but it's no big deal if it's an internal project that the long timers don't have time for anyway.
posted by krippledkonscious at 5:27 PM on June 12, 2009
- Setting up and configuring a Wiki
- Integrating other tech (RSS, other APIs, etc.)
- Introduction to business process and workflow analysis, while using IT to address the situation.
In return, we have a site that people here actually use (Google map showing recycling locations and hours) and we have a place where our green initiatives are documented. Not bad for 3 weeks of cheap labor. Of course, it really depends on the initiative these kids have. We routinely throw our interns and new hires into the fire, but it's no big deal if it's an internal project that the long timers don't have time for anyway.
posted by krippledkonscious at 5:27 PM on June 12, 2009
I think one of the strong points of a good IT person is not knowing how to do something, but being able to find solutions. Give them a problem and see if they can find the solution. Give them some resources and pointers in the right direction and help them troubleshoot, but don't handhold. Ask them questions and let them find the answers.
This.
Regardless of what the task is, don't tell them or teach them how to do it. When they come to you for help, suggest search terms that might be helpful.
But, make clear this is a game, that failure is always an option. It turns what could be insanely stressful (being put on the spot to do something you don't understand) into a big, fun puzzle. Either that, or they really aren't cut out for IT.
My podmates and I were in charge of an intern once. Aside from having him run to the store for more Jolt, we also had him do all manner of tedious shit that nobody else wanted: renaming batches of files, editing out formatting marks in fubar'd files, properly indenting and formatting our (notoriously messy) codebase. He could program a little bit, too, so we had him read code (enormously helpful to learning to code) and write javadocs for the functions. Since the comments explained what the code did, and not why it did it, they were pretty useless to us. But he certainly got a feel for a commercial codebase.
posted by Netzapper at 5:28 PM on June 12, 2009
This.
Regardless of what the task is, don't tell them or teach them how to do it. When they come to you for help, suggest search terms that might be helpful.
But, make clear this is a game, that failure is always an option. It turns what could be insanely stressful (being put on the spot to do something you don't understand) into a big, fun puzzle. Either that, or they really aren't cut out for IT.
My podmates and I were in charge of an intern once. Aside from having him run to the store for more Jolt, we also had him do all manner of tedious shit that nobody else wanted: renaming batches of files, editing out formatting marks in fubar'd files, properly indenting and formatting our (notoriously messy) codebase. He could program a little bit, too, so we had him read code (enormously helpful to learning to code) and write javadocs for the functions. Since the comments explained what the code did, and not why it did it, they were pretty useless to us. But he certainly got a feel for a commercial codebase.
posted by Netzapper at 5:28 PM on June 12, 2009
This thread is closed to new comments.
posted by mmascolino at 3:15 PM on June 12, 2009