Capstone Performance Review and Rubric

Example Self Assessment

This example below is considered meeting expectations.

Feedback given to teammates

1) Name is an excellent person to work with, especially when we have complimentary desires. (He enjoys front end development, I enjoy back end development). We have worked together multiple times over the course of this project and others, each time he pushes for the understanding of the core concepts of what it is we’re working on and not simply just to get something to work.

Any time we’ve been in a larger group, he makes it a priority to know that everyone is tracking with whats happening in the group, even when it requires going over something multiple times to verify that everyone feels comfortable with their knowledge of the task.

Something to be aware of, particularly in a large group project is his strong desire to continue learning new things and trying to get the whole group to learn with him could come across as overwhelming or potentially discouraging for others in the group if a pulse check isn’t done first. In the group we had some who were very comfortable with all the topics we’ve learned so far, some who were mildly comfortable, and some who felt like they were just barely scraping by. Trying to push for more from a position of extreme comfort sounds like a good idea, but the ones who feel like they’re barely scraping by suddenly feel the goal line get pushed out of reach. The desire to learn is not a bad thing by any means, but remembering that others in the group may not learn as easily or as eagerly is something to keep in mind.

Though if Name is able to be put into a group of similarly impassioned and knowledgeable people, the kind of work that could be developed is sure to be impressive to see as some of his side projects show.

2) Name’s code is high quality, demonstrating a thorough understanding of principles of good design in both FE and BE. Name’s strengths as a coder and his independent nature lead to Name taking an active role in fixing bugs, accounting for edge cases, and revising code and file structure to be better organized. His independent nature can lead to his contributions to be overlooked or neglected unfortunately. When Name utilized a new pattern in his api calls. Some group members did not know to do the same, leading to inconsistencies that needed to be addressed down the line. Even though Name’s idea was good, the inconsistent implementation by others led to issues. Name created a new file in the FE repo called fileName.tsx to store api calls. This was a convention worth implementing into our FE repo, however the previous file for making calls to the BE continued to be used by some group members because this change was not adequately communicated to all group members. The discrepancy caused issues that needed to be rectified after the fact. Name’s contributions are hindered by the lack of communication to the group. I believe that Name’s contributions would have more positive impact on the group if there was more effort put into communicating his ideas with the group, everyone would benefit from hearing Name’s good ideas.

Feedback received from teammates

1) Working with you is always a pleasure. You’re ability to know when to ask questions and when to let the other person to continue with their thought is something that may be overlooked by others, but it’s a great skill in working well with others.

It’s a testament to you as a person that it’s very difficult to point to anything that really needs addressing. And if I have to think that hard about it, it feels more like it’s nitpicking than actually helpful. You’ve got a solid foundation of knowledge, you know how to keep a conversation moving forward well, you know when to ask probing question, and you’ve got the where-with-all to know when to ask for help.

2) Name set a good example for what an ideal teammate would look like in a project. His coding ability is as impressive as his interpersonal skills. When my goals for this project overlapped with Name’s, communication was clear and effective. From my perspective Name tackled many big picture issues throughout this project including deployment and integration of Tailwind and Typescript. What stood out to me was the example Name set for handling new integrations that not everyone was fully familiar with. Not only did Name advocate for smart design decisions, he was able to assist others when they had confusion or questions about those decisions. Name excels at leading by example. I think this strength has a potential drawback. Anyone’s capabilities are finite, for Name to be an effective leader and teammate he will have to make decisions about how much effort he can afford to spend on implementing new ideas. Name’s ability as a coder is not the limiting factor, his capacity to help others could be a bottleneck for production if too much is added too quickly. In this project Name seemed to navigate this appropriately, but moving forward it is something for Name to keep in mind to continue to grow as a developer, and as a leader.

Contributions to the project

• Ticket 60, refactoring of Contact Serializer and added tests, created nested contact routes
• Ticket 61, added support for creating contacts with optional company info
• Ticket 14, add contacts feature with model/controller and tests
• Ticket 1, create new contacts BE
• Ticket 19, set up contacts table with tests.
• Ticket 33, menu bar refinements, Cypress testing, fixed tests in other test files, CI green
• Ticket 47, create contacts model unique name fix
• Ticket 36, contacts controller
• Ticket 8, create all contacts FE
• Assisted with companies team to decide on nested contacts routes under companies so that contacts can be optional and companies can be optional/contacts and companies can be created with or without one another.
• Assisted with show contacts page bug
• Assisted with debugging and fixing broken tests in Cypress that was not a part of my tickets but improved the CI/CD process
• Assisted with create new job application Cypress testing and development of new application page error handling
• Created ticket #58 to refactor ContactsController for later
• Created ticket #62 to move FE contacts fetch calls to separate API call file
• Worked with and had discussions with design team members to ward off or fix issues related to design elements

Technical Areas of Strength

Rails, react, tailwind, and to some extent cypress. This project made me more comfortable with get/post requests.

2-3 Areas of Improvement

1) As a team member definitely communication. I am still not used how much communication is needed for this type of environment. From my personal style of communicating and my previous experience I’ve always taken the route of “communicate when you have something to communicate” but, I’ve learned that’s not how any of this works in development.

2) As a dev I need to study more about code construction. After doing projects with others seeing the ways other people are able to design stuff that’s light and powerful, I don’t yet truly utilize the power of these tools.

3) I also need to figure out how to walk away and come back later. I’m still not the best when it comes to that and it really does effect the quality of what you’re able to do.

Scores

• Work Ethic and Attitude: Meets Expectations
  • I would say I am somewhere between meets and exceeds expectation. I attended every check-in and bring ideas and questions. I actively participating in all stand-ups. I am very urgent to respond on slack. I demonstrate a positive attitude and willingness to learn. I could take more initiative to research and propose solutions to bigger problems. I am completing this self assessment with thoughtful reflection and clear action items.
• Collaborative Workflow: Exceeds Expectations
  • I consistently updated project board and includes progress and blockers. I used co-authored commits on paired pull requests. I could solicit project ideas and feedback from quieter teammates more often. I communicated effectively with team members and project manager through appropriate channels. I collaborated well on pair programming tasks, showing both the ability to lead and follow. Melchor and I worked very together in this way. I sought clarification when requirements or tasks are unclear. I demonstrated active listening skills during team discussions and meetings - evident in building off their conversations with comments on their tickets and responses in chat. Showed willingness to help team members when they encounter difficulties. Transparently communicates blockers and seeks help when appropriate - this happened a number of times.
• Code Quality: Meets Expectations
  • I think I have a solid understanding of Ruby on Rails and React. I learned Tailwind pretty well and incorporated it into two other solo projects (portfolio and chess war). I effectively addressed feedback from code reviews. Got 100% tests passing with sad paths included. I have good error handling for the different states (empty states, loading states, error states) Wrote SRP and DRY code I was extremely active in the review and support of others’ code giving quality feedback. Shows a keen interest in learning about tools and architecture solutions outside of the scope of lessons taught at Turing - this I demonstrated by learning VueJS over break and making an application of my own design from scratch. Proactively seeks to understand and improve code performance by asking questions and researching solutions
• Technical Problem Solving: Meets Expectations
  • I think I was able to demonstrate my ability to break down issues into smaller components. I raised concerns about potential oversights and discrepancies. I was available to help my teammates debug issues they were encountering. I think I handled my initial technical research spike in a very proactive way where I was not just acknowledging concerns, but offering potential solutions to them.
• Git Workflow and Deployment: Meets Expectations
  • I helped set up the PR template and took time to help be know how to use it better. There is still more learning to be done, but the effort was there. I gave constructive feedback on many PRs - more than 4. I made focused PRs, but sometimes they were not super small (not sure what counts as small) but they were always related to a single issue. I didn’t delete branches after merging - this is a to-do moving forward. It would probably be good to set as a group’s intention, especially since the way we set up the PR merging, we would be deleting someone else’s branch. Once CI was implemented, everything was passing before merging.

Work Ethic and Attitude

• Exceeds Expectations:
  • Regularly brings questions and ideas to check-ins
  • Responds with an appropriate urgency to messages in Slack during work hours
  • Demonstrates a positive attitude and willingness to learn
  • Takes initiative to research and propose solutions to problems
  • Completes self assessment with thoughtful reflection and clear action items
• Meets Expectations:
  • Attends every live or async daily check-in, on time, and notifies the instructor if they are unable to attend
  • Actively participates in daily stand-ups, providing clear updates on progress and blockers
  • Responds to Slack messages within a reasonable amount of time during work time
  • Shows enthusiasm for the project and a desire to improve
  • Maintains a positive and respectful attitude in all team interactions
  • Completes self assessment with thoughtful reflection
• Approaching Expectations:
  • Misses or is late to up to two live or async daily check-ins without notifying the instructor
  • Does not always provide clear updates on progress and blockers during daily check-ins
  • Occasionally responds to Slack messages slowly such that other teammates are blocked
  • Slow to ask questions
  • Actively participates in the project but does just enough to get by
  • Completes self assessment but reflection is lacking
• Below Expectations:
  • Misses or is late to three or more live or async daily check-ins without notifying the instructor
  • Daily updates are unclear, vague, or lacking detail at least half the time
  • Asks questions infrequently, if at all
  • Sporadic or infrequent communication in Slack
  • Does not participate in the project or does not contribute to the project in a meaningful way
  • Does not fill out the self assessment

Collaborative Workflow

• Exceeds Expectations:
  • Consistently updates project board and includes progress and blockers
  • Uses co-authored commits on paired pull requests
  • Solicits project ideas and feedback from quieter teammates
• Meets Expectations:
  • Moves tasks along on the project board in real time (or close to it)
  • Communicates effectively with team members and project manager through appropriate channels
  • Collaborates well on pair programming tasks, showing both the ability to lead and follow
  • Seeks clarification when requirements or tasks are unclear
  • Demonstrates active listening skills during team discussions and meetings
  • Shows willingness to help team members when they encounter difficulties
  • Transparently communicates blockers and seeks help when appropriate
• Approaching Expectations:
  • Updates the project board about once per day
  • Ineffective time boxing: Spends too much time trying to figure things out on their own before asking for help or struggles to communicate blockers and seek help in a timely manner
• Below Expectations:
  • Updates project board less than once per day
  • Behaving in an anti-collaborative way. This might look like:
    • Not contributing to project planning or decision making discussions
    • Disappearing for 24 hours or more (Monday-Friday) without notice or explanation
    • Not following the project’s defined workflow
    • Missing deadlines, meetings, or discussions without notice more than once

Code Quality

• Exceeds Expectations:
  • Proactively seeks to understand and improve code performance by asking questions and researching solutions
  • Shows a keen interest in learning about tools and architecture solutions outside of the scope of lessons taught at Turing
  • Actively participates in reviews of their own code and addresses feedback effectively
  • 100% of code is well tested, including sad paths and edge cases
• Meets Expectations:
  • Demonstrates strong understanding of the primary programming language and framework used in the project through implementation and successful completion of all issues assigned
  • Effectively addresses feedback from code reviews
  • At least 90% of code is well tested, including sad paths and edge cases
  • Implements proper error handling
  • Demonstrates understanding of code organization principles (e.g., separation of concerns, SRP, DRY)
  • Maintains a clean and organized codebase, following agreed-upon coding standards
• Approaching Expectations:
  • Usually demonstrates a strong understanding of the primary programming language and framework used in the project though occassionally strays from conventions or the project’s coding standards
  • Usually addresses feedback from code reviews but occassionally misses details
  • Improperly handles some errors
  • Most code is well tested but some edge cases or sad paths are not tested
• Below Expectations:
  • Does not demonstrate a strong understanding of the primary programming language and framework used in the project either through incorrect implementation or lack of completion of issues assigned
  • Does not follow the project’s coding standards
  • More often than not, does not implement error handling
  • Code is not well tested missing many edge cases and sad paths

Technical Problem Solving

• Exceeds Expectations:
  • Always breaks down complex issues into manageable components
  • Proactively identifies potential problems and proposes solutions before they become critical issues
  • Assists teammates as needed in debugging and problem solving
  • Regularly seeks out, applies, and offers feedback to improve problem-solving approaches
• Meets Expectations:
  • Consistently breaks down complex issues into manageable components
  • Identifies potential problems before they become critical issues
  • Shows the ability to apply existing knowledge to new situations and technologies
  • Effectively uses debugging tools and techniques to isolate and resolve issues
  • Regularly applies feedback to improve problem-solving approaches
• Approaching Expectations:
  • Breaks down complex issues but not always effectively or into the smallest reasonable pieces
  • Can usually adapt existing knowledge to new situations and technologies but occassionally jumps immediately to asking for help
  • Uses debugging tools and techniques to resolve issues but does not always isolate the root cause
  • Regularly seeks out feedback but does not always act on it to improve problem-solving approaches
• Below Expectations:
  • Often skips breaking down complex issues into the smaller more reasonable pieces
  • Cannot identify potential problems in code implementation
  • Struggles to adapt existing knowledge to new situations and technologies often jumping immediately to asking for help
  • Struggles to debug without asking for help
  • Does not seek out feedback or ignores it when given

Git Workflow and Deployment

• Exceeds Expectations:
  • Uses Pull Request templates and at least four PRs include specific questions/asks of the code reviewer
  • Provides constructive and actionable feedback on 4 or more pull requests
  • Always creates focused, small pull requests that are easy to review
  • Rebases before merging
  • Deletes branches after merging
  • App has passing CI and is deployed successfully after every PR is merged
• Meets Expectations:
  • Uses Pull Request templates and at least three PRs include specific questions/asks of the code reviewer
  • Provides constructive and actionable feedback on at least 3 pull requests
  • Writes clear and descriptive commit messages following a consistent convention
  • Creates focused, small pull requests that are easy to review, but one may be larger than expected
  • Regularly pushes code and keeps the remote repository up-to-date
  • Uses a new branch for each issue and each Pull Request; Never reuses a branch
  • App has passing CI and is deployed successfully after almost every PR is merged, with few exceptions (misses no more than twice)
• Approaching Expectations:
  • Uses Pull Request templates and at least two PRs include specific questions/asks of the code reviewer
  • Provides constructive and actionable feedback on at least 2 pull requests
  • Creates focused, small pull requests that are easy to review, but up to two may be larger than expected
  • Commit messages are usually clear and always professional, but don’t always follow a consistent convention
  • Uses a new branch for each issue and each Pull Request but may accidentally reuse a branch once or twice
  • App usually has passing CI and is usually deployed successfully after a PR is merged, with some exceptions (misses no more than 3 times)
• Below Expectations:
  • Uses PR templates but fewer than two PRs include specific questions/asks of the code reviewer
  • Provides constructive and actionable feedback on 1 or fewer pull requests
  • Commit messages are often unclear, sometimes unprofessional, and don’t always follow a consistent convention
  • Creates focused, small pull requests that are easy to review, but more than two may be larger than expected
  • Inconsistently pushes code or pushes directly to main
  • Regularly reuses a branch or includes multiple issues in a single branch and PR
  • App has passing CI less than half the time and is not always deployed successfully after a PR is merged (misses more than 3 times)