I need to teach a teenage beginner programmer (private tutoring style). The problem is that despite their poor knowledge and skills, they are sure of their abilities, to the point where I find it hard to teach them "better ways".

What's the best way to tackle this?

Just to be clear what I'm talking about:

  • Constantly changing between tools/IDEs/libraries when it's tough.
  • Blind certainty that really bad designs are really very good.
  • Copying and pasting from the Internet, without understanding the code, and "marking" it as a project.
+214  A: 

Let them fail. Nothing proves your own mortality more than seeing bugs you never thought possible in your own code.

C. Ross
If you're convinced you're an immortal coding god, you won't realize that the reason your code is failing is actually your own fault. There are numerous ways of solving problems in code, most of which have some hidden drawbacks or downright critical consequences that will never show up to a beginner. They won't know how to deal with this, unless taught the basics of common sense.
J. Steen
If you don't have the reasoning skills to tell when your bugs are your own bugs (after serious inspection of course), you don't need to be a programmer ... (IMO)
C. Ross
Yes, but the higher they are now, the more painful the fall will be.
@Metaphor - True, but if you're a teenager and it keeps "not working," maybe you're likely either to figure out that the problem is you, or decide you don't really like programming. Very few things teach humility like seeing something you built fail catastrophically.
I think the biggest problem is up to one point you might not aware of that you failed, because the project is working fine! But when it comes to maintaining or can't introduce a new feature because the initial design was ridiculous you might see that you failed. So "let them fail" might not work as quickly as expected.
dr. evil
And what's wrong with experience? Not every programmer is a natural talent. =)
J. Steen
I agree with this one. Give them a simple task, and review it with them when it's done. For an extra lesson ask them for their time estimation of the project before they start. Someone overly confident will probably give too short a time.
Reasonably, "Let them fail" is the most controversial way to go, and you'd better be damned good at teaching, and empathy, to guide someone who just keeps failing because they refuse to learn. Letting them fail brings about experience, but it might not be the right kind of experience you want them to embrace.
J. Steen
fm, In that case perhaps getting them to introduce a new feature to code they have already written might be the lesson.
@CiscoIPPhone that make sense, also I liked the idea of estimation :) This is classical weakness of of over-confident people.
dr. evil
Along with the estimation of time, also restrict the technology and IDE. That way they won't 'jump around' for the solution. Treat it like a mini-project and give project requirements. This way it will be easier for you to go over the code issues and/or why the technology chosen was wrong.
Agreed. And if they didn't fail, they might really be what they think... so that won't harm their self-confidence if they are right!
Mehrdad Afshari
+1 for the first 3 words.
Rob Stevenson-Leggett
"Let them fail" can backfire spectacularly - some people are just not capable of assigning blame to themselves, they will convince themselves it must be something else. If you try this, it could be you they choose to form a conspiracy like theory around.
"Let them fail"? Hell, MAKE them fail. Take a look at the crappy code the kid is producing, and then for the next assignment, have them expand the code in ways that require an understanding of the code they blindly copied and pasted, or that would be fairly simple with good design but are quite painful with the design actually used. And for the sake of contrast, do the same thing targeting functionality that the kid DOES understand, or sections of code that ARE designed well (assuming any exist). Don't tell them they're screwing up; SHOW them.
I agree with David that the "Let them fail" method could backfire. Too many kids have it way too easy b/c frankly, we keep programming things to make their lives easier! So easy in fact, that they never learned how to overcome challenges. Thats why your student switches IDEs/tools when it gets tough, they are giving up. Teach them small obstacles that they can overcome, progressively getting more difficult. Solving each challenge provides real self esteem, which will replace the fake stuff they use as a defense mechanism.
Charlie Brown

First form a spiritual binding with her, then she will be more susceptible to your teachings.

Try first to initialize this teacher-pupil relationship on non-technical stuff.

uh... .
Let me see how could this go wrong
'Hey, I think we should develop more than code. How about a *spiritual* relationship. Its ok, shhhh, its ok'
Aiden Bell
I totally agree that first she should respect you then you can teach something. Unless she understands you have far more superior skills from her it's not going to work.
dr. evil
Did you all just assume that the subject is a girl, or was that post edited before I first read it?Either way. . . urg
Ed Woodcock
lol, +1 for using "initialize" in this context, but is this "spiritual binding" process even legal in most places. ;)
Dana Holt
Not sure. The first question was quickly deleted, could have contained "her". Or I could have imagined that. Now hard to say.
Wanted: Female Programming Students, must enjoy spiritual bonding.
Aiden Bell
@Ed + Mastermind: The original question said 'she' and 'her'; it's in the revision history.
+2  A: 

I'd try moving away from the tools/libraries and tackling on more theoretical topis, such as OO design, algorithms, etc.

+1 - Getting them away from "already solved" problems (which might be at the heart of the "switching tools" issue) and into areas that there aren't convenient/easy tools to use might help break that habit.
+2  A: 

The only thing that may help her is time and experience.

If not the only thing it's of course the most important.
+63  A: 

Unplug the internet connection.

+1 - This is what I was just thinking. :)
Dana Holt
What about the neighbor's "linksys" access point?
Mehrdad Afshari
If she can tackle the WPA2, she really might be a know-it-all :-)
A very good idea. Another might be only allow certain compiles per day.
C. Ross
"I just downloaded this code and it seemed to work. Don't really know what it does though,......"
Steve Claridge
@Steven Claridge - A great example of encapsulation!
@Neil - Wonderful, wonderful answer, and in so few words.
@CiscolPPhone: more like information hiding
hasen j
+10  A: 

It's not enough to tell them they're wrong, you have to show them. There are limits to the coding style you describe. You're going to have to make your student reach those limits before they can go beyond them. Challenge them with interesting problems that they won't be able to solve the easy way. Work through them with the student the right way. I'd recommend Project Euler, but it's not for everyone, and I have a feeling you're going to need to find problems that are particularly interesting to this specific student.

Bill the Lizard
+5  A: 

Give them a task that is very hard. Look through 'The Art of Computer Programming' as there are plenty of good ones there. Maybe issue an NP-Complete problem. Then when it runs in O(stupid) you can point out how bad there design way and show them why they were wrong. Or maybe ask them to write something in under-x-lines of code.

I tend to think I am right until I find out that I am wrong. The lessons best learned are the ones you find out yourself

Aiden Bell
Sounds like a sure-fire way to frustrate them: People don't take it well when you give them an impossible problem and then come back with "told you so". That's at least insulting and taking the instable emotional state of teenagers into account, it's the wrong way to handle this. Defuse over aggression.
Aaron Digulla
Not so much an impossible task, but one that is sure to highlight to them where there short-comings are. So they can go "oh, so that's why we abstract the OS API" or whatever.
Aiden Bell
+7  A: 

Require her to grow a project: to start it and then, in your next assignments, add to it.

That should:

  • Require her to understand what she's provided in previous assignments
  • Explain the value of good design (which is maintainability)
  • Be like real life

I suggest too that you concentrate on verifying the correctness of program's output (because the extent to which the output meets requirements is an objective measure of goodness, whereas 'design' is subjective).

Something else is to teach by example ("that works; I would have done it this way though, because ...").

Something else is to ask, "What do you want me for? Is there something you want me to tell you?" But that veers from being programming-related onto the topic of teaching in general.
+6  A: 

Confidence is a common and necessary attribute of programmers. We tackle problems that seem hard in their totality, and often are in their constituent parts. This confidence can be evident in strong ego, and even arrogance.

I remember being confident at pretty much every stage of my development career. The first time I wrote some code in assembly, I thought I could rule the world. That feeling is less strong now, because it is less important to me. I have been humbled so many times by other developers, and by the rapid, constant evolution of our field, that I assume anything I know to be a "truth" now, will be considered terrible practise in very short time (I exaggerate to make my case, but believe this to be true in spirit).

For me, the best way I have learned the "better way" is by using those tools and practices. Make the student work with, and modify good code, so they appreciate the elegance and ease that prior programmer has afforded them. Make them use design patterns and frameworks (e.g., MVC) that are generally agreed on to be a good thing at this point in history.

Ask them to do things THEIR way as well, and then discuss the differences. Why is A preferable to B? More maintainable? Less lines of code? Less layers of abstraction for a new developer to get oriented with? More loosely coupled? Better documented? Faster? More common standard? Feels better?

And never forget that some issues, that are most important to a seasoned developer, are completely lost on a greenhorn: Maintenance, code duplication, design patterns. These only distract learners in the beginning because they feel overwhelmed.
Aaron Digulla
Absolutely - my first code was full of magic numbers and sweet hacks. When I looked at it 6 months later, it looked like a foreign language to me. Entirely opaque.

Give her a closed book exam, no books, no phone, no Internet access. Something simple, code written in notepad, compiled at the command line. Let her fail, see her make excuses when she has nothing to blame except herself.

Also, find something external to IT that she's interested in Sports, Musicians, fictional characters, and teach using their example

e.g. Do you think David Beckham would be proud if he played a game the way you did that assignment? or Spiderman has natural ability but even he has to study . . .

Bad examples, but you see where I'm going

Binary Worrier
Closed book exams aren't like real life: real life for a programmer usually includes internet access. For example, some people object if they're given closed-book tests in a job interview.
And then they don't get the job. I've said it before on this site, that any one professing to be a programmer should be able to write code at any time, for any reason, under any conditions, short of hung upside down in a tank of water. But definetly yes to "On paper", and "on white board with 10 people watching", and also yes to "a theoritical symbolic programming lnguage with 10 or so symbols, once they've a cheet sheet in hand". Primarily you need to be able to "think" solutions and code, and express those thougts with what ever you have at hand. continued . . .
Binary Worrier
We all need IDE's and to be able to look stuff up on line to be productive, but lots of us started off in this business before ide's and the internet existed, and we still managed to get the job done. At this stage for this pupil, it's not about "what's real life" it's about learning how to think and how to express those thoughts.
Binary Worrier
Without a computer in an interview, there are many *interview* questions that I can answer (including whiteboard things) ... but there are many *programming* questions that I couldn't, for example I don't remember exactly what parameters you pass to the CreateWindow function; I've always found it sufficient to remember only the name of the function, so that I can look it up ... and I was doing that (i.e. using the documentation and sample programs while I was programming) even before the WWW became available.
One of the things I liked about leaving school was that I was given 'real' problems: instead of 'artificial' problems (e.g. closing the book and then working to solve a problem that had already been solved by previous generations of students).
"or example I don't remember exactly what parameters you pass" which is why paper exams should be pseudo code, you really shouldn't be failed on not knowing the calling convention of some obscure api. But you should be marked down for not knowing the simple stuff (i.e. not using .equals for strings in java, or being un aware of pointer notation in C), and definetly marked down for not being able to solve a problem. e.g. 2 years ago I was asked to give pseudo code to convert an int to a string, he sort of apologised saying "everyone has to do it, for all tech positions". Cool, my kind of place.
Binary Worrier
"paper exams should be pseudo code" Yes. So maybe you're saying that the OP's student should be learning to pseudocode, rather than programming.
Yes ChirsW, that's EXACTLY what I'm saying, you've hit the nail squarely on the thumb - I mean head - right there . . . I couldn't POSSIBLY be saying that the mental disciplines that underlie our ability to write code are more important than the ability to find a code snippet on line. Yes, I'm saying that it's sufficient that any idiot with browser can find samples and snippets that solve their problem. There will never be an occasion where they can't find the stuff they need online and have to build a solution from first principals. That shit never happens in the real world.
Binary Worrier
Saying, "teach her pseudocode" isn't quite the same thing as saying, "demonstrate that she fails and/or makes excuses in a closed book exam".
*sigh* You give the student the heads up for a closed book exam. You introduce them to the concept of pseudo code, you inform them that they'll get a chance to prove their ace skills with problem solving / data structures and all that good stuff, then they crash and burn and they realise that they have a lot learn and you might be the one to teach them . . . or they don't, or you don't give them that test and choose a different course.
Binary Worrier
However, if you want them to fail, close the books and expect them to write real code - not pseudo code - with notepad. However, I'm not sure thats quite fair though :)
Binary Worrier
+80  A: 

Ok here comes a rather philosophical, but nevertheless correct, idea:

A strange phenonemon is that regardless the skills people have or don't have, the skills they think they have are more or less constant.

This is because the skills you have are the only skills you can use to judge the skills you have....

This lead to the phenonemon that your pupil, and many others, suffer from: "unskilled and unaware of it"

See this very interesting text: Unskilled and unaware of it: How difficulties in recognizing one's own incompetence lead to inflated self-assessments.

Now, ask yourself, why you think you are skilled and your pupil is not? You know you shouldn't copy paste from the internet. But if you really know why, why is that? If you can phrase it for yourself, why not for her?

What I mean is, if you know something is bad, you should know it that well that you can explain it to others. If you want to tutor, make a habit of questioning your own certitudes. Explain them to yourself as if you had to persuade yourself.

And importantly, try to find examples. Examples are the alpha and the omega of teaching. That's how people tend to get something: by seeing an example of it.

If a design is bad, show her where it goes wrong with an example. If you cant find an example, produce one yourself. If you can't produce an example, ask yourself why that is.

I think if you can find counter-examples for every false certitude a beginner has, you will not find it that difficult to persuade them.

You actually explained what I "just knew" :)
cool answer.. appreciate it
The pdf reference is great
OMG that paper you refer to is **amazing**! Any of you who hire or manage people: this is required reading!
Dave Swersky
The link is broken :( Any chance of getting the title. It wasn't about the Dunning-Kruger effect was it?
+12  A: 

I was once that know it all, fresh out of college developer. It took about 2 weeks and 10 code reviews to show me that I was nothing.

When I started my current job out of college, I had to do a throw away program to learn the companies standards for 2 weeks. My code followed the companies SOP for development, meaning the code was code review. The two code reviewers I had tore it apart for 2 weeks. By the end of it, I realized that I and my code are no better then anyone else. That is the exact time that I started to grow as a developer and actually learn.

+1 for formal code review
David Plumpton
+60  A: 

Simply ask.

Let them do something. When you see they do it wrong, ask why they do it. Let them explain their reasoning. Nobody likes it to be pampered but everyone likes to boast -- to the point where they will talk themselves into a corner.

When they start to struggle with their answer, ask a "how about ..." question: "How about you encapsulate this into a class, so you can forget about the details?"

This makes them lead themselves, using your experience.

[EDIT] In my experience, there are no fools. When someone does something extremely foolish, that happens for two reasons: They didn't think about it at all ... or they thought about it and came to the conclusion that this course of action was the perfect one. Since you can't tell what it was by looking, you have to ask. This is the key to answer your question: How can I help?

Aaron Digulla
"In my experience, there are no fools." - then you need to get out more :-)
If one starts to think of someone else as a "fool", then that's prejudice. People can lack knowledge, insight or guidance. Just wrapping them in a label to let them rot in a back corner of ones consciousness will make one happy but it won't change anything.
Aaron Digulla
+1 "In my experience, there are no fools": at work, you really do have to think that way.
Bob Cross
"Everyone is a fool sometimes". Dunno who said that but I have my moments, too.
Aaron Digulla
+1  A: 

I think we all started out as the invulnerable teenage programmer who knows everything that there is to know about programming and especially doesn't know when they're attacking the impossible. It takes a while to work out that the problem usually isn't the tools but sitting in front of the keyboard.

Realising that good practise is something that's useful to be adhered to comes wiht experience and that's usually best gained with trial, error and failures...

Timo Geusch
+2  A: 

Don't let them fail by giving them something difficult. That leads to frustration which is not a fertile ground for a teacher/student relationship.

Give them a simple problem, but strive for elegance and clarity in the code. If you have multiple students, try making it into a little contest: Whoever can come up with the solution in fewest lines of code / fewest operations / fewest bugs.

Don't talk tech at first, judge code purely on its aesthetic merits.

And, yes, disable the internet. Or, better yet, switch off the computers. Let them do the coding on paper/whitebooard/blackboard/origami/spaghetti.

David Rutten
+1  A: 

A teacher really cannot "teach". What happens is that the pupil learns, or learns not. Teacher's job is to create suitable conditions so that it's easier to learn effectively.

Give him more challenging tasks so that bad designs simply won't work. It's possible to solve easy problems with bad designs, but with challenging enough problems it becomes more difficult. Maybe he then will learn to appreciate better designs.

Nothing sucks more, especially from a teenager's point of view, than having to listen "don't to that way, do this way, even though your way works for now, just believe me.." kind of preaching. Things have to be experienced to be understood.

Joonas Pulakka

As soon as projects exceed a certain size everybody feels that some discipline is needed to really keep being productive, which correlates at least a bit with having fun programming ;-)

So I would try to let them write stuff that can be modified and extended. This forces them to face their own crap again and again. This can then lead to introduction of refactoring, code quality, unit testing and so on.

In university I participated in a XP-style programming course. We were handed over a running traffic simulation. Then the product owner appeared and wanted us to fix certain issues and change some of the behavior. In order to simulate reality as good as possible he changed his opinions every week.

Maybe a running prototype might be a good starting point in your case, too.

This. Simulate "real life".Or break their fingers so they can only type REALLY SLOWLY... :-) I am a dreadful typist - but that has helped me to favour elegance over cut'n'paste'n'change the strings/variablenames/function calls
+38  A: 

Point him/her at StackOverflow, and see how many questions they can answer.

The breadth of issues on here might give them some idea how big the programming problem space is.

This is a good response. I'm consistently humbled when I read the questions posted here.
Or point them to tasks at rosettacode.org and start coding
glenn jackman
I agree. Nothing more humbling than looking at the level of expertise on this site.
Look at the PHP questions, a lot of answers there are actively encouraging copying from the internet without understanding.
Oh please don't destroy our community.
@Jacco yeah, large proportions of PHP Users are unskilled and don't know it ;)
Kent Fredric
+2  A: 

My initial answer is to always let them fail -- agreeing with the current solution. Even after I was made aware of my failures and my ridiculous software designs, I took it as a personal failure and not one of lack of experience or knowledge. Furthermore, it doesn't really help if you need to teach someone.

What helped me to gain perspective is work in the Enterprise consulting field. Looking at the APIs and designs of professional (and expensive) projects taught me a lot about where I was, and how far I had to go. I saw how much more complex these things are, and how people are made to work with them. It shocked me out of my bravado and made me listen and study.


I will give them a task where you know they will mess up. Maybe before you give them the task tell them what they MUST use to get the task working 100%. The when you see that they cant do the task tell them "SEE, i told you guys what you must use and still you dont LISTEN to me!!!!" Then show them how its done and tell them to pay attention from NOW ON!!

+8  A: 

Give them a rather complex assignment. When they complete it, analyze the code failures (such as lack of extensibility, etc), and make them, for example, extend it. Make them do modifications that require changes in the copy-pasted code. As they run into difficulties, explain how these could be avoided, by better design, and understanding what they copy-paste.

Additionally, you might what to give them problems from http://projecteuler.net/, which require thinking and not just brute-force+copy-paste programing, though i may have diverted myself a bit.

+1  A: 

I'm not in the "destruct their beleave" thing, i think you could make an sample project with some mistyrious bugs or exeption that you've put in, and has an exercice or practice they have to debug it.

You learn alot by debuging code and they wont find the solution on the internet :) beside that case happens all the time at work, some tools is jamed and the programmer isn't here so you end up debuging someone elses code...

+2  A: 

Give them a good book to read. I had this problem with a co-worker and it was very hard to convince him with the basic concepts behind things like encapsulation and so. I threw at him a good book (that matches his level being experienced in the field not in programming) and it was miraculous how he changed his mind about many aspects of his work. Try books that serve as moral advisers for languages or general practice like "Code Craft" or "55 Effective C++" or "The Productive Programmer" and so on ..


I would have her implement a binary search algorithm. It is fundamental, looks easy, and it is surprisingly tricky to get right. Even "Programming Pearls" had a bug in the implementation.

Søren Elverskov

I think that I would start with Donald E. Knuth series and get them to work through them.

+3  A: 

His fake omniscience is due to insecurity, not confidence. You must destroy him before he can be rebuilt.

Actually sounds like fun... =)

This works in martial arts movies, but I think this is not a very nice approach to a student-teacher relationship...
+3  A: 

One option might be to get them trying to contribute to an open source project. Pick a bug and try to fix it together. It might be a helpful way of showing them other peoples code and getting a wider response to their code when they try to submit it to the project.

+2  A: 

Ask them lots of questions. Get them to explain their designs, their modelling and their implementation.

Then start picking apart the explanations. It may not sound pleasant, but it might be one of the few ways to get them really thinking about their designs and approaches.

Hopefully they'll realise that there is a lot more to programming than "just making it work".

Lastly, give whatever they build the "manual tester" treatment and start breaking their applications by doing things in a way that "real users would never do" (i.e. things they haven't considered).


I'm assuming you've tried the "talking it through with them" route and not getting much feed back. So...

Take just one of their files that they are very happy with and ask them to wheel to one side then start hacking it up how you'd do it. Its easy to write bad code and hard to write good code. Talk as you do stuff, don't ask for an opinion this time, you are showing the way rather than getting them to think about it. They are clearly dead sure their way is best so no point asking this time around. Make it neat, make it clear, commented, well defended (try catches that are actually needed and do stuff if appropriate), declare all your variables that sort of stuff. Basically show them how its really done!

With luck you'll end up quietly humbling them into realising that maybe they are not such a hotshot and they have a long way to go. If not leave them to Google and go find another student :)

Pete Duncanson
+1  A: 

Let them find out the hard way when they choose to not follow direction and attempt to do it their own way.

The greatest thing is to just keep at it. Eventually they will learn that what you are showing them is the best way and eventually they will start listening.

Good question by the way!


Help them discover by themselves the weaknesses of their code.

It depends on their weaknesses, but for instance, if they were not sanitizing user input, you can ask them to work out how they would crack their own code. And if they are so full of it, make a bet with them, win it and make them pay for it.

If the code is long winded, ask them how they would do the same in 5 lines of code. And when they say it can't be done, do it.

If they have a design set in stone, add one requirement that will force them to redo the whole darn thing.


The whole point is that they have to find out for themselves that they do have a problem. Until they know they have a problem, you have little chance to get them actually learn.

+3  A: 

Your problem is not new.

Here is some research on the subject, makes an interesting read. Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments


I suggest you find a site related to teaching since this has nothing to do with programming.

I'm sorry, I have to strongly disagree with this. Part of being a programmer is sharing knowledge. Sometimes this is being a teacher, sometimes the student. I don't care how kick rear end that code you write is, you aren't good unless you can, and are willing to, share what you've done with the rest of the crowd
Chad Ruppert
My point is that the technique is not programming specific.
If you don't like the question you don't have to answer it; there is no reason to be rude.
Mike Bethany
+40  A: 

I've done private tutoring for some years, and I think that the same approach can work with maths and programming. (After all we know that they're more than closely related).

  • Take away any help from them. Programming is done best in one's mind. No IDE, no google, heck no computer! Go pen & paper.
  • Make them explain why they think the solution is valid. Always!
  • Make them explain why, but do it before telling them if the solution it's right or wrong. This helps a lot with over/underconfident persons.
  • Ask questions. Theory questions, practical questions that can be solved without writing, any question. But don't be satisfied with approximate answers.
  • Give examples, of what works and what doesn't, and always explain why. Evidence is the key.
  • Make them fail. But be aware! This must not, for any reason, be a clash of egos. There's no point in proving someone wrong for the sake of it. The typical know-it-all reacts worse when he feels humiliated. The truth that has to become clear is not that they can't program, is the right way to do it.
  • Be a good example, and never accept compromises on the topics you think are crucial. This means never copy and paste if you told him to never copy and paste!
  • Always say why something's wrong, and incrementally ask for solutions to individual problems. Small things are tackled best, and a sense of direction is very important.
  • Systematic and logic errors are not abstract, we all know that they have heavy practical repercussions: make clear what will happen if they don't follow best practices.
  • Always make it fun, or at least interesting. Learning always has to.
  • Lastly... some people have no will to learn. Humility is key in learning more than in any aspect of life, and unless you're a close relative... there is very little to do about it. You can decide to invest your time in people with the right mindset.
very nice answer
-1; when i was learning coding i would have had an *absolute horrible* time writing code; why? no compiler, not syntax highlighting, and plus writing is simply so slow that you can't really think at the speed you can write.
Programming is not a race! These tools are there to make **work** fast, but learning is an inherently slow process. And since we were talking about know-it-alls, humilty is not achieved through speed, more like the opposite.

Horse; water; think...

Brian Postow
+4  A: 

What was it Obi-Wan said... "Was I any different when I was that age"?

Give them problems from TopCoder, and then compare and contrast the elegance and efficiency of their solution to the examples of contest winners.

Tim Hoolihan

While I would argue they shouldn't act that way, perhaps they are a "hacker" and not a programmer like you. Maybe it's a personality clash.

There is a programmer that I work with that can simply glance at code, intuit what it does, and modify it almost instantly; he can hack kernel modules all day and they actually work when he is done. Whereas I would need to spend time investigating the structure of the code, he can pick it up instantly. He does have a bit more experience than I do, is terribly cocky and somewhat arrogant and a total hotshot, but he has programming skills and knows what he's doing. Doesn't mean he doesn't get into trouble or everything he does is right, but you're pupil might be better than you, as humbling/aggravating that may be.

Without meeting the pupil, I can't say for sure. If I'm wrong, I recommend pondering all of the rest of the answers and ignoring mine. :)

+3  A: 

Introduce them to StackOverflow

I find that seeing the depth and breadth of knowledge available, especially dealing with somewhat foreign languages and concepts, is extremely humbling, even on my most egocentric days.

Tell him/her "Until you can out-wit Jon Skeet, you've got more to learn."

+4  A: 

I personally feel the best way to teach is not to tell a kid how to think but to ask them what they think and then ask them to defend their ideas with facts. So if the kid says XYZ is the best method don't disagree say, "OK great answer and now why is it the best?"

Never use "but" with a kid, or anyone really, because it sounds like you are saying, "I heard you BUT you are wrong." Kids just shut off if they think you aren't listening to them. I try to go by the adage that you should never take away from what they say but instead you try to nudge them in the proper direction by showing them how to deduce and answer for themselves.

Though you should be careful that in the teaching you don't forget to keep you mind open and learn too; very often we learn from those we teach.

Oh, and make sure you are non-confrontational. You aren't there to force them to do things your way, you're there to teach them how to think for themselves and you're just providing the tools.

Mike Bethany

Don't let them copy-paste code. I've seen far too many developers depend on copy-pasting of other people's code even though they don't understand how or why it works. It becomes a very bad habit.

I would also be a little hardcore with them too. Notepad and the command-line. That's what I used while learning Java, and I turned out all right. Ok, bad example...

+20  A: 

Teenagers almost always think they know everything. In some ways they're like two- or three-year-olds - their experiences haven't taught them (yet) that there's more to [insert your thing here].

Working with teenagers in my church youth group and as a Boy Scout leader (and Computers Merit Badge counselor) has taught me a few things:

  • be patient.
  • they are generally smarter than you think.
  • don't say "but" if you can avoid it. Exceptions to anything let them turn on their inner lawyer and they will try to split finer and finer hairs. It's unwinnable and takes you both off task.
  • their logic skills are ... undeveloped. That may be the hardest thing to overcome because they will see relationships where none exist, and will miss the elephant in the room.
  • practice being patient. For yourself and for them.
  • be a teacher, not a Charlie Brown-adult talking head. Don't be condescending. This can be tough with a know-it-all who's sure they are right.
  • give them solvable problems.
  • they'll want to do something that gives them near-instant feedback. Whiteboarding logic might be important but will turn them off and you may never get them back.
  • be patient.
  • let them fail.
  • be patient. They will get it. Eventually.
great response!
+1 Going to apply this to my teenage kid! :-)

A true programming god knows that all software has it's design and performance limitations at any implementation level.

A true programming god sees flaws in their own designs and understands how the customer wants it, not just how they think it would be better.

Personally, such egos are not worth dealing with. The truly skilled developers are always open, always asking, always open to being wrong (and learning), and always curious about different ways to do things.

Jas Panesar

notepad and notepad alone...that and the command line


Patience. Sounds like your student lacks patience... so teach him or her patience by example.

+1  A: 

Regarding bad designs, have the student perform a code review. Write a solution in the student's style and another with a good design. Hopefully that without an investment in the code, the student's ego won't interfere with criticism. Of course, if the student doesn't understand enough to see why one approach is better than another...

While this isn't a panacea, it might be a useful pedagogical tool.


Don't worry about it, this guy will probably be a manager in a few years time.

Chris Needham

Competition: have them try and solve a problem with some criterion like "fewest lines of code", or "fastest runtime". Then show them how well a more experienced programmer can do it. If you can't find any local programmers, try websites like http://www.topcoder.com/

Elaboration: before entering university or a workplace, many smart teenagers have rarely had the opportunity to meet someone smarter than themselves, and even more rarely someone who knows more about computers. Depending on their social or family background, they may only know a couple of dozen people, and the chances are they have got used to being the best or only programmer out of that set of people. Realising that there are other, better programmers out there can be hugely beneficial by giving them something to aspire to.

+2  A: 

Maybe you can get them to shift their ego. Instead of being writing the best code around (as we are all :), maybe they can find some fun at saying WHY other's code SUCKS ? What if they where the buyers, would they pay for that ? Since they would be riches (after coding some killing app, of course), they would not have time to code all what they want - so they would have to hire - what kind of code would they want ? Is unmaintenable code ok ?

And what if they were Bill Gates with 100 000 developpers beneath them ? Would they accept that a wiz kid create a killing feature that nobody would understand ?

That's the beginning of code review. And the begining of great software development carriers, I think.

All the best :)


When he starts looking for source to copypaste from the Internet, tell him that he is already proficient with this programming technique; there is little point in further exercising what he is greatly capable of. The skills which need attention and exercising are those which are lacked, so today, we're going to write programs with the Internet disabled. He may argue, that this is pointless, as the copy-n-paste methodology is the superior; well, it doesn't matter if it is, because he has to know the "inferior" solutions as well.

Likewise, if the way he partitions business logic into modules and subprograms is mediocre but he argues it is superb, you may tell him, that he has perfected the skill of writing all of the application in one main function with seven levels of nested ifs. Thus, no point in pursuing education of that skill. Time to learn another solution for the sake of variety, let's say, how about learning about restructuring the classes and methods in a way which allows all methods to have at most one indentation level and no use of else branches (through, for example, proper use of inheritance).

Adrian Panasiuk
+1  A: 

This makes me immediately think of the empty cup story of Zen Buddhism:

Nan-in, a Japanese master, received a university professor who came to inquire about Zen.

Nan-in served tea. He poured his visitor's cup full, and then kept on pouring.

The professor watched the overflow until he no longer could restrain himself. "It is overfull. No more will go in!"

"Like this cup," Nan-in said, "you are full of your own opinions and speculations. How can I show you Zen unless you first empty your cup?"

-Zen Flesh, Zen Bones

Ask your student to bring an empty cup and serve him tea...

Pascal Thivent
+1  A: 

This is coming from a teenager,

  • choose one platform, and stick to that platform (iphone, mac, windows, etc.) don't switch UNTIL he knows enough about that platform that he can pump out programs.

    HIM!!!! (eg cocoaheads) it'll get him excited about that platform.

  • When you teach him DO NOT USE THE
    INTERNET!!!! Use books.

  • When things get hard, help him figure it out, don't leave him in the dust

  • IMPORTANT! Create a new user account on the computer he uses, this is your "development account" on the desktop (if you're using windows) remove all the icons EXCEPT: my computer, the IDE, a folder that will contain all the projects, and an image editor (photoshop, gimp, etc.). On a mac just leave these in the dock: Finder, xcode, IB, and an image editor. On this account BLOCK ALL INTERNET ACCESS

  • Do "contests" with him. Come up with an application idea, it can be something simple, like a calculator. Just make sure you can easily do it. When you do it with him make sure he's using the "developer" account that I mentioned above, and you use a different computer. Chances are it'll be too hard for him and he'll steam off in a pissy mood, THAT'S OK!!! Once he cools down show him your finished app and go through the source code with him, line by line. He'll pick up little "tricks" that you used, if he starts to ignore you make something up, don't keep on going, stop, say something to him, and continue. After seeing this he SHOULD realize that he doesn't know everything and be more prepared to learn.


  • Give hints you want him to learn a specific language, go to your local bookstore and pick a book out about that language/platform and first YOU USE the book (optional, you can fake it if you want, or just give it to him), then when you're all done put the book somewhere where he'll see it, if you want to put a note on the book saying "here you go!" but you don't have to. Eventually he'll look at it, it probably won't be right away, but he'll look at it.


Oh yea, a biggy:

  • Make him realize his mistakes. Don't point them out. Have him figure it out when the app crashes.
Matt S.

Just make the learning fun and all the rest will follow ! Amazingly Scala might be the easiest language if you try Kojo Examples, puzzles, help and FUN - all included in a simple installer.

Łukasz Lew