Notice/Advisory: I am not an accountant nor a day trader. The following is not advice, only notes I've taken for myself. Content may be wrong or inaccurate. Use at your own risk.

The following is a list of items and things to think about if you would like to be a day trader. I wrote it with the intent of identifying what were the requirements to be a day trader and what would be the impacts of being considered as one vs being an investor.

• Basics
  • Computer or phone
  • Internet
  • Broker
  • Money
• Do not do day trading in your TFSA/RRSP/RESP accounts
• Your gains/losses will either be categorized as capital gains (50% taxable) or business income (100% taxable) based on how you trade. In any case, since this is a day trading article, you can assume this will be business income. Here are some properties taken into account
  • Volume and frequency of trading
  • Length of ownership of securities
  • Type of securities owned
  • Your profession and level of stock market knowledge
  • If trading is your main source of income or substantially supplements it
    • Here it is not clear what substantially represents. I would estimate that anything below 25% of your non-trading income isn't substantial.
• If you want to day trade, you will want to have access to level 2 data, which costs money depending on your broker
  • Some brokers will reimburse your data package fees if you spend a certain amount of money on commissions each month. For example, Questrade data package will cost you 90$/month, but if you spend over 400$ on commissions this fee will be rebated.
• You do not need to register with the government or any agency
• You do not need a minimal amount of money, although it is suggested to have a few thousands dollars otherwise you will not make a lot of profit daily and your commissions fees are likely to eat any profit you will make
  • Some brokers have minimum account balance
• You have a trading strategy
• Track your transactions
  • Time of entry/exit
  • Cost at entry/exit
  • Symbol/Ticker

References

• https://investingbasics.ca/guides/day-trading/#2--how-to-start-day-trading-
• https://www.wealthsimple.com/en-ca/learn/how-to-start-day-trading

• Decide what habit you want to have and record why you want this habit
• Start with the smallest amount of effort possible
• Increase the amount of effort regularly until you reach the desired amount of regular effort
• Track your habit in a habit recording system such as Loop Habit Tracker
• Review on a regular basis (monthly) whether you want to keep this habit or not
  • If you decide not to keep the habit, record why you decided to drop the habit such that if you decide to pick it up again, you can determine whether you might end up dropping it again.
• It's not a problem if you miss doing your habit, just make sure to do it when you're supposed to

My habits

Daily

• Daily planning
• Daily review
• Eat/Drink
• Shower
• Wash dishes
• Cook
• Exercise
• Read
• Watch TV shows
• Floss
• Brush teeth

Weekly

• Weekly planning
• Weekly review
• Wash clothes
• Clean apartment
• Buy groceries

Monthly

• Monthly planning
• Monthly review
• Pay bills

Yearly

• Yearly planning
• Yearly review

My prompts

• Daily planning at 10 am
• Weekly planning on Mondays
• Monthly planning on the first of the month
• Pay credit card on the first of the month

My prompt sources

• Google Keep
• Google Calendar
• Google Mail
• Slack
• Daylio
• Notion

• List all the features you would like to develop
• Define an appetite for the task (day, week, month, quarter)
• Identify the features where the appetite differs between individuals and discuss them to reach consensus
• Define the roles necessary to complete the task
• Identify dependencies between features
• Categorize the dependencies
  • Soft: somewhat depends on this other feature but isn't blocked by its absence from the codebase
  • Hard: depends on this other feature and is blocked by its absence from the codebase
• Prioritize the features
  • Use the RICE framework
  • Priority can also be skipped if using ROI as prioritization metric
• Estimate the value of a features in dollars
• Calculate a ROI (return on investment) as the estimated value of the feature divided by the defined appetite
• Order tasks according to dependencies and ROI

• Start the longest tests first. If you have for example 2 tests, a short one and a long one, the long one will be the sequential bottleneck. If you have many additional short tests, they will run in parallel to the longer one. If you have 2 workers, 1 will be dedicated to the long task while the other will process many of the short tests. If the total execution time of the short tasks is greater than the longer task then the total execution time will be at least the duration of the long task.
  • If we were not to schedule the longest tests first, we run the risk of running many short tests on a worker and then running the longest test, which may be suboptimal.
  • As you accumulate many short tests this issue is mitigated. However you have to be careful of distributing your longest tasks on separate workers as much as possible.
• If you know the exact duration of a test (or an approximation of it, given a desired quantum), determine if you can solve the scheduling problem in a reasonable amount of time such that solving the scheduling and running the scheduled tests takes less time than running the tests.
• From the standpoint of execution, we will prefer to have the best response time possible (i.e., run the shortest tasks first to get most of the tests executed as soon as possible).
• As you have many short and long tests, it may make sense to run all the short tests first and keep all the long tests for the end, ignoring the heuristics that suggests running the longest tests first.
• Other important consideration when running tests are shared environments/resources between tests. If those take a non-neglectable amount of time to setup/teardown and could be reused, it may be beneficial to group such tests on the same worker in order to avoid paying the cost of setup/teardown.
  • Setup/teardown duration should be recorded and be associated to each test.
  • Some system have different types of setup/teardown: global, per class/module/scope. Being able to be aware of whether the test system will need to re-run a set of setup/teardown functions may help with scheduling the tests.
• While we may be collecting test duration data, it is important to be aware that this data may end up being tainted if used in a continuous integration system. What this means is that we may sometimes record durations that are out of the ordinary due to a bug in the code, or because the tests execute on different hardware.
  • To mitigate this issue we may use different approaches such as using the median of the recorded values (which is more robust to outliers than the mean), use a percentile (such as 95%) to determine the expected duration, record the duration of successful tests separately from failed ones, record tests in separate buckets defined by the user (e.g., defined on the CPU spec used to run the test), etc.
• If the number/list of tests hasn't changed since the last run, it would also be beneficial to store the computed schedule so that it is only computed once and reused many times, which is a common use case. The only time you may not want to do this is if computing the schedule is very cheap and represent a neglectable amount of time in the overall testing process.

Example use case - pytest-xdist

• By default pytest does not store any prior test duration so we would have to estimate that all tests are of equal duration.
  • As we run tests, we may start to collect information about the duration of parameterized tests. This may serve us to determine whether the parameterized test has the same duration over different set of parameters and serve as a base to start providing estimates for the remaining parameters combination of this test.
  • A system similar to the cache provided by pytest may be used to record the duration of tests

Concepts

• Scheduler: responsible for taking a set of tests with meta data and scheduling them (i.e., determine in which order they will be executed).
• test: the unit of code to execute.
• test duration: the duration of a test. Test duration may be represented as a distribution since tests generally do not complete in an exact and fixed amount of time.
• test unit: a collection of tests that we can assume as being the same test (e.g., parameterized tests).

References

• https://en.wikipedia.org/wiki/Scheduling_(computing)
• https://en.wikipedia.org/wiki/Queueing_theory
• https://en.wikipedia.org/wiki/Queuing_Rule_of_Thumb
• https://docs.pytest.org/en/latest/cache.html

• Do you understand what is at stake?
• Do you know what already exists?
• Can you take an informed decision?
• What did you consider during your decision?
• What are your unknowns (things you'd need to know before your can make a decision)?

• Do you have experience with the problem which needs a decision?

• Indicate who has the most expertise to make the decision.

• You should be allowed to cast a vote if the decision will impact you. If it doesn't (i.e., you're not a stakeholder), your vote will not be counted towards any option.