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.
To be honest, I probably wouldn't be surprised if I had warnings/errors in my code, but I certainly would be disappointed. :)
For a short while (6 months) I worked at a business that wrote software for police agencies. After working there for a couple months I thought all programmers work in the “don’t plan, improvise” scheme. The programming department next to my cubicle was the post-deployment bug fixing, the “add a forgotten module that got lost in the bid” or the “add a customer requested modification the sales crew agreed to do without talking to the programmers” department. And it had to be done in two days to keep a customer happy. So I know what Ka Wai Cheung is referring to in his blog. Programmers that operate in that kind of environment practice horrible techniques that make programming teachers cringe. Speed, not elegance, is the driving factor.
A good IDE (like Visual Studio) does let you cheat on the details. All the little stuff; spelling errors, missing semicolons, missing parentheses, etc. are all caught before hitting the magic green arrow. Back in the days when men were men, computers were scarce and text editors and compilers were not friends I was super meticulous about typing and editing to catch anything before compiling and getting a nonsensical error report. Now my, and the kids, compiling errors are not simple typos, but major head scratchers. Teaching the kids to plan, not hack, has become a challenge because it is so easy for them to type something in that sort of looks good and then give it a try. Is just so easy to do the trial and error programming method when using a good IDE. I try to teach that fifteen minutes of planning will save an hour of debugging. They listen, then ignore. It is a lot more fun to hammer on the keys and hope something magical happens.
At a high level, I always "visualize" what I am coding long before I actually code it, but at a low level, sometimes because of syntactic noise, or easy optimizations I refactor shortly after I write it (I try to remain as flexible as possible for as long as possible).
Sometimes I thoroughly check the code before the first compile, but often it is just as easy to let the compiler tell me what's wrong. It saves on brain-power (you can stop concentrating so hard and get a breather).
Since my favorite error is off-by-one, I often code up the code, get the syntax verified by a compile, and then go back and re-examine all of the +1s and -1s to see if I botched any.
Given what I've seen of programmers just out of school, I highly suspect that the only real way of learning how to code well is by getting a mentor. The secrets are not in the syntax or semantics, they are in taking something extremely complicated and making it appear easy.
I remember the days when compiling was a big deal. You had to get your program to work perfectly within 3 compiles. Having syntax errors were a waste of a compile. And a stain on your reputation as a programmer.
I was recently at a .NET conference. The presenter was showing us all the awesome debugging tools and syntax helpers available in .NET. You should have heard the audience going "OOOOHHH" "AAAAAHHHH". They were using Notepad to code C## and VisualBasic. I was seeing debugging capabilities that were available to us in the 1990's and could not even imagine preferring to write programs in Notepad now. It makes me wonder what college kids are learning in school today.
As far as teaching high school students, you have to be able to relate these concepts to something concrete so that beginners have a reference point. I often have my students act out whichever concept we are covering, usually with props. You have to be able to teach them to plan, and convince them of the plan's usefulness - that it's not wasting their time. Otherwise, you do end up with programmers that can't make up their minds and write unsupportable programs because they did not have a top-down approach, even in object oriented programs.
And, I totally agree about being in situations where you have to put bandaids all through the code to make your clients happy. It happens. But it should not be taught by someone who believes that that is a normal way to operate.
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!
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.
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.
I would not take any developer (or teacher) seriously who has not read Code Complete and Rapid Development.
@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.
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...
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.
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 Whyld
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.
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.
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.