Encouraging the Next Generation

Recently, some of the people where I work have started a weekly writing prompt in order to get people to blog more often. This week's topic is “How do we involve the next generation of young minds?” and was inspired by two of my co-workers building quadcopters with a group of students in the northern part of the state.

This is a very open topic and very difficult to cover in a way that is less wordy than a copy or War and Peace (or at least your average work by Stephen King). However, I think it can be approached by breaking it down into a number of subjects which need to be addressed.

That being said, let's begin.

Start Them Early

The truth is that the earlier you start to instill curiosity and creativity in people, the easier it is to get them to continue on that path. There are a number of ways to do this, but if you're looking for ways to get a small child started, Legos, Lincoln Logs, Tinker Toys, etc are really a wonderful way to get the ball rolling. They offer nearly endless ways to combine pieces creatively, are tactile (which helps a lot of people, children or not. Never underestimate the value of physically building and handling something), and are generally fairly affordable.

Realize that not everything has to involve circuitry and code. Even things like basic woodworking projects can help instill creativity and the engineering mindset. I've built everything from birdhouses and toolboxes to actual buildings while I was growing up and I learned something valuable from every project.

As they get a little older, introduce them to things like crystal radio kits, 130-in-1 experiments kits (yes, they still make those), snap circuits and even simple programming languages like Scratch and Logo. A little later still get them involved in writing code on something like a RaspberryPi (it's fairly inexpensive and if you somehow manage to botch the os, just re-flash the SD card and start over. You can even extend it in order to interact with hardware). Tangoes are also a wonderful, inexpensive tool for teaching spatially related problem solving.

You want things that are simple to get a beginner's grasp of yet versatile enough to keep their attention after they master the basics and, most importantly, make them want to learn even more.

Mindset

“A mind all logic is like a knife all blade. It makes the hand bleed that uses it.”

- Rabindranath Tagore

Logic is a very important part of being successful in technology fields. However, there is another part of the equation that is often overlooked – creativity. You really do need both the ability to think your way through a problem as well as the ability to look at a problem from a completely different angle than other people at times.

We need to foster not only logical thought, but also appreciation of and involvement in the arts. I would almost argue that the type of art doesn't matter nearly as much as being involved. Painting, drawing, writing, music, theater, and countless others – all of these things exercise your brain in ways that simple logic based problem solving doesn't.

On the logical side, we need to encourage the next generation of technical people to cultivate the skills to look at situations objectively, come up with a set of possible answers, and then evaluate or work through them (revising their general assumptions as they uncover more information) until they reach a conclusion. This is the time for measured experimentation instead of just wildly poking at a problem until something happens (though, admittedly, sometimes poking at the problem is necessary in order to uncover behavior).

Encourage the next generation to ask questions. That's not to say that you should spoon feed them the answers since guiding them through the discovery process is both an extremely effective way of teaching and often fun for everyone involved. However you do it, you should encourage them to ask the “whys” and “what ifs”.

Continuing in the vein of asking questions, foster the questioning of authority. If someone says “You can't do that” they should ask WHY. If it's because doing that thing is dangerous, that's one thing. If it's just because they don't think it can be done or because of other foolish reasons (“getting above your station”, “that's not something that proper girls/boys do”, etc), they should be encouraged to CHALLENGE IT.

We are, among other things, professional troublemakers. We create and change current reality as a part of our jobs. It's what we do. Innovation is inherently disruptive. Embrace that; don't try to stomp it out of the next generation.

Encourage reading. I can't stress this enough. Fiction, non fiction, philosophy – just read. It exposes you to different voices and approaches from your own. It's literally a different view on the world, and being exposed to that will help you grow.

Quick Feedback, Small Victories

Make initial victories easy to attain. This is especially true for younger children. Defeat is frequently demoralizing. Starting off with a victory encourages people to continue. It doesn't matter if it's just making a ball bounce on the screen. Give them something that provides near instant feedback that they have done something with a real, visible result.

As they progress, keep feedback loops tight even though the difficulty of what they are doing increases with time. Yes, I realize that this sounds a lot like Agile practices.

Make it Safe to Fail

“I have not failed. I've just found 10,000 ways that won't work.”

- Thomas A. Edison

Failure, both professionally and personally, is an occasional fact of life. No matter what we try or how hard we work, there are times when things just won't happen the way we want them to.

The problem is that we have stigmatized failure to such a degree in this society that some people are afraid to even try because they might fail. This needs to stop.

Teach people that it's okay to fail on occasion. That's not to say that we should excuse laziness, but re-enforce the idea that failure occasionally happens, treat it as a learning experience, and teach others not to fear making a mistake.

Access to Tools

It may not occur to a lot of us in this field that not everyone is as well off as we are from an economic standpoint. Not everyone has ready access to the equipment needed to learn various technical skills. This is especially true in both poorer urban and rural areas.

Access to programing tools (IDEs, etc) has become considerably cheaper thanks to open source tools and educational/community licenses offered by companies like JetBrains and Microsoft. However, for some people, computers are still an expense that they can't justify (even if they are much cheaper than when I started learning to program).

That's not to mention the expense of things like quadcopter kits. Some of the things that you need access to for some projects are simply out of reach for a number of individuals as well as some school districts without outside help.

Access to Mentors

When I started out, I didn't have any mentors to help me learn how to code. The internet wasn't an option (yes, dinosaurs roamed the Earth and we had to walk to school uphill both ways). I had never even met or spoken to a professional software developer until I was in college. In fact, the only other people I knew who wrote code were a few friends in basically the same situation as myself.

It would have been much easier and a lot less discouraging if I had had access to mentors (even online) instead of having my only resources when I started out be the manual for a TRS-80 color computer and the occasional code sample in magazines borrowed from our very small public library (I told you that dinosaurs roamed the Earth at the time).

If you want to encourage the growth of a new generation of creative and technical people, you have to literally be there to encourage and guide them. Answer questions on the internet, make yourself available to schools/after school clubs and programs, and generally be a good community member.

Parental Involvement

This is the really difficult one. In order to encourage young people to go into technology based careers, their parents have to be positively involved. They can't just treat the computer as a way to babysit their child or, possibly even worse, view everything that their child does, no matter what it is, as simply “playing on the computer” like my parents did (which, I might add, included programming homework in college).

Keeping up momentum when it feels like nobody cares or you are being actively discouraged is extremely difficult. Not everyone is as hard headed as I am.

Parents don't even have to be experts in the field. They just have to be positive influences. Be curious about what your child is doing, encourage them, have them show off what they're doing to you a bit. Be a cheerleader. It's important.

Show Me The Money

Show people that there is a (generally) fun, well paying job doing work in this field and that it doesn't matter if they're a girl or a boy or even what socio-economic background they come from as long as they work at it. After all, it's important to be able to do things like pay your bills, go on vacation, and buy sandwiches.

As I said, this is by no means an easy problem, and this is only the short list of things that can be done to help, but it's a start and even if you can only manage a few of them that's better than the alternative.

Current mood: calm

Current music: Murray Head – One Night in Bangkok

Presentations and Public Speaking.

October’s Central Ohio .NET Developers’ Group meeting was a series of “lightning talks” (15 minute presentations) instead of a single 90-120 minute presentation.

It was an interesting change of pace and, on the whole, went pretty smoothly. Granted, there were a few small hitches with changing between 6 laptops and speakers, but that’s to be expected and the problems were really incredibly minor.

I mentioned the meeting a couple of posts ago, so that’s all I’m really going to say about the meeting itself. The reason I’m doing this particular post is because of the presenter that I mentioned wanting to give some additional feedback to.

Unfortunately, I didn’t get a chance to talk with him directly. However, I started thinking that this topic might be important enough to generalize and make a blog post out of because so many of us have problems with public speaking and giving presentations.

As always, please keep in mind the words of Baz Luhrmann: “The long term benefits of sunscreen have been proved by scientists, whereas the rest of my advice has no basis more reliable than my own meandering experience.

“I will dispense this advice now.”


First off, relax.

I know that’s easier said than done. Public speaking makes a lot, perhaps even most, of us nervous (myself included even though I’ve had to do it before).

There’s not a whole lot that’s more nerve wracking than being the only person at the front of a crowd and knowing that everyone is looking at *you*. It doesn’t matter if it’s a presentation to the directors of your org, a political campaign, or a talk that you’re giving to a group of your peers. It’s always stressful.

Just remember that we’re not going to bite. Especially if it’s a users’ group or some other set of your peers that you’re speaking to. After all, we came there to listen to you, so why would we want to waste your time and ours by sitting there and heckling you (though we may occasionally joke along with you)?

For my part, I’ve done drama, had to represent the magazine I worked for at a conference (both the day of with the crowd and the night before at the dinner for the presenters) and have had to give more presentations for organization directors and management than I care to think about. Thankfully, I haven’t had to deal with being in a political campaign, but I’ve known plenty of people who have.

Even with that experience and knowing that mistakes aren’t the end of the world, I still get a serious case of butterflies and wonder how things are going to go (not to mention wondering why people are listening to *me* of all people). However, like most of the other speakers I know, I just try to make the best of it and somehow it all tends to work out fairly well.

How you relax is up to you. If picturing the audience in their underwear works for you, go for it. I’m not sure I’d want to do that with some of the groups I’ve talked to, but to each their own. Just take a breath, calm down, and be prepared to laugh off minor technical difficulties =]


Second - tailor your talk not only to the subject, but also to the group and allotted time.

Andrew, the software developer who gave the lightning talk last month that cause me to write what has become a novel of a blog post, chose to speak about Test Driven Development, a subject which I am quite interested in, but haven’t had a chance to dig into on my own yet.

He opened by saying that he was giving a longer version of the talk this month (November) and had just shortened it to fit in the 15 minutes allotted for the lightning talk. This was a pretty big mistake.

You wouldn’t give the same talk to a group of (largely) non-technical managers and directors that you would to a group of people who are going to be using and/or implementing the technology.

By the same token, there’s a lot of difference between how you structure a 15 minute talk and how you structure the same talk to last 60+ minutes. You can’t just cut off little pieces (or talk really really fast) and have it come out well – especially on a technical subject.

For a 1 hour talk, you can go into at least a little bit of depth, but in 15 minutes, you really have to follow the KISS mantra (and I don’t mean “They call me Dr Love”). In the case of Andrew’s presentation, the general outline of the talk should have probably looked something like the following:

1) Explain what Test Driven Development is
2) Explain why you want to use it
3a) Show a simple test or two by itself (probably no more complex than “Hello World” level stuff for this)
3b) Show the result of the test by itself (notably, probably a FAIL – we hope anyway)
4a) Show the code around the test
4b) Show the result of the test+code (We should hope that this one will PASS)

Instead of the above, in the interest of shoehorning what he had been designing as an hour long talk into 15 minutes, Andrew basically skimped on 1, killed 2-3, and did 4a&b with examples that were far too complex for the time allowed (or for an introduction level presentation, really).

In fact, he spent most of his presentation time mucking around with SQL and SQL Server as well as fighting with the web page he was using as an example. While this may have been alright for a longer presentation (depending on how he did things, but even then I would have went the KISS route), it really didn’t work for a 15 minute presentation.

In all honesty, he could have completely cut out the SQL and website and, instead, just written a few simple functions to show how to write tests for code and what the results should look like even in the longer presentation.

The end result was that most of the people in the room were looking at each other and wondering what was going on.

This could have been greatly alleviated if not eliminated altogether by doing the last thing I’m going to cover here.


Third – Rehearse.

You really need to do a number of dry runs of your presentation to make sure that you have the kinks worked out of the technical aspects, can make it fit reasonably into the time allotted, and actually know what you’re supposed to be saying/doing next.

Ideally, you would do your presentation a few times by yourself with all of your equipment and then, once you think you have it down, grab a few friends or colleagues and try it out on them as a sort of dress rehearsal, eliciting feedback before you give the “real” presentation.

It’s amazing how many problems can be prevented or corrected by just going over a presentation a couple of times. The major one, apart from timing issues, is that other people can point out things which aren’t immediately obvious to you such as parts of a presentation that may be confusing to others while they sound perfectly reasonable to you.

Think of it as a sort of peer review for your presentation instead of for your code. It’s the same idea, really.

So, having said all of that, it really boils down to three things – relax, be prepared (including being prepared to answer questions), and try to have a little fun with it. It will work better for you and your audience will thank you.

Current mood: Not bad =]
Current music: Depeche Mode – Everything Counts [Live]