Slashdot Mirror
How Do You Explain Software Development To 2nd Graders?
First time accepted submitter zimania writes "At the start of every school year, my kids' teachers invariably ask if any parents have any special skills they can present to the students. As a software engineer, I'd like to give a presentation to the classes about developing software. The tricky part is making a presentation fun, inspirational, and easy enough for 2nd and 4th graders to grasp. Has anybody been brave enough to attempted such a thing? Are there kid-tested prepackaged presentations freely available? Would it be best to present the development of a simple game? Web page? Any advice is welcome."
Have them stand together and execute a "program" as if each of them are "utilities". Something like getting an apple onto the teachers table, but each person does one thing and one thing alone. Then let them have fun seeing what they can figure out to do - so long as they still only do that one thing. This isn't about "code" it's about a way of thinking!
CS majors know the time/space tradeoff, but they never get taught the 3rd, crucial, tradeoff of the set: comprehension!
Use abstract language and flow charts to explain, for instance here is pseudocode for a function called doSoftwareEngineering:
function softwareEngineering outputs betterBonusForBoss and meagerSalary
do until tooOldToEmploy
change jobs
do until bossFiresYouForBonus
do TPSRepeatsReportsUntilYouWantToCry
repeat
repeat
repeat
gosub without return
Monstar L
One of the most engaging presentations I've seen on this was the making of a peanut butter and jelly sandwich where the students write out the instructions and you execute them -- very literally, as a computer would do -- illustrating the attention to detail and error checking required for programming.
I recall seeing the knife go through the lids for the peanut butter and jelly jars, the jars being placed directly on slices of bread, peanut butter being spread on the bread wrapper, etc.
This would be something to incorporate into a larger talk, probably at the end (to keep their attention going).
A projector, and Scratch?
http://scratch.mit.edu/
Mindstorms could also make sense?
To explain a programming I would demostrate how changes to a simple piece of code changes something that you can see, like an animation (scratch) or a robot's behavior (mindstorms).
.: Max Romantschuk
http://www.briggs.net.nz/log/writing/snake-wrangling-for-kids/
What do prostitutes and programmers have in common? They both have trouble explaining their jobs to 2nd graders!
I rarely respond to comments. Also, don't ask for clarifications: a brain and Google are faster, believe me!
This information is available on wikipedia.
Is it more effort for 10,000 non-US-based geeks to look up Wikipedia, or 1 US-based OP to mention an internationally recognisable age in his question...?
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
This might be true if your first introduction to code was your first day at uni.
Many software engineers started out as kids coding their own games and learning stuff on their own.
The software development doesn't stop with your job.
I always have several projects on the go at home. These days they're mostly geared towards earning a second income, and some have been successful.
But to see my life as a software engineer as purely what I do for my employment - that would make me cry.
My job just pays the bills - yes I write code for a living and I do enjoy my job (as much as that is even possible), but none of it compares to the stuff I tinker with in my own time. Software engineering is a way of life, not just something you do for a job.
This seemed like a reasonable sig at the time.
Yep, that's the trick part, way I see it. He asked about software development, not programming. Programming what you want, especially in a game, is fun. Software development, on the other hand has lower average job satisfaction than being a garbage man, according to a survey from a couple of years ago.
Mind you, it might still be able to explain it via an exercise, but I don't think anyone has the heart to do that to some innocent little kids. I mean, it would probably go like this:
"Hi, kids, my name is Moraelin and I'm here to show you how software development goes. I must thank Mrs Crabapple for letting us come to the park for this exercise. We'll be making this a role-playing exercise, so it's easy to understand. I brought a few friends to help with some key roles. Say hi to Tom, Dick, Harry, Jack and Jill.
"Now the first thing to remember is that we're not in this for the fun. You'll get a grade for this, so try to do your best.
"The most important skill in my profession is to sit in meetings and look interested. It may not be the greatest percentage of the day, unless you really draw the short straw, but you'd be surprised how much more important making a good impression to the boss is than actual work...
"You over there? Yes, you in the blue sweater. What's your name? Well, Billy, you get a minus one point on the grade for fidgeting instead of paying attention. Yes, I know it's boring, but that's the whole point I'm trying to convey. Let this be your first lesson in real world employment.
"Well, anyway, for the purpose of this exercise, you'll be divided into teams and have to draw something on the pavement with chalk. As a team. Remember, what matters is the whole result, not just your own personal performance.
"Now to make things more educational, I brought a second class to pad the teams with. The assignments will be big enough to include them, but they've all been assigned some secret roles to play. Most... let's just say it sounds like 'mazy loron', but occasionally you'll get the guy who just tells you how to do your job instead of his own doing his, the guy who keeps adding pointless "THIS IS A FLOWER" comments to your work instead of doing his own part, the guy who keeps trying to tell you about his vacation instead of letting you work, and so on. Some may even be naturally inclined to go beyond even the assigned role in their being useless and counter-productive.
"I probably don't need to tell you that you're not supposed to beat them up even if they 'accidentally' erase your part of the work. In fact, you're not even allowed to complain about them. Doing so will get you a bad grade for being a bad team member.
"You have a question? Oh, WHAT you'll have to draw? I don't know myself either. Tom and Dick will role-play the customer. You'll have to make them tell you what they want drawn.
"Now they'll be as vague and occasionally wrong as humanly possible, and occasionally obnoxious, but you must extract exact information from them. You don't get points by just doing close enough. If they say they want a flower, you must get out of them exactly what flower and what colour. If they say they want a boat, you must find out exactly what kind of boat. And if they say they want a cow, well, better make sure they don't ACTUALLY mean the kind that meows and catches mice.
"They'll also change their mind or demand changes at random times, and at the end will blame you for not guessing they actually wanted something different. You'll also have to change it to that, and repeat about a dozen times.
"Harry will play the Pointy Haired Boss in his exercise. He'll give you extra directives, like only using blue and yellow chalk because of trying to consolidate into fewer technologies, or drawing with the chalk on paper because he read that that's the latest buzzword. For your grade, you'll have to figure out a way to satisfy both him and your customer. If you end up trying to mix
A polar bear is a cartesian bear after a coordinate transform.