Agile Java: question for beginning Java developers (i.e. most of you here)

[Jeff Langr]

A lot of my goal in writing Agile Java was to figure out a way to make it easier for beginning Java developers to come up to speed in Java. The posts here regularly demonstrate a good amount of pain involved in building small bits of Java code.

My question for you: What do you find most difficult about learning Java?

thanks,
Jeff

[miguel lisboa]

i learned strictly by myself, with books(thinking in java and head first java) and net (mainly forums and java sun tutorial).
i guess the harder was to get all the pieces together: instance variable, initialization, static, references, classpath, constructor, and so on. Work with all those notions in a very simple app was hard, because most of it made no sense. What i mean: when i read about them, ok, i understood, but afterwards, aplying it in the whole scenario of a concrete app was a diferent ball game.
Only sensibly an year after i started to see the light: polymorphism, object oriented.

[Junilu Lacar]

This is from the point of view of one who has to teach other developers. As Miguel alluded to, it's not so much the syntax that's difficult to grasp but the higher-level concepts of good OO design principles and design patterns and how to apply them in Java code that's difficult. It's good to see that you touch on some design principles and patterns in your book.

It does help if the person you're trying to teach is actually interested in learning about these though. I recently tried to explain the article "The Paperboy, the Wallet, and The Law of Demeter" to a some colleagues I was pairing up with and all I got was some smartass remarks :roll: . I still managed to show them the essence of the article though, through code examples. Maybe it was just me...

I'm obviously not a complete beginner, but to answer the question as one who is still learning about Java, I think the most difficult concepts for me to grasp (even now) are concurrency and threads. Doug Lea's book is my bible for this. As for new Java 5.0 features, annotations look absolutely foreign to me (although I haven't really spent time trying to learn more about them).
[ March 10, 2005: Message edited by: Junilu Lacar ]

[M Beck]

static typing, polymorphism, and casting (implicit and explicit). this is tricky for me to keep straight in any statically typed language, because i've been completely spoiled with the dynamically typed ones i've learned.

most Java texts seem to do a good basic overview of types and even casting, but i think it might be good to make a note of how polymorphism interacts with argument typing. it took me a while to understand what polymorphism worked because i couldn't seem to make the proper connections between those at first, and none of the texts i was using came right out and said what they were.

i don't know if autoboxing will make this issue easier or harder; on the one hand it'll eliminate some of the ugly syntax involved in casting, but on the other hand it might tend to just hide what's going on behind the scenes - if textbooks start to rely on autoboxing in order to push a thorough discussion of type conversions to a later point in the learning curve, i think people with my sort of mind (if there are any others, that is) might just get more confused.

the package/module system and how it interacts with the access control (public, private, protected) system. i'm still not at all clear on this, but i know it's important; how else can you avoid unmanageably long source code files?

a good discussion of techniques for keeping classes short, concise, and readable. that might be more of a style issue, but i feel it's an important one; multiple-thousand-line classes are unwieldy, hard to read, and hard to manage. Java is a very verbose language, to the point where hints and tips for combatting this backdraw would be handy even in a beginner's text.

a basic overview of the most commonly seen patterns and idioms in the API. mentioning the "factory" pattern, for example, would be worthwhile. it gets used a lot, but it isn't used exclusively, and the syntactic differences between classes in the API that use it and classes that can be instantiated directly might be confusing.

[Jeff Langr]

Originally posted by Junilu Lacar:
It does help if the person you're trying to teach is actually interested in learning about these though.

There's that. That's one of the quandaries I've come across: Most of the people who need to learn about the better way to do things just don't care. To the rest, it's often stating the obvious.

-Jeff-

[Jeff Langr]

Originally posted by miguel lisboa:
Only sensibly an year after i started to see the light: polymorphism, object oriented.

It took me quite a while, about 15 years ago when I first started getting into OO, to "see the light." I mentioned to another poster in a private message that I struggled with OO considerably at first. And that I honestly wish I'd learned it through doing TDD--it seems like it would have been a lot simpler way to pick it up.

-Jeff-

[Jeff Langr]

Originally posted by M Beck:
a good discussion of techniques for keeping classes short, concise, and readable. that might be more of a style issue, but i feel it's an important one; multiple-thousand-line classes are unwieldy, hard to read, and hard to manage. Java is a very verbose language, to the point where hints and tips for combatting this backdraw would be handy even in a beginner's text.

This has ended up being my number one crusade: getting developers to code in a way that is easily maintainable. I personally think it's the biggest problem in most systems.

I'm working on a system now where there's a class with a few 1000+ line methods. This code has a lot of comments, but enough of the comments are lies or simply useless. I made a small change to this class today. Had this class been coded properly, it would have taken me less than 5 minutes to figure out where the change goes. Instead, I had to wade through the entire method to figure out what it's doing and thus where my code belonged. Doing so, I uncovered rampant redundancies.

Time spent = 90 minutes, or more than eighteen times as long as it should have taken. Unfortunately, this kind of experience isn't atypical with respect to most systems.

Jeff

[Mark Vedder]

While I am not a beginner (nor a guru yet), I still remember some of the struggles I faced when I first learned programming. One thing I found frustrating was that no one showed me a good process to follow when doing my programming. In other words, how do you actually type the code?

Jeff alludes to this in another thread:

The thing I've observed most is that beginning Java developers seem to trip over a lot of simple things. They code too many lines at once before getting feedback. They then post 50+ lines of code and ask others to spot the error that they can't figure out.

I agree with his assessment. And this is what I mean when I say the process of "typing code in" is not taught.

It turns out that the process I developed as I was learning was a good one. I found myself writing a very small part of the solution, and then testing the heck out of it. I would often write other mini-applications or classes just to test that small part; sometimes I would simply be testing a single line of code, such as a compound logic expression, to make sure my if statement worked as I expected. I would "wrap" this single expression in a separate runnable test class. As my experience grew, I would not necessarily break it down so finely, but I would still write very small chunks of code, and test them throughly. That way I could isolate problems (both syntax and logic problems) quickly and easily.

The hard part was, all the while I was doing this, I didn't know if this was a good thing or not. It was unbeknownst to me at the time that I was using a form of test-driven development (TDD). Without doing some research on time lines, I do not know if TDD (or JUnit) was even a concept at that time. All I knew was that it worked for me.

I think that academia assumes you will learn good processes either by osmosis, divine intervention, or, most likely, via apprenticeship once you are out in the industry. There are, however, two major problems with the latter method: 1) it only occurs after students have learned many bad habits; 2) it assumes the student's first programming job will be in a large shop with available mentors.

In my case, my first programming job was on a three person team. All of us were very novice programmers. Our project manager was not a technical project manager, let alone one familiar with Software Development Life Cycles or Development Processes. I went about coding the way I always had; write a little, test it. Write a little more, test it. The problem was that it resulted in my taking significantly longer to code my portions of the project then my coworkers who could pound out code quickly. (The fact that I was not using an established testing framework added some delay since I typically had to develop my test classes from scratch, although I did do a lot of "copy 'n paste" coding to reduce the burden).

Since project managers are only happy with check marks on the project plan, I was viewed as being the weak link; the slow guy. My vindication only came once we piloted the application. A little over 100 bugs were found during pilot. Only one in the code I wrote; the remainder in the other two developers' code. They then struggled to find ways to reproduce & isolate the bugs and fix the issues. I simply called up my test code, and saw that I failed to test for a very unique case. I added that case to my test code, allowing me to isolate and quickly fixed my bug.

When I learned about the process of writing test code first (such as TDD and portions of XP), and of things like the JUnit framework, it was not a "eureka" moment for me; it was a great validating moment. I realized that I was not a freak of nature, but had been following a process that others in the industry felt was a good process. (Learning about JUnit was a great "hey, this will save me a lot of work" moment.)

So after all that back story, my question for you Jeff, and the rest of the JavaRanch community) is this: is there a fundamental problem with the pedagogical process - both in academia and in the available literature - used to teach programming today? I often believe that the current process is too disjointed. We learn language syntax, design, UML, build scripts/processes (Ant), version control (CVS, Subversion, etc), data structures, documentation, processes (XP, agile, etc), patterns, and other areas of programming, all in separate and typically disjointed courses & books.

My dream would be a series of books and/or courses such as Programming Part 1, Programming Part 2, ... Programming Part n that taught all these areas, a little bit of time in a cohesive manner. You would learn the basics of Ant, UML, CVS, JUnit, JavaDoc, and Java Syntax as you wrote your first Hello World program; then as you wrote your next small application, you learned a little more about each of these. Most importantly, you learn about them in a cohesive and comprehensive way. I realize that the sheer size of such an undertaking, and the nature of the publishing industry, likely make this an unrealistic dream for a series of books, but I was hoping academia might start working towards this. Since I am obviously unfamiliar with ever CS program in the world, maybe there is a CS academia program out there that is doing such a thing. Does anyone know of one? What are people's thoughts.

Based on some comments he has made in other threads, it appears Jeff's book Agile Java is doing this to a some extent. Not just teaching Java Syntax, but a process of programming. I really think this is needed in our industry. I look forward to taking some time and looking through the book. Hopefully it is a start of my dream being realized.
[ March 10, 2005: Message edited by: Mark Vedder ]

[Jeff Langr]

Originally posted by Mark Vedder:
is there a fundamental problem with the pedagogical process - both in academia and in the available literature - used to teach programming today?[/i][/b] I often believe that the current process is too disjointed. We learn language syntax, design, UML, build scripts/processes (Ant), version control (CVS, Subversion, etc), data structures, documentation, processes (XP, agile, etc), and other areas of programming, all in separate and typically disjointed courses & books.

Thanks for the nice post Mark! I'd have to answer "yes" to your core question. I think the pedagogical process is a bit of a mess. Certainly there are people who've tried to rectify this, but most of the efforts are spent on after-the-fact re-education. It seems bizarre to teach students how to program in an OO language such as Java, and then go back and teach them that what they learned will work, but it's not really an acceptable way to program. Most of the Java books I pick up have examples that work just fine, but exhibit all sorts of bad programming practices.

Steve McConnell's, Code Complete is a great book (I should know, my name's in the latest version ), considered essential reading by many. But who reads it? Most developers don't and won't bother (it might help were there a Java specific version, a C++ version, and so on). Yet the lessons it teaches are core to solid development. The only way to ensure everyone learns these lessons is to couple them with the first baby steps of all programmers.

Here's a frightening analogy to what we do: Take a medical student. Teach them basic anatomy using the book Gray's Anatomy, which shows them where everything is and how it all connects. Now give them a scalpel and a pretty face, and hope they've taken the time to read http://www.plasticsurgery.org/medical_professionals/publications/Plastic-and-Reconstructive-Surgery-Essentials-for-Students.cfm.

I can't guarantee that Agile Java solves all these problems, nor can I guarantee that I don't demonstrate practices that others consider bad. But the approach I take using TDD is accepted by a large community. And while you can't possibly cover everything in a 750-page book whose core goal is to teach basic Java programming, Agile Java does hit on many of the key points that beginners need to understand.

Ultimately, the best resource is a patient mentor. Development is a craft in which the master-apprentice relationship works well.

-Jeff-

[miguel lisboa]

My dream would be a series of books and/or courses such as Programming Part 1, Programming Part 2, ... Programming Part n that taught all these areas, a little bit of time in a cohesive manner. You would learn the basics of Ant, UML, CVS, JUnit, JavaDoc, and Java Syntax as you wrote your first Hello World program; then as you wrote your next small application, you learned a little more about each of these. Most importantly, you learn about them in a cohesive and comprehensive way.

Head first java doest it! not thoroughly but does it. and has a pleasant and working sense of humor.

My first book was thinking in java but that was, at the time, too much for me. HFJ opened many doors for me - test first, writing pseudo code (which in my opinion strenths the understanding of what is on the table), but mostly made me feel more confortable with the language itself: methods, instances, how the stack works and so on. All that while building light, efective and enjoyable very small working apps.

A couple of months ago i hesitated before buying Head First Design Patterns but in the end bought the book that made me realize what really OO is about: i refer to Design Patterns Explained 2nd ed.

i'm very enthusiastic about trying to teach java upside down, like author does (i supose) in this agile java book

[miguel lisboa]

Ultimately, the best resource is a patient mentor. Development is a craft in which the master-apprentice relationship works well.

i'm a bridge enthusiast and this friend of mine's dream is to get a pro-am partnership.
A couple of days ago i answered a post here and in a short time after a senior member just corrected me. at that point i too whished i could have a pro-am partnership in doing java. I guess my improvement would be supersonic
[ March 10, 2005: Message edited by: miguel lisboa ]

[Mark Vedder]

Originally posted by Jeff Langr:

Steve McConnell's, Code Complete is a great book (I should know, my name's in the latest version ), considered essential reading by many. But who reads it? Most developers don't and won't bother (it might help were there a Java specific version, a C++ version, and so on). Yet the lessons it teaches are core to solid development.

I have started this book a couple of time, but always seem to get pulled off it as I have a sudden need to learn some latest and greatest technology or framework. From the parts I have read, I agree it is a great book. I keep saying I need to read it completely and learn some of the core fundamentals better.

Ultimately, the best resource is a patient mentor. Development is a craft in which the master-apprentice relationship works well.[/QB]

That is why I frequently wish I had a mentor. As I read some of the JavaRanch posts/responses from the advanced developers I often find myself wishing I had someone of that caliber to work with. There's a couple in particular I would almost be willing to work with for free just to learn from them. We won't mention any names to avoid embarrassing them (I am keeping my eyes open for other opportunities in a larger shop where I could find such a mentor.)

Again, though, I think the reason the master-apprentice paradigm is not working is that even when it happens, we are preceding that relationship with an academia environment in which the would be appentice is learning too many bad habits; the master is not getting a blank slate to start with. On top of that the high-paced market driven reality of the corporate world today often precludes such a relationship from occurring.

[Sean Magee]

Hey there!

I can definitely say that I am an official beginner. I have been coding in java for approximately 6 months. I feel as if i have different struggles with java than other beginners, but hey, what do i know? To answer Jeff's question I would like to list problems I do and do not have with java.

1. The biggest problem, by far, is being able to approach a problem or program effectively, effeciently, and coherently. I swear, I try the UML and I try to think as hard as I can to scribble down psuedo code as much as possible. However, it always seems like the Brain Lightning never starts striking until its just the computer and I, one on one. And I know this is very bad.

2. Container classes, and using them correctly has been a problem for me as well, someone care to explain exaclty why i use an Iterator? (please dont actually answer that in this forum )

3. So far, what I have actually dived into with OOP hasn't been as difficult as it has been enlightning, however, I do stumble when trying to understand how to use OOP as effectively as possible.

These are just a fragment of some of the big problems I have, and there are some the I am probably unaware of. A lot of these problems can be demonstrated with a new program, I just wrote,

https://coderanch.com/t/398886/java/java/design

[Mark Vedder]

Originally posted by miguel lisboa:

Head first java doest it! not thoroughly but does it. and has a pleasant and working sense of humor.

I agree that Head First Java is a phenomenal book, as is the whole series. I am consistently recommending the books to others, especially beginners.

Head First Java solidified many concepts for me that previously I thought I knew, but ultimately only had a cursory understanding of. Head First Servlets & JSP did the same. (I primarily develop enterprise Web Applications.) Head First Design Patterns was the first time I was able to "get" design patterns. I think the Head First books do a great job at teaching their respective disciplines, and are sprinkled a little with other disciplines. However, in the end they each are treaties of distinct subject matters. Their primary focus (or "thing") is they use a fundamentally different cognitive method of teaching. I think that method is great and works very well.

My ultimate dream is to have everything taught together and simultaneously in a cohesive manner. I realize that this is ultimately one of those "nice in theory but nearly impossible to implement" type of things (at least as far as a book series is concerned). But I presented it here as a point for discussion.

[Jeff Langr]

Greetings Sean,

I noted a dozen or more things that you could improve upon with your scheduling program; I quickly rattled off three in response. While the code you wrote isn't terrible, it's already getting too big for its britches. In other words, were you to develop a sizeable application without tightening up your approach, you would begin to have difficulty maintaining it.

The thing I like about TDD is that it teaches you to solve a problem in terms of goals. You first specify what you expect to happen in a test. How do I want to interface with this class that I'm creating? What's the simplest way for me to accomplish my goals? How do I know whether or not the code actually accomplished those goals?

This gets you thinking in terms of how to organize and compartmentalize code to meet your goals. If you can't figure out how to write a simple test for code, then it's in all likelihood poorly constructed. The ability to test your code is one of the most significant indicators of good design--it bears directly on what is referred to as low coupling.

How would you write tests for the code you supplied in the other thread? It'd probably be pretty difficult. How might you construct the code to allow you to more easily test it? That's what TDD teaches you. As one of many side effects, your design will dramatically improve. As another side effect, you'll have code that actually works right the first time around.

-Jeff-

[Jeff Langr]

Originally posted by Mark Vedder:
I agree that Head First Java is a phenomenal book, as is the whole series. I am consistently recommending the books to others, especially beginners.
...
Their primary focus (or "thing") is they use a fundamentally different cognitive method of teaching.

I think it's important to recognize that there are many approaches to teaching/learning. Up until recently, the one-size-fits-all mentality has dominated in the teaching of software development. The Head First books are great at serving a significant segment of people who learn best through right-brained approaches. That segment doesn't include me, but that of course doesn't mean it's a bad approach. I often will try to suss out what a would-be programmer best responds to; in a number of cases I've recommended HFJ as the most appropriate starting point.

One big distinction that I'll make about Agile Java (pitch time) is that it's a technique that stays with you. TDD should help you learn more rapidly and with greater retention, due to its high levels of feedback. But it also ends up being a professional technique, not just an academic means, that you can carry throughout your development career.

I'd love to see a Head-First Agile Java.

-Jeff-

[miguel lisboa]

I'd love to see a Head-First Agile Java.

[Mark Vedder]

Originally posted by Jeff Langr:

I think it's important to recognize that there are many approaches to teaching/learning. Up until recently, the one-size-fits-all mentality has dominated in the teaching of software development.

I agree whole-heartily.

Originally posted by Jeff Langr:

I'd love to see a Head-First Agile Java.

Sounds like a good next project for you. Drop Kathy & Bert a line...

[Junilu Lacar]

Originally posted by Mark Vedder:
I think the reason the master-apprentice paradigm is not working is that even when it happens, we are preceding that relationship with an academia environment in which the would be appentice is learning too many bad habits; the master is not getting a blank slate to start with. On top of that the high-paced market driven reality of the corporate world today often precludes such a relationship from occurring.

I am currently working on a state-sponsored project where the contract specifically calls for pair programming and test-driven development (unfortunately, other agile practices have been deemed too extreme). We are into iteration 13 right now and the client only recently noticed that pair programming and TDD are not being truly practiced. So, I have been asked by management to help spearhead the effort to work these practices into our daily development efforts. Ironically, it's the developers who are skeptical and are giving me the most resistance to doing pair programming and TDD. The most common reason given is "We're already finding it hard to finish our work as it is, now we have to pair up and write tests first? We don't even have detailed designs yet!"

There are, as I am finding out first-hand, many different forces that cause resistance to adapting agile methods and developer bias and pressure from management to get things done are just two major forces. However, as a developer I remain optimistic that as TDD and agile methods continue to be validated by successful implementations, the tide will turn and agility will become the norm rather than the exception. You gotta believe!

[Mark Vedder]

I am a proponent of TDD. As I mention above (in my long, exciting, and griping story), I have been using TDD, or at least a form of it, since I first started learning to program. As for pair programming, I have never had the opportunity to try it, but have read some very favorable studies and articles on the subject. I could see why it would be beneficial. My comment about the master-apprentice relationship, however, was not referring to pair program. It was in regards to the school of thought that novice developers (i.e. the apprentice) will learn the trade under the careful and patient tutelage of a senior developer. I just do not think that is happening any more like it once did and it suffers from the problems I listed. Given the opportunity though, I would jump at the chance to "study" under a good master developer and learn more of the craft from him/her.

[Jeff Langr]

Originally posted by Mark Vedder:
I just do not think that [the master-apprentice relationship] is happening any more like it once did and it suffers from the problems I listed.

I agree, it's not happening, and often when it does, it's too late. Hence one of the things I tried to do with Agile Java is make it palatable for the university market as well as mass markets. Each chapter contains exercises and there are, not-so-coincidentally, 15 chapters to match a typical 15-week university course.

The McBreen book Software Craftmanship is an interesting read. Many good ideals, but as you suggest, most of it is highly unlikely to occur within today's culture.

-Jeff-

[Junilu Lacar]

Originally posted by Jeff Langr:
The McBreen book Software Craftmanship is an interesting read. Many good ideals, but as you suggest, most of it is highly unlikely to occur within today's culture.

Yeah, especially the part about good developers getting paid more than the people who manage them.

[Jeff Langr]

Originally posted by Junilu Lacar:
Yeah, especially the part about good developers getting paid more than the people who manage them.

I've been in a number of places where the top developers/architects are making more than their managers. But I'm not always in tune with what the managers are getting. I'd be curious to see stats on that.

One of the other interesting things I remember is that McBreen suggests that entry level developers should be making around $30,000-$40,000, instead of the $70-$90 thousand they were getting at the time, and that "master" developers should be making up to ten times that, since they can be at least ten times more productive.

-j-

[Ilja Preuss]

Originally posted by Sean Magee:
1. The biggest problem, by far, is being able to approach a problem or program effectively, effeciently, and coherently. I swear, I try the UML and I try to think as hard as I can to scribble down psuedo code as much as possible. However, it always seems like the Brain Lightning never starts striking until its just the computer and I, one on one. And I know this is very bad.

I might open a can of worms here, but I think you are wrong. It isn't bad, it's just natural.

The problem with UML and pseudo code is that it doesn't execute. They don't give you the feedback running code gives you. As a learner, you need as much feedback as fast and often as you can get.

During the first years of learning programming, I always struggled with the same problems - I tried to come up with some design, coded it, after some time realized that I did get it badly wrong, had to start over and felt worse and worse for it.

Things changed when I read "Refactoring" by Martin Fowler. I realized that I didn't need to get the design "right" up front, that I could improve it over the time, while I learned what a good design actually looked like. The next project I started was the first one I didn't maneuver into a dead end - not because the design I started with was better, but because I didn't have to get it right from the beginning.

That's not to say that UML and pseudo code aren't usefull tools - they are. But I think they are mostly usefull to the *experienced* developer, the one who can "see" what the code to a diagram will look like, who has experience with what forces will show up in the code when you start to implement a design - to the developer who can make up for the missing feedback with his gut feel, guided by past experience.

I just wish Jeff's book would have been available when I was starting to learn Java. (I didn't read it yet, but I expect it to be much better targeted at beginners than "Refactoring" was...)

[Ilja Preuss]

Originally posted by Mark Vedder:
is there a fundamental problem with the pedagogical process - both in academia and in the available literature - used to teach programming today?

Speaking about academia, I think one *big* problem is that teaching is not their only or even primary goal - another one is research. And as the people who teach and who research are the same, they naturally prefer to teach about the topics they research. Unfortunately, many of the things that lend themselfs to being researched, for example because they are easy to transform into mathematical models, are quite irrelevant in practice; and many of the things that are vital in practice would be rather impractical objects for reasearch.

[Karen Baog]

I am a student. And a beginner for that matter.

The problem I see is that Instructors, like most authors, don't have an understanding of teaching methodologies.

An expert might write a simple line of code. To this person, it can't get any simpler, because the person knows what it means. For a beginner, it can be a huge task to understand it.

Instructors (and authors) must need to fully evaluate the audience they are trying to reach, and not generalize everything.

A lot of Instructors have the tendency to "prove" something. What's their point of "impressing" everyone?

Here I am, learning Java. The instructor wants to introduce GUI straight away (hard-coding and no drag/drop), when a lot of my classmates can't even understand what a constructor is for, and the whole notion of classes!

To cite an example, the instructor shows a code about initializing variables using a constructor, but not explaining what this constructor is all about, that it is automatically generated if you don't write one, etc.

[Jeff Langr]

Greetings Karen,

Thanks for the posting. It sounds like a familiar dilemma, one that I've faced myself from both sides.

What books and/or instruction techniques have you come across that you've responded well to?

thanks,
Jeff

[Karen Baog]

For a really, really "intro" books on Java, I have to say the HFJ has the best approach; "funnily serious", i have to say.

Some people would belittle their approach. But the problem is, these people are already java "experts"; and I therefore believe they have absolutely no right to criticize it. Let the target audience make the criticism. Better off for them to b*** off.

How I wish something similar for a basic, bare-bones Outliner program is available. Kathy, do something!

See, this is what I need to do(It's OK - have a good background in C++ GUI). I have no clue just yet. I could write up something equivalent using Borland Builder C++, but using Java, I have no idea, and it's due soon! Well, I guess I'll have to do this course again. Oh no! I don't want to.
I've posted a question on Outliner program in the Swing site, and hope that I would get some response.

So you see, the instructor failed to evaluate the different strengths and weaknesses of the target audience. Some have only done Mathlab, or programming (really just configuring) specific machines! A classmate of mine said she knows the format has to be written that way, but admitted she doesn't even know why. She doesn't understand the dot notation either. But the instructor failed to understand this and just goes on "proving" to us how good he is, blah, blah, blah. Well, we already know he's a java guru, otherwise he wouldn't be standing in front of us (beginners).

Here's my 1-cent worth of advice: authors and instructors alike to consult a formally-trained educator (people who majored in teaching or education)before picking up that pen (or should I say powering up that laptop). It does not necessarily follow that a professor is a good educator. There's more to the subject matter. The deducator doesn't need to know programming; In fact, it's a plus.

I've studied many programming languages (VB, C/C++, C#) and I went through lots of pain because the approach of authors of books just isn't in tune with its target audience. Maybe, I bought the wrong books. It wasn't until I came across HFJ that I thought learning a new language, albeit basic, isn't too painful after all.

[Karen Baog]

Hi Jeff,

I've looked at the reviews at Amazon of your book. It sounds good.
Maybe, I'll get that, when I save up enough money.

[Matt Moran]

I'd like to see a book in the Head First style that deals with more in-depth intermediate to advanced J2SE topics, like how to put together the stuff learned from HFJ, when to use composition as opposed to inheritance, how best to decide on access levels when designing classes, with more exercises based on real-world programming tasks you're likely to come across. And maybe more in the way of "What's wrong with this code" type exercises where maybe the code compiles and runs, and it looks alright, but you get something unexpected from it. And definitely more in the way of Swing tutorials - like what Kathy & Bert did with the Box and Border layouts in HFJ, only with Gridbag & trying to model common app layouts with that accurately so that the app doesn't look like a dog's dinner when you resize it.



I'm just getting to the end of HFJ now, and I'm quite hungry for more - what would people recommend as the next step?

[Ben Wood]

I was taught Java first in 2000 as a major part of a 1 year post-graduate qualification (MSc in England, not sure on the equivalent elsewhere). The lecturers were all self-taught programmers whose main work was scientific rather than IT. It was not a pretty sight - 10 bewildered students sitting in a lab every afternoon for 12 months!

All I was taught was what Java looked like, rather than how it was put together. My class mates and I then struggled through the rest of the year trying to understand what on earth was going on. Looking back I think the problem was that OO was never properly explained, we started writing Java code in a procedural way, leading to horrible code with 5000 line classes containing 1 method

These days I teach Java a little myself; a 3-day internal course on the basics. It's a lot to fit into 3 days! What I try to do is cover enough so that they each make something interesting that is created in a nice OO way, and explain why they are doing this. On the last course which I ran a few weeks ago I also decided to make them work in pairs and do the design of the software themselves and bring in CRC card workshops which seemed to work really well, I think they got the OO stuff much better than previous times.

Anyway, to summarise, I think the biggest problem is that courses concetrate on the syntax too much. Like somebody said earlier, the syntax is not the problem for beginners, the problem is why and how you are using it. Teach good OO and explain the fundamental concepts properly and the rest will fall into place much quicker IMHO. I also think the point about writing the least amount of code that will work, and then testing it is an extremely useful approach, especially for beginners. Like you say, beginners will post 50 lines of code they just wrote and tried to compile for the first time and got an error. It's got to be easier to debug 1 line of code than 50
[ March 14, 2005: Message edited by: Ben Wood ]