Ask HN: I will have a 14-year old shadow me at work – any advice?

9 points by maest ↗ HN
Their parents are interested in having them get a sense of possible career paths.

I have never met the kid before. I honestly don't even know what this entails - I'm worried writing code is not a very fun spectator sport, so I probably won't walk him through whatever tedious piece of code I'm trying to write. I'm thinking I'll give him a quick overview of what the company does and then maybe just chat about programming with him.

I'm also considering giving him a very easy coding task in Python - not for work, just to keep him busy? - but it's difficult to gauge what's appropriate here.

Any suggestions or advice from people who have done something similar in the past?

21 comments

[ 3.2 ms ] story [ 62.3 ms ] thread
That's kind of insane. The most I'd think a 14 year old would be interested in is learning some browser related tricks (inspecting requests, elements, etc). On the technical side of things, unix utilities like ping / nano would be a good bet.

For day to day related work, just show how you decide what to work on? Maybe go through an instance of investigating a task?

IDK, I think this says more about your expectations than it does a 14 y/o nerd.

At 14-15 I could fluently program various flavours of Basic on various home computers, had also learnt Forth on the Jupiter Ace, had played with Lisp and understood the basics — and was totally fluent in 6502 assembly language. I could disassemble other folks code, and worked out how to hack games to give extra lives / disable collision / etc., had also learnt how to rip the music players from various games, and was messing about with- and making my own- demos/intros.

Sure, things are different today, but that doesn't mean a 14 y/o can't be bright, nor have any existing tech knowledge.

Inspecting browser stuff, and simple network utilities, are interesting and all that. But even for a 14 year old with minimal (or zero) tech knowledge, they're probably not going to hold their attention for more than a few hours, perhaps half a day if I'm being generous. And if the kid already has some tech chops, the things you outline can likely be covered in just an hour.

It's not that insane that a 14 year old comes into the workplace to learn / gain some work experience. In my late teens, as a professional games coder, we had someone about that age come to our company office for a week or so of work experience.

— Your later suggestions are much closer to the mark. Show the kid what happens normally, day to day, and talk it all through, whilst providing a reasonably sufficient amount of higher-level background knowledge, so they understand the context. The kid wants work experience, they want to learn about the actual job you have, that's what they've come for, not to be treated like you're trying to give them mere distractions.

True, I'm thinking of the average 14 year old who is well, average. Do you really think the average kid spends their time writing code?

Anyways, the part I'm considering insane is the parents, should have clarified. Career opportunities for a 14 year old, sheesh.

If the kid wants to learn programming, there are much better avenues then going to sit in an office. For example, they can make a game mod / Roblox game, etc.

> If the kid wants to learn programming, there are much better avenues then going to sit in an office. For example, they can make a game mod / Roblox game, etc.

Sure. But it's clearly not about learning programming... it's about work experience, and therefore, in part, about possible future career choices.

Nobody thinks sending their kid on a week of work experience is going to teach them much about programming. That's not the motivation here at all.

> For example, they can make a game mod / Roblox game, etc.

— How do you know the kid isn't already tinkering with that kind of thing already?

> Do you really think the average kid spends their time writing code?

No, not at all. I never said the 'average kid' writes code at 14. But some kids of that age certainly do. I did.

And who says this is an 'average kid' anyhow — they might not be at all, clearly they're somewhat of a nerd/geek kid, particularly if they're interested in spending their work experience week with a software development team / a software developer / tech company.

And even if they are the 'average kid', anyone can learn to code — arguably one has somewhat of an advantage if one starts at an early age.

> Career opportunities for a 14 year old, sheesh.

Here in the UK, it's pretty normal for school-age kids to do a week of work experience whilst at secondary school. It's usually organised by the school. Not everyone does it, but the option is there.

After all, kids leave school — and, if they don't choose to go to college, can go into work — at 16.

It's not about the kid going into work at 14. Far from it.

> the part I'm considering insane is the parents

With respect: I think our conversation here says more about your own beliefs, than it does about the parents, or the kid, or the purpose of work experience.

— You can read more about what work experience is actually about (it's not about learning programming) and how it works, at least in the UK (where I am — but it'll be similar in other countries too), here:

https://www.nidirect.gov.uk/articles/work-experience-your-ch...

Great, yeah I'm all for that :)
Giving him a task and putting him to the side might make him feel dismissed. I'd instead recommending using the time as an opportunity to practice teaching, and some basic pair programming. By all means, walk him through whatever tedious code you are writing. To you it is tedious, to him it is something completely new and exactly what he wants to see - what do you really do all day? If he hates it, he will choose another path, if he loves it, he'll follow up more on this path. Either way, the purpose is not for you to entertain, but to demonstrate.
I would focus on the “why” of the work more than the “how”. The details of your coding may not land, so be prepared to discuss the job and business more generally. Maybe they don’t end up coding. Help them understand how your role fits into the business as a whole. What do other people do that helps the business succeed.

Most of all, if they seem interested in anything you say, just ‘yes’ that and give them more even if it wasn’t your plan A.

You've never met the kid so I'd say talk to them first and assess what they know about software. It might be unlikely but if they turn out a prodigy coder show them everything you do and have time for, like Morpheus teaching Neo. If they barely know how to turn on a PC, then your idea sounds good.

Btw the parents sound like helicopter parents going by your first sentence alone, I wouldn't mind them if they think their kid has to consider careers at 14.

> Btw the parents sound like helicopter parents going by your first sentence alone, I wouldn't mind them if they think their kid has to consider careers at 14.

My middle school required career shadowing at the end of 8th grade.

I agree with the first paragraph.

I have conversations with my nieces and nephews about practically everything. Business, power dynamics, opportunity cost, risk, upside and downside, social interactions, reputation, local optima and global optima (if you could ever know them in real life), growth, compounding, mastery, competitive and comparative advantage, etc. I do that first without introducing the concept and by asking questions that lead them to extract the insight, then I'll put the term on that at the end with some references and the prior work on a topic.

I was putting some food in the microwave and my then 12 year old nephew was with me. We were in a short conversation about the price of things and he arrived at the concept of a loss leader. I mean he really understood it. Then I told him what it's called. I merely guided the conversation with questions that challenged his intuition, presented counter-examples to intuitive answers. He'd just "hmmm", then think about it for a few seconds, then upend his hypothesis. It was beautiful to watch.

I'd suggest helping him to see the 'whole' job. What do I mean by that? The best development (and developers) understand that they're not just writing code, but that code is the tool that they use to solve the real problem of the business.

That would mean spending a few minutes helping him to understand why you're writing the code you're writing and how it will impact the product or business.

Then, I'd walk him through your typical development process. Show him your ticketing system, how you identify user stories (if you're using agile) or features, how you groom those stories (e.g. things that make a story useful or not, the dialogues that you have with people to understand what you need to build), and the life cycle of a ticket.

Finally, (perhaps after a break), you could walk him through your development loop - Look at a ticket or feature, start exploring the code to see what you need to change, make an edit, run tests, commit your code, etc.

IMO, the important take away for him would be to see that development most often isn't a developer sitting at a desk typing at a computer all day. My experience has been that software development is an interactive experience with myself and other developers, myself and other teams, etc.

Not sure what kind of dev you do, but if you were so lucky to be working on front end, showing him how a change you make creates visible change on the screen that he sees as a user would be pretty powerful. Particularly if the thing you're working on is something that he could see after he leaves or that his friends might know about.

Give him a choice between the red pill and the blue pill. Put acid in both of them.
Got me in the first half
Be professional 100% of the time. Do not try to be their friend. Be a good, patient mentor.
Can you elaborate a little more? I'm interested why being a mentor (or professional) excludes being a friend.

I mean, we're talking about social interaction and that's always different. My 14 year old self would have needed a personal connection to feel good in a new environment.

If 'being a friend' means not doing work or something in this direction, then I completetly agree.

I think people are misunderstanding (or I am) the point of having someone “shadow” someone.

They basically follow you and see what you do. The entire point is you pretend they are not there.

> The entire point is you pretend they are not there

I disagree strongly with this.

Nearly everyone who shadows you will benefit more from the context of what you’re doing and why you work the way you do than they will from just watching you work in silence.

Having someone shadow you is the opportunity to talk passionately about your work and share information. You are putting on a show but people like a good show more than they like some sad sack sitting in silence or grousing.

As others have echoed, I'd suggest trying to talk to him and get a sense of his level of interest and knowledge. Many of us probably grew up trying to make QBasic games and trying to build our own computers in a much different era around that same age, so his level of interest in your real world coding tasks might surprise you.
Since the goal is discovery, I would have him shadow others colleagues too, so that he can discover more parts of the company. That would break the monotony, and increase the surface covered.

And of course first speak with him about what he is interested in.

Be careful what's in the other tabs -- you did already make sure anything NSFW is only logged in on your phone, which has notifications silenced on the lock screen in case your... partner or whatever... sends you a photo... right?

And yes, a short Python task is a good idea. Treat it like an interview -- get breakfast with him, tell him about the company, then let him try to program while you do email.

And otherwise, be very careful what you say, they will repeat it back to whoever they want, because they are minors and thus not subject to whatever weird NDAs you give them. (You'll probably want to write yourself a script.)