Skip to main content

TPM & Development Portfolio

Given there have been many questions about what is allowed for a developer portfolio, here is a description of the different types of assignments allowed for a portfolio. Note that these descriptions assume people are 3 credits, and 1 credit should see the 1 credit rubric.

Developer#

Portfolios must include some indication of what work you have done (see below).

Requirements Please include two sections: one section for all PRs that you have made and all PRs that you have reviewed since the last portfolio due date.

Each portfolio must include at least one link to a PR you've made since the last portfolio. Such PRs must be published (in review, approved, or merged). You don't have to describe the PR in the portfolio, but make sure PR descriptions are detailed, as they should be!

Each portfolio must ALSO include at least one link to a PR you've reviewed since the last portfolio. The review made must be more than a "LGTM". If it truly is all good (which is unlikely, if nothing else there are almost always nits to catch), then mention things you were impressed that they did!

To summarize: the work submitted in every portfolio, in general, includes at least a link to a PR you've made and at least a link to a PR you've given a non-trivial review. That's it. We expect most devs to follow this format.

In exceptional circumstances where this simple PR/review link submission doesn't apply, there are other options for the dev portfolio detailed below.

Link to Personal Repository#

A link to a personal repository should be used for three reasons:

  • You are new to the team or have recently switched subteams and you spent the sprint learning the tech stack
  • Your subteam just pivoted tech stacks (or even projects) and you have been picking up the new technical stack
  • You created a demo to test a model you have been developing, and you and your TPM did not want this to appear on the team's repository.

With the link, in the README, you should describe

  1. What this repository is (vue tutorial? Firebase tutorial?) and specifically what it does.
    • So a bad readme would just say "this is a vue tutorial" while a good readme would say "this is a vue tutorial. In the tutorial, I create a website that lists recipes and sorts them by ingredients needed."
    • Additionally, screenshots of your work is greatly appreciated if possible
  2. Why you are doing this tutorial (2-3 sentences will suffice)

To do this, the dev leads need to be contacted before the portfolio deadline. Note that if you reach out too late, we may not be able to respond before the deadline, so make sure you reach out early! We will then reach out to your TPM to ensure the personal repository aligns with the work you have been doing this sprint.

Note that this alternative only replaces the PR link requirement - a PR review is still required.

Design Document#

This should only be used for the cases where you have a large-scale task that needs to be completed and you need to research it before completion. Some potential use case examples are:

  1. You are on Flux and you want to create an improved algorithm to estimate wait time. Before you start coding, you do some research on a better model
  2. You are on CoursePlan and you are redesigning the requirements algorithm.
  3. You are refactoring the backend to work better with a new, major specification about your product while also not breaking the current codebase. You are thinking about ways to do this before implementing it.

This is not the same as the developer assignment! The portfolio should be focused on the research conducted while the developer assignment is more focused on how you will implement it.

To do this, you must include a link to a Google Document (it must be a sharable link or be shared with the developer leads) with the following information:

  1. What are you researching?
  2. Why is it relevant to your subteam work?
  3. Write out your research! Bullets or paragraphs are acceptable
  4. Include either a link to GitHub issue(s) about the tasks you need to implement based on what you researched or a screenshot of a Monday.com/trello/Asana/Jira board with the task(s) that will be doing based on your research

Note that we will expect your future portfolios to resolve the GitHub issue(s) or task(s) you listed in the Google Document. If you do this in the second half of the semester, then we will look for this in the following semester.

Commit#

This case should rarely, if ever come into play. A GitHub commit is allowed if a task you were given is too difficult to be done in a two week sprint AND does not split into multiple PRs well.

  • This would mainly be cases where you tried to implement it doing x, that didn't work for reason y, so you had to try again.

Both you and your TPM should communicate with us if such a situation arises. In the text box with the link, you also need to write an explanation as to why you are submitting a commit link instead of a PR. Moreover, the commit itself needs to still be nontrivial, and a future portfolio needs to include the PR that contains this commit

Other Role Portfolio#

Like the commit, this case should rarely, if ever come into play. If your team needs you to temporarily take on a different role's work (design, business, PM, TPM) for up to one sprint, you can also submit a different role's portfolio as your dev portfolio. However, there are some limitations:

  1. As soon as you realize you will be doing other role work for a majority of the sprint, you and your TPM needs to let the developer leads & the respective role's leads know, as that other role may try to move someone else to fill your team's need instead. Ideally the TPM should have let us know before you even find out about this, but do message us in case we missed something or there was miscommunication between the TPM and Dev Leads.
  2. This can only be done for one sprint. If you need to continue in that other role, then we will interview you for a half dev half X or potentially even a full transition to the new role.

TPM#

For technical project manager, you need to include 1-2 paragraphs with the following information:

  1. What did you personally do these past two weeks?
  2. What did the team do the past two weeks?

In addition, if you have created and/or reviewed pull requests, please include those links (split it by PRs you made & PRs you reviewed). There is no required minimum or maximum but please do include them when you do them.