What is the best way to approach a job shadow when you are the one being shadowed?

Question

I was talking with an acquaintance about his son's plans post-high school and he indicated that his son might be interested in the sort of work I do -- software development. I offered to have him come job shadow me for a day, but it occurs to me that some days might be better than others due to the number of meetings. I'm thinking that meetings would be pretty boring to a high schooler (since they frequently are for me too).

If I were to plan a day as a job shadow to give a realistic, but compelling view of the work of software development:

• What sorts of activities should I plan?

• How much time should I build in just for questions and how much time would you actually devote to the job shadow -- whole day, half day?

• Any other ideas you'd like to share?

• Have you ever had a person shadow you and how did it go?

Answer 1

Brainstorming sessions are almost always fun for me. And maybe he'll have a contribution to the discussion, too.

I've had folks shadow me on sysadmining, which isn't always interesting (to the observer) - but asking them for ideas, or showing-off some cool thing you made brings them into the day.

Also, find out if your friend's son could shadow you for an entire week - more opportunity to see how work works.

Answer 2

I would say a whole day, but plan it with your bosses and co-workers so you might have a meeting, do development, testing, etc. Try to schedule out a day so you do a good number of your routine tasks in the same day, giving him a good idea of the tasks you do. Although it might hurt your productivity slightly, I would say it might be worth it for a single day.

Answer 3

Don't drown them in details.

Sit down with them at the beginning of the day, and give a high-level overview of what's going on that day. Make sure they feel OK asking questions, and encourage them to write down anything that's confusing.

At the end of the day, have a short Q&A based on the day's events.

In a gentle way, let them know what you're doing before you do it. For example:

We're going to have a meeting that will determine what SMS vendor we're going to sign up with. We'll balance pricing, features, and ROI.

or:

Several of our sites have just gone down, and I'm going to troubleshoot our redundant server array to see if any flags were raised earlier today.

Act as if you're informing a superior that doesn't have time for all the piddling details. Then during the Q&A, feel free to get granular.

Answer 4

Before anything else, I'd make sure your boss and co-workers know about the day ahead of time.

Meetings are definitely going to be boring, but you should make sure they at least know what kinds of meetings they might need to be involved in if they pursue software development. If they like to code, but can't stand the meetings, they're not going to want to pursue the field (instead, they might enjoy a job where they'd the flexibility to write their own small tools to improve their efficiency in a non-software field).

I'd say try to get in a full cycle for a bug and an enhancement in if you can, so they can see what can be involved in testing, development, debugging, researching alternatives, determining requirements... every task you might be able to give them a glimpse into. Encourage them to ask questions, and give them the opportunity to try things out on their own. What they try out doesn't need to be something complicated, or even related to what you actually need to do - it could be a simple hello-world type app. Try to make it something that fits their skill level.

When it's all over, make sure they've got your e-mail so they can ask more questions if they think of anything later.

Answer 5

As with the others I would say keep it high level, but really don't try to plan around it too much. Avoiding meetings personally I think is a BAD thing. Meetings are a way of life in the software development field, and honestly proper handling of yourself in a meeting is a key piece to being a good developer. So I think exposure to some form of metting might be a good thing.

A general overview at the start of the day is good, especially if they are not familiar with the software products/services you work with and create, but really show them what you do, and create an environment that is open for questions. Be sure to ask for any questions at the end of the day.

Answer 6

are you trying to encourage or discourage him from being a programmer? or give a realistic picture?

if you're trying to encourage:

• have him shadow you when you do a roll-out to the users so he can see that what you do benefits people
• have him help you solve a difficult problem, so he can get the warm fuzzy feeling that comes with success

if you're trying to discourage:

• have him watch you sit in silence for 10 hours straight trying to debug a tricky memory leak in an obscure piece of code
• have him sit through all-day meetings with vendors

if you're trying to be realistic:

• all of the above!