Curriculum: Projects that require user to dive into existing codebases

[NikitaRevenco]

Checks

• This is not a duplicate of an existing issue (please have a look through our open issues list to make sure)
• I have thoroughly read and understand The Odin Project Contributing Guide
• Would you like to work on this issue?

Describe your suggestion

I think it would be a good idea if there were projects which don't have the user implement an app from scratch - but rather have an app that is already working and add features to it.

For example, there could be a project in the JavaScript section that is a snake game with some basic features like the snake grows, the snake can eat food, food appears randomly etc. And some of the points of the assignment would be for example

• have the snake wrap around the map if it reaches the edge of one side
• introduce different foods that give the snake more points when eaten
• introduce hazards and enemies that will try to follow the snake and hurt it

Just a silly little example. I think this would be useful because:

• More often than not, people will have to work on existing code rather than start from scratch.
• It allows learners to develop skills to work with other people's code, which may use different approaches to their own
• Builds skills to read code. If the project at the beginning is complicated and has a lot of things in it, for example a project later in the React course could have several dozen files and the learner would have to dive into the code base and understand the code before starting to work on the assignment.

This could be introduced into the curriculum by adding new projects, or replacing existing projects with this new type of project.
Let me know what you think.

Path

Foundations, Ruby / Rails, Node / JS

Lesson Url

Curriculum

(Optional) Discord Name

Revenco

(Optional) Additional Comments

No response

[JoshDevHub]

I think this kind of thing is potentially a cool idea, and I've discussed this internally with a couple of maintainers before.

Another nice thing to potentially explore with this idea: intentionally write a bug or two into the existing app. Then learners could be told fix the problems in the app. This is a very common type of real world task that's a bit different from feature work.

To me, one of the main cons with this type of thing is that it probably doesn't play well on a portfolio? It's more of a theoretical learning exercise, which is fine. I just think that potentially by the time learners are advanced enough to work on this kind of thing, they're going to be getting close to job ready and will want to spend their time on projects that can go on a resume. But maybe that's just a con in my mind.

Curious if other maintainers have thoughts on this kind of thing @TheOdinProject/maintainers

[cakegod]

I believe it is a good idea. These exercises have the potential to improve code comprehension and debugging skills. Not everything needs to be explicitly included in the portfolio.

We can incorporate these exercises throughout the curriculum with varying levels of difficulty based on placement in the curriculum.

[NikitaRevenco]

If people are on board with this, I think a good place to get started would be the JavaScript Foundations section. Specifically, after the "handling javascript error" lesson.

Getting started

• Fork the repository guide
• The program should have the player guess a number between 1 and 100. The computer will then try to guess the correct number, the player can tell the computer whether it's guess was correct, higher than actual, or lower.

Find errors

1. The game doesn't even start. Find the error and fix it so that it works!
2. Inputting in something other than "higher", "lower" or "null" will stop the program instead of going onto the next question. Can you try figure out why?
3. Clicking on "cancel" doesn't work - fix it!
4. The program incorrectly guesses the number.

Features

5. Display how many steps the computer took when it tried to guess the number!
6. Add a feature so when play() is called, the user is prompted for for difficulty - either "Easy", "Medium" or "Hard" which would change the maximum values from 10, 100 and 1000.
7. Make the game playable in reverse! By passing in play(reverse) the player should now be the one guessing, and the computer telling the player whether they their guess was higher, lower or correct

// This is what the learner will work with
function play() {
    let min = 1;
    let max = 100;
    let guess = Math.floor((max + min) / 2);

    for (let i = 0; i++; i < 30) { // error 1
        if (guess === max || guess === min) {
            alert(`Your number must be ${guess}.`);
            break;
        }
        let userInput = prompt(`My guess: ${guess}. If your number is higher, say "higher". If it's lower, say "lower". If it's correct, say "correct".`);

        if (userInput === "correct") {
            alert(`I won! Your number was ${guess}.`);
            break;
        } else if (userInput === "higher") {
            min = guess; // error 4
        } else if (userInput === "lower") {
            max = guess; // error 4
        } else if (userInput === "null") { // error 3
            alert("You quit the game!");
            break;
        } else {
            alert("Invalid input! Try again.");
            break; // error 2
        }
        guess = Math.floor((min + max) / 2);
    }
}

[MaoShizhong]

I like the idea for sure and agree that not everything needs to be portfolio-focused. There are already plenty of great portfolio candidates around the areas where people seem to start applying for jobs.

I'm not so sure about introducing such kinds of exercises so early as Foundations though. I agree with Josh in that there probably should be a little more experience with reading and writing code than you'd likely expect people in Foundations to have. Plus, in Foundations, we already have some "fix these bugs" beginner exercises before the repo/Jest-based exercises later.

Two prime spots for me are towards the end of the JS section and towards the end of React section.
Similar to the way the CS section is handled between pathways, perhaps then a Ruby equivalent towards the end of that course and the JS section one omitted as "a duplicate".

I really like the idea of having more in the React section overall. A "fix this React app and add XYZ features to it" project/exercise before the "Shopping Cart capstone" I think might be both fun and also break up the slog of reading about routers, fetching and testing between Memory Card and Shopping Cart.

I know quite a few people in the community express surprise at the end of the React section going "is that it?". If they're taking the Node pathway then it'll come back in the latter part of Node but they don't necessarily know that. But if they're taking the Rails pathway, then that really is it. Personally, I do think adding one more "checkpoint" within the React course can make it feel more fleshed out.

[thatblindgeye]

This sounds like a really nice idea! I can definitely see the merit in helping expose users to reading code someone else wrote and having to fix or add things to it, rather than doing everything from scratch.

Agreed that Foundations may not be the best spot, but this is worth more of a discussion. Depending on the implementation, we could always introduce some of this stuff in the JS exercise repo, either instead of or in addition to a project.

Maybe starting out with more simple exercises to get users used to reading smaller blocks of code, before eventually ramping up to a larger project that requires users to have to traverse multiple files and such?

No actual points but @NikitaRevenco ++ for this idea! (and I guess @JoshDevHub ++ too 😆 )

[github-actions[bot]]

This issue is stale because it has had no activity for the last 30 days.

[CouchofTomato]

@NikitaRevenco Are you still working on this?

[thatblindgeye]

This might be better served converting to a discussion for now since there's nothing actionable yet to do. It may require further nailing down if ultimately it's something we want to move forward with, where it would live if so, and how exactly to implement it.