share
Stack OverflowHow can I teach a know-it-all beginner programmer?
[+143] [50] Liran Orevi
[2009-05-15 12:08:28]
[ teaching ]
[ http://stackoverflow.com/questions/868301] [DELETED]

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:

(26) I was like that at 15 or 16. Full sure I knew eveything, and couldn't be told I didn't. It took a very humilating personal failure to snap me out of it. - Binary Worrier
(134) I have met people like this. There is always one day when they come and declare: I have found a bug in gcc. - mouviciel
(1) Good question... +1 - Kyle B.
(7) Albeit few, there are some who actively refuse to learn. These will only learn from experience, if ever. - romandas
(22) Physical discipline, of course. Always works. - DrJokepu
(1) Perhaps they need a more proficient mentor. - jsamsa
(2) You cannot teach someone that knows everything, by definition. - johnny
(1) can you give a small example? - Avram
(33) Apply a rolled-up newspaper to the nose, repeatedly, until they stop piddling on the carpet. - Steven A. Lowe
I'm sorry to hear you're in one of those situations; I think we've all had to deal with someone like this, in different situations. I'm afraid I'd agree that the problem you have to solve, somehow, is to make them realise, possibly painfully, that they are not all that; it'll be impossible to impart any knowledge while that arrogance is maintained. - Rob
(9) Actually, I did find a bug in GCC :-) - Matthew Farwell
(2) I was like that too. For me, it took building a large unmaintainable project on my own to realize how careless I was. I learned not to screw up the next time. Luckily I was allowed to write a new version---this time I've made it maintainable and I know how and why (my own sanity). @MatthieuF: I found a stack overflow bug in .NET 2.0: When you set BindingSource.Filter = "(X OR Y OR Z) AND (A OR B OR C) AND etc." to a long enough query, the naive parser crashes instead of throwing a BadArgumentException. - Jared Updike
(2) I remember the very day in school when I realized that all my problems were my own fault. That was a difficult day. At least it wasn't publicly humiliating, though. I just accepted my fallibility and moved on. :) - Greg D
I've always found that people like this get taken down a notch the first time they have relationship troubles with a serious significant other. :-P - windfinder
100th vote!!! :D - claws
(1) not anymore: 101 :) - mlvljr
[+229] [2009-05-15 12:12:00] C. Ross

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


(36) 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
(2) 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. - smok1
(1) @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. - AllenG
(10) 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
(2) 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. - CiscoIPPhone
(1) 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
@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. - JFV
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
(5) "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. - David
(146) "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. - BlairHippo
(4) 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
I understand the reasoning but in a commercial setting with real goals and deadlines this may not be the most cost effective way of dealing with this issue. - Seventh Element
1
[+86] [2009-05-15 12:25:57] Peter

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. [1]

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.

[1] http://psycnet.apa.org/?fa=main.doiLanding&doi=10.1037/0022-3514.77.6.1121

(2) You actually explained what I "just knew" :) - VVS
(1) cool answer.. appreciate it - rpr
The pdf reference is great - bobobobo
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? - calico-cat
2
[+76] [2009-05-15 12:28:24] Aaron Digulla

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?


(12) "In my experience, there are no fools." - then you need to get out more :-) - paxdiablo
(25) 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) +1 "In my experience, there are no fools": at work, you really do have to think that way. - Bob Cross
(7) "Everyone is a fool sometimes". Dunno who said that but I have my moments, too. - Aaron Digulla
3
[+73] [2009-05-15 12:13:45] community_owned

Unplug the internet connection.


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

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.

(1) very nice answer - sstock
-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. - RCIX
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. - Agos
but my point is that i'll get so hung up on the trivial things that I won't be able to see the forest for the trees. - RCIX
@RCIX: fair point; to that end I suggest using Python + a plain text editor, so there is no “trivial things” overhead, or fighting with the compile - you're right, “segmentation fault” never really helped anyone. - Agos
@Argos: Years of tutoring others, and I can relate to your approach. In the maths, we'd openly talk about the tutoring plan. Basically it was: "1. You need to learn the theory. 2. You need to develop skill in applying it." Many people (novice programmers included) tend to stop during partial understanding in #1, or just after full understanding in #1. It's a good prod to remind them that their entire life will be tested against #2. - Edwin Buck
5
[+44] [2009-05-15 12:46:23] DanSingerman

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.


(18) This is a good response. I'm consistently humbled when I read the questions posted here. - JimDaniel
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. - SergioL
(3) Look at the PHP questions, a lot of answers there are actively encouraging copying from the internet without understanding. - Jacco
(26) Oh please don't destroy our community. - JavaRocky
(5) @Jacco yeah, large proportions of PHP Users are unskilled and don't know it ;) - Kent Fredric
6
[+23] [2009-05-15 17:00:13] DaveE

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! - jsamsa
+1 Going to apply this to my teenage kid! :-) - IrishChieftain
7
[+14] [2009-05-15 12:27:23] Tony

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
8
[+10] [2009-05-15 12:15:10] Bill the Lizard

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 [1], 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.

[1] http://projecteuler.net/

(1) For example, if they don't think 200-line long methods are a problem, give them one to maintain. When they start to struggle, ask (don't tell) them "What's wrong with the way the code was written?" Them telling you that there are too many nested loops or local variables reused 5 times means you've won without a battle. - Kelly S. French
@Kelly: Great example. - Bill the Lizard
9
[+8] [2009-05-15 12:58:20] Hugo

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.


10
[+7] [2009-05-15 12:16:18] ChrisW

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. - ChrisW
11
[+7] [2009-05-15 12:21:36] RedFilter

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. - RedFilter
12
[+6] [2009-05-15 12:16:12] Aiden Bell

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


(9) 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
(4) 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
13
[+5] [2009-05-15 15:19:59] Tim Hoolihan

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.


14
[+4] [2009-05-15 13:23:05] ilivewithian

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.


15
[+4] [2009-05-15 14:07:18] ongle

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 [1]

[1] http://www.apa.org/journals/features/psp7761121.pdf

16
[+3] [2009-05-15 13:22:19] Garrett

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

Actually sounds like fun... =)


(1) This works in martial arts movies, but I think this is not a very nice approach to a student-teacher relationship... - Pranab
17
[+3] [2009-05-15 16:04:49] TheMissingLINQ

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."


18
[+3] [2009-05-15 16:17:56] community_owned

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.


19
[+3] [2009-06-15 19:06:41] Sylvain

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 :)


20
[+2] [2009-11-29 17:04:03] Matt S.

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.

  • GO TO A USERS GROUP MEETING WITH
    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.

  • DON'T FORCE HIM TO SAY HE DOESN'T KNOW EVERYTHING, HE'LL REALIZE IT SOON OR LATER (and won't admit it)

  • 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.

  • IT TAKES TIME, BE PATIENT.

Oh yea, a biggy:

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

21
[+2] [2009-05-15 13:25:54] RobS

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).


22
[+2] [2009-05-15 13:15:16] Mohammed

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 ..


23
[+2] [2009-05-15 12:12:03] pgb

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. - romandas
24
[+2] [2009-05-15 12:12:40] Slim

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


(1) If not the only thing it's of course the most important. - VVS
25
[+2] [2009-05-15 12:51:26] rashfeather

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.


26
[+2] [2009-05-15 12:37:56] David Rutten

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.


27
[+1] [2009-05-15 12:39:24] Joonas Pulakka

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.


28
[+1] [2009-05-15 12:34:17] Timo Geusch

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...


29
[+1] [2009-05-15 13:13:57] Polo

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...


30
[+1] [2009-05-15 13:33:13] community_owned

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!


31
[+1] [2009-05-30 09:37:38] kdt

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.


32
[+1] [2009-11-29 16:51:57] Pascal Thivent

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...


33
[+1] [2009-05-21 05:47:30] outis

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.


34
[0] [2009-05-28 13:02:03] Chris Needham

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


35
[0] [2009-07-09 00:16:16] Adrian Panasiuk

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).


36
[0] [2010-03-19 13:51:41] Łukasz Lew

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

[1] http://www.kogics.net/sf%3akojo

37
[0] [2009-05-15 13:49:02] Sylverdrag

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.


38
[0] [2009-05-15 13:18:39] Søren Elverskov

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.


39
[0] [2009-05-15 13:21:30] community_owned

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


40
[0] [2009-05-15 13:27:01] Pete Duncanson

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 :)


41
[0] [2009-05-15 15:30:03] J. Polfer

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. :)


42
[0] [2009-05-15 15:15:29] Brian Postow

Horse; water; think...


43
[0] [2009-05-15 17:12:12] Jas Panesar

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.


44
[0] [2009-05-16 01:37:36] johnny

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


45
[0] [2009-05-21 04:42:36] MrDatabase

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


46
[0] [2009-05-15 12:56:27] Etienne

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!!


47
[0] [2009-05-15 12:41:31] jens

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 - kpollock
48
[0] [2009-05-15 12:23:22] Binary Worrier

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


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. - ChrisW
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
(2) 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
(1) 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. - ChrisW
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). - ChrisW
(1) "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. - ChrisW
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". - ChrisW
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
49
[-1] [2009-05-15 16:42:23] Tim Scarborough

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...


50