Can we have more specific goals for projects please?

I really feel that the user stories for the projects need to be more specific. I’ve been thinking this since the Random Quote Generator. With that one, it stated “feel free to use any API or library you need”, so I initially thought, OK, maybe the purpose is to allow us the creativity to do the project any way we want.

However, I also think that there is a big difference between stifling creativity and specifying goals for the purpose of teaching something and/or making sure that the result works the way it should.

For example, with the Random Quoter, there are essentially two way you can do it. One way is to go to a quote site, copy a few dozen quotes, and build your own list. Then, for these to be presented randomly, you need to generate a random number yourself and figure out the logic to use that to present each quote randomly. The second way is to use an API that delivers the quotes to you one by one in an already random order. These approaches are really quite different and I feel that the course needs to know what it intends to teach here. If you noticed, all the projects in that section used API’s, so I’m guessing the focus here was to get people using and used to API’s. But that’s only obvious after doing three or all four of the projects. Whether the point was to get people using API’s or to generate random numbers, it should be specified. This is not limiting creativity. it’s simply telling us what the point of the project is. We can still be as creative as we want with it.

In the calculator example, I felt there should have been a few warnings. I was testing mine a lot and I believe I got all the bugs out, but there are a couple that, if I hadn’t thought of just clicking away randomly, I wouldn’t have found and thought to fix. Looking at other people’s projects, I can see that most people forgot to check for and prevent double decimals, for example. This is something I was just lucky to stumble across when clicking away randomly and realized when I saw I did that, “oh yeah, two decimals isn’t possible. Gotta fix that.” But this depends a little on luck, or, I suppose, extremely thorough analysis of every possible combination of user input. Then I started thinking about it more and started to do some real testing. I came up with a list in my post in the Project: Calculator thread of things I watched for. But as I was looking at more and more calculators, it occurred to me that these are things that most people just didn’t think about. I didn’t even think of testing until I accidentally discovered that! Most of us already have our heads stuffed with new information and are concentrating on getting the project done. It’s so easy to forget that testing should even be done and even if we do think about it, it’s hard to know how to do good thorough testing. I really strongly feel that a list of things to be careful for should be provided in the description. Things like:

  • it should only accepts one decimal point
  • the user should be able to change their mind when pressing operators without having to start over
  • numbers should all fit into the display (no numbers cut off resulting in only half a digit being visible at the end)

IMO, this is not about creativity or letting the student “figure it out on their own”. Again, it’s just about setting some clear expectations. IMO, if any of these three points aren’t working properly, it’s a bug. Plain and simple, it’s not working the way a calculator should work. Styling and design and how to achieve these goals is still up to the student to decide so it’s not like we’re removing the burden of thinking. LOL

Throughout the course, we are presented with dozens and dozens of challenges that run a variety of tests to ensure that the function does what it should do. Why not specify the basic functional expectations in projects too?

I think their method will be much easier to understand once they get the Agile lessons/videos created.

HI @GitCoderr, thanks for posting! If you you an interest in contributing to free code camp, check out the wiki page! Thanks, and happy coding :slight_smile:

1 Like

I think that the User Stories specify exactly the minimum requirements that your project is supposed to have. The calculator is a good example because things you mention, like how many digits after the decimal point, or the possibility of undoing some error without having to start all over are things we appreciate in a calculator, but not necessarily part of the requirements. It seems to me that, more than asking for more specific goals, you’re expecting more goals. If you look at the projects people have done, there’s quite a lot of variety, and I personally like that.
In the case of the quote, they clearly state that you can use any API or library you want. That’s what you’re supposed to do. Use either method. By the time all four challenges are done, you’re clearly familiar on how to use an API so whether or not you used one in the quotes challenge doesn’t change things too much.
Personally, I don’t even know if or how they are graded. The fact that as soon as you click the “I’ve completed this challenge” button, the challenge appears as completed, even before entering the url for your pen. So i have no idea how and if the projects are evaluated. They are clearly a great source of learning and a cool thing to revisit and improve as we learn more. :slight_smile: