Things I Learned While Teaching Java (part 2)
May 10, 2014
I blogged a similar thing a few weeks ago. Coincidentally, I also taught a 5-day Java Boot Camp this week (HTML5, Angular JS, and Android Programming classes are scheduled for the near future). A few more interesting observations in this class...
A woman in the front row asked "What's a GUI?". She claimed to have an IT background. Is this a generation gap thing?
Lots more COBOL programmers signed up for this class. Whoever said COBOL had died off in the 60's was wrong. 10 students, at least 5 were COBOL people, happily writing COBOL code for a living in 2014.
I still don't like some things about Eclipse, but I'm becoming less annoyed with it the more I use it (for Java development anyway).
The only good way to teach people about "implementing an interface" is to flat-out steal the "SimUDuck" example from the Head First Design Patterns book. Any other examples just confuse junior developers too much. Believe me, I've tried them all. (And starting with "it acts like a contract with your code" only makes matters worse.)
I still don't think I should have to write a constructor in a child class if ALL it's doing is calling super("foo"); and handing "foo" to the parent class. The authors of Java disagreed.
Class variables defaulting to "protected" is fine, even if I forget once in a while and tell students the default is "public", then have to back-track. What's NOT okay is that "protected" variables in Java are visible to any class in the same FOLDER even if it doesn't extend the parent. I don't think I've ever used this in a real app, and I tell students to just avoid it in their code too.
Despite all the hype languages like Ruby and Groovy are getting these days, I find it's NOT possible to just throw junior developers straight into OO. I've taught Java dozens of times. I've had ONE student that grokked the OO concepts on the first try. Everyone else gets completely tripped up and needs to start with the basics...variables, for() loops, if/else statements, basic variable scoping, etc. Any time I try to go faster and start with a more OO approach, the entire class gets confused.
Remember...there is a difference in "I have never programmed before in my life, and I'm starting with Grails" and "I've programmed for 20 years and am just now learning Grails". Syntax is easy. Getting someone to go from "what is a for() loop" to "private static variable that inherits from the base class" is not always as simple. :)
-nolan
A woman in the front row asked "What's a GUI?". She claimed to have an IT background. Is this a generation gap thing?
Lots more COBOL programmers signed up for this class. Whoever said COBOL had died off in the 60's was wrong. 10 students, at least 5 were COBOL people, happily writing COBOL code for a living in 2014.
I still don't like some things about Eclipse, but I'm becoming less annoyed with it the more I use it (for Java development anyway).
The only good way to teach people about "implementing an interface" is to flat-out steal the "SimUDuck" example from the Head First Design Patterns book. Any other examples just confuse junior developers too much. Believe me, I've tried them all. (And starting with "it acts like a contract with your code" only makes matters worse.)
I still don't think I should have to write a constructor in a child class if ALL it's doing is calling super("foo"); and handing "foo" to the parent class. The authors of Java disagreed.
Class variables defaulting to "protected" is fine, even if I forget once in a while and tell students the default is "public", then have to back-track. What's NOT okay is that "protected" variables in Java are visible to any class in the same FOLDER even if it doesn't extend the parent. I don't think I've ever used this in a real app, and I tell students to just avoid it in their code too.
Despite all the hype languages like Ruby and Groovy are getting these days, I find it's NOT possible to just throw junior developers straight into OO. I've taught Java dozens of times. I've had ONE student that grokked the OO concepts on the first try. Everyone else gets completely tripped up and needs to start with the basics...variables, for() loops, if/else statements, basic variable scoping, etc. Any time I try to go faster and start with a more OO approach, the entire class gets confused.
Remember...there is a difference in "I have never programmed before in my life, and I'm starting with Grails" and "I've programmed for 20 years and am just now learning Grails". Syntax is easy. Getting someone to go from "what is a for() loop" to "private static variable that inherits from the base class" is not always as simple. :)
-nolan