How not to teach programming

re: How not to teach programming

Alfred Thompson — Thu, 23 Dec 2010 21:52:03 GMT

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.

re: How not to teach programming

Spencer — Thu, 23 Dec 2010 09:09:06 GMT

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.

re: How not to teach programming

Alfred Thompson — Wed, 22 Dec 2010 22:10:14 GMT

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.

re: How not to teach programming

Whyld — Wed, 22 Dec 2010 20:52:54 GMT

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

re: How not to teach programming

Alfred Thompson — Wed, 22 Dec 2010 19:07:01 GMT

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.

re: How not to teach programming

Ely_Bob — Wed, 22 Dec 2010 18:32:48 GMT

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

re: How not to teach programming

Alfred Thompson — Wed, 22 Dec 2010 14:36:43 GMT

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

re: How not to teach programming

Rob Miles — Wed, 22 Dec 2010 09:45:54 GMT

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.

re: How not to teach programming

Dave — Wed, 22 Dec 2010 09:33:47 GMT

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.

re: How not to teach programming

jake — Wed, 22 Dec 2010 07:17:28 GMT

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!