How not to teach programming
Through the wonders of DZone I came across a blog post called Don't teach like you code. The target audience seems to be professional coders who are teaching beginners. It’s always interesting to read articles like this and part of that is to understand the perceptions that people have about teaching when they are not full-time teachers themselves. And this article does make some good points about how not to teach. Unfortunately the examples of how people, one presumes the author included, actually code are not what I want new programmers to learn. In fact this post was quite unsettling to me as someone who made his living writing code for 14-15 years and who still writes some when necessary.
The article has a line that reads “”But, good coding isn't like teaching at all. It promotes habits that are entirely counterproductive to the art of teaching.” Really? I’m skeptical. He goes on to say “”Part way through writing a method, you might decide you need to track things in an array. After a few minutes, you'll decide a hashtable works better.” Oh please in the name of all that is good in the world don’t let that be common among professional developers. Yes, that happens sometimes but it should be awfully rare. You should have thought things through in some detail before you started coding. If you are making big data structures in the middle of coding you clearly (in my opinion at least) were not ready to start coding at all.
On the other hand in teaching I would expect this to be more common. Specifically the lecture that worked well with one audience may not work as well with another. A good teacher sees this, adapts and tries to explain things a little differently.
And then there is this gem “Second, coding lets you cheat on the details. We compile our code not because we think we're done, but because we want to find out what we may have missed. ” No! If you run the compiler and get errors and warnings you should be surprised. Or at very least disappointed. Now maybe the author is using crummy tools. I am spoiled by Visual Studio which notices a lot of syntax and other errors as you are typing. And IntelliSense goes a long long way toward helping avoid spelling errors. This makes it easier to avoid missing things. But don’t people read though and self-edit before compiling any more? Some days I think we were all better off when programmers had only one or two chances to compile their code a day. Coding is about details. Cheating on details is a path to destruction.
The last line of the article is priceless. “How do you teach people well? It starts by knowing that what may make you a great programmer will not make you a great teacher.” Probably true. But you also have to understand what makes a great programmer. I think a lot of programmers have a much higher opinion of their coding ability than is warranted. I never saw myself as a great programmer BTW. In fact I know what a great programmer is and how they work. I’m pretty sure I don’t have it. But I know enough about it to teach it. Like a great football coach who has never thrown a touchdown pass or gotten a sack or kicked a field goal but who can help others do all those things better a good teacher is someone who helps others learn from the mistakes of others.
A great programmer may not make a good teacher because they may not understand how they do what they do in a way that they can translate for a beginner. But someone who speaks the language of software and can translate the concepts and ideas for beginners may make for a great teacher even if only an average (or even fair) programmer themselves. We still have to focus on what makes for a great programmer not what makes a lazy programmer though.
Comments
Anonymous
December 20, 2010
To be honest, I probably wouldn't be surprised if I had warnings/errors in my code, but I certainly would be disappointed. :)Anonymous
December 21, 2010
The comment has been removedAnonymous
December 21, 2010
The comment has been removedAnonymous
December 21, 2010
The comment has been removedAnonymous
December 21, 2010
I still code as if all i have is a notebook to jot down my code then when my turn comes, i will go type it into a jealously gaurded time-shared terminal which gives very useless error messages when it finds a bug. I paint works of art that are as error free as possible and pretend that the reviewers are ax-murderers who know where I live. I learnt to code using Turbo C for chrisakes. That IDE was klingon and never coddled the weak. Now while I use Visual Studio and Coderush, I have never forgotten my roots and the illustrious shoulders on which I stand. NEITHER SHOULD MY STUDENTS!Anonymous
December 21, 2010
Not taking the p!ss, just thought this statement was funny in its irony: "And Intellisence goes a long long way toward helping avoid spelling errors." It's "Intellisense", no? Possibly "IntelliSense" but you get the point.Anonymous
December 21, 2010
As someone who has written code for money I kind of understand what he is saying. And it is a fact that a good programmer can "code themselves out of trouble" if the requirements or the design are broken and the project is not that big. But this should not be the default position. For people with such a naive approach to development I have three simple words of advice: Read. Steve. McConnell. http://www.stevemcconnell.com/ I would not take any developer (or teacher) seriously who has not read Code Complete and Rapid Development.Anonymous
December 21, 2010
@Dave Clearly I need to desk check my writing better and not trust the tools as much. :-) @Rob Completely agree about Steve McCommell's writing. I have copies on my book shelf. Just the other day I was thinking about putting together a list of must read books for professionals and teachers alike and Code Complete was first on my mind.Anonymous
December 22, 2010
I dissagree, even the best laid plans can after slight implementation need to be adjusted. And with the current trend towards test driven development and agile practices this is even more true today then it was 5 years ago. 90% of my job involves going into other peoples code and fixing their wrong assumptions about how the code should work, and how it actually does work. And there are tons of things that are syntacticaly correct but result in errors that you won't see until youve fired up the debugger... I agree fully with the statement which you've made light of. One of the worst things you can do as an educater is to imply to "fresh minds" that yours is the right way, or that they will not make mistakes if they plan ahead. I've been in acadamia in one way or another for over 20 years and I KNOW that there is nothing you can do as a educator to prepare a pupil for "the real world" if your using such draconian methadology as : Have a well thought out plan and it will always work... fixing mistakes and wrong assumptions is the art...Anonymous
December 22, 2010
I would never say "Have a well thought out plan and it will always work." Of course things change. And I have always taught students to write code to be modified and expanded. BTW I am not yet convinced that "agile" is not just a fancy work to justify "Ready, Fire, Aim" programming. Or programming without planning.Anonymous
December 22, 2010
Alfred I really have to respectfully disagree with you. 1. "You should have thought things through in some detail before you started coding." If your coming from the prospective of a new project or a large team effort then I agree. But many of us work in companies where your one of a half dozen programmers or less, sometime solo. So most often that new project is some VP’s brainstorm and you have till end of day to bring it to life. Or some email(s) you were handed from a user with minimal / incomplete information and you have to recreate a “bug” and then find a solution quickly before the company loses some substantial business. 2. “If you run the compiler and get errors and warnings you should be surprised. Or at very least disappointed.” Two things here, especially in web development your often blending compiled code with code that is outside of the compiler such as client side or db code. So running the compiler may be a way just to look at the solution run as a whole. Secondly you may have to make additions to very large solutions that contain many projects, and external services. It is totally not uncommon to have to compile before the gui will actually catch up and show you your errors, and it’s often much quicker then navigating back and forth between classes in several projects to figure out all the inputs and outputs. Just take your best guess do a quick compile and make the corrections it denotes and then compile for effect. ;) What makes a great programmer? A great programmer can listen to non-technical description of a problem or need, and can create a solid technical solution for that problem that is both maintainable and intuitive to the user base. – Best Regards WhyldAnonymous
December 22, 2010
Whyld, I see your point with large and web based projects where you are dependent on other code/platform to resolve some issues. On the other hand the less time you have to finish something the more important it is to plan out the solution before coding a fix. I was writing test code for a while and we had fast turn arounds as a rule. A problem found on an over night run had to have a fix before the next night's run. Planning time cut the debugging time way down. Understanding before coding.Anonymous
December 22, 2010
On the point of using the compiler to 'find things you missed,' I think you missed the original author's point. He is not saying that the compiler should or can be used in lieu of good programming discipline. He is saying that a programmer can (and commonly does) use the compiler as a reminder tool. For example, when I am making minor refactors such as adding an additional parameter to a method I will commonly change the method first. I then perform a compile just to get a nice list of all of the places where the method had been used so I can go through each and update them to use the new method signature. One of the examples the author cites is the 'non-returned value' error. I do that too. When writing a new class, I will often stub the methods in such a way that they do not compile. I can then go implement them one at a time. The compile error then serves me as a reminder that I forgot to complete one.Anonymous
December 23, 2010
There are a lot of great refactoring tools these days and I think that using them is a better practice than having the comipler find things. Even find and replace is a better frist step. At some point you will rely on the compiler to find missed things but a good refactoring tool handles things much better. Such as those built into Visual Studio for example. I like to have stub methods return a "not implimented" exception BTW. Also the use of the TODO: tag in Visual Studio is a great help for finding work left to be done.