Change:
A lot of campers do not understand they have to use the parameters and keep creating an object inside the function. I know this is verbose. Not sure if we need an example that uses a function as well: We might also want to add a call to the function in the seed code Campers should understand the function signature with its parameters and use them properly. No response Device: [e.g. iPhone 6, Laptop] OS: [e.g. iOS 14, Windows 10, Ubuntu 20.04] Browser: [e.g. Chrome, Safari] Version: [e.g. 22]
I would be fine changing the description to what you have suggested. Might as well. But, this is after many lessons teaching/involving arguments and parameters. Did we not recently spend time removing a bunch of these?
I think so but I'm not entirely sure why? Seeing the function invocation can help in understanding the function definition. I think we are taking it for granted that they should look at the test output to see the invocation when in fact it is just the test status people look at. Yes, they should know better by now, but they don't. In fact, not understanding parameters/arguments is an overall issue we see. It can not have been reinforced properly because we see it all the time. My best guess is that too many of the challenges have premade functions and in not forcing people to write the function definition and invocation campers are left not fully understanding it.
I think they were confusing Campers . Campers would write their function as though only the example call was what was being tested - they hard-coded based on the seed example call.
I guess that makes some sense but that too points to the same issue. There is a disconnect between writing and running the code.
I like the more explicit instructions. I'm not sure if the sample function call is the right band-aid for learners not understanding what a function call does?
Do you mean the example function or adding the function call to the seed code? I believe it can help with pattern recognition. Seeing the definition and invocation in close proximity can help connect the dots between the parameters and arguments.
There's a non-insignificant number of learners who don't seem to understand much about how a function call works. I'm not sure that giving more examples of the thing they don't understand will target the underlying reason of why they don't understand it. The problem is though, I'm not sure why the idea of a function call's arguments giving values to the parameters is such a mysterious idea for some of the learners.
Because not having the definition and invocation in close proximity throughout the course is part of the underlying problem. The pattern isn't getting reinforced correctly (both through seeing and writing). Not enough functions are written from scratch and we (almost) never require the camper to execute the function with the correct arguments. One exception would be the recursion challenges. The TDD setup is creating a disconnect for beginners and I believe the way the test runner is implemented isn't helping. I have said this before, but I would prefer if the test running was embedded and exposed better in the UI, for example, the way it is on Codewars. It would require explaining the interface in the beginning as it is a bit technical. But the function getting called for the camper is a detail that often is lost until we explain it.

Discussion:
# --description-- <del> Sometimes it is useful to check if the property of a given object exists or not. We can use the `.hasOwnProperty(propname)` method of objects to determine if that object has the given property name. `.hasOwnProperty()` returns `true` or `false` if the property is found or not. </del> <ins> To check if a property on a given object exists or not, you can use the `.hasOwnProperty()` method. `someObject.hasOwnProperty(someProperty)` returns `true` or `false` depending on if the property is found on the object or not. </ins> **Example** ```js <del> const myObj = { top: "hat", bottom: "pants" }; </del> <ins> function checkForProperty(object, property) { return object.hasOwnProperty(property); } </ins> <del> myObj.hasOwnProperty("top"); myObj.hasOwnProperty("middle"); </del> <ins> checkForProperty({ top: 'hat', bottom: 'pants' }, 'top'); // true checkForProperty({ top: 'hat', bottom: 'pants' }, 'middle'); // false </ins> ``` <del> The first `hasOwnProperty` returns `true`, while the second returns `false`. </del> <ins> The first `checkForProperty` function call returns `true`, while the second returns `false`. </ins> # --instructions-- <del> Modify the function `checkObj` to test if an object passed to the function (`obj`) contains a specific property (`checkProp`). If the property is found, return that property's value. If not, return `"Not Found"`. </del> <ins> Modify the function `checkObj` to test if the object passed to the function parameter `obj` contains the specific property passed to the function parameter `checkProp`. If the property passed to `checkProp` is found on `obj`, return that property's value. If not, return `Not Found`. </ins> # --hints--