Sprint 3 Feedback

[mlinderm]

Key: Exceeds Expectations (EE), Meets Expectations (ME), Below Expectations (BE), Falls short of expectations (FS)

User stories: ME (clear-ish user stories, some over use of Connextra, some over-constrained, mininaml/no supporting materials)
Agility: ME/EE (use of the backlog, assigned tasks, some commits throughout)
Integration: ME (many broken builds, minimal interaction)
Implementation: ME/EE (tests, extensive use of library functionality)
Functionality: ME/EE (core functionality, authn, some authz)

Final checklist: ME

• Sprint 3 tag
• Install dependencies
• npm run dev starts the development server
• Passes CI tests
• Deployed
• Sent .env.local file if needed to instructors

• As noted in the last sprint, not all tasks need to or should fit the Connextra format, i.e., having a stakeholder. And specifically the developer as stakeholder doesn't make much sense. Infrastructure tasks are a means to achieve your actual features and can be expressed as such.
• I encourage you to think through the motivations for each user story and the implications for that motivation. For example, is the motivation for only one upvote knowing that you contributed, or having a meaningful count of interest. If truly the former are there easier/different ways to achieve that goal? Clear motivations will help guide your design and prioritization of work (which users stories are most important)
• I encourage you to think about the infrastructure tasks in the same "priortized" way as features. For example, which tests are most important - likely those related to authn/authz and data integrity? Focus your energy there. Break those tasks down into smaller pieces to faciliate parallel and asynchronous work.
• I recognize that as you got to the crunch at the end, there are lots of commits and the PRs can get large. But some of those PRs, e.g. New #44, are so large it would be impossible to meaningfully review that code. In crunch times it is that much more important to try to keep your branches short-lived (and with a single feature). This is one of those situations where slow is fast. If you are experiencing a lot of friction that is warning sign of tactical programming. Pause and reconsider your approach. There may not always be a better way, but if there is, a little more time invested up front in design will pay dividends later.
• Nice use of Objection and other library features. I particularly noticed the extensive use of related queries. I suspect the learning curve was steep, but the resulting code is much more clear and maintianable (extensions require fewer modifications). In particular if you post process on the client, you become hestitant to make simplifying changes that effect both the client and the server. But when that work is done on the server, the changes don't impact the client.
• It looks like a lot of state collected in _app. I suspect that is partly a neccessary outcome of your component hierarchy. But it is also a warning sign to think more about how state could be better encapsulated, either in components, or alternately in custom hooks. The latter is something we didn't talk about in class, but is a technique to consider for futurue React proejcts.
• Great use of authentication on both the client and server. The latter is critical to ensuring data integrity. I was unclear why certain routes, like modifying a POST did not have authn or authz. Keep in mind that a client applicaiton is not the only way to access your API. Anyone can makes requests to your API!
• I appreciate that the testing is difficult to implement. Keep in the mind that the goal is to maximize confidence in your code so prioritize your testing efforts on those aspects you are least confident in and/or are hardest and most important to get right, e.g. tricky data transformations (switching/deduplicatng upvotes), authentication, etc.

Team Write-up

Functionality: ME/EE (clear description of features/choices)
Process: ME/EE (most required elements with specificity)

Final Presentation

Presentation: ME/EE (covered major topics, demo effective, can be disorganized)

• Great to see your application in action! I thought your demo was effective. If you were to give the presentation again, I would encourage you to move the demo forward. The discussion of challenges was reptitive. Tightenting that up would free up time for the demo.
• There were some interesting design choices embedded in the "categories" concept vs. sub-reddits. In similar presentations in the future, I would encourage you to discuss those kinds of choices, including motivations and alternatives considered.
• While I realize that revising your data model was frustrating, I think that is an example of the process working. The chance you (or anyone) gets it right the first time is small. That said, I think your "challenges" highlighted one of the key challenges I see with our agile approach, which is its reliance on prior experience to make decisions now that you set you up for success in the future (i.e. making decisions about your data model based on what you know about the capabilities of the tools, e.g. Objection, and your anticipation of future needs).
• Not sure what you are referring to by Objection's "CRUD" methods. Do you mean related queries? Or implementing Create, Read, Update and Delete API routes?
• "Jump-ins" are awkward in a group presentation. Aim to avoid those and other abrupt transitions.