Note that most of the process is guided by a long term investment strategy. In other words, we expect to keep the assets we purchase for as long as possible, only selling to rebalance our portfolio.

• Do not put all your eggs in one basket (stock), diversify.
• Use indexes to determine which stocks to buy.
• Start small (10% of what you want to invest in total) and do not invest everything at once, learn from your mistakes.
• Do not sell when your stock drops, as it will drop in value at some point while you're holding it
• When you start, there will be a period of time where some of your stocks value will go into the negative. Ignore it and wait a few months before deciding whether to part from it or not.
• Pick stocks with good $R^2$ score and positive slope.
  • The idea here is that we want to invest in stocks which have shown to be highly predictable in the past, while also displaying linear growth (as such, this is not a useful indicator for stocks which have explosive growth).
• Invest some percentage of the portfolio in stocks which provide regular dividends, this is to replace holding "high yield" saving accounts.
  • Opt to invest in REIT, which will offer monthly dividends as well as attractive growth in their value while you hold them.
• If you want to keep things simple for yourself, buy ETFs.
  • VFV.TO is an ETF that tracks the S&P 500 in CAD and has a low expense ratio.
• Compare your portfolio's performance against indexes.
  • If you perform more poorly than indexes over 6 months/1 year, sell the stocks you have and buy the index you compare against.

Before

• Write/prepare an agenda listing the items to be discussed
• Indicate the duration and responsible/lead of each
  • Aim for a meeting to last under an hour. If more time appears to be required, then prior work should be done in order to reduce the amount of time necessary for the meeting.
• Define the list of invitees, try to keep it short, possibly under 6 people
• Share the agenda with all the attendees
• Schedule the meeting around boundaries (beginning/end of day, before/after lunch)

During

• Present the agenda
• Designate a person that will make sure that the agenda is respected

At the end

• Determine next actions
• Define deadlines for each next action
• Assign a responsible for each next action

After the meeting

• Create tasks in a task tracking system for the next actions

Recurrent meetings

• In the case where a recurrent meeting needs to be scheduled at a different time than usual, specify in the body of the message the reason of the change.

References

• https://vadimkravcenko.com/en/how-to-run-efficient-meetings-with-engineers/

Steps to create a task

• Give it a title
• Give it at least one label
• Give it an assignee
• Decide if it's important or not
• Decide if it's urgent or not
• Estimate the effort required to accomplish the task (in hours)
• Estimate the value the task brings (in $)
• Give a rough estimate of effort (in hours)
• Give a description if necessary
• Set a deadline if possible
• Set status to Unprioritized

Statuses

• Unprioritized: New task are created as unprioritized, so as to avoid having to put them in a state immediately when creating them.
• Won't do: A task that ends up not being relevant or useful will not be acted further upon and set to "Won't do".
• Backlog: A task that is not of priority at the moment but something that would be worthwhile to do at some point in the future (although maybe never due to other priorities).
• Queue: A task with a priority that is not high enough to be done immediately but that should be done in the near future.
• Scheduled: A task that has been scheduled to be done by a specific date.
• Today: A task that is scheduled to be done today. Tasks picked from the queue are moved to today.
• In progress: Tasks that are were in progress yesterday but aren't blocked, waiting, or done are moved back to today, the queue, or the backlog.
• Blocked: A task that is blocked by something else. The task should be moved back to today when it is unblocked.
• Waiting: A task that is waiting for something to happen before it can be worked on. The task should be moved back to today when it is unblocked. The difference between a blocked task and a waiting task is that a blocked task is blocked by something that is not under your control, while a waiting task is blocked by something that is under your control.
• Done: A task that has been completed and does not require further action.

During a workday

• Go through the tasks in the Do section, then the Decide section, then Delegate

Important/Urgent

Use Eisenhower matrix to determine task importance/urgency

• Tasks that are not important/not urgent are moved to the backlog
• Tasks that are not important/urgent are delegated to someone else
• Tasks that are important/not urgent should be scheduled
• Tasks that are important/urgent should be done ASAP

Effort/Value/ROI

Using the estimated effort and estimated value of a task, you can compute the return on investment (ROI) of the task as estimated value divided by estimated effort. For example, a task you estimate is worth 100 $ and takes 2 hours to complete will have a ROI of 50 \$/h.

Use the ROI of your tasks to prioritize them. You will want to complete the tasks which are likely to have the best return on investment.

The ROI metric will also give you clues about the task you should probably not spend your time on. If you are paid 50 $/h and a task has a ROI less than 50 \$/h, then it should probably be moved to the backlog and only reconsidered if its ROI changes.

Task processing

• Unprioritized tasks should be moved to Queued, given their priority compared to already queued tasks
• You should attempt to keep the Unprioritized tasks count to 0
• A task that is Queued should have a deadline date
• Work on tasks In progress first, then take tasks from Today, then from Queued

Task management progression

If you've never done task management before, I suggest you do not start by applying all the above at once. First, start by simply recording the tasks you need to get done (title only). Once you've recorded most of the tasks you have to deal with, start giving them an important/urgent assignation. It will help you rapidly determine which tasks should be done and which ones are nice to have, but not critical, or even not really useful if you think about it. Once you are able to have this information for most of your tasks, then you should start giving them effort and value estimates. Once you've reached this point, you will have a much better grasp on the importance of your tasks, as well as their potential impact in terms of value, as well as to the amount of effort it will require from you.

Notes

• Tasks should not remain in the "in progress" state for extended periods of time. After approximately a week in that state, I would suggest re-evaluating whether this task is still in progress or should be moved back into the backlog, queue, scheduled or today state. The same should apply to the waiting and blocked states.

References

• Given that you define a return on investment (ROI) on a task, when should you stop working on a task and abandon it given its cost?
• How do you prioritize things when there are so many of them competing against one another?

Ticket content

• Summary
• Software version
• Reproducible in latest version?
• Environment details: compiler/interpreter, operating system, etc.
• Steps to reproduce
• Expected results
• Actual results
• Screen capture (if relevant)

References

• https://codingnest.com/how-to-file-a-good-bug-report/
• https://testlio.com/blog/the-ideal-bug-report/

• Verify that the build/tests pass
• Read the issue title and description
• New code
  • Understand the feature and associated requirements that are supposed to be implemented
  • Verify code implements the desired feature and that the requirements are completed
• New/Changed code
  • Check code contains tests
    • Is all the new code covered by those tests?
  • Verify the location of new/moved files
    • Are the files in the right directory?
    • Are they appropriately named?
  • Verify classes, methods, functions, parameters naming
    • Are they significant of their purpose?
    • Are they clear enough?
    • Are they respecting the naming convention?
  • Does the code respect SOLID?
  • Consider that when functions/methods signature change, code may now be backward incompatible.
    • Discuss whether this is necessary
    • Backward incompatible changes should be documented
  • In a weak typed or type hinted language, are parameters and return of functions/methods typed?
  • Are there TODOs that should be completed within this review?
  • Check code for code style issues
• Bug fix
  • Verify that the fix is applied at the right location and will not "fix the symptoms, not the cause"

When reviewing

• Provide specific and actionable feedback
• Clearly mark nitpicks and optional comments
  • Alternatively, use an approach such as RFC2219 where you indicate whether a change is a MUST, SHOULD, or MAY
  • I've used traffic light color emojis to communicate 🔴 MUST, 🟡 SHOULD, 🟢 MAY
    • Another emoji based option is gitmoji
• Assume competence
• Provide rationale or context
• Consider how comments may be interpreted
• Don't criticize the person, criticize the code
• Don't use harsh language

Reference

• https://en.wikipedia.org/wiki/SOLID
• https://medium.com/palantir/code-review-best-practices-19e02780015f
• https://phauer.com/2018/code-review-guidelines/
• https://smartbear.com/learn/code-review/guide-to-code-review-process/
• https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/
• https://nyu-cds.github.io/effective-code-reviews/03-checklist/
• https://google.github.io/eng-practices/
• https://testing.googleblog.com/2019/11/code-health-respectful-reviews-useful.html
• https://engineering.18f.gov/code-review/
• https://conventionalcomments.org/
• https://docs.gitlab.com/ee/development/code_review.html
• https://gitmoji.dev/