Call a Spade a Spade

[Pres Brawner]

It would help me a great deal if the nitpicking either came with a decoding ring, a translator, or a dictionairy.
I've seen things like "I might recommend", or "Some people have done x", etc. That's nice. I might like a cup of tea. Some people prefer coffee.
If it's broke, I'll fix it. If it's not, somehow convey that improvements are possible (not that I ever think my code is perfect). This gets back to my earlier discussion.
Those of us who submit need clarification. We are trying to learn a new thing. That new thing has many parts. We are trying to accomplish something in a disjointed fashion with feedback coming days after the time when we were really "into" the problem. When we get back our nits, we need clear, concise, non-ambiguous wording that says "Although what you have compiles and delivers the result, throw this code away and start again. Next time don't do X." I had to go through several nit sessions on my last project before I realized that this was the message to me.
I threw out my program and started again. The next submission was received with far fewer comments. We sometimes end up guessing at logic, data structures, connectivity ... please don't make us guess at what you intend.
Many thanks,
Pres

[matthew austin]

hmm . . . you seem pretty ambitious in stating what you'd like in terms of feedback.
With that tone I'm sure you must have sent in $500 or more dollars.
Me I'm just happy someone with more experience then me is taking the time to respond at all.
2 cents

[Pat Barrett]

Hey Pres,
Personally, I like the ambiguity. It forces me to research many alternatives while gently nudging me toward an efficient solution. I believe I submitted at least 6 different versions of the "Say" assignment, each one almost completely different than the last. I'm sure it would have been easier for the nitpicker to simply tell me what she wanted, but how would I ever learn anything?

The best way to learn is to make mistakes, and it helps that there are no employment or financial pressures tied into the work we (and especially the nitpicker(s?)) do here. In this way learning remains the main focus of this part of the javaranch site. There are lots of books that will tell you exactly how to code (see the Sams Teach Yourself series ) but being able to follow a recipe doesn't make you a gourmet chef.
just my .02
Pat B.


[This message has been edited by Pat Barrett (edited March 02, 2001).]

[bill bozeman]

Pres, I agree with Pat. What would you learn if you got your code back and it said, "Why are you using this method, why don't you go and use this method instead?" It would be easier, but you wouldn't really be learning you would just be doing what you are told.
Now if they say, "Are you sure this method is the most efficient?" Then you get the hint that there is a better way to do something and you start searching, which is a BIG part of the learning process. You are searching the API, making your own choices, making your own mistakes, etc...
Nitpickers, I would never change the way you do things. Granted it can be frustrating sometimes when I am in the middle of a project, and I think I have it right and I get back 20 "nits", but whenever I finish a project, I always feel that I have learned something and I am grateful that I did it on my own and didn't have someone saying do this step, then this step, etc... I can get that from a book.
Just my opinion,
Bill
[This message has been edited by bill bozeman (edited March 02, 2001).]

[Pres Brawner]

I'm sorry folks, but I'm going to stick to my guns. I think there is some confusion in my request, so let me try for a little clarification.
I don't want the answers. However, there is are people who research the psychology of learning that say if you go down the wrong road too far, you have a tendency to go back to that wrong road when faced with similar challenges. However, according to this group, if you have someone who stops you and says, "Try again," you learn more, learn faster, and retain the good stuff without the clutter of the bad.
That aside, I would settle for one thing. Some indication that the message I am receiving says, "Fix this." Some of the wording has had the appearance of opinion. Opinions are great. In case nobody's noticed, I have a few of my own. If someone has an opinion I'll be more than willing to listen to it. That doesn't mean I'm going to change my code.
If I get a nit that seems like an opinion, but when I disregard it and it pops up a second time, I have learned that this is not an opinion. It means that if I don't change this, I won't get a crack at the next assignment. Sometimes I have had to write three and four times to get reasons why something I did was not appropriate. The instructors knew. They just wouldn't say. I can understand that when you're in the developmental stages of the project, but when you're just fixing formatting, there should be some way of knowing what's up.
Maybe there is another way around this. With each project there is supposed to be a lesson learned or a series of lessons. Perhaps if there was some password protected place that held the purpose of each lesson, that would be enough. When you get the instructors solution, you also get the password that lets you see that project's lesson.
Getting a working piece of code is not everything. I may think I understand the point, but it sure would be nice to get independant confirmation.

[Marilyn de Queiroz]

Originally posted by Pres Brawner:
Maybe there is another way around this. With each project there is supposed to be a lesson learned or a series of lessons. Perhaps if there was some password protected place that held the purpose of each lesson, that would be enough. When you get the instructors solution, you also get the password that lets you see that project's lesson.

The purpose(s) of each assignment is not password protected but is openly posted on its assignment page. For example, the Java-4a page starts as follows:
"Assignment Java-4a (Say)

"Purpose: To learn how to create method(s), how to build and access an array, and how to concatenate strings."

The general purpose of the entire course is to learn how to make simple, readable, java code. I also throw in tips about optimization and style.

[Daniel Olson]

Originally posted by Pres Brawner:
Some of the wording has had the appearance of opinion. Opinions are great. In case nobody's noticed, I have a few of my own. If someone has an opinion I'll be more than willing to listen to it. That doesn't mean I'm going to change my code.

I think you need to allow for different social styles in language. In the culture I grew up in, it was considered rude to say things directly. When we moved to a different area, there were sometimes misunderstandings with people. The obvious meaning to someone in our family might go right over the head of someone visiting our house. For example, if at the dinner table my mother says to my friend, "Would you like more potatoes?", I knew that was her way of asking him to pass her the potatoes, but my friend would just look at the bowl of potatoes near him and say no. My mother thought it was uncivil to say things directly and within my family it was no problem. We understood.
I don't know the cultural background of the nitpickers, but it seems that you have realized that when they give their opinion about making a change in your code, that it means change it. If you understand that, why try to require them to adopt your speaking style? I like indirectness. It reminds me of home. Am I being too direct?

[bill bozeman]

From what I have seen, if you get a comment back on a piece of your code, be it an opinion or direct statement, you need to change it. If you don't get the instructors solution back and the statement saying "looks good you can move on" then you still have some work to do.
I'm from the south (US) so I agree with Daniel. I like the subtle statements that you screwed up.
Just my opinion,
Bill

[paul wheaton]

"If someone has an opinion I'll be more than willing to listen to it. That doesn't mean I'm going to change my code."
"If I get a nit that seems like an opinion, but when I disregard it and it pops up a second time ... "
Allow me to provide some clarification.
Ignoring the hints that you have been given wastes the time of the JavaRanch volunteers. That is not okay.
You are welcome to question the hints in this forum, but there is no guarantee that you will be convinced that our way is the right way.
The important thing is this: The nitpickers are not your personal slaves. I am not your personal slave. We are all volunteers. You are welcome to suggest, persuade and ponder in these forums. The people that work the hardest are the people that have the most influence with us. Not the people who choose to ignore our advice.

[Pres Brawner]

My humble appologies if I ever suggested that anyone was my slave. That was never intended. This is an interesting way of gaining new knowledge. I cannot contribute as do your volunteers, in being a nitpicker myself, because I lack the knowledge and experience to do so.
If I cannot contribute to the success of this operation as a nitpicker, what can I do? My thought was to recommend ways of improving the processes followed.
I see that my approach has been incorrect or misguided. It has never been my intention to waste anyone's time. I will make all changes from now on, as if they were commands.