|
Who's there?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Albany
Will Rogers never met me.
|
|
|
|
|
*what have I started?*
Albany who?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Albany rabbits have fluffy white tails.
Don't blame me - you started it. 
Will Rogers never met me.
|
|
|
|
|
Roger Wright wrote: Don't blame me - you started it
I was bored! 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
And I can't play ESO (Elder Scroll Online) because, server update! 
|
|
|
|
|
I'm sure you've seen this before or remember doing it yourself as a newbie. An assignment say something like "divide the array of bytes into groups of 4 bytes, then XOR all the groups" and the student thinks that means they have to make an byte[][] to hold thousands of tine 4-byte arrays, which is completely pointless but "the assignment said to do it". Or when explaining Huffman codes or such a "bitstring" is mentioned and the student thinks that means they should use a string to hold a bunch of "0" and "1" characters. Or the assignment says to translate a for-loop into assembly and they implement it in the most general and naive way even though it was just a "repeat 8 times"-kind of loop which has a much simpler implementation but they thought they wouldn't be allowed to use that because it's "not what the code says".
I'm not sure what to do about this. I've told a bunch of them that it's basically OK as long as it does the end result is the same, and that they should really just use a simple and/or efficient way to implement it. They're struggling with this whole "how you talk about what you're doing abstractly isn't literally how you code it up" thing though.
So, any ideas? How do I get this across properly?
inb4 "just make the assignment literal"; that's not how it will ever work in their careers. Besides, it complicates and spoils the assignment with the kind of implementation details that they should come up with.
|
|
|
|
|
Isn't that the question every customer asks about their IT-staff?
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
harold aptroot wrote: How do I get this across properly?
I'm not actually sure what your point is. Maybe I'm taking you too literally. But in the abstract sense, programmers fall into two camps - those that can think creatively, and those that can't. Actually, three camps. The third camp is "WTF. I'm not doing this stupid assignment!" Those are the people you want to hire. 
Marc
|
|
|
|
|
And if they've got eggs, buy half a dozen.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
It's because your instructions are to literal, "divide the array of bytes into groups of 4 bytes, then XOR all the groups": they are doing exactly what you asked them to do - and inasmuch deserve an A, whereas anybody doing any other / creative method is not following instructions and deserve to awarded a fail. You've not just removed the chance for creativity, you've stifled the opportunity. If "bitstring" trips them up, don't use those words until after the assignment, "turn a for loop into assembly and repeat 8 times," take away the "8".
Give them the possible input(s), the expected result(s), perhaps mention any common got-ya's, and sit back and let them create the solutions.
That's real work: boss/client tells you what, the how is entirely up to you - if they already know the how why do they need you?
Side note: As to processes such as Huffman coding I really hope you aren't expecting them to memorize such methods, google is as much a tool to a programmer (in fact any profession) as a hammer is to a builder or a mixing bowl to a baker - please don't fill the heads of students useless information that at best only 1 in 50000 will ever actually need.
Sin tack ear lol
Pressing the "Any" key may be continuate
|
|
|
|
|
Robert den Hartog wrote: It's because your instructions are to literal
Well no, that was part of my point. They use the descriptions that are typical for that abstraction level. You do divide that array into groups of 4 bytes, but only mentally. That is what they have to get used to, because descriptions of algorithms and data structures are always going to work that way.
But these examples are just examples. You're taking them too literally too.
|
|
|
|
|
harold aptroot wrote: But these examples are just examples. You're taking them too literally too.
Agree, it's taken literally because that is what your instructions specify: 'take this, do this then do this then do this,' not 'take this and give me that.'
Yes you do need to give examples, but make the examples more abstract, instead of:
'take this array,
divide the array of bytes into groups of 4 bytes,
then xor those blocks like this'
instead (i.e. shown on blackboard / projector):
'using this data // show a string of data bytes
xor these 4 bytes, xor with this next 4 bytes, now draw some arrows 1 -> 5, 2 -> 6, 3 -> 7, 4 -> 8
then xor that with the next 4 bytes, (draw new dotted line arrows, 5 -> 9, 6 -> 10 ...)
repeat to the end'
It's your instructions that are are too explicit.
It's your instructions that are explicitly stifling creativity.
(And hold back a bit to see if any of the students have enough thought to ask about the length of data not being evenly divisible by 4 - and if so let them propose solutions before giving them an answer.)
Sin tack ear lol
Pressing the "Any" key may be continuate
modified 16-Oct-16 0:32am.
|
|
|
|
|
But my entire point is that this not too explicit. This is precisely the level of "it looks like it's telling you to implement it a certain way, but you still shouldn't" that they should get used to. How are they going to get used to it if I go out of my way avoid the normal way of specifying these things?
Edit: to put it an other way, the problem is not that they're writing those solutions. The problem is that maybe half of them are not learning to see past the literal wording of an assignment, which is a skill they will need daily. So removing that aspect is the opposite of a solution.
modified 16-Oct-16 7:35am.
|
|
|
|
|
While they may need to "learn to see past the literal wording", THIS is not a scenario in which such behavior is generally rewarded. When you are taking a programming class, and your instructor gives instructions that have a clear literal solution, providing anything else is usually a good way to get a bad grade. (Take my word for this as someone who had to challenge any number of professors on this point because of my "creative" solutions to their "literal" assignments. It usually boiled down to - Prof: "This doesn't do what I said!" Me: "Did you actually run my code?")
In other words, the instructions are "translate the for loop into assembly" NOT "provide the most efficient assembly that accomplishes the task represented by this for loop". Depending on the for loop provided, transliteration may indeed be the most efficient implementation. On the other hand, if the provided start, end, and increment values are constants, it might be most efficient to just repeat the code. You didn't provide enough information (to us) to determine which might be the case.
Or "break down this array into 4-byte blocks and XOR them" - starting with the fact that I have no idea WHY you want to do this. What are you actually testing with that particular assignment? Their ability to subdivide an array? Their understanding of XOR? Both? Neither and you just want them to give you a specific 4-byte result?
|
|
|
|
|
Perhaps I may still be missing something but if you are asking how to get people to see the "big picture" and look past the initial, literal assignment then good luck 
I guess this comes with experience and I have come to the conclusion that quite a bit of this "programming" of ours falls into the category of tacit knowledge. I guess since it is more of a creative synthesis of sorts. Also falls in quite nicely with the "Dreyfus model of skill acquisition" at the "Novice" level.
Anyhow, I think you basically have to wait for the penny to drop.
|
|
|
|
|
Put it in the syllabus! 
All jokes aside, I saw it mentioned in another response that explicitly following the instructions is something that is baked into the education system nowadays with standardizations. An explanation that is missing from your original post is that the explicit specifications and the need to determine what is fluff and what is specification is an industry standard. There is a lot of rewiring of brains needed here. You'll need to experiment to get the results you want, but this is what I would try
1) Talk about it leading up to the first assignment.
Make sure they know what you are looking for, dissect the first example in class. Let them try it out then critique them gently. Make sure they know that they will be penalized in the following assignments. Also give them the explanation before hand. Maybe dig up some real world examples and tell them their job is to find the most efficient approach for the correct answer, not follow along line by line.
2) Hammer them on the second assignment.
Make them shocked when they see their results. Don't just blow them off though (it would suck to make that much animosity right off the bat). But, now that their eyes are open, give them a chance to redeem for partial credit. Maybe go over it as a thing that is commonly happening and this is how to fix it. Drive the point home that this is a skill they will need to perfect to work with the specifications which can be seen in the industry.
3) Keep a tough but fair approach going forward.
Keep an ear to the ground when other abnormally large assignments are going around and cut some slack in those weeks for the students who could use it. Otherwise, offer office hours for those few who just "don't get it"
That's my 3 cents, good luck 
|
|
|
|
|
Those are the days of dirt-cheap memory... People born with that never think about O(1) in memory algorithms 
Banking establishments are more dangerous than standing armies. T.Jefferson
|
|
|
|
|
They've been taught all through their schooling that if they are given instructions, they must follow the instructions. They would be downgraded if they ever got the right answer but not in the way specified. This is a hard habit to break.
One way is, like another reply said, to not give any 'how-to', but only specify inputs and outputs.
Another way is to give a bad and buggy implementation and tell them to both fix and optimize it.
Both are useful skills for them to learn.
|
|
|
|
|
Start by Googling "requirements specification." The phrase "For example" can do wonders. Define both input and output data structures. When some students use different strategies to get from I to O, you have an opportunity for discussion.
In the case of the for-loop, did you specify coding for maximum efficiency in that specific case of 8 loops, or did you leave their minds open to the possibility that they were expected to create a general solution and would be down-graded for giving you a trivial specific solution?
Writing good exam questions takes time and experience. If you rush the process the students will find valid possible answers you never anticipated, but are correct for the specified question. I have written exam questions in the biological sciences for decades and still get "caught" writing an ambiguous test question from time to time. Few people achieve perfection without recycling their "good" questions and refining the "bad" ones. That's how professional testing services work: they continually evaluate and refine their pool of exam questions.
|
|
|
|
|
In order to prevent students from taking the assignment too literally, give them examples.
I mean, give them an example of an assignment, then give them a solution for this assignment that corresponds to taking the assignment too literally, and after that give them a solution that you think is way more appropriate.
Then do this with another example assignment, and its own solutions that are "too literal" and that are "appropriate".
Then do this with yet another example assignment, and its own solutions that are "too literal" and that are "appropriate".
If you do this a few times, the students will eventually understand.
|
|
|
|
|
In the "old days", we (noobs) had to submit a "flow chart" for review / approval before starting to code.
But I guess that now flies in the face of being "agile". Or that's not how "functional programming" works.
Anybody know what a "flow chart" is? How about an ERD?
|
|
|
|
|
Yea the new style is "throw code at the test cases and see what sticks"..
|
|
|
|
|
Add to that that some people are better with pictures versus others that prefer text versus the spoken word ...
Different levels of comprehension right from the outset.
|
|
|
|
|
I take it you are teaching then?
In my university days I had an eye opening experience across two courses. The first course we had an prof who would give us an assignment and award a C to work that did the strictest literal thing asked for, this prof asked us to always think about over delivering, optimizing, adding useful features, etc.
The second course we had a different prof. On the first assignment I actually forgot about it until the day it was due, so I rush coded the bare strict literal requirements given to us. I got 98/100 A. I was confused, adding to the situation most of my classmates (who had also been in the previous course with me) were receiving D's and F's... and they were pissed.
Turned out different profs wanted different things, the second prof was a true believer that we code to the requirements literally, period. The first not so much, he liked seeing extra effort.
I am just sharing this in reply to your post, as it may be that your students already had a prof like my second one?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
