The Udacity React Nanodegree's first project is a simple application called "My Reads". Effectively, the app involves you adding and moving books between "bookshelves/lists" based on whether you:
The premise is simple enough, but it illustrates an important aspect of web development which is "deciding on state" aka. How are you going to organise and manage data/state in your application?
The way I approached this project was to considering the following: At minimum there is the relationship between the units ("Books" in this case) and the collections ("Bookshelves" or categories). There are many books, and many bookshelves, but a particular book can only be on one bookshelf at a time. As a result, the decision on how to structure/manage the state is premised on how one decides to model the relationship(s).
In this case, to my thinking, I decided that my app's primary collection would be "Shelves". Which meant that books were added to or removed from a shelf. Much like physical bookshelves in a room. You take a book and you put it on a shelf. If you want to move it, you take it off the shelf and put it on another. I would say it is the obvious analogy.
The thing to consider here is that even this simple premise reveals the concept of trade-offs.
Consider for a moment, that an alternate approach to this question would be that you have "books" as your base collection. Essentially you only have a list of books and then each book has a field that determines which shelf it belongs to. In this approach, you have no "shelves" per se. Only books. This approach has the benefit of making it relatively simple to determine which shelf a book belongs to anywhere in the application since the information is right there with the book.
One trade-off here, however, is that the "shelf" does not really have anything to do with the book itself. As a result, if you are then asked "Which books are on shelf x?", in order to answer this question, you would need to iterate through all the books in order to determine/assign the books to the necessary shelf. This might be considered onerous the larger the collection of books becomes.
With the former approach however, i.e. having shelves as the base collection. One gets to keep the book's data "pure" in the sense that you do not mix shelf data in with the book data. This has the benefit of being able to easily determine which books are in a shelf by looking only at the shelf and not bothering with any other books not on that shelf.
The trade-off however, is that, you need to do extra work to be able to determine which shelf a book is on when looking at the "only" the book. In this case, the latter solution would be more convenient since you would be able to know which particular shelf a book belongs to quite easily. The problem comes when someone wants to know about the shelf, or how many shelves there are...
While it is a simple example and the repercussions of such a decision within such a small app are likely very small, my feeling is that, even this simple example illustrates at least two possible paths and their associated trade-offs to be considered. This is an important lesson and design concept to keep in mind because with each extra feature an application has, these decisions and trade-offs come into focus and over time, their associated strengths and weaknesses will become more pravalent.
One of the lessons to keep learning about software, is that, while you certainly get right/wrong decisions at times, most often it is more a case of evaluating the strengths and weaknesses of an approach. The better you are able to make the cases for and against any particular course of action, and to dig into the possible strengths and weaknesses, the better equipped you will be to solve the problem and improve your solution over time.